Bug Report一般有两种说法：一是“微观Bug Report”，是指深入分析单个bug产生的影响、产生的根因、后续如何避免等；二是“宏观Bug Report”，是指在一个项目开发周期中，对bug原因、修复周期、bug趋势等维度进行总结分析。

说起Bug Report，QA同学都不陌生。本文我们主要聊一聊Bug Report该怎么做。

Bug Report一般有两种说法：一是“微观Bug Report”，是指深入分析单个bug产生的影响、产生的根因、后续如何避免等；二是“宏观Bug Report”，是指在一个项目开发周期中，对bug原因、修复周期、bug趋势等维度进行总结分析。通过对bug的分析以及测试过程中出现的任何问题进行总结而形成的质量报告，不仅可以对过去项目产品质量进行准确的评估，还能对未来项目在质量方面的改进点和方向提出建议，以对产品质量进行不断改进和完善。本次我们主要针对后者进行讨论。

首先，我们需要了解第一个问题：为什么要做bug分析？

众所周知，bug越早被发现并修正，所消耗的资源越少。因此，我们应该尽快地提前发现bug和预防bug，而不仅仅是修正它们。而一个很好的预防bug方法——适当借鉴我们自己现有的经验。因此，通过对现有的bug进行分析，找到bug产生的根因以及流程上的不足，并思考如何从各个方面去优化改进，可以进行bug预防，把控质量风险，提升产品质量。
紧接着，我们便要考虑：怎么做bug分析呢？

Bug分析第一步：记录bug

不论你使用bug管理软件，还是只是简单的excel等文档记录bug，这都是bug分析的一个前提，我们需要这些数据用于后续的分析。记录bug需要注意的是，我们记录的维度越广泛，对之后的数据分析就越有利。至于我们要记录哪些信息，我们将稍后在阐述分析维度时讨论这个问题。

Bug分析第二步：我们要分析什么？

首先，我们需要确定分析维度。针对不同的项目，分析维度也不尽相同。一般情况下，比较常见的分析维度如下：bug分类、bug趋势、bug状态流转效率、多个周期对比等。

01 Bug分类分析

Bug分类一般包括功能模块、引入时机、bug类型、优先级、严重性、产生原因等。首先我们介绍bug分类统计的规则，一般来说，我们会按照不同维度来分类，而每个维度下面又可以分为多个不同的属性值，具体可以参考下图:

一个bug可以有不同维度的多个属性值，例如：一个优先级是最高级别的、严重性是严重影响用户体验的、功能模块是订单管理bug。

这里举几个bug分类统计里的具体例子供大家参考，见下图：

02 Bug趋势分析

我们通过分析bug增长和减少的趋势，来实现了解测试的效率、开发修复bug的效率、测试瓶颈、测试延期原因、测试生命周期等目标。趋势分析包括每日新增、每日关闭、累计活跃、累计关闭、bug总数、严重bug占比、反复打开bug占比等。下图是一个按天统计的动态趋势统计：

03 Bug状态流转效率分析

这一步也被称为效能分析。我们通过bug状态的时长分布，可以分析bug状态流转的时效。如果再结合卡墙去分析，就能很明确的看出哪些状态被及时挪卡了。下图的例子可以看出，绝大多数bug都是在一天内处理并解决的。

另外，我们还可以根据团队成员的一些指标进行分析，如下图：

从上图我们可以尝试得出以下结论：

• Team1：处理遗留问题较多，帮其他组也修了不少Bug。可见开发质量最好，可以尝试多放一些新功能开发。
• Team2：环境配置问题较多，需要更关注基础设施，而开发质量要差一点。
• Team3：新功能引入Bug最多，急需提升开发技能。

04 Bug根因分析

当然，我们要分析一个bug产生的原因，只看表面原因是远远不够的，只有深入指导这个bug的根本原因，才能谈得上过程改进和持续优化。下面我们用两个例子，辅助我们确定根本原因。（关于根因分析的具体理论还有很多，我们这里不做展开分析，感兴趣的小伙伴可以自行学习，也欢迎来私下交流）

一般情况下：

5Why：比较适合原因单一的问题，通过刨根问底可以找到根本原因。

5M1E：比较适合成因复杂的问题，可以通过多个维度进行综合分析，找出可以改进的方面。

上文只是列举一些比较常用的分析维度，由于每个项目不尽相同，大家需要根据项目情况去思考分析维度的选择。

我们还需要强调的是，统计数据的变化趋势要比绝对值更重要。相对于绝对值，变化趋势更能体现出被统计数据的动态过程。比如，相比于在某个迭代产生的bug总量，我们更关心在迭代内产生bug数量的变化趋势，若在某一时间段内bug提交量激增，我们则需要分析出bug激增的原因以避免潜在的风险。

另外，bug分析的还要考虑对团队成员的分析。通bug分析发现软件生命周期中团队人员能力的不足（技术、沟通、规范性等），制定有针对性的方法和训练，从而提高团队人员技术能力、沟通能力，增强软件过程人为活动的规范性，减少人为的疏忽和失误，最终实现组织综合生产力的高效率与软件成果交付的高质量。

今天的发现和分析是为了明天的预防

只是基于已有bug进行最基本的数据统计，当然不是bug分析报告的最终目的。bug分析报告最有价值的应该还有风险预估。第一，通过根因分析，发现bug产生的根源，及早采取调整和控制措施，继而对现有方法和流程进行优化，预防和控制问题的蔓延和新问题的产生。第二，使用统计分析方法，通过bug的共性发现软件生命周期中技术、人员、过程、项目和组织存在的问题，揭示软件质量、过程质量、人员能力、组织能力之间的关系，加强软件精细化管理，促进人、过程、组织持续性改进。

并且，通过对每一个迭代周期进行持续的bug分析，也可验证我们之前的action是否有效，进而做到持续优化，这些才是bug分析的重点。

最后，特别感谢于晓南同学，对本文做了很多想法和内容的补充。

文/ThoughtWorks何婷婷