测试阶段的过程度量内容或项目比较多，包括软件测试进度、测试覆盖度、测试缺陷出现/到达曲线、测试缺陷累积曲线、测试效率等。在进行测试过程度量时，要基于软件规模度量(如功能点、对象点等)、复杂性度量、项目度量等方法，从三个不同的测度来完整度量测试的过程状态：

测试广度的测量 提供了多少需求(在所有需求的数目中)在某一时刻已经被测试，来度量测试计划的执行、测试进度等状态;

测试深度 是对被测试覆盖的独立基本路径占在程序中的基本路径的总数的百分比的测度，基本路径数目的度量可以用McCabe环形计算复杂度方法来计算。

过程中收集的缺陷数度量 ，发现的、修正的和关闭的缺陷数量在过程中的差异、发展趋势等，为过程质量、开发资源额外投入、软件发布预测提供重要依据。

如前所述，测试过程的度量可以将过程状态度量和过程结果度量结合起来分析，是测试过程度量更有效。

在测试阶段，主要的过程质量度量有：

*　缺陷度量或缺陷分布度量

*　测试用例的深度、质量和有效性

*　测试执行的效率和质量

*　缺陷报告的质量

*　测试覆盖度(测试整体的质量)

*　测试环境的稳定性或有效性

缺陷度量是测试阶段的主要度量内容，包括产品缺陷度量和缺陷过程度量。产品缺陷度量将在下一回做详细介绍，而测试环境的稳定性或有效性度量，就像软件有效性一样，用MTTF来测量。所以下面将简单介绍其他度量内容，如软件缺陷到达模式、PTR出现/ 积压模型、测试用例的度量、基于需求的测试覆盖评估、基于代码的测试覆盖评估等等。

基于时间的缺陷到达模式

产品的缺陷密度、或者测试阶段的缺陷率是一个概括性指标，缺陷到达模式可以提供更多的过程信息，有时即使得到的整体缺陷率是一样的，但其质量差异可能较大，原因就是缺陷到达的模式不一样。越多的缺陷到达越早，则测试过程质量就越好。无论是从测试进展的观点，还是从用户重新发现(customer rediscoveries)的观点来看，缺陷的过程跟踪是非常重要的，开发周期里大量的严重缺陷将有可能阻止测试的进展，也必然直接影响软件产品的质量和性能。

相对产品发布时间、上一个版本的缺陷水平来说，经常会被项目经理或开发经历问的就是：

缺陷何时到达峰值?这个峰值有时多少?

在到达峰值后又要化多少时间趋于(降低)到一个低而稳定的水平?

低而稳定的水平持续多少时间，当前版本可以发布?

回答这些问题，正是缺陷达到模式要实现的目标。定性的分析比较容易，测试团队越成熟，峰值到达得越早，有时可以在第一周末或第二周就达到峰值。这个峰值的数值取决于代码质量、测试用例的设计质量和测试执行的策略、水平等，多数情况下，可以根据基线(或历史数据)推得。从一个峰值达到一个低而稳定的水平，需要长得多的时间，至少是达到峰值所用的时间的4-5倍。这个时间取决于峰值、缺陷移除效率等等。

PTR累积模型

测试的目标在于尽早地发现软件缺陷，通过测试用例可以更有效、更快地发现软件中缺陷，而软件缺陷通过PTR(问题跟踪报告，Problem Tracking Report)来描述。因此，PTR的数量一定程度上代表了软件的质量。每个缺陷/PTR都有一个生命周期，从测试人员发现问题并形成报告(称为PTR出现，也称缺陷到达)，开发/设计人员要重现、修正这个PTR/缺陷，并构建、提交包含已修正PTR/缺陷的新软件包(New Build)给测试组，所修正的问题得到验证直到该问题通过测试为止(称为PTR关闭)，测试过程中特定时间PTR保持的数量(所有新发现的PTR和关闭的PTR的差值)——PTR累积/积压值。PTR出现/累积模型就是根据问题跟踪报告的两种数据——某个时间单位内的PTR出现值和某个时间PTR累积值来度量测试中所发现的缺陷变化过程，即软件产品质量状态的变化过程。

