在软件项目测试过程中，我们可能会“发掘”大量的bug，与此同时，也不可避免的会漏掉一些bug。为了能减少bug遗漏的情况，我们需要针对遗漏的bug进行分析总结，从教训中积累经验、总结方法，从而提高软件测试的覆盖度，提升产品的整体质量。
什么样的bug需要进行总结？
1、遗漏到线上的bug
没有被测试发现而遗漏到线上的bug。其直接影响到用户的体验和产品的口碑，势必需要进行总结。
2、内部测试阶段遗漏的bug
没有在规定的测试阶段发现，而导致晚发掘的bug。例如，XX模块已经测试完毕，结果后面又发现该模块的新bug。这类bug会导致bug修改和验证的时间增加，从而可能影响项目的整体进度，甚至导致项目延期。
进行bug总结的时机？
1、软件项目上线后，应尽快对bug进行总结。否则，时间一长会出现遗忘的情况（包括测试和开发两方面），给总结操作带来不便。
2、遇到严重的或致命级的遗漏bug，可随时进行单独总结，比如线上发现的严重问题。
那，我们需要总结哪些内容？
总结bug的目的
是为了后续减少遗漏bug，提高测试覆盖度，最终提升项目质量。想要达到此目的，首先需要分析bug的原因，尤其是遗漏原因；其次是确定后续的改进方案，避免类似的问题再次发生。
bug遗漏的常见原因有哪些？
1、非遗漏bug：bug总结时，出现概率最高的可能就是非遗漏问题，这类问题并不需要进行具体的总结，其中主要包含三类：
不是bug：例如用户反馈的问题，但符合产品的需求要求，这种就不属于bug。
开发引入：例如我们测试完成的模块，开发修改bug，或在测试不知情的情况下修改了代码，引入的新bug。
需变引入：例如我们测试完成的模块，发生了需求变更，导致新的bug产生。
2、用例设计遗漏：bug是用例设计时没有覆盖到的场景，又可以细分为几类：
基础用例设计不足：例如需求中详细说明的内容，没有在用例中体现。
需求理解出错：例如需求理解错误，导致测试用例的预期结果不正确，而开发实现正好符合错误预期。
模块间影响考虑不足：例如没有A模块（与B模块有关联），会对B模块产生影响，但B模块的用例中未涉及到相应的场景。
复杂路径无法覆盖：路径过于复杂，或者涉及较多层级的操作，例如经过10步操作后才会出现的bug。
复杂场景考虑不足：例如两个或多个看似完全没有关系的场景，结合起来产生的bug。
适配问题考虑不足：例如在某些特定的机型上出现的bug。
3、用例执行遗漏：bug是执行用例过程中出现过，但没有被发现，可细分为两类：
纯执行遗漏：测试用例中涵盖，但没有执行；或者执行了用例，也出现了bug，发现后没有提交bug。
敏感度不足：测试用例中涵盖，但没有明确说明，遇到了问题，但没有意识到是bug。例如同样都是头像，在A页面是个圆的，在B页面是个方的。
4、重现率低的问题：重现几率较低的bug，无稳定复现的步骤。
5、体验性或性能问题未关注到：需求中没有明确说明，也未在用例中涉及，但对用户体验有影响，后经他方指出的bug。例如产品logo不够明确、使用过程中设备发热等。
发现以后后，制定改进方案
针对bug遗漏的不同原因，也有不同的改进方案。
1、针对非遗漏问题
这种类型，与测试无关，无需改进。（建议反馈给上游团队，毕竟质量不仅仅靠测试团队）
2、针对用例设计遗漏：