G2401测试管理指南.docx
《G2401测试管理指南.docx》由会员分享，可在线阅读，更多相关《G2401测试管理指南.docx（33页珍藏版）》请在冰点文库上搜索。
G2401测试管理指南
测试管理指南
文件状态：
[]草稿
[√]正式发布
[]正在修改
文件编号：
G2401测试管理指南
当前版本：
1.0
作者：
修订者:
审核者:
批准者:
发布日期：
2013-10-28
密级：
[]绝密[√]普通[]部门公开[]外部公开
修订记录
类别：
A–增加M–修改D–删除
日期
版本号
类别
描述
作者
2013-9-30
V0.1
A
建立初稿
2013-10-4
V0.9
M
修订活动及流程内容
增加度量
公司内部评审
按CMMI-DEV,Version1.3修改
2013-10-28
V1.0
M
发布V1.0正式版
1.
目的
设计富有创造性的测试用例是测试设计的关键，本指南文件的制定，旨在指导测试用例编写人员开展测试用例设计活动，确保设计出富有创造性的测试用例，以指导测试的实施，并充分保障所测试系统的质量。
2.范围
本指南适用于测试人员开展测试用例设计活动。
本指南是一份指导性文档，在没有正当理由的情况下，应严格按本指南的要求执行。
3.参考文件
描述本文件所参考的相关文件。
（通常包括相关的设计、需求文档等）
4.测试用例开发概述
4.1.用例开发目的
●保障软件测试质量的稳定，减少客观因素的影响
●指导测试工作，保障测试质量
●指导测试的实施
●规划测试数据的准备
●分析缺陷的标准
●评估测试结果的度量基准
4.2.设计原则
a）测试用例的代表性：
能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等；
b）测试结果的可判定性：
即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果；
c）测试结果的可再现性：
即对同样的测试用例，系统的执行结果应当是相同的。
5.系统测试用例设计及方法
5.1.用例基本格式
测试用例编号
测试项目
测试标题
重要级别
预置条件
输入
操作步骤
预期输出
以上是一般的测试用例格式，可以根据项目具体要求删除一些或加入其它项。
5.2.必要元素描述
Ø测试用例编号
测试用例编号是由字母和数字组合而成的，用例的编号应该具有唯一性，易识别性。
比如可以采用统一的约定，产品编号—ST—系统测试项名—系统测试子项名—序号。
这样看到编号就可以知道是做的什么测试，测试的对象是什么。
也方便维护。
Ø测试项目
你现在这个测试用例所测的项目名，可以是测试用例所属的大类，被测需求，被测的模块，或者是被测的单元。
例如：
计算器加法功能。
Ø测试标题
测试标题是对测试用例的简单描述。
用概括的语言描述该测试用例的测试点。
每个测试用例的标题不能够重复，因为每个测试用例的测试点是不一样的。
例如：
手机在没有SIM卡的情况下，拨打119。
Ø重要级别
重要级别分为高中低三等：
高：
保证系统基本功能、重要特性、实际使用频率比较高的用例；
中：
重要程度介于高和底之间的测试用例；
低：
实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例。
注：
一般情况下，重要级别为高的测试用例，一个测试子项里有且仅有一个，大多数都是重要级别为中的测试用例。
因为一般我们会进行一个系统测试预测试，如果重要级别为高的太多，则就失去了预测试的实际意义。
Ø预置条件
就是执行当前测试用例的前提条件，如果不满足这些条件，则无法进行测试。
Ø输入
测试用例执行时，需要输入的外部信息。
例如某一个文件，数据记录等。
Ø操作步骤
执行当前测试所要经过的操作步骤，需要给出每一步操作的描述，测试人员根据测试用例操作步骤，完成测试用例的执行。
Ø预期输出
当前测试用例的预期输出结果。
用来与实际结果比较，如果相同则该测试用例通过，否则该测试用例失败。
5.3.用例编制
5.3.1.测试用例文档
编写测试用例文档应有文档模板，须符合内部的规范要求。
测试用例文档将受制于测试用例管理软件的约束。
软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。
测试用例文档由简介和测试用例两部分组成。
简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。
测试用例部分逐一列示各测试用例。
每个具体测试用例都将包括下列详细信息：
用例编号、测试项目、测试标题、重要级别、预置条件、输入、操作步骤、预期输出等。
以上内容涵盖了测试用例的基本元素：
测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。
5.3.2.测试用例的设置
早期的测试用例是按功能设置用例。
后来引进了路径分析法，按路径设置用例。
目前演变为按功能、路径混合模式设置用例。
按功能测试是最简捷的，按用例规约遍历测试每一功能。
对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。
没有严密的逻辑分析，产生遗漏是在所难免。
路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。
但路径分析法也有局限性。
在一个非常简单字典维护模块就存在十余条路径。
一个复杂的模块会有几十到上百条路径是不足为奇的。
若一个子系统有十余个或更多的模块，这些模块相互有关联。
再采用路径分析法，其路径数量成几何级增长，达5位数或更多，就无法使用了。
那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。
这是按功能、路径混合模式设置用例的由来。
5.3.3.设计测试用例
测试用例可以分为基本事件、备选事件和异常事件。
设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。
而对孤立的功能则直接按功能设计测试用例。
基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。
设计备选事件和异常事件的用例，则要复杂和困难得多。
例如，字典的代码是唯一的，不允许重复。
测试需要验证：
字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。
往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。
而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。
软件测试常用的基本方法将在下面详细介绍。
5.3.4.测试用例的评审
测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。
测试用例在设计编制过程中要组织同级互查。
完成编制后应组织专家评审，需获得通过才可以使用。
评审委员会可由项目负责人、测试等有关人员组成，也可邀请客户代表参加。
评审的流程请参见《评审程序》文件。
5.3.5.测试用例的修改与更新
测试用例在形成文档后也还需要不断完善。
主要来自三方面的缘故：
Ø在测试过程中发现设计测试用例时考虑不周，需要完善；
Ø在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；
Ø软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。
一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。
软件的版本升级更新，测试用例一般也应随之编制升级更新版本。
5.3.6.测试用例的管理
通常由配置管理员将已经评审通过的用例进行统一受控管理。
在条件允许的前提下，可以引用相关的软件辅助管理。
运用测试用例还需配备测试用例管理软件。
它的主要功能有三个：
Ø第一、能将测试用例文档的关键内容，如编号、名称等等自动导入管理数据库，形成与测试用例文档完全对应的记录；
Ø第二、可供测试实施时及时输入测试情况；
Ø第三、最终实现自动生成测试结果文档，包含各测试度量值，测试覆盖表和测试通过或不通过的测试用例清单列表。
5.4.用例设计方法
5.4.1.等价类划分法
等价类：
某个输入域的集合，在这个集合中每个输入条件都是等效的，如果其中一个的输入不能导致问题发生，那么集合中其它输入条件进行测试也不可能发现错误。
等价类分为有效等价类和无效等价类，有效等价类就是由那些对程序的规格说明有意义的、合理的输入数据所构成的集合；无效等价类就是那些对程序的规格说明不合理的或无意义的输入数据所构成的集合。
划分等价类的方法：
下面给出六条确定等价类的原则。
a）在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类；
b）在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类；
c）在输入条件是一个布尔量的情况下，可确定一个有效等价类；
d）在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类；
e）在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）；
f）在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。
根据等价类划分原则，将等价类填入下表。
等价类表
输入条件
有效等价类
无效等价类
根据等价类表，然后从划分出的等价类中按以下三个原则设计测试用例：
1、为每一个等价类规定一个唯一的编号。
2、设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止。
3、设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。
5.4.2.边界值分析法
测试过程中，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。
因此针对边界情况设计测试用例，可以查处更多的错误。
下边界点的定义：
边界点分为上点、内点和离点。
上点，就是边界上的点，不管它是开区间还是闭区间，就是说，如果该点是封闭的，那上点就在域范围内，如果该点是开放的，那上点就在域范围外；
内点，就是在域范围内的任意一个点；
离点，就是离上点最近的一个点，如果边界是封闭的，那离点就是域范围外离上点最近的点，如果边界是开放的，那离点就是域范围内离上点最近的点。
边界值分析方法的原则：
1、如果输入（输出）条件规定了取值范围，则应该以该范围的边界值及边界附近的值作为测试数据；
2、如果输入（输出）条件规定了值的个数，则用最大个数，最小个数，比最小个数少1，比最大个数多1的数作为测试数据；
3、如果程序规格说明书中提到的输入或输出是一个有序的集合，应该注意选取有序集合的第一个和最后一个元素作为测试数据；
如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试数据。
5.4.3.判定表法
判定表通常由四部分组成，如图：
Ø每一个部分之间用双线或粗条线分开，左上部称条件桩，它列出决定一组条件的对象；
Ø右上部称条件项，它列出各种可能的条件组合；
Ø左下部称动作桩，它列出所有的操作，右下部为动作项，它列出在对应的条件组合下的动作。
判定表法经常和因果图法一起用，先进行因果图分析，再结合判定表。
5.4.4.因果图法
因果图法就是从程序规格说明书的描述中找出因（输入条件）和果（输出或程序状态的改变），通过因果图转换为判定表，最后为判定表中的每一列设计一个测试用例。
在多个条件决定多个动作，并且每个条件的取值只有两种情况下，我们就可以采用因果图和判定表方法。
使用因果图法的步骤：
1、根据程序规格说明书描述的语义内容，分析并确定“因”和“果”，将其表示成连接各个原因与各个结果的“因果图”。
需要注意的是，由于语法或环境的限制，某些原因和结果的组合情况是不可能出现的。
为表明这些特定的情况，需要在因果图上使用若干个约束符号来标明约束条件；
2、将得到的因果图转换成判定表；
3、为判定表中每一列所表示的情况设计一个测试用例。
5.4.5.状态迁移图法
许多需求用状态机的方式来描述，状态机的测试主要关注在测试状态转移的正确性上面。
对于一个有限状态机，通过测试验证其在给定的条件内是否能够产生需要的状态变化，有没有不可达的状态和非法的状态，可能不可能产生非法的状态转移等。
构造能导致状态迁移的事件，来测试状态之间的转换。
状态迁移图的步骤：
1、画出状态迁移图；
2、列出状态——事件表；
3、得到状态转换树；
4、推出测试路径；
5、根据测试路径编写测试用例。
5.4.6.流程分析法
流程分析法是将软件系统的某个流程看成路径，用路径分析的方法来设计测试用例。
根据流程的顺序依次进行组合，使得流程的各个分支都能走到。
注：
用例设计完后，对照流程图分析是否有遗漏的路径没有覆盖到。
如果有，设计用例覆盖这些路径。
5.4.7.正交试验法
正交试验法，是一种成对测试交互的系统的统计方法。
它提供了一种能对所有变量对的组合进行典型覆盖（均匀分布）的方法。
可以从大量的试验点中挑出适量的、有代表性的点，利用“正交表”，合理的安排试验的一种科学的试验设计方法。
指标：
通常把判断试验结果优劣的标准叫做试验的指标；
因子：
所有影响试验指标的条件；
因子的状态：
影响试验因子的，叫做因子的状态。
因子1
因子2
…
因子n
状态1
状态2
…
状态m
5.4.8.错误推测法
错误推测法：
基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例方法。
错误推测方法的基本思想：
列举出程序中所有可能有的错误和容易发生错误的特殊情况,，根据他们选择测试用例。
例如，在单元测试时曾列出的许多在模块中常见的错误。
以前产品测试中曾经发现的错误等，这些就是经验的总结。
还有，输入数据和输出数据为0的情况。
输入表格为空格或输入表格只有一行。
这些都是容易发生错误的情况。
可选择这些情况下的例子作为测试用例。
6.保证测试用例功能覆盖100%的方法
6.1.常用软件测试覆盖率计算公式
常用的软件测试覆盖率计算公式有如下几种：
1.功能覆盖率=至少被执行一次的测试功能点数/测试功能点总数（功能点）
2.需求覆盖率=被验证到的需求数量/总的需求数量（需求）
3.覆盖率=至少被执行一次的测试用例数/应执行的测试用例总数（测试用例）
4.语句覆盖率=至少被执行一次的语句数量/有效的程序代码行数
5.判定覆盖率=判定结果被评价的次数/判定结果总数
6.条件覆盖率= 条件操作数值至少被评价一次的数量/条件操作数值的总数
7.判定条件覆盖率=条件操作数值或判定结果至少被评价一次的数量/（条件操作数值总数+判定结果总数）
8.上下文判定覆盖率=上下文内已执行的判定分支数和/（上下文数*上下文内的判定分支总数）
9.基于状态的上下文入口覆盖率=累加每个状态内执行到的方法数/（状态数*类内方法总数）
10.分支条件组合覆盖率=被评测到的分支条件组合数/分支条件组合数
11.路径覆盖率= 至少被执行一次的路径数/程序总路径数
测试覆盖度的评估依赖于不同的测试阶段或不同的测试方法。
如在单元测试中，测试覆盖率是建立在被测试的代码行、程序分支和程序路径等的度量之上，其覆盖率要达到80％之上。
6.2.功能覆盖率100%的方法介绍
功能的覆盖以需求为依据，通过建立需求与测试用例的对应关系，确保一个功能点至少对应一条测试用例。
6.2.1.需求与测试用例的对应关系
最高层的是涉众需求。
通常，一个项目包含五到十五个这样的高层需求。
较低层次的是特性，用例和补充规约。
不同层次的需求有不同的细节。
越低的层次需要越多的细节。
需求与测试用例的对应关系可用下图表示：
用例描述了功能性的需求，补充规约描述了非功能性的项目。
另外，每个用例映射到许多场景。
映射用例到场景，是一对多的关系。
场景映射到测试用例也是多对一的关系。
另一方面，在需要与特性之间，是多对多的映射。
6.2.2.示例需求简述
下面使用一个在线书店作为项目的一个例子。
下图展示了这个项目的用例图。
用例的通用格式是：
1.简要描述
2.事件流
o基本流程：
基本流程包括最通常的一系列行为，此步骤发生在每件事正确运转的时候。
o可选流程1：
可选流程表现了流程的变更，包括不很普遍的情况和错误条件。
o可选流程2
3.特殊需求
4.前提条件
5.后置条件
6.扩展点
7.环境图：
环境图是用例图的一部分，向参与者和其它用例显示了特殊用例之间的关联。
8.活动图：
活动图是一个解释用例的流程图。
环境图和活动图不是必须的，但是可以帮助你可视化用例和它在项目中的位置。
在我们的在线书店项目中，用例的基本流程的安置顺序也许像这样：
1.B1用户在浏览器输入网站的地址。
系统显示登陆界面。
2.B2用户输入电子邮件地址和密码。
系统确认正确的登陆，显示主页，并且提示输入搜索字符串
3.B3用户输入搜索字符串—书名的一部分。
系统返回与搜索标准匹配的全部书籍。
4.B4用户选择一本书。
系统显示这本书的详细信息。
5.B5用户把这本书放在购物车中。
购物车中的货物显示给用户
6.B6用户选择"进入到结帐"选项。
系统索要送货地址。
7.B7用户确认送货地址。
系统显示送货选项。
8.B8用户选择送货选项。
系统询问使用哪种信用卡。
9.B9用户确认储存在系统中的信用卡。
系统请求最终确认此次订购。
10.B10用户订购。
系统返回确认数量。
除了基本流程外，还有许多可选流程。
例如，第一个可选流程描述了当用户是一个新的用户时所发生的事情（不是在线书店的已注册用户）。
在基本流程中，用户经常拥有一个用户ID和密码。
相反，可选流程1描述了当第一次用户需要注册并提供顾客数据时的情况。
可选流程的另一个例子是无效的密码。
用户输入了错误的密码，系统显示错误信息。
表1显示了"安置顺序"用例中的可选流程：
表1:
可选流程
A1
未注册用户
A2
无效密码
A3
没有找到匹配搜索标准的书
A4
下架书籍
A5
在购物车中放入一本书后继续购物
A6
输入新的地址
A7
输入新的信用卡
A8
取消订单
下列约定用于为事件流命名：
基本流程：
B
可选流程：
A1，A2，A3，...
在基本流程中的步骤：
B1，B2，B3，...
在可选流程1中的步骤：
A1.1，A1.2，A1.3，...
在可选流程2中的步骤：
A2.1，A2.2，A2.3，...
为得到可选流程，使用活动图5。
图5显示了描述用例的活动图。
图1.活动图
基本流程是一条向下的直线，然而可选流程可以是向前或向后的循环线。
6.2.3.如何从需求（用例）创建测试用例
在创建一个测试用例之前，需要为所给用例确定全部的场景。
一个场景是用例的一个实例。
它描述了一个贯穿事件流的特殊路径。
图6是一个假设的图表，它描绘了一个拥有基本流程B和可选流程A1，A2，A3，A4的用例。
为了找到全部的场景，需要画出贯穿于此图的所有场景。
图2.在用例中找到场景
每一个可选流程都有一个场景，并且每个结合的可选流程都有一个场景。
显然，这里场景多于可选流程，因为一个场景用于A1,另一个场景用于A2，还有一个场景用于这两个的结合。
描述场景最简单的方法是提供一系列的可选流程，例如，做两遍流程A2，然后做一遍流程A6：
SC16：
A2，A2，A6。
另一种描述场景的方法是列出它的所有步骤，但是这种方法既困难又未必详细。
如果陷了无限循环（向后循环），这时该怎么办？
理论上它将产生无限的场景。
图3显示了一个无限循环。
图3.无限循环。
6.2.4.如何选定值得测试的用例
最合理的方法是做一遍基本流程，一遍循环流程，然后再做一遍循环流程。
如果程序能为这两个循环都工作的话，便假设它能为所有的循环工作。
书籍订阅的例子中包含了一个基本流程和8个可选流程。
它们中的4个向前走，另外4个向后走。
如果你想描述全部可能的用例结合，你将有超过4000个场景（这里有8个可选流程，我们想让其中4个做两次，因为他们向后循环，所以是2的（8+4）次幂,，等于4096。
很明显，我们不需要把他们全部做完。
选择能代表这四千个场景的一个合理子集。
通常，明智的做法是选择一个基础流程，一个覆盖了每一个可选流程的场景，以及一些合理的可选流程的结合。
使用表1的例子，做一个包含流程A1和A7的场景也许没有什么意义，因为它们在图标上分隔太远以至于不能互相影响。
但是，做A1和A2是有意义的，因为他们互相紧埃，之间互相影响。
表2图解了选择的场景：
一个代表基本流程，8个代表每一个可选流程，6个反射一些流程的结合（特别是那些拥有两个距离很近的向后循环）。
因此确定，以下15个场景值得测试：
表2.值得测试的场景
表2：
获取选择的场景
场景1基础流程
场景9A8
场景2A1
changjing10A1，A2
场景3A2
场景11A3，A4
场景4A3
场景12A4，A5
场景5A4
场景13A3，A5
场景6A5
场景14A6，A7
场景7A6
场景15A7，A8
场景8A7
已经选定场景，余下的工作便是根据场景设计可以测试的用例。
7.测试用例编写要点
7.1.数据和数据库完整性测试
数据库和数据库进程应作为{项目名称}中的子系统来进行测试。
在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。
对于数据库管理系统（DBMS），还需要进行深入的研究，以确定可以支持以下测试的工具和方法。
见下表：
目标
确保数据库访问方法和进程正常运行，数据不会遭到损坏。
方法
调用各个数据库访问方法和进程，并在其中填充有效的和无效的数据或对数据的请求。
检查数据库，确保数据已按预期的方式填充，并且所有数据库事件都按正常方式出现；或者检查所返回的数据，确保为正当的理由检索到了正确的数据
完成标准
所有的数据库访问方法和进程都按照设计的方式运行，数据没有遭到损坏。
需考虑的特殊
事项
测试可能需要DBMS开发环境或驱动程序以便在数据库中直接输入或修改数据。
进程应该以手工方式调用。
使用小型或最小的数据库（其中的记录条数很有限）来使所有无法接受的事件具有更大的可见性。
7.2.功能测试
测试对象的功能测试应该侧重于可以被直接追踪到用例或业务功能和业务规则的所有测试需求。
这些测试的目标在于核实能否正确地接受、处理和检索数据以及业务规则是否正确实施。
这种类型的测试基于黑盒方法，即通过图形用户界面（GUI）与应用程序交互并分析输出结果来验证应用程序及其内部进程。
以下列出的是每个应用程序推荐的测试方法概要：
目标
确保测试对象的功能正常，其中包括导航、数据输入、处理和检索等。
方法
利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：
在使用有效数据时得到预期的结果。
在使用无效数据时显示相应的错误消息或警
升级会员 