从Bug中学习--Bug根因分析法

我会带着你远行 2023-10-07 23:03 7阅读 0赞

## 从Bug中学习--Bug根因分析法 ##

#### **目录：导读** ####

1、认识Bug

2、Bug的发现

3、Bug的产生

4、Bug的改进

5、总结

--------------------

> 一提起**测试**，大多数人很容易就会联想到**Bug**。的确，测试的日常工作离不开Bug，测试工作很重要的一部分就是发现Bug。但是，发现Bug、解决Bug，就足够了吗？肯定不是的。
> 
> 　　Bug是我们测试人员宝贵的财富，通过Bug我们可以获得经验，这种经验又能用在以后的测试中，帮助我们更早、更快地找到同类的Bug。

![366672b489da4f4381dbcab5e5e12209.jpeg][]

**Bug最大的价值不在于找到并解决它，而在于通过对Bug的分析，使我们增加一些经验、掌握一些规律，以便更好地进行测试。**

在对Bug进行分析时，一般很容易能想到的问题有：

**这个Bug是什么？**

**　　为什么会出现这个Bug？**

实际上，如果做Bug分析，只做到这个层次，还远远不够，上面只对Bug产生的原因进行分析，除此之外，还要更加注意：

**　　Bug的发现阶段**

**　　Bug的产生阶段**

在这方面，我也总结了一套方法，即缺陷根因分析法，主要目的是基于缺陷的过程改进（开发的改进、测试的改进、组织的改进），通过问10个问题来对Bug进行根因分析，看似很简单，实则重在引导和交流。

**结合自己的理解，认为分析Bug要分为四个步骤：**

> 　**　第一步，认识Bug**
> 
> 　　Bug是什么？（有什么影响？）
> 
> 　　为什么会出现Bug？（什么场景下会出现？）
> 
> 　**　第二步，Bug的发现**
> 
> 　　在哪个阶段发现的？
> 
> 　　应该在哪个阶段发现？
> 
> 　　为什么在这个阶段没有发现？
> 
> 　　如何才能在这个阶段发现？
> 
> 　**　第三步，Bug的产生**
> 
> 　　在哪个阶段产生的？
> 
> 　　为什么会在这个阶段产生？
> 
> 　　如何避免Bug的产生？
> 
> 　**　第四步，Bug的改进**
> 
> 　　如何改进，做到Bug预防？

下面来详细说说。

### **　　1、认识Bug** ###

在这一步骤中，要清晰全面地认识Bug，包括

通过问“这个Bug是什么”，来清楚描述这个Bug，包括向开发人员提Bug时也要用到这个描述

通过问“Bug有什么影响”，来判断这个Bug需要修复的优先级和影响的严重程度，对于优先级高的Bug要尽快上线，对于严重程度高的Bug可通过T-RCA方法进行根因分析

通过问“为什么出现这个Bug”来快速找到原因，一般我们通过询问开发人员或自己定位得到这个原因，并且这个原因大多是代码层面的原因，要知道根因分析，不能止于代码层面

通过问“什么场景下会出现”来复现Bug，并且最重要的是，可以反思自己在测试时是否遗漏了测试场景，测试覆盖是否不够

这一步可以说是测试人员的基础能力，遇到Bug后我们自然而然就能想到的问题。对于大多数的Easy Bug，做到这一步也足够了，毕竟我们的测试总是要在有限的时间和资源下做平衡，分析Bug也不例外。

Easy Bug，是指不需要精心的测试设计、不需要复杂的测试场景，就可以验证出来，随便找一个人来点点点，就可以发现的Bug。注意，验证和测试是完全不同的两个概念。但很可惜，大多数业务测试都是在做验证，而不是在做测试。

### 　**　2、Bug的发现** ###

在这一步骤中，要着重对Bug的发现进行分析，根据尽早测试原则，Bug发现越早，修复的成本也就越低，所以分析Bug的发现过程，也十分有价值。

“Bug是在哪个阶段发现的”，软件研发的阶段，不论是瀑布式开发、迭代式开发，还是敏捷开发，细分下来大体可以是需求定义阶段、**需求分析**阶段、开发设计/测试设计阶段、开发编码阶段、联调阶段、 测试阶段、改Bug回归阶段、预生产环境测试阶段、部署上线阶段、线上释放阶段等等，越晚发现的Bug，更应该去反思为什么没有更早地发现它