测试用例的深度、质量和有效性

测试用例是测试执行的基础，其质量的好坏直接关系到测试的质量，也就影响着软件质量的保证过程。测试用例的度量将包含测试用例的深度、质量和有效性，而且包含自动化程度的度量，即多少比例的测试用例已被自动化了。

测试用例的深度(TCD, Test Case Depth)度量可以表示为每KLOC的测试用例数或每个功能点/对象点的测试用例数，而测试用例的效率可以用每100或1000个测试用例所发现的缺陷数来衡量，不同的测试阶段是不一样，应该对同一阶段的不同版本进行比较，而不宜对同一版本的不同阶段进行比较。而测试用例的质量(TCQ, Test Case Quality)可以用由测试用例发现的缺陷数量来度量，即TCQ = 测试用例发现的缺陷数量/总的缺陷数量

因为还有一部分缺陷可以通过ad-hoc 测试(随机、自由的测试)、集体走查(Work-through)和Fire-drill测试(类似消防训练的用户压力/验收测试)等其他手段发现缺陷

测试执行的效率和质量

测试执行的质量一般可以用软件发布后所遗留的软件缺陷和总缺陷数的比值来衡量，一般要求低于0.5%，也可以通过种子公式或交叉测试等方法衡量。测试执行的效率可以用下列几种方法来综合度量：

*　每个人日所执行的测试用例数

*　每个人日所发现的缺陷数

*　每修改的KLOC所运行的测试用例数

缺陷报告的质量

缺陷报告质量可以评估测试人员工作质量的方法之一，如可测量的指标有：

缺陷报告有效性，所有修正/关闭的(等级高的)缺陷和测试人员所报的所有(等级高的)缺陷的比值，这个值越接近1，有效性就越高，如果考察等级高的缺陷，其正常值大约在0.92 – 0.96

缺陷报告质量，可以用一些中间状态为"需要补充信息"、"不是缺陷"的缺陷数量来衡量，一般占总缺陷数的3%-5%为正常，高于或低于这个值都可能不正常，高于5%，可能说明缺陷报告质量低;低于3%，可能说明测试人员缺少怀疑精神。

基于需求的测试覆盖评估

基于需求的测试覆盖评估是依赖于对已执行/运行的测试用例的核实和分析，所以基于需求的测试覆盖评测就转化为评估测试用例覆盖率：测试的目标是确保 100%的测试用例全部成功地执行。一般在测试计划中，就定义了测试的工作量、测试用例数量和测试用例覆盖率(98%-100%)，我们根据事先确定的测试日程安排，可以将测试计划值做成曲线，然后根据实际执行结果，定期(每天或每周)去画实际值曲线，从而可以进行测试全过程监控和预测。

在执行测试活动中，评估测试用例覆盖率又可分为两类测试用例覆盖率估算：

确定已经执行的测试用例覆盖率，即在所有测试用例中有多少测试用例已被执行。假定Tx已执行的测试过程数或测试用例数，Rft是测试需求的总数：

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

确定成功的测试覆盖，即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试，假定Ts是已执行的完全成功、没有缺陷的测试过程数或测试用例数。

成功的测试覆盖 = Ts/Rft

基于代码的测试覆盖评估

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

评估代码覆盖率，需要断定测试目标期望的、总的测试代码行数，在测试中真正执行的代码行数及其百分比，将此结果记录在测试评估报告中。测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流(语句、分支或路径)或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效，例如，数据元素在使用之前是否已经定义。

基于代码的测试覆盖通过以下公式计算：

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

其中Tc是用代码语句、条件分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数，Tnc(Total number of items in the code)是代码中的项目总数。