聊聊 BUG 的根因分析

这篇文章的灵感，来自前几天技术交流群讨论的内容，也是广大测试同学日常接触最多但也最容易忽视的一点：bug 根因分析。bug 嘛，一说起来大家都熟，毕竟测试这个岗位，最初的时候，被称为“捉虫者”。

软件测试岗位工作的日常，就是执行用例验证开发交付的软件系统是否达标，存在哪些 bug，然后提单子并跟进修复和验证，说起来简单轻松，做起来无聊乏味，难怪很多同学自嘲，软件测试岗位就是一个“点工”。

如果仅是这样看待软件测试工作，那确实有点浮于表面。要做好软件测试甚至质量保障工作，除了最基本的找 bug 跟进，还需要对需求有足够的了解，熟练掌握研发测试流程和方法，并且还要灵活应用多种技术手段来辅导团队提升整体的交付质量和过程效率，这才是质量保障工作的核心。

既然提升质量是工作核心，那反过来理解，就是想办法减少 bug 的出现，或者在 bug 出现后能更快的修复，这样也能达到提升质量和效率的目的。

工欲善其事，必先利其器；欲利其器，必晓其理。同理，出现 bug 意味着背后存在多种原因，比如对需求的理解不够完善导致实现的功能存在偏差，比如修复老问题引发新问题等等，这些原因都是引起 bug 的现象，其背后更本质的因素在于需求评审、技术实现方案、编码规范、用例设计、沟通协调等多种因素。

只有从根本上找到 bug 出现的原因，才能更好的达到提升质量这一目的。特别是在当前这种降本增效的大环境下，对测试团队来说，更需要的是性价比较高的解决问题的方法。

前几年业内很火热的做了很多技术和方法实践，比如单元测试、自动化测试，然后以此为基础开创了各种维度的指标，即所谓的质量度量。表面来看，每个版本每次迭代甚至每次发布每次代码提交的质量一目了然，以此指标可以精准的得到哪个团队甚至哪个开发的代码质量差，然后通过 OKR+KPI，即所谓的引导员工提升自己。

但实际上呢，投入了如此多的资源，做了各种平台，质量真的获得了明显的提升吗？以我的观察，并没有，线上问题该发生照样发生。那能以此推论质量度量就是没价值的吗？也不尽然。

度量只是保障质量的第一步，质量一定是需要定量的标准的，否则就会陷入不可控的状态。但仅仅度量是不够的，这只是统计层面的分析，只能看到问题发生在哪里，为什么产生了这个问题，还需要进一步分析。

要分析问题出现在哪里，需要证据，各种质量度量指标的元数据就是很好的参照物。但与此同时，要对问题进行深入的分析，还需要工程师具备丰富的理论知识和实践经验，只有这样才能更快的找到问题的根源。

举个例子，某个正常的版本迭代，bug 数量和 reopen 数量激增，如果从统计层面来看，可能是某个开发的代码质量太差，可能是代码合并冲突，也可能是开发没有按照编码规范进行实现，这些因素都有可能。但更深入的思考一下，如果只是某个版本 bug 数和 reopen 数激增，其他版本正常，那就要可能是需求层面出了问题。

比如需求描述不清晰，比如编码过程中需求多次的大面积变更，比如研发资源被抽掉同时兼任多个项目的开发工作，这些也会导致交付的软件质量不高。但是，这些因素在质量度量层面，是看不到的。

还有其他可能，比如项目的 deadline 一直在变化，项目指标在变化，但关于变化产生的影响，大家并没有做好沟通，导致信息传递变形，最终影响了编码质量，这也是一种因素。但同样，在质量度量层面，依然看不到。

要提升质量和效率，最实用和最具性价比的方式，依然是 bug 根因分析。只有解决了最根本的问题，才能更有底气的完成保质提效的目标。

说到根因分析，很多公司都会有所谓的问题复盘，但遗憾的是，复盘后的改进动作和落地结果，很少有人关注和不断验证。说到提升效率，大家往往想的是自动化测试；说到提升编码质量，大家一窝蜂的跑去搞单元测试和研发自测，各种冒烟测试和质量门禁。

在我看来，大家好像在一段时间内，患上了头疼医头脚疼医脚的习惯。却唯独忘了去调查 bug 产生的背后真正原因。这也是为什么很多测试团队开发测试平台和各种自动化，最终无法落地的原因所在。

质量保障和提效比较合理的步骤是这样的：

• 统计问题，收集数据和证据(日志)；

• 开展根因分析，找到最底层最本质的问题；

• 思考解决问题的办法，并进行调研论证对比；

• 找到适合自己团队现状的方案，进行快速落地验证；

• 观察一段时间，有效就扩大范围，并且持续优化，如此反复；

近两年我写了很多关于质量保障体系建设的文章，你说这是方法论也好，说太复杂无法落地也罢。站在我的角度，我认为方法论依然是值得我们不断学习并且深入思考的。兼听则明，多看多想，然后找到适合自己的方式去落地解决问题，才是最核心的。

当然，bug 根因分析和质量的持续改进并不仅仅是测试团队的工作，而是应该和其他团队如运维、架构合作，一起来持续的对质量和效率进行改进和提升。毕竟对于技术团队来说，线上高性能高可用不出 bug，是大家一致的目标。

测试团队在其中要发挥的作用，可以是牵头者，也可以是辅助，更可以是整个技术团队统一目标的调停者。