有句话是不要让你的野心无处安放，那么你想做测试主管，却不知道测试主管的工作和测试专员的工作有何区别，连测试主管必须要建立的监控机制都不知道，你说你怎么做测试主管?甚至现在还有人问建立监控机制有何作用?其实作用很简单，就是为了保证测试任务能够顺利完成而建立的。今天我们就来聊聊如何建立有效的监控机制!

监控整体流程

我们可以用一系列的活动来组织监控流程。

一个良好的监控流程应该有以下阶段：

◆ 信息采集

◆ 问题分析

◆ 实施控制

具体到过程上：了解情况、发现问题、核实问题、评估影响、给出方案、解决问题。

如下所示：

信息收集阶段：了解情况——发现问题——核实问题

问题分析：评估影响——提出方案

控制实施：解决问题

触发机制

监控触发机制定义测试管理人员在什么触发条件下，启动监控手段。

CMMi定义了以下三种启动形式：

l 定期监控：安排固定的监控周期，比如每天、每周等。

项目的管理安排一般都会确定这样的定期活动，比如周例会是很多项目会采取的形式，会议中与会各方会提供关于项目进展的信息以供跟踪控制。

在敏捷型项目中，一个Scrum会议就是典型的定期监控活动，每天项目成员会集体讨论各自的工作进展情况。

而在每一个冲刺期的最后阶段，还会安排当前冲刺期的定期回顾会议活动。

l 阶段性监控：以项目生命周期各阶段的里程碑为标记，通过里程碑的评审会议来对项目的各种参数进行跟踪和监控。

前文我们在测试计划中提到了里程碑的概念，一个里程碑的到达标识着阶段性成果的达成。

之所以要设置里程碑，最主要的意义就在于给我们预先设立一个检查点，让我们检查项目进度情况。

l 事件触发性监控：当突发性事件发生时，需要启动及时的控制手段以应对事件的影响。

比如需求的计划变更;比如人员的变动等。

除了以上这些触发场景之外，测试管理人也需要实时关注测试工作进展，保证测试任务尽可能无偏差完成。

度量机制

测试管理人应该建立相应的度量指标，这样才更有利于对相应情况进行比对分析。

否则如果缺乏明确的度量办法，监督得出的结论可能偏向主观评判。

测试的监控对象主要可以有以下方面：

l 质量风险

l 缺陷

l 测试进度

l 覆盖率

l 信心

在项目和业务中，产品风险、缺陷、测试和覆盖率可以，且通常以特定的方式进行度量和汇报。

如果这些度量数据和测试计划中定义的出口准则相关，他们可以作为判断测试工作是否完成的客观标准。

信心的度量可以通过调查或使用覆盖率作为替代度量，不过通常也会以主观的方式汇报信心。

如果以上内容在项目中适合做为监控对象，那么测试管理人应该尽量明确量化的标准，并且建立这些相关数据的采集办法。

比如对于风险的监控，可以采用的度量：

l 完全覆盖的风险百分比

l 部分覆盖的风险的百分比

l 还未完全测试的风险的百分比

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

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

对于测试过程的监控，可以采用的度量：

l 已定义的测试工作项(比如用例设计)的完成度与完成时间

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

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

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

l 测试环境的可用性(准备测试团队可用的测试环境占计划测试时长的百分比)

对于缺陷情况可以采用的度量：

l 缺陷到达率：缺陷在一定时间段内爆出的数量;

l 缺陷移除率：缺陷在发生阶段被移除的情况;

l 缺陷分布：缺陷在不同模块或子系统中出现的占比;

l 缺陷修复率：单位时间内，报出的，被修复的以及遗留的缺陷数量的对比;

除了这些以外还有缺陷有效率，缺陷类型统计等等可以帮助我们去度量缺陷收敛情况的数据。

对于覆盖率监控，可以采用的度量：

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

l 风险覆盖率

l 环境/配置覆盖率

l 代码覆盖率

信息采集机制

上节提到的数据度量，都需要基于足够并且准确的数据才能完成，所以有必要建立高效的数据采集机制。

可以考虑采用以下办法：

l 问讯：即测试管理人主动向测试干系人和测试人员询问进度情况

l 阶段性汇报：比如日报和周报的手段，收集测试人员关于工作内容及时间花费、测试执行情况、缺陷收敛情况、需要解决之问题以及未来大致安排等信息。

这些信息需要被整合，得出整体进度、缺陷、工作安排、严重问题的汇总。

l 跟踪矩阵：采用跟踪矩阵的形式，收集测试活动进程信息。

常见的矩阵可以从个人工作信息和汇总信息两个层面组织。

采用图表跟踪的办法可以让收集的信息呈现出更高的可视性和可读性。

补充

最后，测试监控的目的，不仅仅是确保测试进度、完成情况与计划和预期的吻合。

对于测试管理人而言，我们测试管理的终极目的在于对质量的保证，而不单单是完成测试的任务。

像之前章节中提到的，测试做为整体研发的反馈回路，测试监控中收集到的信息和分析，也是对于项目整体情况的反馈信息源。

测试工作本身并不能直接产出质量，就像用体重器称重并不能减肥一样。

测试需要依靠它的反馈功能，来促使问题的解决和质量的提高。

测试的反馈作用体现在汇报问题和促进问题解决，还表现在用测试的信息收集功能，对于整个研发过程乃至项目管理的情况进行反馈，帮助解决研发过程和管理效能方面的问题。

测试监督过程中收集到的数据和信息，都可以用于研发过程能力的反馈。

比如项目计划阶段，我们通过风险评估可能会得出某一模块出现缺陷的分概念较低的结论。

但是实际测试过程中，可能反映出的实际情况是该模块缺陷频繁爆出。

这样的信息可以很大程度推出开发过程出现了未预知的问题。

测试管理人应该及时将类似问题系统化，并反馈给开发负责人，依靠和告知团队其他干系人比如项目经理。

不能一味的依靠测试执行工作去解决这样的现状，而是要争取从研发链路的更上游控制问题的解决。

感谢您的阅读，以上就是对测试主管建立有效监控机制的一些流程、方法所作的一些阐述，你理解了吗?更多软件测试相关的内容尽在达内软件测试培训机构官网，敬请关注!

免责声明：内容和图片源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。