往期关联文章回顾：

瀑布、V、W、快速原型模型、增量、螺旋模型

测试管理 | 4种优先级排序方法一定要掌握

测试管理 | 基于风险的测试

管理上有这样一句名言，进行度量的工作才会得到有效的执行。反之，因为很容易忽略那些不进行度量的工作，所以不进行度量的工作通常不会得到有效的执行。因此，对于包括测试在内的任何活动，建立适当的度量都是很重要的。

测试度量可以划分到以下的一种或多种类型中：

  项目度量，对照既定的项目出口准则，如测试用例执行率、通过率和失败率，度量项目进展

  产品度量，度量产品的某些属性，如测试程度和缺陷密度

 过程度量，度量测试或开发过程的能力，如通过测试发现的缺陷百分比

 人员度量，度量个人或小组的能力，如在给定的时间内测试用例的实施情况

任何给定的度量都属于以上的两种、三种、甚至四种类型。例如，体现每日缺陷发现率的趋势图可以与以下内容都相关：出口准则（连续一周都未发现新缺陷）、产品质量（测试无法再找出产品的缺陷）、和测试过程的能力（在执行测试的前期发现了大量缺陷）。

人员度量尤为敏感。测试经理有时会把过程度量误认为是人员度量，导致大家为了让该度量对他们更有利而采取一些行动，产生灾难性的后果。

我们主要关注的是使用度量来衡量测试工作的进展，如项目度量。度量的使用可以让测试人员在汇报结果时保持一致，而且可以连贯地跟踪测试进展。测试经理通常被要求在各种会议上展示度量数据，这些会议的参与人可能包括从技术人员到执行管理层的各级别的干系人。因为有时确定一个项目整体成功与否也会用到这些度量数据，在决定需要跟踪什么内容、汇报的频率和呈现这些信息的方式时都需要特别留意。需要强调的是，测试经理必须考虑以下内容：

 度量的定义：应定义一组有限的有用度量。度量的定义依据项目、过程和／或产品的具体目标。定义度量时应考虑到平衡，因为单个的度量可能会误导对状态或趋势的印象。对这些定义的度量的解读必须得到所有干系人的认可，避免讨论这些度量时产生混乱。经常发生定义了过多的度量而没有关注那些最相关的度量的情况

 度量的追踪：应该尽可能自动化度量报告和汇总，以缩短采集和处理度量数据的时间。随时间的推移，特定的度量数据可能会反映出和度量定义阶段约定的解读不同的信息。测试经理应做好准备，仔细分析这些度量数据和期待可能出现哪些偏差，以及造成偏差的原因

 度量的汇报：目的是帮助管理层迅速理解所获得的信息。应呈现对某段时间度量的“快照”或度量随时间推移的变化，这样才能进行趋势分析

 度量的有效性：测试经理还必须验证汇报的信息。为某个度量收集的数据可能无法反应项目的真实情况或可能传达了过于乐观或过于悲观的趋势。在呈现数据前，测试经理必须就数据的准确度和可能传达的信息两方面对数据进行评审

监督测试进展主要就以下五个方面：

 产品（质量）风险

 缺陷

 测试

 覆盖率

 信心

在项目和业务中，产品风险、缺陷、测试和覆盖率可以，且通常以特定的方式进行度量和汇报。如果这些度量数据和测试计划中定义的出口准则相关，他们可以作为判断测试工作是否完成的客观标准。信心的度量可以通过调查或使用覆盖率作为替代度量，不过通常还会以主观的方式汇报信心。

与产品风险相关的度量包括：

 完全覆盖的风险百分比（所有的测试都通过（Pass））

 部分覆盖的风险的百分比（有些测试或很多测试都没有通过）

 还未完全测试的风险的百分比（有些测试还没有测试完）

 按风险类别划分的覆盖的风险百分比

 在初次质量风险分析后识别的风险的百分比

与缺陷相关的度量包括：

 已报告（发现）的缺陷总数对比已解决（修复）的缺陷总数

 失效的平均时间间隔和失效出现率

 按下列分类统计的缺陷数或百分比 o 特定的测试项或组件 o 根本原因 o 缺陷来源（如需求规格说明、新功能、回归等） o 测试发布 o 引入、发现和移除缺陷的阶段 o 优先级／严重程度 o 拒绝或重复的缺陷报告

 从报告缺陷到修复缺陷所花的时间趋势

 引入了新缺陷（有时也称子缺陷）的缺陷修复数

和测试相关的度量包括：

 已计划的、已详细说明（已实施）的、已运行、通过的、失败的、无法执行的和跳过不执行的测试总数

 回归测试和确认测试的状态，包括趋势和未通过的回归测试总数及未通过的确认测试总数

 计划的每日测试时长对比实际的每日测试时长

 测试环境的可用性（准备测试团队可用的测试环境占计划测试时长的百分比）

和测试覆盖率相关的度量包括：

 需求和设计要素的覆盖率

 风险覆盖率

 环境／配置覆盖率

 代码覆盖率

