前言：在项目过程中，测试同学会发现大量的bug，但同时也不可避免的会存在一些遗漏的bug。为了能够减少遗漏bug的现象，我们需要针对遗漏的问题进行总结，从教训中积累经验，总结方法，从而提高测试的覆盖度，提升产品的整体质量。

一、什么样的bug需要进行总结？

1、线上遗漏的bug

没有被测试发现而遗漏到线上的bug。其影响不言而喻，会直接影响用户的体验，影响产品的口碑，势必需要进行总结。

2、非线上遗漏的bug。

没有在规定的测试阶段发现，从而导致发现晚的bug，例如XX模块已经测试完毕，结果后来又发现该模块的新bug。这类bug会导致增加bug修改和验证的时间，从而有可能影响项目的整体进度，甚至导致项目delay。

俗话说”人非圣贤，孰能无过“，软件是由人编写的，所以再所难免都会有问题，而我们所要做就是尽量避免出现问题，或者是避免出现重复的问题。

对于软件测试人员来说分析BUG是非常好的一个措施，这样可以检测到测试人员在测试过程中哪些地方考虑不周，或没有考虑到，从而可以提醒测试人员下次思考的范围扩大，尽可能地完全覆盖测试范围。

从分析结果的角度出发，bug大多都是开发人员和测试人员麻痹大意所导致的，并不是不可避免的。

二、什么时机进行bug总结？

1. 项目上线后，应尽快进行bug总结，否则时间一长会出现遗忘的情况，包括测试和开发两方面，给总结操作带来不便。

2. 遇到严重的或非常重要的遗漏bug，可随时进行单独总结，比如线上发现的严重问题。

三、总结什么内容？

总结bug的核心，是为了后续减少遗漏bug，提高测试覆盖度，提升项目质量。想要达到这个目的，首先需要分析bug的原因，尤其是遗漏原因；其次是确定后续的改进方案，避免类似的问题再次发生。

四、怎么分析bug原因？

bug遗漏的原因一般分为几大类：

1、 非遗漏问题

bug总结时，出现概率最高的可能就是非遗漏问题，这类问题并不需要进行具体的总结，其中主要包含三类：

• 不是问题：例如用户反馈的问题，但符合产品的需求要求，这种就属于不是问题。
• 开发引入：例如我们测试完成的模块，开发修改bug，或在测试不知情的情况下修改了代码，引入的新bug。
• 需变引入：例如我们测试完成的模块，发生了需变，导致新的bug产生。

2、用例设计遗漏

bug是用例设计时没有覆盖到的场景，又可以细分为几类：

• 基础用例设计不足：例如需求中详细说明的内容，没有在用例中提现。
• 需求理解错误：例如需求理解错误，导致测试用例的预期结果不正确，而开发实现正好符合错误预期。
• 模块间影响考虑不足：例如没有A模块与B模块有关联，会对B模块产生影响，但B模块的用例中未涉及到相应的场景。
• 复杂路径无法覆盖：路径过于复杂，或者涉及较多层级的操作，例如经过10步操作后才会出现的bug。
• 复杂场景考虑不足：例如两个或多个看似完全没有关系的场景，结合起来产生的bug。
• 适配问题考虑不足：例如在某些特定的机型上出现的bug。

3、用例执行遗漏

bug是执行用例过程中出现过，但没有被发现，可细分为2类：

• 纯执行遗漏：测试用例中涵盖，但没有执行；或者执行了用例，也出现了问题，发现了问题但没有提交bug。
• 敏感度不足：测试用例中涵盖，但没有明确说明，遇到了问题，但没有意识到是bug。例如同样都是头像，在A页面是个圆的，在B页面是个方的。

4、重现率低的问题

• 重现率低：重现几率较低的bug，无稳定复现的步骤。

5、体验性或性能问题未关注到

• 需求不明：需求中没有明确说明，也未在用例中涉及，但对用户体验有影响，后经其他方指出的bug。例如产品logo不够明确、使用过程中设备发热等。

五、如何进行方案改进？

针对bug遗漏的不同原因，也有不同的改进方案。

1、非遗漏问题

• 这种类型，与测试无关，无需改进。

2、用例设计遗漏

• 用例补充：补充对应模块的测试用例，这个是基础。
• 用例通用：补充后的case是否具有通用性，如果有，那么需要应用到所有相关的模块中，并作为后续用例设计的经验积累。例如：锁屏后再解锁会导致某个页面控件的功能失效，那么各个页面都应该添加“锁屏后再解锁，检查控件可用”的case。

3、用例执行遗漏

• 执行遗漏：纯执行遗漏不可饶恕，除了自己做好备忘外，没什么更好的改进办法，这个层面出现问题，更多的应该是自我反思。
• 敏感性遗漏：如果是敏感度不足导致的遗漏，那么可以持续进行经验积累，提升自己对bug的认知。

4、重现率低的问题

• 有原因：如果是能够找到具体原因的bug，那么应该深入挖掘，找到问题的本质原因以及重现步骤，然后再进行分析，对遗漏原因进行归类，然后再进行针对性的改进。
• 无原因：如果是无法找到具体原因的bug，这块暂无有效的改进方法。

5、体验性或性能问题未关注到

• 持续积累：这类问题的改进方案跟敏感度不足的改进方案类似，需要持续的进行积累，提升自己的产品感觉。

六、推行RCA会议

作为软件开发工程师或者管理者的你有没有经常遇到这样的问题：为什么自己的产品不断涌现regression bug？为什么改了一个bug以后，引发出N个其他的bug？甚至很多bug是在客户使用的过程中爆出来的，给公司造成了经济和名誉的损失。如果我们在开发的早期，能够及时地找到产生这些bug的原因并加以修复，就可以最大程度地挽回这些损失了。

1、RCA介绍

根本原因分析法Root Cause Analysis（后面简称RCA）。通过RCA的分析，不仅可以在研发的早期探测到bug，而且还能为管理者提供批判性思维和组织内可持续提高的方向，以进一步地提高产品的质量，形成一个正反馈。

这是一项结构化的问题处理法，用以逐步找出问题的根本原因并加以解决， 而不是仅仅关注问题的表征。根本原因分析是一个系统化的问题处理过程，包括确定和分析问题原因，找出问题解决办法，并制定问题预防措施。在组织管理领域内，根本原因分析能够帮助利益相关者发现组织问题的症结，并找出根本性的解决方案。

2、RCA的分析工具

RCA的分析工具有因果图，头脑风暴法，因果分析-鱼骨图 和因果分析-5why法，每个组织可以根据自己的实际情况，选择对应的方法。MSTR常用的RCA分析工具有两种，一种是5Why分析法，还有一种是鱼骨图（Ishikawa diagram）。 它们都可以帮助我们，有效地找到问题的根本原因，并且提供了清晰的记录方式，以免我们在分析过程中被各种信息淹没。

3、RCA具体操作流程

下面我们来看一下具体的RCA操作流程。如下图所见，整个流程分为5个步骤：

1. 选择合适的问题进行分析

• 比如，有代表性的，引发严重问题和影响的bug。RCA属于深度分析，所以通常会比较耗时，如果每个问题都要分析，会占用较多的组织资源。

2. 选择合适的人参加分析

通常一场分析会需要以下人员参加：

• 项目经理：熟悉RCA流程，把控会议节奏和讨论方向，做好会议记录和后续改进措施的跟踪和汇报。可以是scrum master，或者product owner。
• 开发工程师：引入这个问题的工程师。在会议中讲述整个事件发生的起因经过。提供第一手的分析资料。
• 架构师：从代码架构等角度考虑，帮助开发工程师挖掘根本原因，提出今后改进的方法。
• 测试工程师：从测试的角度出发，去考量是否可以通过测试覆盖率，在测试的早期发现问题。

3. 召开正式的RCA分析会议

• 下面RCA分析会议四部曲会详细介绍。

4. 定期回顾和跟踪

• 在RCA会议产生的改进方法和行动需要定期回顾和跟踪。

5. RCA会议结束

• 对于已经完成所有行动计划的RCA分析进行批准和结案。通常可以选择product owner作为批准者。

4、RCA分析会议四部曲

正式的RCA分析会议包括以下四部曲：

1. 获取问题

获取问题所有相关的消息和事实，比如由开发工程师讲述整个时间的原委：

• 从测试人员或者客户的角度出发，这是一个什么样的问题？在遇到这个问题前，他们是想要做什么？
• 这个问题是在什么情况下，怎么被发现的？
• 从技术分析的角度，这个问题的本质原因是什么？
• 在问题被发现以后，我们是怎么去修复这个问题的？
• 还有其他相关的事实和信息我们需要注意的？

2.5Why分析

用5Why分析工具开始做具体的分析，项目经理可以从第一步已经收集到的事实和现象开始提问，根据大家给出的答案，来判断这是另外一个现象还是根本原因。如果还是现象，再问下一个问题，以此重复，从而推进分析的不断深入，直到找到问题的根本原因。给大家一个最简单的例子帮助大家理解。

• 第一个why: 为什么手机不亮了？
  答：手机电池没电了
• 第二个why: 为什么手机电池没电了？
  答：昨晚没充电。
• 第三个why：为什么昨晚没充电？
  答：家里停电了。
• 第四个why：为什么家里停电了？
  答：自己没缴电费。
• 第五个why：为什么没有缴电费？
  答：没钱了，自己没有合理的理财，月光族。

3. 答案反推

根据上面5个why问完以后得到的答案反推回去，检查逻辑是否正确。注意顺着逻辑向下问，不要跳跃，实际工作中的情况比上述的例子要复杂多，容易跑题。

4. 制定行动计划

以上检查无误以后，开始针对每一个root cause制定行动计划。比如针对上面的例子，行动计划可以下面两个选项。除了做什么，每个行动计划还需要制定行动的执行者和完成期限，以备后面的跟踪。

• 选项一：跟朋友或者亲戚借钱，缴电费。
• 选项二：下回提前每月留出基本生活费，比如电费，通信费等。

5、RCA的核心意义

• RCA的过程是去挖掘问题的根本问题，不是开批斗大会，所以主持人和参会人员不要给引入问题的软件工程师太大的压力，要营造轻松的头脑风暴的氛围。
• 分析过程中，不能着急做出判断和解决方案，因为它们不是真正的root cause，自然我们会制定错误的解决方案。通常4小时的分析也属于正常范畴。
• 所有制定出来的行动计划都是要可以执行的，清晰的，可以衡量的。

七、总结

• 多数bug都是人为的，避免这些情况就需要开发人员在开发过程中多注意，培养良好的编程习惯，而测试人员在测试过程中需要将测试范围考虑完全，尽量避免遗漏测试点，对于不清楚的点，不管是开发还是测试人员，都应该拿出来讨论，切忌闭门造车，不懂装懂。
• 对于bug总结，应该正面认识，并不是一味的追讨责任，而是更好的改进测试方法、提升测试是能力。认真做好bug总结，对测试团队、测试个人的能力提升，都有很大的帮助。
• 对于线上bug我们一定要整理并分析形成缺陷报告，通过统计分析，找出可以避免的生产故障，使生产故障率有效降低，并形成统一分析模板。