在项目过程中，测试同学会发现大量的bug，但同时也不可避免的会存在一些遗漏的bug。为了能够减少遗漏bug的现象，我们需要针对遗漏的问题进行总结，从教训中积累经验，总结方法，从而提高测试的覆盖度，提升产品的整体质量。
什么样的bug需要进行总结？
1.线上遗漏的bug
没有被测试发现而遗漏到线上的bug。其影响不言而喻，会直接影响用户的体验，影响产品的口碑，势必需要进行总结。
2.非线上遗漏的bug。
没有在规定的测试阶段发现，从而导致发现晚的bug，例如XX模块已经测试完毕，结果后来又发现该模块的新bug。这类bug会导致增加bug修改和验证的时间，从而有可能影响项目的整体进度，甚至导致项目delay。
什么时机进行bug总结？
项目上线后，应尽快进行bug总结，否则时间一长会出现遗忘的情况，包括测试和开发两方面，给总结操作带来不便。
遇到严重的或非常重要的遗漏bug，可随时进行单独总结，比如线上发现的严重问题。
总结什么内容？
总结bug的核心，是为了后续减少遗漏bug，提高测试覆盖度，提升项目质量。想要达到这个目的，首先需要分析bug的原因，尤其是遗漏原因；其次是确定后续的改进方案，避免类似的问题再次发生。
原因分析：
bug遗漏的原因一般分为几大类：
非遗漏问题：bug总结时，出现概率最高的可能就是非遗漏问题，这类问题并不需要进行具体的总结，其中主要包含三类：
不是问题：例如用户反馈的问题，但符合产品的需求要求，这种就属于不是问题。
开发引入：例如我们测试完成的模块，开发修改bug，或在测试不知情的情况下修改了代码，引入的新bug。
需变引入：例如我们测试完成的模块，发生了需变，导致新的bug产生。
用例设计遗漏：bug是用例设计时没有覆盖到的场景，又可以细分为几类：
基础用例设计不足：例如需求中详细说明的内容，没有在用例中提现。
需求理解错误：例如需求理解错误，导致测试用例的预期结果不正确，而开发实现正好符合错误预期。
模块间影响考虑不足：例如没有A模块与B模块有关联，会对B模块产生影响，但B模块的用例中未涉及到相应的场景。
复杂路径无法覆盖：路径过于复杂，或者涉及较多层级的操作，例如经过10步操作后才会出现的bug。
复杂场景考虑不足：例如两个或多个看似完全没有关系的场景，结合起来产生的bug。
适配问题考虑不足：例如在某些特定的机型上出现的bug。
用例执行遗漏：bug是执行用例过程中出现过，但没有被发现，可细分为2类：
纯执行遗漏：测试用例中涵盖，但没有执行；或者执行了用例，也出现了问题，发现了问题但没有提交bug。敏感度不足：测试用例中涵盖，但没有明确说明，遇到了问题，但没有- 意识到是bug。例如同样都是头像，在A页面是个圆的，在B页面是个方的。
重现率低的问题：重现几率较低的bug，无稳定复现的步骤。
体验性或性能问题未关注到：需求中没有明确说明，也未在用例中涉及，但对用户体验有影响，后经其他方指出的bug。例如产品logo不够明确、使用过程中设备发热等。
改进方案：
针对bug遗漏的不同原因，也有不同的改进方案。
非遗漏问题：这种类型，与测试无关，无需改进。
用例设计遗漏：
补充对应模块的测试用例，这个是基础。
补充后的case是否具有通用性，如果有，那么需要应用到所有相关的模块中，并作为后续用例设计的经验积累。例如：锁屏后再解锁会导致某个页面控件的功能失效，那么各个页面都应该添加“锁屏后再解锁，检查控件可用”的case。
用例执行遗漏：
纯执行遗漏不可饶恕，除了自己做好备忘外，没什么更好的改进办法，这个层面出现问题，更多的应该是自我反思。
如果是敏感度不足导致的遗漏，那么可以持续进行经验积累，提升自己对bug的认知。
重现率低的问题：
如果是能够找到具体原因的bug，那么应该深入挖掘，找到问题的本质原因以及重现步骤，然后再进行分析，对遗漏原因进行归类，然后再进行针对性的改进。
如果是无法找到具体原因的bug，这块暂无有效的改进方法。
体验性或性能问题未关注到：这类问题的改进方案跟敏感度不足的改进方案类似，需要持续的进行积累，提升自己的产品感觉。
其实对于bug总结，应该正面认识，并不是一味的追讨责任，而是更好的改进测试方法、提升测试是能力。认真做好bug总结，对测试团队、测试个人的能力提升，都有很大的帮助。
感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
