前段时间开展了“构建全方位的测试管理体系”公开课，课堂中和学员探讨了如何对测试执行进度进行监控的问题。本文将讨论的内容进行整理，供大家参考。
测试执行进度的监控，所谓的监控实际包含了两层含义，“监”指的是监督Monitoring，简单层面可以理解为在测试过程中收集各种数据并进行分析，得到当前的测试状态，而“控”指的是控制Control，当监督过程中收集与分析数据得到当前状态，并与计划中的目标进行比较，假如两者之间的偏差超过了计划中定义的管理阈值，此时就需要采取行动进行控制。
测试执行进度的监控，是为测试目标服务的，例如：评估软件版本是否可以及时发布？当前的软件产品质量如何等？本文主要从5个角度进行讨论：
1、产品风险
2、测试Tests
3、缺陷
4、覆盖率
5、信心
一、产品风险
测试过程中经常采用基于需求的测试策略和基于风险的测试策略，因此通过收集产品风险相关的信息，就可以帮助确定当前的测试执行进度状态。假如采用基于风险的测试策略，那么测试过程中会识别产品风险，然后通过测试分析与设计阶段分别得到对应的测试条件和测试用例，假如在测试执行过程中发现缺陷，由于确保了测试的可追溯性（具体的可追溯性概念，可参考文章：测试过程中的可追溯性要求），因此就可以确定哪个风险得到了缓解，哪个风险变成了真实发生的事件。
从测试执行进度的角度，可以通过产品风险对应的测试用例状态，进行定性和定量的剩余风险分析，以确定是否满足测试计划中对风险的阈值要求。与产品风险相关的主要例子包括：
1）与产品风险关联的测试用例执行通过的百分比，即哪些产品风险通过测试得到了缓解；
2）与产品风险关联的测试用例执行失败的百分比，即哪些产品风险没有得到缓解，变成了需要采取行动的事件（剩余风险的情况，可以参考下图）；
3）未完全测试的产品风险百分比；
4）按照风险级别划分的覆盖的风险百分比；
5）初次产品风险分析后再识别的产品风险百分比（用于判断前期风险识别和分析的有效性）；
二、测试Tests
测试Tests通常也是作为测试执行进度监控的重要组成部分，也是出口准则定义中的重要考虑项，例如：要求执行的测试用例通过率必须达到95%。同样的，通过“产品风险”中提到的可追溯性要求，不管是具体需求还是产品风险，最终会设计对应的测试用例进行覆盖，根据其执行的实际状态评估其是否实现或得到缓解。因此针对测试Tests也可以进行通过或失败进行监控，同时，也经常会对执行情况进行分析。与测试Tests相关的主要例子包括：
1）不同状态测试Tests的统计数据，例如：已计划的、已实施的、已运行的、通过的、失败的、无法执行的（被阻塞的）和不执行等；
2）回归测试和确认测试的状态，包括未通过的回归测试和确认测试的趋势；
3）计划的测试周期与实际的测试周期；
下面分别是测试执行率和测试通过率的跟踪数据的例子：
三、缺陷
根据发现的缺陷对测试执行进度进行监控，也是一个重要的手段。其相关的数据主要包括（下图是两个例子）：
1）已发现的缺陷总数与已修复的缺陷总数的趋势图；
2）失效的平均时间间隔和失效出现率；
3）按不同缺陷分类的统计数据，例如：功能模块或组件、缺陷发现和移除阶段、优先级/严重程度、根本原因、拒绝或重复的报告等；
4）从报告缺陷到修复缺陷所花的时间趋势；
四、覆盖率
基于前面提到的可追溯性要求，我们就可以针对不同的对象进行覆盖率的数据收集和分析，例如：
1）需求覆盖率；
2）产品风险覆盖率；
3）环境配置覆盖率；
4）代码覆盖率；
五、信心
信心主要来自两个层面，一方面可以参考前面4个维度的客观的度量指标进行评估，而另一方面，可以来自负责该功能测试的测试人员的主观判断。
上面提到的5个维度，可以为测试人员，特别是测试经理监控测试执行进度提供很好的视角。当然，具体采用的维度和数据，还是要根据测试周境进行调整，重要的是适合你的要求。另外，测试过程中数据收集和分析，必定要以大家对相关度量理解一致的基础之上，以便大家可以同样理解和报告当前的状态。同时，根据测试级别的不同，所选择的数据也会不一样。这是在实际过程中需要注意的。记住：收集和分析数据都是为你的目标服务，而不是为了收集而收集。
