修订记录

本文件用于指导软件测试完备性评估，并为软件测试提供停止标准。

2．范围

本文件适用于软件测试组织的软件测试活动。

3．术语和定义

✓缺陷：是对软件产品预期属性的偏离现象，指程序中存在的错误，也指存在于设计、需求、规格说明或其他文档中的错误。

✓覆盖率：语句覆盖率、测试用例执行覆盖率、测试需求覆盖率等的总称。

✓系统测试：将经过测试的子系统装配成一个完整的系统来测试，是针对整个产品的全面测试，既包含各模块的验证性测试和功能合理性测试，有包括对整个产品的可靠性、健壮性、安全性、UI合理性及各种性能参数的测试。

4．概述

本文件主要概述了软件的评估过程，说明了测试覆盖率的估算方法；另外，还介绍了软件测试停止标准，用于判定测试的暂停与终止，保证测试工作的完备性。

4．测试评估过程

软件测试评估贯穿整个软件测试过程，可以在测试每个阶段结束前进行，也可以在测试过程中某一个时间进行，目的是提高测试覆盖度，保证测试的质量，通过不断的测试覆盖度评估或测试覆盖率计算，及时掌握测试的实际状况与测试覆盖度目标的差距，采取措施，保证达到预期的测试覆盖度。

软件测试评估过程量化测试进程，生成缺陷和测试覆盖率的总结报告，从而确定测试的继续进行与停止，其具体的评估步骤为：

（1）回顾查看测试记录、测试日志等文件；

（2）评估测试的覆盖率；

（3）分析缺陷；

（4）决定是否达到本次测试的标准，如果未达到标准，可参考一下备选方案：

✓收集进一步的信息；

✓另行撰写报告，如不同的缺陷密度报告；

✓通过研究流程，判断意外条件是否导致背离已确定的测试标准，并在这一新信息的基础上再次评估标准；

✓建议安排进一步测试；

✓实施新测试以进一步执行测试用例；

✓实施新测试以扩大测试覆盖面；

✓修改测试标准；

✓复审并评估测试后变更标准会带来的风险；

✓确定满足测试标准的软件子集，并决定是否可以部署该子集。

（5）生成测试分析报告，撰写《测试缺陷报告》、《测试总结报告》。

5．测试覆盖率评估

测试覆盖是对测试完整性的评估，它所基于的是测试需求和测试用例的覆盖所指出得测试覆盖以及执行代码的覆盖所指出的测试覆盖。测试覆盖率体现了测试的完整程度。

测试覆盖度的评估依赖于不同的测试阶段或不同的测试方法。例如，在单元测试中，测试覆盖率是建立在被测试的代码行、程序分支和程序路径等的度量之上，从软件质量保证的要求出发，单元测试的覆盖率要达到80％之上；白盒测试方法主要以程序语句、判定－条件、条件组合和（基本）路径等覆盖率来衡量，和单元测试是吻合的；而在系统功能测试中，则以功能点、测试用例、需求数等覆盖率来衡量。

最常用的测试覆盖评估是基于软件需求和基于源代码的测试覆盖率，可手工获得这两种评估，或使用测试自动化工具进行计算。

4.1．基于需求的测试覆盖率

基于需求的测试覆盖评估是依赖于对已执行/运行的测试用例的核实和分析，所以基于需求的测试覆盖评测就转化为评估测试用例覆盖率，测试的目标是确保100%的测试用例全部成功地执行。

基于需求的测试覆盖要在测试生命周期中评估多次，来确定测试生命周期中里程碑上的测试覆盖，例如：计划的、实施的、执行的、成功的测试覆盖。

覆盖率计算公式：

测试覆盖率 = T(p,i,x,s) / RfT

其中：

T：测试（表示为测试过程或测试用例，包括计划的、实施的、执行的或成功的）数目；

RfT：“测试需求”的总数。

⏹在“计划测试”任务中，测试覆盖率按以下方式计算来确定计划的测试覆盖率： 

