测试度量是非常重要的。它可以帮助测试团队追踪测试活动的有效性，也可以为测试过程的改善、测试活动的改善、各类报告提供有力的支持。它可以帮助测试组织从更高层次上实施一些评估活动和改善活动。
测试度量的分类
- 项目度量
- 产品度量
- 过程度量
- 人员度量
监督测试进展主要就以下五个方面：
- 产品（质量）风险
- 缺陷
- 测试
- 覆盖率
- 信心
在项目和业务中，产品风险、缺陷、测试和覆盖率可以，且通常以特定的方式进行度量和汇报。如果这些度量数据和测试计划中定义的出口准则相关，他们可以作为判断测试工作是否完成的客观标准。信心的度量可以通过调查或使用覆盖率作为替代度量，不过通常还会以主观的方式汇报信心。
与产品风险相关的度量
- 完全覆盖的风险百分比（所有的测试都通过（Pass））
- 部分覆盖的风险的百分比（有些测试或很多测试都没有通过）
- 还未完全测试的风险的百分比（有些测试还没有测试完）
- 按风险类别划分的覆盖的风险百分比
- 在初次质量风险分析后识别的风险的百分比
与缺陷相关的度量
- 已报告（发现）的缺陷总数对比已解决（修复）的缺陷总数
- 失效的平均时间间隔和失效出现率
- 按下列分类统计的缺陷数或百分比
o 特定的测试项或组件
o 根本原因
o 缺陷来源（如需求规格说明、新功能、回归等）
o 测试发布
o 引入、发现和移除缺陷的阶段
o 优先级／严重程度
o 拒绝或重复的缺陷报告
- 从报告缺陷到修复缺陷所花的时间趋势
- 引入了新缺陷（有时也称子缺陷）的缺陷修复数
和测试相关的度量
- 已计划的、已详细说明（已实施）的、已运行、通过的、失败的、无法执行的和跳过不执行的
测试总数 - 回归测试和确认测试的状态，包括趋势和未通过的回归测试总数及未通过的确认测试总数
- 计划的每日测试时长对比实际的每日测试时长
- 测试环境的可用性（准备测试团队可用的测试环境占计划测试时长的百分比）
和测试覆盖率相关的度量
- 需求和设计要素的覆盖率
- 风险覆盖率
- 环境／配置覆盖率
- 代码覆盖率
重要的是测试经理要知道怎样去解读和使用覆盖率的度量，以便理解和报告测试状态。对于级别较高的测试，如系统测试、系统集成测试和验收测试，主要的测试依据通常是需求规格说明、设计规格说明、用例、用户故事、产品风险、支持环境和支持配置等工作产品。结构化的代码覆盖率度量更适用于级别较低的测试，如单元测试（如语句和分支覆盖）和组件集成测试（如接口覆盖）。测试经理可能使用代码覆盖的度量数据来衡量测试覆盖待测系统的程度，但在汇报较高级别的测试结果时，通常不会提到代码覆盖的度量。此外，测试经理应该知道即便单元测试和组件集成测试达到了结构覆盖目标的100%，缺陷和质量风险仍有待较高级别的测试来处理。
度量也可以连系到基本测试过程中的活动。这样一来，在整个测试过程中，就可以对照项目目标和测试过程本身，使用度量数据来监督测试过程本身以及达成项目目标的进展。
和监督测试计划和控制活动相关的度量
- 风险、需求和其它测试依据要素的覆盖率
- 缺陷发现情况
- 计划开发测试件和执行测试用例的时长对比实际的时长
和监督测试分析活动相关的度量
- 识别的测试条件数
- 测试分析中发现的缺陷数（如通过使用测试依据识别风险或其它测试条件）
和监督测试设计活动相关的度量
- 测试用例覆盖的测试条件百分比
- 测试设计中发现的缺陷数（如通过对照测试依据开发测试）
和监督测试实施活动相关的度量
- 测试环境配置的百分比
- 测试数据记录加载的百分比
- 测试用例自动化的百分比
和监督测试执行活动相关的度量
- 执行、通过和失败的测试占已计划的测试的百分比
- 执行（和／或通过）的测试用例覆盖的测试条件的百分比
- 计划与实际的报告／解决的缺陷对比
- 计划与实际达到的覆盖率的对比
监督测试进展和测试完成活动的度量包括里程碑、入口准则和出口准则（测试计划中定义和批准的）的映射，其中可能包括以下内容：
- 计划的测试条件、测试用例或测试规约说明的数目和按测试是否通过分别统计的执行的测试条件、测试用例或测试规约说明的数目
- 总缺陷数，通常按严重程度、优先级、目前状态、受影响的子系统或其它分类统计
- 要求的、接受的、开展的和测试过的变更数
- 计划成本对比实际成本
- 计划工期对比实际工期
- 测试里程碑的计划日期对比实际日期
- 有关测试的项目里程碑（如代码冻结）的计划日期对比实际日期
- 产品（质量）风险状态、通常按已缓解与未缓解的风险，主要的风险区域、测试分析后发现的新风险等分类统计
- 由于阻塞事件或计划的变更导致的测试工作量、成本或时间损失的百分比
- 确认和回归测试状态
和监督测试结束活动相关的度量
- 测试执行期间已执行的、通过的、失败的、无法执行的和跳过不执行的测试用例的百分比
- 纳入可复用的测试用例库的测试用例的百分比
- 自动化的测试用例的百分比或计划的与实际的自动化的测试用例百分比对比
- 并入回归测试的测试用例的百分比
- 已解决／未解决的显著缺陷报告的百分比
- 识别和归档的测试工作产品的百分比
另外，标准的项目管理技术，如工作分解结构，通常被用来监督测试过程。在敏捷团队中，测试是燃尽图上用户故事进展的一部分。使用精益管理技术时，测试进展以一系列故事为基础，通常通过用户故事卡在看板图上移动的状态来监督。
在给定了一组度量标准后，度量数据可以通过口头陈述、在表格中以数值的形式，或用图形来进行汇报。度量数据可以有很多用途，包括：
- 分析，找出可从测试结果中观察到的趋势和原因
- 汇报，将测试结果告知感兴趣的项目参与人和项目干系人
- 控制，改变整个测试或项目的进程和监督进程纠正的结果
收集、分析和报告这些测试度量数据的适当方式取决于具体的信息需要、目标和使用这些度量数据的个人能力。另外，测试报告的具体内容也应该根据不同的读者而变化。
为了测试控制的需要，非常重要的一点是度量数据必须能够提供给测试经理有关整个测试过程（测试计划完成后）的信息，并能指导测试经理成功完成测试任务、实施测试策略和实现测试目标。因此在计划时一定要考虑到信息需要，监督时一定要包括收集任何需要的工作产品度量。需要的信息量和采集信息需要的工作量取决于各种项目因素，包括项目规模、复杂度和风险。
测试控制一定要回应测试产生的信息和项目或活动存在的不断变化的环境。例如，如果动态测试在某些认为不可能有很多缺陷的区域发现了缺陷群，又如由于测试开始时间延迟导致测试执行周期缩短，则必须对风险分析和计划作出修改。这么做可能需要对测试优先级重新设定和对剩余的测试执行工作重新进行分配。
如果通过测试进展报告发现与测试计划出现了偏差，则应执行测试控制。测试控制的目的是为项目和／或测试重新定向到更可能取得成功的方向。当项目的控制工作取决于测试结果或受测试结果影响时，需要考虑以下内容：
- 修改质量风险分析、测试优先级和／或测试计划
- 增加资源或增加项目或测试工作量
- 推迟发布日期
- 放松或加强测试出口准则
- 改变项目的范围（功能或非功能）
实施这些内容通常需要项目或业务干系人之间达成共识，并且取得项目或业务经理的同意。
测试报告中发布的信息应该大部分取决于目标读者，如项目管理人员或业务管理人员的信息需要。项目经理最可能感兴趣的是关于缺陷的详细信息，而业务经理最关注的可能是产品风险的状态。