软件测试指南.docx
《软件测试指南.docx》由会员分享，可在线阅读，更多相关《软件测试指南.docx（20页珍藏版）》请在冰点文库上搜索。
软件测试指南
软件测试指南
更新历史
1.前言
为了指导公司集成测试、系统测试和确认测试，规范公司软件测试用例，形成统一的软件测试用例编写风格，以及正确进行测试执行特制订本指南。
该指南结合公司ISO9000和CMM软件测试的过程和技术流程，给出软件测试用例的编写等规范和指导原则，为测试用例设计、测试内容提供选择，作为制定、编写集成测试、系统、确认测试测试用例和测试执行应遵循的基本要求。
自动化测试使用工具测试的，测试用例、实施测试和编写报告使用工具完成。
2.术语表
序号
术语名
术语含义
1.
集成测试
确保经过测试的各单元组合在一起能够按设计要求协作运行、构成符合设计要求的软件，并确保增量的行为正确的测试。
2.
系统测试
在完整的条件下，特定网络系统、多机联网测试系统
3.
黑盒测试
是一种按照需求规格说明设计测试数据的测试方法。
4.
白盒测试
是一种按程序内部的逻辑结构和编码结构设计测试数据的测试方法。
5.
渐增式测试
不是独立地测试每个单元，而是首先把下个要被测试的单元同已测试的单元集合组合起来，然后再测试的一种集成测试方法。
6.
全局数据结构
主要指数据库表结构、全局变量
3.过程概述
3.1测试目的
集成测试的目的是是检验软件单元之间的接口关系，主要测试模块之间数据传输是否正确、模块集成后的功能是否实现、模块接口功能与设计需求是否一致。
系统测试的目的是为充分运行系统，验证系统各部件是否都能正常工作并完成系统设计赋予的的功能
3.2角色
开发经理实施经理测试经理测试工程师
3.3输入和输入
输入《用户需求说明书》
《软件需求规格说明书》
《系统设计说明书》（可能分为详细设计和概要设计）
输出《系统测试用例》
《系统测试报告》
《性能测试报告》
缺陷记录
4.活动说明
4.1分析测试特性
分析并确定被测试模块/功能点需要测试的测试特性，测试特性是系统测试的主要内容，测试特性分为
4.1.1可安装测试
系统可安装测试是指系统在测试环境或运行环境下安装的测试。
通常包括服务器端和客户端安装两部分。
在进行安装测试前必须检查测试环境或运行环境的配置是否与《用户需求说明书》、《软件需求规格说明书》中要求相近或一致，确认网络是否连通。
1.按照《系统安装手册》进行安装，选择自动安装还是手工配置安装，测试各种不同的安装组合，并验证各种不同组合的正确性，
最终目标是所有组合都能安装成功。
2.安装退出之后，确认应用程序可以正确启动、运行。
3.在安装之前请备份你的注册表，安装之后，察看注册表中是否有多余的垃圾信息。
4.卸载测试和安装测试同样重要，如果系统提供自动卸载工具，那么卸载之后需检验系统是
否把所有的文件全部删除，注册表中有关的注册信息是否也被删除。
5.安装完成之后，可以在简单的使用之后再执行卸载操作，有的系统在使用之后会发生变
化，变得不可卸载
6.对于客户服务器模式的应用系统，可以先安装客户端，然后安装服务器端，测试是否会出
现问题
7.考察安装该系统是否对其他的应用程序造成影响，特别是Windows操作系统，经常会出现
此类的问题。
4.1.2功能性
系统级功能测试：
功能测试考察软件对功能需求的完成情况。
1．有效数据的录入和正常业务（流程）的测试。
2．无效数据的校验。
3．异常业务的测试。
4．交叉业务与流程的测试。
5．业务周期的测试。
4.1.3人机交互性（界面测试）
1．根据需求，对所有界面进行打开校验，检验界面存在的快捷方式和链接是否可用，对菜单工具栏的关闭、最小化按钮，帮助热键等非需求规定的工具栏进行检查
2．鼠标/键盘：
是否所有操作可以键盘和鼠标互换。
光标：
当打开窗口时，光标是否停留在将要输入的编辑框中、当某个已经录入了信息的编辑框报错之后，光标是否回到此编辑框中、Tab,enter,方向键是否能移动光标且顺序是否合理，如在编辑状态，关标是否自动移向下一编辑区域。
对存在鼠标和键盘可交互操作的，必须使用用例至少进行各一次的操作
3．流程控制：
上下紧连的流程状态是否正确、违反流程操作时是否禁止，在一流程结束时是否提示下一流程操作。
4．对错误操作最好支持可逆性处理，如取消、回退等操作；
5．对可能造成较长等待时间的操作（大量数据处理）应该有等待提示；
6．在读入用户所输入的信息时，根据需要选择是否去掉前后空格。
7．屏蔽用户操作错误。
考察对用户常见的误操作的提示和屏蔽情况，例如可否有效避免日期的录入错误或写入无效的日期。
8．错误提示的准确性。
当用户操作错误或软件发生错误时，能否有准确清晰的提示，使用户知道造成错误的原因。
例如当用户未输入完有效信息时存盘，系统应当给出关于未输入项的提示；进行大数据量的处理时是否提示正在进行避免用户退出造成数据丢失。
9．输入数据有效性检查。
当用户输入的数据有错时，软件应能判断数据的有效性，避免无效数据的生成。
常见控件的测试项参考下表
控件测试项参考标准表
对象类型
控件的特殊属性
窗口
1、检查窗口中的文字是否明确易懂。
如果意思表示不明确，会直接影响软件操作员对业务流程的理解。
如：
窗口标题、操作区域是否有可见的提示如操作的流程。
2、菜单项是否能正常打开和关闭
按钮
1、是否有同样的字体类型和大小、统一对齐、布局是否合理，退出和删除按钮是否置于显著的位置
2、按钮自动隐藏和激活是否符合业务流程的操作。
按钮恰到好处的隐藏和激活能防止操作员的滥操作，减少编程控制和非法录入数据
编辑框
1、是否可以输入和编辑文本
2、是否被正确的初始化了
3、输入值是否有效
4、当某个已经录入了信息的编辑框报错之后，光标是否回到此编辑框中
5、涉及日期型、字符型、指定的类型数据是否添加校验
列表框
1、单选还是多选？
2、窗口建立时，是否所有的列表框都被正确的初始化了
3、输入值是否有效
4、如果一个非法数据被输入，用户是否可以马上得到提示
5、如果需要，是否需要水平或者垂直滚动条
组合框
1、是否可以编辑？
是否应该这样？
2、是否被正确的初始化了
3、输入值是否有效
4、如果一个非法数据被输入，用户是否可以马上得到提示
5、如果有一个很长的列表，是否已排序、是否可以通过第一个字母或前两个值得到索引和过滤
数据窗口
（PB）
1、数据的存取显示是否正确
2、查询速度是否可以接受，是否能满足用户需求
3、特别注意是否能够根据所给条件正确检索出数据库信息
选择框
1、在选择框中选择时，是否出现了不应该出现的选择项
2、同样类似的情况，系统设置区里是否存在与本系统无关的信息没有去掉。
3、系统是否根据用户习惯设置默认选项
4、在批量数据处理时是否提供全选按钮
4.1.4报表测试
1.涉及到打印操作的，要注意测试如下部分
1）网络打印是否连接正常，本地打印是否正确调用打印操作；点击打印时是否提示用户打印信息。
2）打印套表格式的，根据样表进行，需要特殊打印机，在用例中说明并至少在用户环境测试一次。
3）通过打印控件调用打印驱动的，注意安装时是否提示安装打印控件
4）测试工具栏打印按钮、窗口调用按钮和页面内按钮至少各测试一次
5）打印预览时报表头、标题栏、日期、报表宽度等项是否一致正确
2.涉及表格测试的，要注意测试如下部分
1）表格格式是否和用户提供的文件相一致
2）表格名称、列名称、调用窗口名称是否相同，避免出现歧义
3）表格中数字显示和中文数字显示是否一致
4）表格中数据是否正确
校验数据采用以下方法
a.合计金额是否正确采用尾数法校验数据，即将小数点尾数进行相加，快速检验总数尾数是否相符
b.各费用根据需求计算方法应该相互平衡
c.四舍五入与比例与需求相符
4.1.5安全可靠性
1．用户和密码封闭性。
软件对用户名和密码有无校验，有无保护措施，尤其对密码有无屏蔽功能，如用拷贝方式是否能够获取加密度不高的用户口令；检查配置文件是否包含用户密码
2．系统对用户错误登录的次数限制。
软件对用户错误登录有无次数限制，一般做法是连续三次登录失败就退出系统。
3．用户权限限制。
软件是否按功能模块划分用户权限，权限划分是否合理，考察超级用户对各个用户的权限管理是否合理，包括修改用户的登录资料等。
测试用户授予超级管理员角色并取消后是否拥有超级管理员权限，测试不同组用户角色是否能够彼此操作
4．对于Web页面，拷贝地址栏、超时链接和点击返回按钮后是否还能够进入系统；检查编辑功能、cookie、Script脚本是否能够获取用户密码
5．留痕功能。
软件是否提供操作日志，比如某用户登录的时间，查询、修改或删除的动作以及离开的时间等。
6．错误是否导致系统异常退出。
考察软件运行的稳定性，当软件发生一般错误或严重错误时，软件是否会自动退出。
7．数据备份与恢复手段。
主要针对有数据存储需要的软件，有的软件依靠数据库操作系统本身的备份与恢复机制，这需要用户具备一定的操作知识；好的软件会提供备份与恢复的操作，不需要用户直接对数据库系统进行操作。
8．异常情况的影响。
在程序运行过程中进行掉电等试验，考查数据和系统的受影响程度；若受损，是否提供补救工具，补救的情况如何。
网络故障对系统的影响。
当网络中断连接时，是否会造成数据的丢失。
4.1.6性能/压力
1．测试软件在获得定量结果时程序计算的精确性，如数据处理与计算精度、时间控制与测量精度。
2．测试系统的吞吐量（单位时间内能处理的事务数），如每秒能处理事务数。
3．测试系统在大量数据和用户下的响应时间，特别是平均、最坏响应时间。
4．测试系统在大量数据和用户下服务器的资源利用率。
4.1.7接口测试
接口测试检验软件内部、软件与系统之间接口的正确性和协调性。
外部接口
1．软件对系统每一个真实接口的正确性。
2．检查从接口接受和发送数据的能力。
3．检查数据格式、类型的符合性。
4．检查数据的约定、协议的一致性。
5．需要进行导入、导出的检查接口是否存在指定数据库表名或文件位置、默认文件类型
内部接口
1．软件单元调用关系（调用覆盖）。
2．数据项的相容性（数据项的范围、数据项的类型、数据对象的顺序、传递方式）。
3．全局数据结构测试
在集成测试阶段，接口测试采用渐增式测试策略
a.将最底层的模块和类分组，原则是将那些与其他模块和类相关联的窗口为一组。
b.对每一组分别进行测试，各组测试可并行展开，这样可以加快测试的进程。
c.沿软件的结构，逐级增加，直到所有的单元都组合到一起，这样就完成了集成测试的任务。
4.2选择测试用例设计方法
测试用例采用的测试方法主要为黑盒测试并辅助少量的白盒测试。
4.2.1白盒测试用例设计方法
.语句覆盖
.判定覆盖（分支覆盖）
.条件覆盖
.判定/条件覆盖
.条件组合覆盖
.路径覆盖
以上设计方法又成为逻辑覆盖，覆盖的强弱程度
语句覆盖<判定覆盖（分支覆盖）<条件覆盖<判定/条件覆盖<条件组合覆盖；路径覆盖为较强的覆盖，但是不能代替条件覆盖和条件组合覆盖
4.2.1.1语句覆盖
选择足够的测试用例，使得每个语句至少执行一次
4.2.1.2判定覆盖（分支覆盖）
选择足够的测试用例，使得所有可能的结果至少出现一次
4.2.1.3条件覆盖
选择足够的测试用例，使得判定中的每个条件的所有可能结果至少出现一次，但是判定表达式中的某些可能结果并未出现
4.2.1.4判定/条件覆盖
选择足够的测试用例，使得判定中的每个条件的所有可能结果至少出现一次，并且每个判定本身的所有可能结果至少出现一次
4.2.1.5条件组合覆盖
选择足够的测试用例，使得判断中每个条件的所有可能结果的组合至少出现一次
4.2.1.6路径覆盖
选择足够的测试用例，每个可能执行到的路径至少经过一次
4.2.2黑盒测试用例设计方法
·等价类划分方法
·边界值分析方法
·错误推测方法
·因果图方法
·判定表驱动分析方法（可选）
·正交实验设计方法（可选）
·功能图分析方法（可选）
4.2.2.1.等价类划分:
等价类划分是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.
1）划分等价类:
等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:
测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:
有效等价类和无效等价类.
有效等价类:
是指对于程序的软件需求规格说明书来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了软件需求规格说明书中所规定的功能和性能.
无效等价类:
与有效等价类的定义恰巧相反.
设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性.
2）划分等价类的方法:
下面给出六条确定等价类的原则.
①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.
②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.
③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.
④在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.
⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）.
⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类.
3）设计测试用例:
在确立了等价类后,可建立等价类表,列出所有划分出的等价类:
输入条件有效等价类无效等价类
.........
.........
然后从划分出的等价类中按以下三个原则设计测试用例:
①为每一个等价类规定一个唯一的编号.
②设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.
③设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.
4.2.2.2.边界值分析法
边界值分析方法是对等价类划分方法的补充.
（1）边界值分析方法的考虑:
长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
（2）基于边界值分析方法选择测试用例的原则:
1）如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据.
2）如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少1,比最大个数多1的数作为测试数据.
3）根据软件需求规格说明书的每个输出条件,使用前面的原则1）.
4）根据软件需求规格说明书的每个输出条件,应用前面的原则2）.
5）如果程序的需求规格说明书给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例.
6）如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例.
7）分析软件需求规格说明书,找出其它可能的边界条件.
3.错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法.
错误推测方法的基本思想:
列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例.例如,在单元测试时曾列出的许多在模块中常见的错误.以前产品测试中曾经发现的错误等,这些就是经验的总结.还有,输入数据和输出数据为0的情况.输入表格为空格或输入表格只有一行.这些都是容易发生错误的情况.可选择这些情况下的例子作为测试用例.
4.2.2.3因果图方法
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系,相互组合等.考虑输入条件之间的相互组合,可能会产生一些新的情况.但要检查输入条件的组合不是一件容易的事情,即使把所有输入条件划分成等价类,他们之间的组合情况也相当多.因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例.这就需要利用因果图（逻辑模型）.
因果图方法最终生成的就是判定表.它适合于检查程序输入条件的各种组合情况.
利用因果图生成测试用例的基本步骤:
（1）分析软件需求规格说明书描述中,那些是原因（即输入条件或输入条件的等价类）,那些是结果（即输出条件）,并给每个原因和结果赋予一个标识符.
（2）分析软件需求规格说明书描述中的语义.找出原因与结果之间,原因与原因之间对应的关系.根据这些关系,画出因果图.
（3）由于语法或环境限制,有些原因与原因之间,原因与结果之间的组合情况不不可能出现.为表明这些特殊情况,在因果图上用一些记号表明约束或限制条件.
（4）把因果图转换为判定表.
（5）把判定表的每一列拿出来作为依据,设计测试用例.
从因果图生成的测试用例（局部,组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加.
4.2.2.4判定表驱动分析方法
前面因果图方法中已经用到了判定表.判定表（DecisionTable）是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确.
判定表通常由四个部分组成.
条件桩（ConditionStub）:
列出了问题得所有条件.通常认为列出得条件的次序无关紧要.
动作桩（ActionStub）:
列出了问题规定可能采取的操作.这些操作的排列顺序没有约束.
条件项（ConditionEntry）:
列出针对它左列条件的取值.在所有可能情况下的真假值.
动作项（ActionEntry）:
列出在条件项的各种取值情况下应该采取的动作.
规则:
任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则.显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列.
判定表的建立步骤:
（根据软件需求规格说明书）
①确定规则的个数.假如有n个条件.每个条件有两个取值（0,1）,故有种规则.
②列出所有的条件桩和动作桩.
③填入条件项.
④填入动作项.等到初始判定表.
⑤简化.合并相似规则（相同动作）.
B.Beizer指出了适合使用判定表设计测试用例的条件:
①软件需求规格说明书以判定表形式给出,或很容易转换成判定表.
②条件的排列顺序不会也不影响执行哪些操作.
③规则的排列顺序不会也不影响执行哪些操作.
④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则.
⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧
4.2.2.5.功能图分析法
通过形式化地表示程序的功能说明，并机械地生成功能图的测试用例。
4.3编写测试用例
4.3.1测试用例基本要求
1．系统测试用例遵循典型、完整、充分性编写
典型必须将系统中最具代表性的业务流程整理出来，形成测试用例
完整必须全面的覆盖需求并一一对应，不能遗漏
充分必须有足够的用例以验证整个系统
2．必要情况下必须包含正常和异常业务处理的测试用例
对涉及到可测试的分支业务以及可能存在错误数据的需求每个功能点或者UC，除了要有对正常业务流程和合法数据进行验证的测试用例外，还要给出对非正常业务流程和错误数据进行验证的测试用例。
即正常输入\路径的（正常的业务处理）测试用例和异常输入\路径的（异常的业务处理）测试用例必须同时存在，以保证测试的有效性。
一个测试用例代表预期的条件，它可用于核实行为是否正确或符合预期（正面测试）。
另一个测试用例代表不可接受的、异常的或意外的条件，它可用于核实测试需求是否未以非预期方式执行（负面测试）。
在一般情况下，对于测试的每个需求来说，至少要有一个正面测试用例和为数较多的负面测试用例。
3．测试用例由以下几部分构成
1）根据特定步骤输入有效的数据时，产生预期的结果
2）根据一定步骤输入无效的数据时，产生预期的错误信息/提示信息
4．测试用例要包含测试数据、测试脚本和业务用例
完整的测试用例一般由这三部分组成，如测试数据和脚本不是必须的，则测试用例不能使用模糊的描述语言指导测试，必须清楚的阐述测试使用何种数据以及数据生成办法，描述如何测试以及测试预期结果。
4.3.2测试用例编写规范
a.业务用例
根据需求或者用例规约，对业务办理和业务流程编写业务用例，编写规范如下:
1）必须按照需求逻辑对业务用例进行步骤说明
根据需求办理业务次序分步描述，例如第一步，第二步…或者使用数字标识，尽量不使用逗号分割的长句。
2）不同的业务用例必须分开进行描述
一个业务用例实现对系统的一个操作，不允许在一个用例内出现两次不同操作，即涉及业务不同入口或者出口的，使用两个用例实现。
例如对人员进行审核，审核成功一个结果，审核不成功另一个结果，那么，设计两个用例分别描述，尽量不要使用一句话去说完。
3）业务用例尽量使用逻辑性描述，不能出现歧义和误解，增加用例可读性
b.测试数据
测试用例一般涉及测试数据的使用，测试数据指测试过程中使用到的具体数据，包括人员姓名、组织结构、数字、货币、日期、字符等，测试用例不包含测试数据的、必须注明测试数据的生成办法、数据类型或者输入约定，测试数据编写规范如下
1）测试数据唯一性
测试数据必须是唯一的，保证在测试用例中测试数据输入与确定测试数据输出相对应
2）测试数据一致性
在整个测试表中保持测试数据完整的生命周期，从数据调用到调用结束必须保持严格一致。
在周期内保证测试数据不被其他额外用例调用影响测试结果正确性和测试完整性。
3）测试数据的可用性
根据测试用例设计方法对测试数据进行设计，保证测试数据能够充分暴露系统缺陷，不要使用随意或者假定的固定测试数据进行用例编写。
c.测试脚本
测试用例如果涉及到后台数据生成、接口、过程调用、自动化工具使用时，往往使用测试脚本实现，测试脚本指利用编程语言编写的测试驱动程序，使用测试脚本时遵循以下编写规范。
1）测试脚本命名规则
使用如下约定
项目名称拼音字母首位缩写＋模块名
同一模块需要不同脚本的，对名称后使用自然序数，并在用例中说明
2）测试脚本调用规则
在测试用例中调用测试脚本，必须说明调用的脚本名，调用的规则和调
升级会员 