重要的是测试经理要知道怎样去解读和使用覆盖率的度量，以便理解和报告测试状态。对于级别较高的测试，如系统测试、系统集成测试和验收测试，主要的测试依据通常是需求规格说明、设计规格说明、用例、用户故事、产品风险、支持环境和支持配置等工作产品。结构化的代码覆盖率度量更适用于级别较低的测试，如单元测试（如语句和分支覆盖）和组件集成测试（如接口覆盖）。测试经理可能使用代码覆盖的度量数据来衡量测试覆盖待测系统的程度，但在汇报较高级别的测试结果时，通常不会提到代码覆盖的度量。此外，测试经理应该知道即便单元测试和组件集成测试达到了结构覆盖目标的100%，缺陷和质量风险仍有待较高级别的测试来处理。

度量也可以连系到基本测试过程中的活动。在整个测试过程中，就可以对照项目目标和测试过程本身，使用度量数据来监督测试过程本身以及达成项目目标的进展。

和监督测试计划和控制活动相关的度量包括：

 风险、需求和其它测试依据要素的覆盖率

 缺陷发现情况

 计划开发测试件和执行测试用例的时长对比实际的时长

和监督测试分析活动相关的度量包括：

 识别的测试条件数

 测试分析中发现的缺陷数（如通过使用测试依据识别风险或其它测试条件）

和监督测试设计活动相关的度量包括：

 测试用例覆盖的测试条件百分比

 测试设计中发现的缺陷数（如通过对照测试依据开发测试）

和监督测试实施活动相关的度量包括：

 测试环境配置的百分比

 测试数据记录加载的百分比

 测试用例自动化的百分比

和监督测试执行活动相关的度量包括：

 执行、通过和失败的测试占已计划的测试的百分比

 执行（和／或通过）的测试用例覆盖的测试条件的百分比

 计划与实际的报告／解决的缺陷对比

 计划与实际达到的覆盖率的对比

监督测试进展和测试完成活动的度量包括里程碑、入口准则和出口准则（测试计划中定义和批准的）的映射，其中可能包括以下内容：

 计划的测试条件、测试用例或测试规约说明的数目和按测试是否通过分别统计的执行的测试条件、测试用例或测试规约说明的数目

 总缺陷数，通常按严重程度、优先级、目前状态、受影响的子系统或其它分类统计

 要求的、接受的、开展的和测试过的变更数

 计划成本对比实际成本

 计划工期对比实际工期

 测试里程碑的计划日期对比实际日期

 有关测试的项目里程碑（如代码冻结）的计划日期对比实际日期

 产品（质量）风险状态、通常按已缓解与未缓解的风险，主要的风险区域、测试分析后发现的新风险等分类统计

 由于阻塞事件或计划的变更导致的测试工作量、成本或时间损失的百分比

 确认和回归测试状态

和监督测试结束活动相关的度量包括：

 测试执行期间已执行的、通过的、失败的、无法执行的和跳过不执行的测试用例的百分比

 纳入可复用的测试用例库的测试用例的百分比

 自动化的测试用例的百分比或计划的与实际的自动化的测试用例百分比对比  并入回归测试的测试用例的百分比

 已解决／未解决的显著缺陷报告的百分比

 识别和归档的测试工作产品的百分比

另外，标准的项目管理技术，如工作分解结构，通常被用来监督测试过程。在敏捷团队中，测试是燃尽图上用户故事进展的一部分。使用精益管理技术时，测试进展以一系列故事为基础，通常通过用户故事卡在看板图上移动的状态来监督。

在给定了一组度量标准后，度量数据可以通过口头陈述、在表格中以数值的形式，或用图形来进行汇报。度量数据可以有很多用途，包括：

 分析，找出可从测试结果中观察到的趋势和原因

 汇报，将测试结果告知感兴趣的项目参与人和项目干系人

 控制，改变整个测试或项目的进程和监督进程纠正的结果

收集、分析和报告这些测试度量数据的适当方式取决于具体的信息需要、目标和使用这些度量数据的个人能力。另外，测试报告的具体内容也应该根据不同的读者而变化。

为了测试控制的需要，非常重要的一点是度量数据必须能够提供给测试经理有关整个测试过程（测试计划完成后）的信息，并能指导测试经理成功完成测试任务、实施测试策略和实现测试目标。因此在计划时一定要考虑到信息需要，监督时一定要包括收集任何需要的工作产品度量。需要的信息量和采集信息需要的工作量取决于各种项目因素，包括项目规模、复杂度和风险。

测试控制一定要回应测试产生的信息和项目或活动存在的不断变化的环境。例如，如果动态测试在某些认为不可能有很多缺陷的区域发现了缺陷群，又如由于测试开始时间延迟导致测试执行周期缩短，则必须对风险分析和计划作出修改。这么做可能需要对测试优先级重新设定和对剩余的测试执行工作重新进行分配。

如果通过测试进展报告发现与测试计划出现了偏差，则应执行测试控制。测试控制的目的是为项目和／或测试重新定向到更可能取得成功的方向。当项目的控制工作取决于测试结果或受测试结果影响时，需要考虑以下内容：

 修改质量风险分析、测试优先级和／或测试计划

 增加资源或增加项目或测试工作量

 推迟发布日期

 放松或加强测试出口准则

 改变项目的范围（功能或非功能）

实施这些内容通常需要项目或业务干系人之间达成共识，并且取得项目或业务经理的同意。

测试报告中发布的信息应该大部分取决于目标读者，如项目管理人员或业务管理人员的信息需要。项目经理最可能感兴趣的是关于缺陷的详细信息，而业务经理最关注的可能是产品风险的状态。