测试覆盖（计划的）= Tp / RfT

其中：

Tp：规划的测试（表示为测试过程或测试用例）的数目；

RfT：“测试需求”的总数。

⏹在“实施测试”任务中，实施测试过程（作为测试脚本）时，使用以下等式来计算测试覆盖率： 

测试覆盖（实施的）= Ti / RfT

其中：

Ti：实施的测试的数目，以存在相应测试脚本的测试过程或测试用例的数目表。

RfT：“测试需求”的总数。 

⏹在“执行测试”任务中使用了两种测试覆盖率评估 － 一种确定执行测试所达到的测试覆盖率，另一种确定成功的测试覆盖率（那些执行时无缺陷或意外结果等故障的测试）。 

使用以下等式计算这些覆盖评估：

测试覆盖率（执行的）= Tx / RfT

其中：

Tx：执行的测试（表示为测试过程或测试用例）的数目。 

RfT：“测试需求”的总数。 

⏹成功的测试覆盖率（执行的）= Ts / RfT

其中：

Ts：执行的测试（表示为成功完成且无缺陷的测试过程或测试用例）的数目。 

RfT：“测试需求”的总数。 

将以上比率转化为百分比，支持以下关于基于需求的测试覆盖的陈述：

x% 的测试用例（以上等式中的T(p,i,x,s)）已经覆盖，成功率为 y%。

这个测试覆盖陈述可与定义的成功标准相对照。如果达不到标准，那么该陈述可提供作为预测还剩多少测试工作的基础。

4.2．基于代码的测试覆盖率

基于代码的测试覆盖评测是对被测试的程序代码语句、路径或条件的覆盖率分析。代码覆盖可以基于控制流（语句、分支或路径）或者数据流。

具体而言代码覆盖率分析是这样一个过程：

✓找出程序经过一系列测试而没有执行的部分代码；

✓创建一个附加的测试用例来增加覆盖率；

✓决定代码覆盖的定量度量。

针对代码的测试覆盖率有许多种度量方式，例如：

✓语句覆盖：也称为行覆盖，段覆盖和基本块覆盖。它度量每一个可执行语句是否被执行到了，这个覆盖度量的主要好处是它可以直接应用在目标代码上，不需要对源代码进行处理，主要缺点是对一些控制结构很迟钝。

✓判定覆盖：也被称为分支覆盖，所有边界覆盖，基本路径覆盖，判定路径覆盖。它度量是否每个BOOL型的表达式取值true和false在控制结构中都被测试到了。这个度量有语句覆盖的简单性，但是没有语句覆盖的问题，缺点是忽略了在BOOL型表达式内部的BOOL取值。

✓条件覆盖：的度量每一个子表达式，报告每一个子表达式的结果的true或false。这个度量和判定覆盖相似，但是对控制流更敏感。不过，完全的条件覆盖并不能保证完全的判定覆盖。

✓路径覆盖：也称为断言覆盖，它度量了是否函数的每一个可能的分支都被执行了。路径覆盖的一个好处是：需要彻底的测试。但有两个缺点：一是，路径是以分支的指数级别增加的，例如：一个函数包含10个IF语句，就有1024个路径要测试。如果加入一个IF语句，路径数就达到2048；二是，许多路径不可能与执行的数据无关。

✓循环覆盖：度量否执行了每个循环体零次、只有一次还是多余一次（连续地）。对于do-while循环，循环覆盖报告你是否执行了每个循环体只有一次还是多余一次（连续地）。这个度量的有价值的方面是确定是否对于while循环和for循环执行了多于一次，这个信息在其它的覆盖率报告中是没有的。

覆盖率计算公式：

测试覆盖率 = Ie / TIic

其中：

Ie：执行的项（表示为代码语句、代码分支、代码路径、数据状态决定点或数据元素名）的数目。 

Tiic：代码中项的总数。

