测试结果评估与终止标准

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

测试结果评估与终止标准

修订记录

1.目的

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

2.范围

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

3.术语和定义

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

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

✓系统测试:将经过测试的子系统装配成一个完整的系统来测试,是针对整个产品的全面测试,既包含各模块的验证性测试和功能合理性测试,有包括对整个产品的可

靠性、健壮性、安全性、UI合理性及各种性能参数的测试。

4.概述

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

4.测试评估过程

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

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

(1)回顾查看测试记录、测试日志等文件;

(2)评估测试的覆盖率;

(3)分析缺陷;

(4)决定是否达到本次测试的标准,如果未达到标准,可参考一下备选方案:✓收集进一步的信息;

✓另行撰写报告,如不同的缺陷密度报告;

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

✓建议安排进一步测试;

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

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

✓修改测试标准;

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

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

(5)生成测试分析报告,撰写《测试缺陷报告》、《测试总结报告》。

5.测试覆盖率评估

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

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

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

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

基于需求的测试覆盖评估是依赖于对已执行/运行的测试用例的核实和分析,所以基于

需求的测试覆盖评测就转化为评估测试用例覆盖率,测试的目标是确保100%的测试用例全部成功地执行。

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

覆盖率计算公式:

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

其中:

T:测试(表示为测试过程或测试用例,包括计划的、实施的、执行的或成功的)

数目;

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

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

测试覆盖(计划的)= T p / RfT

其中:

T p:规划的测试(表示为测试过程或测试用例)的数目;

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;二是,许多路径不可能与执行的数据

无关。

相关文档
最新文档