我们如何进行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分析法，还有一种是鱼骨图。他们都可以帮助我们，有效地找到问题的根本原因，并且提供了清晰的记录方式，以免我们分析的过程中被各种信息淹没。

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分析

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

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

3、答案反推

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

4、制定行动计划

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

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

5、RCA的核心意义

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

七 、 总结

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