将此比率转化为百分比，支持以下关于基于代码的测试覆盖的陈述：

x%的测试用例（以上等式中的 I）已经完成，成功率为 y%。

这个测试覆盖陈述可与定义的成功标准相对照。如果达不到标准，那么该陈述可提供作为预测还剩多少测试工作的基础。

5．测试终止

对于任何软件，缺陷都是永远存在的，因此，从理论上讲，软件测试是一个没尽头的过程。但在实际工作中，在有限的时间和资源下进行完全测试找出软件的所有错误和缺陷是不可能的，应适时而止。

因此，需要制定合理的测试终止条件来停止测试，保证测试质量，提高测试工作效率，降低测试成本。

一个合理的测试终止条件只能来源于一个清晰的测试目标。如果测试目标是找到所有的缺陷，那么无论多少时间都是不够的。而从测试的经济目标来看，合理的终止条件应包括以下两点：

⏹所有在测试计划中列出的测试项和标准都被测试通过。

软件测试是为了保证软件的质量，而软件的质量标准是由用户决定的，这个标准应当在软件开发初期由用户需求调查所得，依此，得出软件的测试项、被共同利益者认可的标准和测试用例等，这样，软件测试结束的第一个必要条件就是所有在测试计划中列出的测试项和标准（常见的有：必要及重要的功能通过测试，公认的认证测试用例包测试通过，连续无故障运行超过一定时间等）都被通过。

⏹当通过测试发现缺陷的成本比发布后再去维护的成本要高时，可终止测试。

软件测试，随着缺陷的不断被发现并修复，软件的质量也越来越好，后继的服务成本就会越来越低，相应的，新的缺陷就会越来越难找，即测试成本越来越高。从企业的利润来说，就是要使这两部分成本之和最小。

在实际情况下，人们绍常按拇指原则，即架设残留的缺陷数与最后一阶段排除的缺陷数相等，启用这样一个较为合理的终止条件：

✓当一段时间内（通常是一个星期）测试不出新缺陷时，就可终止测试；

✓按照已提出的效益规则，即当“找到的新缺陷的实际价值低于相同时间的测试运行费用”或“测试成本与维护成本之和达到最小值”或“经3至5倍企业同类软件开发项目的平均淡味缺陷测试时间内没有发现新缺陷”时，可终止测试。

下面给出软件测试停止标准、系统测试停止标准、缺陷修复覆盖率标准、 测试覆盖率标准作为参考，有助于测试人员掌握一定的测试停止原则。

5.1．软件测试停止标准

软件开发过程一般都会经历四个步骤：单元测试、集成测试、系统测试、验收测试。对于一个软件产品来说，软件测试停止时应满足：

（1）软件系统经过单元、集成、系统测试，分别达到单元、集成、系统测试停止标准；

（2）软件系统通过验收测试，并已得出验收测试结论；

（3）软件项目需暂停以进行调整时，测试应随之暂停，并备份暂停点数据；

（4）软件项目在其开发生命周期内出现重大估算，进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据。

5.2．系统测试停止标准

系统测试的目的是对最终的软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。系统测试停止的参考标准;

（1）系统测试用例设计已经通过评审；

（2）按照系统测试计划完成了系统测试；

（3）达到了测试计划中关于系统测试所规定的覆盖率的要求；

（4）被测试的系统每千行代码必须发现1个错误（选用）；

（5）系统满足需求规格说明书的要求；

（6）在系统测试中发现的错误已经得到修改，各级缺陷修复率达到标准。

5.3．缺陷修复率标准

（1）一、二级缺陷修复率应达到100%；

（2）三、四级缺陷修复率应达到80%以上；

（3）五级缺陷修复率应达到60%以上。

（缺陷等级划分，可参考《附录一》）

5.4．覆盖率标准

✓语句覆盖率最低不能小于80%

✓测试用例执行覆盖率应达到100%

✓测试需求覆盖率应达到100%

附录:

附录一：缺陷等级划分: