测试活动的监控，对于整体测试工程而言是非常重要的管理内容。
测试工作本身是非常依赖项目其他环节的，测试活动的进行充满了变数。所以对测试的实行情况进行持续的监控和做出及时应对，是管好一个测试项目的必要工作。
测试的监控是一个贯穿于整个测试周期内的工作。
在一些情况下，监控的行为并不需要非常系统化的规划和定义，即使如此他很可能也在实时发生着。比如询问某个测试人员的工作进展情况，就可以视作基础的监控动作。对于复杂度相对较低，流程梳理清晰的项目而言，监控工作可能并不复杂，也无需精密的体系和机制进行保证。但是对于复杂平台等一些项目，建立良好的监督控制框架可能是有必要的。
1.监控的目标
在理想情况下，参照V模型理论，我们项目研发应该从项目立项到需求分析到设计到编码，测试从需求评审到测试计划到测试设计到测试执行和报告，有条不紊的开展下去。每个阶段都产出高质量的产出，为下一个或下几个阶段提供支撑。
然而，在实际工作场景中，我们有可能遇到复杂的甚至是计划和预料之外的情况。
比如：
- 需求到位不及时，或者需求文档质量低下，测试依据不足；
- 单元测试覆盖率不达标甚至整体缺失，底层测试不充分；
- 代码提测时间延期，压缩测试时间；
- 交付产品缺陷情况超出预期，测试任务加重；
- 项目计划无预期变更，测试原本规划被打乱；
- 等等......
笔者将监控的目标总结如下：
l 进度掌控
-把握项目进度情况，根据实际与排期之间的差别及时做出调整。
l 管理风险
-及时对项目中的风险进行识别和评估，并作出控制和缓解。
l 解决问题
-做为管理方主动发现和解决团队成员工作中遭遇到的实际困难和问题。
l 加强协同
-通过监控达到加强团队协同能力的目的。
总的来说，管理人员必须及时跟进测试实施情况，一旦发生进度滞后，质量低下等影响产品按期高质量交付的情况，必须采取合适的控制行动，扭转这些偏离和异常。良好规划的测试计划是测试管理人实行监督控制的基准和依据，所以也要求我们的计划本身需要高质量制定。良好的计划会使得监督工作更容易展开，有更明确的测试目标和安排，也就更容易让我们发现实际开展过程中的异常。
实际操作过程中，对异常情况或者目标偏离的控制手段，可以是计划的变更以适应实际情况，也可以是资源（人员，时间）的调整。在这个过程中，很有可能需要项目其他方面的协调协助，测试管理人应该始终与项目其他干系人保持良好的合作关系。
为了保证测试任务能够顺利完成，建立有效的监控机制是有必要的。
2. 建立监控机制
2.1. 监控整体流程
我们可以用一系列的活动来组织监控流程，一个良好的监控流程应该有以下阶段：
- 信息采集
- 问题分析
- 实施控制
具体到过程上：
- 了解情况
- 发现问题
- 核实问题
- 评估影响
- 给出方案
- 解决问题
如下图所示：
2.2. 触发机制
监控触发机制定义测试管理人员在什么触发条件下，启动监控手段。
CMMi定义了以下三种启动形式：
l 定期监控
- 安排固定的监控周期，比如每天、每周等。
项目的管理安排一般都会确定这样的定期活动，比如周例会是很多项目会采取的形式，会议中与会各方会提供关于项目进展的信息以供跟踪控制。
在敏捷型项目中，一个Scrum会议就是典型的定期监控活动，每天项目成员会集体讨论各自的工作进展情况；而在每一个冲刺期的最后阶段，还会安排当前冲刺期的定期回顾会议活动。
l 阶段性监控
-以项目生命周期各阶段的里程碑为标记，通过里程碑的评审会议来对项目的各种参数进行跟踪和监控。
前文我们在测试计划中提到了里程碑的概念，一个里程碑的到达标识着阶段性成果的达成。之所以要设置里程碑，最主要的意义就在于给我们预先设立一个检查点，让我们检查项目进度情况。
l 事件触发性监控
-当突发性事件发生时，需要启动及时的控制手段以应对事件的影响。比如需求的计划变更；比如人员的变动等。
除了以上这些触发场景之外，测试管理人也需要实时关注测试工作进展，保证测试任务尽可能无偏差完成。
2.3. 度量机制
测试管理人应该建立相应的度量指标，这样才更有利于对相应情况进行比对分析。否则如果缺乏明确的度量办法，监督得出的结论可能偏向主观评判。
测试的监控对象主要可以有以下方面：
- l 质量风险 ·
- l 缺陷 ·
- l 测试进度 ·
- l 覆盖率 ·
- l 信心
在项目和业务中，产品风险、缺陷、测试和覆盖率可以，且通常以特定的方式进行度量和汇报。如果这些度量数据和测试计划中定义的出口准则相关，他们可以作为判断测试工作是否完成的客观标准。信心的度量可以通过调查或使用覆盖率作为替代度量，不过通常也会以主观的方式汇报信心。
如果以上内容在项目中适合做为监控对象，那么测试管理人应该尽量明确量化的标准，并且建立这些相关数据的采集办法。
比如对于风险的监控，可以采用的度量：
- l 完全覆盖的风险百分比
- l 部分覆盖的风险的百分比
- l 还未完全测试的风险的百分比
- l 按风险类别划分的覆盖的风险百分比 ·
- l 在初次质量风险分析后识别的风险的百分比
对于测试过程的监控，可以采用的度量：
- l 已定义的测试工作项（比如用例设计）的完成度与完成时间
- l 已计划的、已详细说明（已实施）的、已运行、通过的、失败的、无法执行的和跳过不执行的 测试总数 ·
- l 回归测试和确认测试的状态，包括趋势和未通过的回归测试总数及未通过的确认测试总数 ·
- l 计划的每日测试时长对比实际的每日测试时长 ·
- l 测试环境的可用性（准备测试团队可用的测试环境占计划测试时长的百分比）
对于缺陷情况可以采用的度量：
- l 缺陷到达率：缺陷在一定时间段内爆出的数量；
- l 缺陷移除率：缺陷在发生阶段被移除的情况；
- l 缺陷分布：缺陷在不同模块或子系统中出现的占比；
- l 缺陷修复率：单位时间内，报出的，被修复的以及遗留的缺陷数量的对比；
除了这些以外还有缺陷有效率，缺陷类型统计等等可以帮助我们去度量缺陷收敛情况的数据。
对于覆盖率监控，可以采用的度量：
- l 需求和设计要素的覆盖率 ·
- l 风险覆盖率 ·
- l 环境／配置覆盖率 ·
- l 代码覆盖率
2.4. 信息采集机制
上节提到的数据度量，都需要基于足够并且准确的数据才能完成，所以有必要建立高效的数据采集机制。可以考虑采用以下办法：
- l 问讯 ·
- 即测试管理人主动向测试干系人和测试人员询问进度情况
- l 阶段性汇报
- 比如日报和周报的手段，收集测试人员关于工作内容及时间花费、测试执行情况、缺陷收敛情况、需要解决之问题以及未来大致安排等信息。
- 这些信息需要被整合，得出整体进度、缺陷、工作安排、严重问题的汇总。
- l 跟踪矩阵
- 采用跟踪矩阵的形式，收集测试活动进程信息。
- 常见的矩阵可以从个人工作信息和汇总信息两个层面组织。
比如个人层面：
汇总层面：
采用图表跟踪的办法可以让收集的信息呈现出更高的可视性和可读性，例如：
3. 补充
最后，测试监控的目的，不仅仅是确保测试进度、完成情况与计划和预期的吻合。对于测试管理人而言，我们测试管理的终极目的在于对质量的保证，而不单单是完成测试的任务。像之前章节中提到的，测试做为整体研发的反馈回路，测试监控中收集到的信息和分析，也是对于项目整体情况的反馈信息源。
测试工作本身并不能直接产出质量，就像用体重器称重并不能减肥一样。测试需要依靠它的反馈功能，来促使问题的解决和质量的提高。
测试的反馈作用体现在汇报问题和促进问题解决，还表现在用测试的信息收集功能，对于整个研发过程乃至项目管理的情况进行反馈，帮助解决研发过程和管理效能方面的问题。测试监督过程中收集到的数据和信息，都可以用于研发过程能力的反馈。比如项目计划阶段，我们通过风险评估可能会得出某一模块出现缺陷的分概念较低的结论。但是实际测试过程中，可能反映出的实际情况是该模块缺陷频繁爆出。这样的信息可以很大程度推出开发过程出现了未预知的问题。
测试管理人应该及时将类似问题系统化，并反馈给开发负责人，依靠和告知团队其他干系人比如项目经理。不能一味的依靠测试执行工作去解决这样的现状，而是要争取从研发链路的更上游控制问题的解决。