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

一提起测试，大多数人很容易就会联想到Bug。的确，测试的日常工作离不开Bug，测试工作很重要的一部分就是发现Bug。但是，发现Bug、解决Bug，就足够了吗？肯定不是的。

Bug是我们测试人员宝贵的财富，通过Bug我们可以获得经验，这种经验又能用在以后的测试中，帮助我们更早、更快地找到同类的Bug。

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

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

• 这个Bug是什么？
• 为什么会出现这个Bug？

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

• Bug的发现阶段
• Bug的产生阶段

在这方面，独立顾问邰晓梅老师总结了一套方法，即 T-RCA缺陷根因分析法（T-RCA，Test Root Cause Analysis），主要目的是基于缺陷的过程改进（开发的改进、测试的改进、组织的改进），通过问10个问题来对Bug进行根因分析，看似很简单，实则重在引导和交流。

我在T-RCA的基础上，结合自己的理解，认为分析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中进行反思、总结、学习、改进，以便更好地改进我们以后的测试工作。