全程软件测试（四十二）：评估系统测试的覆盖程度—读书笔记

若未执行测试评估，则不会有测试覆盖率的结果，也就不会有 告测试进程的根据。软件测试评估主要有两个目的：一是量化测试进程，判断测试进行的状态，决定测试可以结束的时间；二是为测试或质量分析 告生成所需的量化数据，如缺陷清除率、测试覆盖率等。

测试评估是软件测试的一个阶段性结论，是用所生成的测试评估 告来确定测试是否达到完全和成功的标准。测试评估可以说贯穿整个软件测试过程，可以在测试每个阶段结束前进行，也可以在测试过程中某一个时间进行。

系统的测试活动建立在至少一个测试覆盖策略基础上，而覆盖策略试图描述测试的一般目的，指导测试用例的设计。如果测试需求已经完全分类，则基于需求的覆盖策略可能足以生成测试完全程度评测的量化指标。例如，如果已经确定了所有性能测试需求，则可以引用测试结果来做出评测，如“已经核实90%的性能测试需求”。测试评估工作主要是对测试覆盖率的评估，测试覆盖率是用来衡量测试完成多少的一种量化标准。

测试的覆盖率可用测试项目的数量和内容进行度量，除此之外，若测试的软件较大，还需要考虑数据量。测试覆盖程度表如下表所示。通过检查这些指标的达标程度，即可度量出测试内容的覆盖程度。

测试覆盖程度表

对测试覆盖率的评估就是确定测试执行的完全程度，其基本方法有基于需求的测试覆盖评估和基于代码的测试覆盖评估。

对软件需求的估算

对软件需求的估算有利于对测试需求的把握，有利于进一步估算测试覆盖率。

假设一个规格设计说明书中有R个需求，其功能需求的数目为F，非功能需求数（如性能）为N，则R=F+N。为了解需求的确定性，一种基于复审者对每个需求解释的一致性的度量方法如下所示。

Q1=M/R

其中 Q1表示需求的确定性，M 是所有复审者都有相同解释的需求数目。需求的模糊性越低，Q1的值越接近1。而功能需求的完整性Q2的计算公式如下所示。

Q2=Fu/（Ni×Ns）

其中Fu是唯一功能需求的数目，Ni是由规格设计说明书定义的输入个数，Ns是被表示的状态个数。Q2只是度量一个系统所表示的必需功能百分比，但它并没有考虑非功能需求。为了把非功能需求结合到整体度量中以求完整，必须将已有需求已经被确认的程度考虑进去。因此Q3的计算公式如下所示。

Q3=Fc/（Fc+Fnv）

其中，Fc是已经被确认的需求个数，Fnv是尚未被确认的需求个数。

基于需求的测试覆盖评估

基于需求的测试覆盖评估依赖于对已执行/运行的测试用例的核实和分析，因此基于需求的测试覆盖评估就转换为评估测试用例覆盖率，测试的目标是确保100%的测试用例都成功地执行。若这个目标不可行或不可能达到，则要根据不同的情况制定不同的测试覆盖标准，主要考虑风险和严重性、可接受的覆盖百分比。在执行测试活动中，评估测试用例覆盖率又可分为两类测试用例覆盖率估算，具体如下所示。

（1）确定已经执行的测试用例覆盖率，即在所有测试用例中有多少测试用例已被执行。假定Tx是已执行的测试过程数或测试用例数，Rft是测试需求的总数，则已执行的测试覆盖计算公式如下所示。

已执行的测试覆盖=Tx/Rft

（2）确定成功的测试覆盖，即执行时未出现失败的测试，例如，未出现缺陷或意外结果的测试。假定Ts是已执行的完全成功、没有缺陷的测试用例数，则成功的测试覆盖的计算公式如下所示。

成功的测试覆盖=Ts/Rft

在实际计算中，很难确定Rft的值，一般可以根据需求点、以往经验来估算。

基于代码的测试覆盖评估

基于代码的测试覆盖评估是对被测程序代码语句、路径或条件的覆盖率分析。若应用基于代码的覆盖，则应评估已执行测试的源代码量。这种测试覆盖策略类型对于安全至上的系统来说非常重要。

评估代码覆盖率，需要确定测试目标期望和总的测试代码行数、在测试中真正执行的代码行数及其百分比，并将此结果记录在测试评估 告中。

测试过程中已经执行的代码的数量，与之相对的是需要执行的剩余代码数量。代码覆盖可建立在控制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已定义。

基于代码的测试覆盖计算公式如下。

已执行的测试覆盖=Tc/Tnc

其中Tc是基于代码语句、条件分支、代码路径、数据状态判定点或数据元素的已执行项目数，Tnc是代码中的项目总数。