告诉你如何从执行测试到管理测试（26）

文/秋之川

【目录】

第二十六章 软件缺陷数据能够告诉你什么？

今天，老大把我喊到办公室叮嘱我，“提测之后每天都要关注项目里的 bug，知道吧？”

我说，“我知道，我每天肯定会及时跟进 Open Bug 的修复进度和 Fixed Bug 的验证进度的。”

他说，“不仅仅是这两类的进度，从 bug 数据里能获取到的项目信息还有很多，我跟你说说，你自己记一下，然后再好好想想。”

1. 根据每个需求模块待修复缺陷和待验证缺陷的数量变化，可以大致了解每个需求的测试进展；
2. 根据缺陷的分布模块，可以分析出问题多发的模块，以此来调整测试策略；
3. 根据每个人的有效缺陷数量，来观察工作量的饱和度；
4. 根据截止到某个时间点的待修复缺陷数量，来判断截止当下的产品质量；
5. 根据回归性缺陷的数量和被多次激活的缺陷数量，来判断开发的代码质量，从而调整测试策略；
6. 如果 Fixed/已修复 的缺陷数量过高，就说明测试工程师没有及时地做验证，那就需要关注一下某个测试工程师的工作状态了，或者看下测试流程是不是有问题。
7. 如果 Deferred/已推迟的缺陷数量过高，就需要检查一下当前项目的计划，是否在人力储备和相关资源储备上有不足之处，导致无法在当下解决。
8. 如果 OnHold/已挂起的缺陷数量过高，就需要安排相关的技术攻坚人员，去预研一下能否解决一些技术限制难题。
9. 如果 Designed/设计的缺陷数量过高，就说明需求评审做的不够好，或者需求文档还不够细，导致很多开发和测试在认知上不一致的问题；
10. 如果 CannotDuplicate/不能复现、NeedMoreInfo/需要更多信息和 NotABug/不是缺陷的数量过高，就说明缺陷报告的质量不高，需要对测试工程师做一些注意事项和执行层面的培训；

除了缺陷的不同状态之外，我们还需要关注缺陷在某些状态上的停留时长，比如：

1. 高优先级和严重的 Open/待修复的缺陷，如果停留时间超过2天，就需要过问一下 fix 进度了，是不是有技术难点需要支援，还是别的原因，导致 fix 延迟。
2. Fixed/已修复的缺陷如果停留时间过长，就需要过问一下，一直不能验证的原因是什么，有什么 block issue 吗？还是任务安排有问题。

最后，我们还需要明确缺陷状态的变更规则和责任人，比如：

1. 任何类型的缺陷都只能被测试工程师关闭。
2. 变更缺陷的优先级和严重级别需要经过产品经理或项目经理的确认，并由测试工程师修改。
3. 将缺陷改为 OnHold 状态，需要开发负责人或开发经理才能决定。

《告诉你如何从执行测试到管理测试》带你迈出第（26）步！，点击这里可查看完整地图

作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵

【目录】