我们该如何进行bug总结？
前言：在项目过程中，测试同学会发现大量的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总结？
项目上线后，应尽快进行bug总结，否则时间一长会出现遗忘的情况，包括测试和开发两方面，给总结操作带来不便。
遇到严重的或非常重要的遗漏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我们一定要整理并分析形成缺陷报告，通过统计分析，找出可以避免的生产故障，使生产故障率有效降低，并形成统一分析模板。
我们该如何进行bug总结？相关推荐
- spring boot 文件上传工具类（bug 已修改）
以前的文件上传都是之前前辈写的,现在自己来写一个,大家可以看看,有什么问题可以在评论中提出来. 写的这个文件上传是在spring boot 2.0中测试的,测试了,可以正常上传,下面贴代码 第一步:引 ...
- 微信无法连接服务器501,微信成语猜猜看第501关BUG出现全是英文怎么过解决方法...
近日因为跳一跳许多微信小程序游戏异常火爆,其中就包括了成语猜猜看游戏,但是很多小伙伴向小编反应游戏之中出现了BUG,那么微信成语猜猜看BUG怎么办呢?为了帮助各位小伙伴,小编特意带来了成语猜猜看BUG ...
- vscode 格式化某一段代码_VSCode格式化代码功能失效的bug解决方法
VSCode格式化代码功能失效的bug解决方法 前不久我装上了 黑苹果,那么为了快速转移开发环境,我使用了VSCode(Visual Studio Code下面简称VSCode)的插件 Setting ...
- 禅道设置bug模板_一款热度很高的项目管理和bug工具，免费使用，可在公司推广哦...
以前在公司会用到各种bug管理工具,但使用最顺手的感觉还是禅道,主要是它除了能满足我的日常工作之外,用户体验上也做的不错 .前段时间领导碰巧看到了工具,觉得使用它管理项目应该不错,打算在全公司推广,让 ...
- 困扰一周的奇葩bug：重复相似代码多，导致单片机程序跑飞
今天是个好日子,困扰一周的bug终于解决了,迫不及待将这个奇葩问题分享给各位朋友~ 硬件环境: 国产MCU:华大HC32L130 问题描述: 最近做一款基于Modbus协议的三通道温度采集模块,程序设 ...
- java string 占位符_驳《阿里「Java开发手册」中的1个bug》？
前两天写了一篇关于<阿里Java开发手册中的 1 个bug>的文章,评论区有点炸锅了,基本分为两派,支持老王的和质疑老王的. 首先来说,无论是那一方,我都真诚的感谢你们.特别是「二师兄」, ...
- 开发人员绩效考核中有效bug数的统计
我们都知道,开发人员的考核中,bug这块占了一定的比重,那么我们在统计每个开发人员的bug数时,显然要做到有效,不能把缺陷管理系统上的bug不经过处理,就直接进行统计. 如何统计有效bug数呢? 我们 ...
- 一个GDIPlus的Bug -- OutofMemory异常
今天发现 framework2.0中的一个GDIPlus的Bug: 在Form的OnPaint事件里面写如下代码: private void Form1_Paint(object sender, Pa ...
- 从难免的线上bug说起代码的思考
经常是某司线上又出bug了,然后是给公司造成多少损失,追根究底总是可以找到一些原因,诸如:写代码逻辑考虑不全面,或者代码有硬伤,也有测试不充分,甚至不测试都有,也有是运维的问题等等. 我对测试部专业, ...
- Visual Studio2005奇怪的bug及解决【月儿原创】
Visual Studio2005查看设计器打开失败的bug及解决 作者:清清月儿 主页:http://blog.csdn.net/21aspnet/ 时间:2007.3.23 在 ...
最新文章
- C# 多网卡 Server Listen
- Springboot 2.返回cookies信息的get接口开发 和 带cookis去请求
- java web日期_java-web——第十一课 时间类
- mysql创建账号并赋予权限
- 2018年第九届蓝桥杯C/C++ C组国赛 —— 第一题：年龄问题
- 先思再行 闭着眼睛编程
- http://www.od85c.com.cn/html/,OllyDbg script for unpacking Enigma 4.xx and 5.xx
- wps文字表格制作拼音田字格模板_学生练字字帖模板118个打包下载 118个WPS、WORD田字格模板...
- 【转】Linux的僵尸进程解决攻略
- CUDA精进之路（三）：图像处理——图像灰度化、灰度直方图统计
- java中substring与substr的用法
- ping命令两种返回信息的区别
- 2.过滤函数-filter/filter-out
- 在线流程图工具推荐 免费 好用 可与语雀联动
- dblp 数据库(mark)
- 一起来学自然语言处理----加工原料文本
- #1135 : Magic Box（枚举）
- MDX基本概念和语法
- html隐藏链接跳转,HTML 链接
- 【思否编程公开课】限时免费 网络安全之 Kali 渗透入门实战