1. 测试广度的测量提供了多少需求（在所有需求的数目中）在某一时刻已经被测试，来度量测试计划的执行、测试进度等状态；
2. 测试深度是对被测试覆盖的独立基本路径占在程序中的基本路径的总数的百分比的测度，基本路径数目的度量可以用McCabe环形计算复杂度方法来计算。
3. 过程中收集的缺陷数度量，发现的、修正的和关闭的缺陷数量在过程中的差异、发展趋势等，为过程质量、开发资源额外投入、软件发布预测提供重要依据。
如前所述，测试过程的度量可以将过程状态度量和过程结果度量结合起来分析，是测试过程度量更有效。
在测试阶段，主要的过程质量度量有：
* 缺陷度量或缺陷分布度量
* 测试用例的深度、质量和有效性
* 测试执行的效率和质量
* 缺陷报告的质量
* 测试覆盖度（测试整体的质量）
* 测试环境的稳定性或有效性
缺陷度量是测试阶段的主要度量内容，包括产品缺陷度量和缺陷过程度量。产品缺陷度量将在下一回做详细介绍，而测试环境的稳定性或有效性度量，就像软件有效性一样，用MTTF来测量。所以下面将简单介绍其他度量内容，如 软件缺陷到达模式、PTR出现/积压模型、测试用例的度量、基于需求的测试覆盖评估、基于代码的测试覆盖评估等等。
1. 基于时间的缺陷到达模式
产品的缺陷密度、或者测试阶段的缺陷率是一个概括性指标，缺陷到达模式可以提供更多的过程信息，有时即使得到的整体缺陷率是一样的，但其质量差异可能较大，原因就是缺陷到达的模式不一样。越多的缺陷到达越早，则测试过程质量就越好。无论是从测试进展的观点，还是从用户重新发现(customer rediscoveries)的观点来看，缺陷的过程跟踪是非常重要的，开发周期里大量的严重缺陷将有可能阻止测试的进展，也必然直接影响软件产品的质量和性能。
相对产品发布时间、上一个版本的缺陷水平来说，经常会被项目经理或开发经历问的就是：
* 缺陷何时到达峰值？这个峰值有时多少？
* 在到达峰值后又要化多少时间趋于（降低）到一个低而稳定的水平？
* 低而稳定的水平持续多少时间，当前版本可以发布？
回答这些问题，正是缺陷达到模式要实现的目标。定性的分析比较容易，测试团队越成熟，峰值到达得越早，有时可以在第一周末或第二周就达到峰值。这个峰值的数值取决于代码质量、测试用例的设计质量和测试执行的策略、水平等，多数情况下，可以根据基线（或历史数据）推得。从一个峰值达到一个低而稳定的水平，需要长得多的时间，至少是达到峰值所用的时间的4-5倍。这个时间取决于峰值、缺陷移除效率等等。
2. PTR累积模型
测试的目标在于尽早地发现软件缺陷，通过测试用例可以更有效、更快地发现软件中缺陷，而软件缺陷通过PTR（问题跟踪报告，Problem Tracking Report）来描述。因此，PTR的数量一定程度上代表了软件的质量。每个缺陷/PTR都有一个生命周期，从测试人员发现问题并形成报告（称为PTR出现，也称缺陷到达），开发/设计人员要重现、修正这个PTR/缺陷，并构建、提交包含已修正PTR/缺陷的新软件包(New Build)给测试组，所修正的问题得到验证直到该问题通过测试为止（称为PTR关闭），测试过程中特定时间PTR保持的数量（所有新发现的PTR和关闭的PTR的差值）——PTR累积/积压值。PTR出现／累积模型就是根据问题跟踪报告的两种数据——某个时间单位内的PTR出现值和某个时间PTR累积值来度量测试中所发现的缺陷变化过程，即软件产品质量状态的变化过程。
3．测试用例的深度、质量和有效性
测试用例是测试执行的基础，其质量的好坏直接关系到测试的质量，也就影响着软件质量的保证过程。测试用例的度量将包含测试用例的深度、质量和有效性，而且包含自动化程度的度量，即多少比例的测试用例已被自动化了。
测试用例的深度（TCD, Test Case Depth）度量可以表示为每KLOC的测试用例数或每个功能点/对象点的测试用例数，而测试用例的效率可以用每100或1000个测试用例所发现的缺陷数来衡量，不同的测试阶段是不一样，应该对同一阶段的不同版本进行比较，而不宜对同一版本的不同阶段进行比较。而测试用例的质量（TCQ, Test Case Quality）可以用由测试用例发现的缺陷数量来度量，即
TCQ = 测试用例发现的缺陷数量/总的缺陷数量
因为还有一部分缺陷可以通过ad-hoc 测试（随机、自由的测试）、集体走查(Work-through)和Fire-drill测试(类似消防训练的用户压力/验收测试)等其他手段发现缺陷。
文章来源于领测软件测试网 https://www.ltesting.net/