我们该如何进行bug总结？

超、凢脫俗 2022-09-16 13:24 227阅读 0赞

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

### 我们该如何进行bug总结？ ###

*  一、什么样的bug需要进行总结？
 *   *  1、线上遗漏的bug
     *  2、非线上遗漏的bug。
 *  二、什么时机进行bug总结？
 *  三、总结什么内容？
 *  四、怎么分析bug原因？
 *   *  1、 非遗漏问题
     *  2、用例设计遗漏
     *  3、用例执行遗漏
     *  4、重现率低的问题
     *  5、体验性或性能问题未关注到
 *  五、如何进行方案改进？
 *   *  1、非遗漏问题
     *  2、用例设计遗漏
     *  3、用例执行遗漏
     *  4、重现率低的问题
     *  5、体验性或性能问题未关注到
 *  六、推行RCA会议
 *   *  1、RCA介绍
     *  2、RCA的分析工具
     *  3、RCA具体操作流程
     *   *  1. 选择合适的问题进行分析
         *  2. 选择合适的人参加分析
         *  3. 召开正式的RCA分析会议
         *  4. 定期回顾和跟踪
         *  5. RCA会议结束
     *  4、RCA分析会议四部曲
     *   *  1. 获取问题
         *  2.5Why分析
         *  3. 答案反推
         *  4. 制定行动计划
     *  5、RCA的核心意义
 *  七、总结

# 一、什么样的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我们一定要整理并分析形成缺陷报告，通过统计分析，找出可以避免的生产故障，使生产故障率有效降低，并形成统一分析模板。![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5aW95aW95YWI55SfJk1yLkxp_size_20_color_FF0000_t_70_g_se_x_16]

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5aW95aW95YWI55SfJk1yLkxp_size_20_color_FF0000_t_70_g_se_x_16]: /images/20220828/23803b76b074488193f8b7ae6218abf0.png

发表评论取消回复

表情：

评论列表（有 0 条评论，227人围观）

还没有评论，来说两句吧...

相关阅读

相关如何进行bug总结？

在项目过程中，测试同学会发现大量的bug，但同时也不可避免的会存在一些遗漏的bug。为了能够减少遗漏bug的现象，我们需要针对遗漏的问题进行总结，从教训中积累经验，总结方...

超、凢脫俗/ 2024年05月23日 18:42/ 0 赞/ 63 阅读

相关软件测试必知：Bug测试该如何进行

Bug，即软件中的缺陷或错误，可能导致软件功能异常、性能下降甚至系统崩溃。因此，通过Bug测试来发现并修复这些潜在问题，对于确保软件质量至关重要。

快来打我*/ 2024年05月23日 18:34/ 0 赞/ 61 阅读

相关我们该如何看待AI的崛起

1.当前作为一名AI工程师，我使用多种AI智能工具，用于机器学习、深度学习和自然语言处理等领域的工作。以下是我最常用的AI智能工具： TensorFlow：是一个广

不念不忘少年蓝@/ 2024年03月23日 11:58/ 0 赞/ 54 阅读

相关我们该如何保护自己的密码？

> 我们的信息在互联网的数据库究竟是如何存储的，我们又该如何保护自己的信息和隐私呢？最近某大学生常用学习软件“XX通”疑似出现了用户数据泄露，可能有超过1.7亿条信息被泄露

男娘i/ 2023年10月03日 19:26/ 0 赞/ 28 阅读

相关我们该如何高效的学习？

本文在这里不讨论学习方法，关于学习的方法网上已经太多了，这里只谈一下我所认识的学习，以及如何进行高效率的学习。 1.正确的认识学习在我们每个人的学习过程中，都

痛定思痛。/ 2023年06月08日 03:27/ 0 赞/ 10 阅读

相关软件测试在不同应用场景中，我们该如何进行测试呢？

在我们的日常工作中，我们通常接触到的都是比较复杂的系统。而复杂的系统就意味着比较复杂的测试程序。首先，对于复杂的系统来说，如果想要做功能测试，一般需要考虑到测试数据的问题，还要

不念不忘少年蓝@/ 2023年01月12日 01:43/ 0 赞/ 147 阅读

相关我们该如何进行bug总结？

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

超、凢脫俗/ 2022年09月16日 13:24/ 0 赞/ 228 阅读

相关遇到bug我们如何分析定位？

前言：日常工作中，每天可能都会遇到不同的bug，有些刚入行的测试喜欢不加分析就直接甩给开发去解决。开发比较闲还好，如果手头工作比较多，就容易烦。甚至有可能是后端的问题，但是你却

古城微笑少年丶/ 2022年08月28日 05:40/ 0 赞/ 207 阅读

相关我们如何进行代码审查

本文来源于我在InfoQ中文站原创的文章，原文地址是：[http://www.infoq.com/cn/news/2014/01/how-we-do-code-review][

矫情吗；*/ 2022年08月24日 14:10/ 0 赞/ 227 阅读

相关该如何教育我们的下一代

以前我们常常开玩笑说：“一人吃饱全家不饿”，可一旦你升级成爸妈了，你的身上自然就多了一份责任，你就不得不思考一些以前压根不当回事的问题，比如：该如何教育我的孩子。就在17年

清疚/ 2022年05月29日 22:01/ 0 赞/ 224 阅读