“Bug应该在哪个阶段发现”，较晚阶段的Bug应该尽早发现，早期阶段的Bug也不应该遗留到较晚阶段才发现，大多数人会认为Bug就是应该测试阶段发现的，但是如果可以做到今早发现，比如在需求分析阶段就从测试的角度提出一些风险，那规避风险的成本就会小得多

“为什么在这个阶段没有发现”，对于线上Bug很容易理解，为什么这些Bug会被遗漏到线上，而不是在测试阶段就发现呢？通过问这个问题，我们能很好地反思我们的测试，究竟是在测试设计的时候没有考虑到这种场景，还是测试的时候巧合地漏掉了Bug，还是修改Bug时影响到了其他的业务逻辑而没有回归

“如何才能在这个阶段发现？”，针对上面的问题，继续刨根问底，我们的测试永远有可以优化的地方

### 　**　3、Bug的产生** ###

这一步骤中是对Bug的产生进行分析，之所以把产生放到了发现的后面，是因为我认为Bug的发现相比于Bug的产生来说更重要。作为测试人员，你对发现Bug的控制，要更强于产生Bug，也就是说，预防Bug是很难做到的，而尽早发现Bug，却是我们都应该做到的。

“在哪个阶段产生的”，有人会认为，Bug都是开发写出来的呀，自然就是开发阶段产生的，这就陷入了一个误区，我们做根因分析，就不能这么粗放地想当然，开发也不是拿到一个需求后上来就写代码的，也是需要分析、设计、code、review等几个阶段的，不同的开发人员之间还要经历联调阶段，所以搞清楚Bug的产生阶段，可以帮助我们更有针对性地注意在这个阶段做一些事情，来及时发现Bug

“为什么会在这个阶段产生”，如果这个Bug不是代码Bug，而是开发从头就把需求理解错了，就要反思一下是不是我们需求细审时做得不够，是产品讲得不清楚， 还是测试没有提出一些有价值的风险？其他阶段如是，这也能帮助我们有针对性地改进

“如何避免Bug的产生”，其实有不少的Bug都是可以避免的，比如作为测试在需求阶段从测试角度想到一些容易出Bug的风险或场景，作为开发在编码之后的自测做得更好等等

### 　**　4、Bug的改进** ###

在这一步中要考虑的就是通过分析了Bug的根因，认识到了我们测试的不足之后，就要想办法如何改进我们的测试过程，以帮助我们在以后的测试工作。比如是我们的需求阶段没有真正地理解需求，还是测试设计阶段遗漏了一些测试场景，还是测试阶段由于测试环境、测试数据等因素没有发现Bug，还是Bug回归阶段没有回归其他收到影响的模块等等。

### 　**　5、总结** ###

Bug根因分析法是很有价值的，**但并不是每一个Bug都需要这样刨根问底的分析**，也没有这样的精力和时间允许我们这样做。要选取那些有价值的Bug，分析完后真正能帮助我们思考和改进，比如我们公司，就会有分析线上Bug的这一环节，是因为线上Bug毕竟是遗留到了线上，普遍会具有一些价值。

除了线上Bug，我们在测试中发现的Bug，如果比较有价值，能带给我们经验的提升，也是应该做根因分析的。所以，**在进行Bug根因分析时，要以Bug的价值作为选取标准**。

作为测试人员，一直是在有限的时间和资源下进行平衡，不存在零Bug的软件，测试也是无穷无尽的，所以平衡资源一直是测试人员应该掌握的技巧，分析Bug也不例外，我们的最终目的不在于把Bug根因分析流程化，比如迭代开发中每个迭代都做一次，作为工作流程中的一环，**而在于从Bug中进行反思、总结、学习、改进，以便更好地改进我们以后的测试工作。**

> **写在最后**
> 
> 如果你觉得文章还不错，请大家 **点赞、分享、留言** 下，因为这将是我持续输出更多优质文章的最强动力！
> 
> 看到这篇文章的人有觉得我的理解有误的地方，也欢迎评论和探讨～

[366672b489da4f4381dbcab5e5e12209.jpeg]: https://img-blog.csdnimg.cn/366672b489da4f4381dbcab5e5e12209.jpeg