缺陷分析测试人员绕不开的知识点

缺陷分析也是测试工程师需要掌握的一个能力，但是很多时候大家只记得要提交缺陷、统计缺陷情况，而忽视了缺陷分析。

其实每个项目的缺陷记录都是有很大价值的。在测试阶段分析当前缺陷情况，及时发现存在的问题并调整测试策略，才能降低风险和损失。测试结束后也需要通过缺陷分析进行总结，做得好的地方继续发扬，做得不好的地方及时反思改正。

很多同学会疑惑，如果要进行分析，要从哪里入手呢？下面是几个缺陷分析的着手点：

总的缺陷趋势

正常的趋势应该是前期快速上升，中期平缓增长，后期基本稳定。

如果缺陷不是在前期上升，而是在中后期上升，那就要分析是前期测试时没有全力投入人力和时间，还是测试态度和能力问题，或者在测试中期开发同学调整设计导致的缺陷数增加。

提测后出现的问题

提测的标准应该是通过回归测试，且新增功能可正常使用。如果提测后就出现了阻塞、危险级别的问题，那要分析是否没有严格控制提测质量、没有明确验收标准导致。

是否有严重问题在测试几天之后才发现

观察严重及以上级别的问题，是不是在前期发现并解决，如果有在测试了几天之后才提出的严重问题，那要看测试策略是否合理，是不是没有先执行优先级较高的测试点。

开发修复问题引发的缺陷

有的测试用例在一开始执行时是没问题的，但是后面出了问题，很大概率是开发同学在修复问题的时候引发的。每次开发同学提交代码后，测试同学需要看代码改动点并评估影响范围。

如果条件允许的话，将这一步前置：和开发同学一起沟通问题修复的方案，将风险降低。
 

挂起的缺陷

挂起的缺陷一般是不需要关注，或者是经讨论在下一个迭代再补充完成的功能，如果是这样，要考虑为什么三方理解不一致，为什么前面需求评审、设计评审、用例评审时没有发现这个点，而在测试时才出现。

缺陷类型是否单一

测试同学不仅要发现需求、设计漏洞，还需要关注界面、交互上的不足并提出优化建议。

哪个模块缺陷比较多

出现问题越多的模块，待发现的问题也越多。测试阶段需要关注缺陷数比较多的模块，设计更多场景去覆盖。同时，这也要求缺陷管理面板需要提供模块分类的功能，在提交缺陷时也需要大家规范填写该问题所属模块。

重要级别以上的缺陷占比

如果一个项目中，重要级别以上的问题占比较高，说明开发质量有待提升，此时要分析是开发时间被压缩还是新人对业务不熟导致的，需要开发经理特别关注这类项目。

上线后缺陷是否有全部解决/关闭

每天负责人需要提醒相关的开发和测试同学处理缺陷并及时更新缺陷状态，上线前缺陷应该全部关闭(或者少数挂起)，如果没有则需要负责人再次提醒。

这么看缺陷分析也不是很难是不是？细心去发现，你还能探索出更多更有意思的问题。

重要的是要从中发现测试策略问题并及时改正，避免下次再犯同样的问题。此外，还要关注几个点：

一是缺陷的标准需要统一，否则大家的评估标准不同，影响分析结果的准确性；

二是测试同学在项目中需要进行缺陷记录，不要线下默默找开发同学解决了就算了，这样不仅容易导致忘记回归，也会导致项目总结评估不准确。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取