作者|

在软件开发交付过程中，难免会出现Bug。针对每一个已发现问题的Bug，完成修复工作后，我们可以对其进行全面的根本原因分析。本文从测试人员的角度，尝试梳理出一些常见的Bug根本原因分析的维度，并列举每个维度中的根本原因的例子。

一、Bug分析的维度

建议尽量用便于统计和维护的方式，记录分析的结果(比如使用Jira系统提供的label功能，下文中括号内的英文是可参考的label名称)，以便周期性地进行全面的Bug分析。

每个Bug常见的可用于分析的根因维度如下：

1.Bug发现的环境 (Env)

(1) 维度定义：

描述该Bug是在什么环境中被测试人员/开发团队成员/客户/用户发现的。

(2) 分析目的：

正常来讲软件开发过程中，越早发现问题，修复问题所需要的成本也就越小。为此，需要关注开发过程中的问题是否可以在早期被发现。

分析此维度可以评估现在项目的Bug发现时机。制定针对性的改进措施，以保证Bug可以被尽早发现。

(3) 维度示例：

各个项目所拥有的测试环境并不相同，请根据实际情况来进行分类。

2.Bug引入时机 (Timing)

(1) 维度定义：

描述引发该Bug的代码/配置是在什么时机或者什么活动中被引入到产品中的。

(2) 分析目的：

通过分析Bug的引入时机，有机会识别出质量保证体系中薄弱的点，或团队在开发/测试流程中的问题。

(3) 维度示例：

常见的引入时机如下：

3.Bug所属的前后端/微服务/功能模块

(1) 维度定义：

描述该Bug的代码问题出现在前后端/微服务/功能模块。

(2) 分析目的：

统计前后端/微服务/功能模块的Bug比例分布，后续可以有针对性地进行补充自动化测试及分配测试资源。

(3) 维度示例：

各个项目所拥有的前后端并不相同，可以根据实际情况来进行分类。

4.Bug产生的直接代码原因 (Root Cause)

(1) 维度定义：

描述引发该Bug的代码的问题，可以与开发人员合作来分析。

(2) 分析目的：

结合下一个维度，评估团队人员上下文以及技术的掌握情况。通过进行session/文档同步上下文的方式进行查漏补缺。

(3) 维度示例：

5.Bug产生的人员原因 (Reason)

(1) 维度定义：

描述写出Bug代码的原因。

(2) 分析目的：

结合上一个维度，评估团队人员上下文以及技术的掌握情况。通过进行session/文档同步上下文的方式进行查漏补缺。

当分析涉及具体人员的原因时，对应人员可能害怕被追责，会不自然地产生抵抗心理。所以在我们分析人维度的根因的时候，侧重点应该是团队对于上下文的掌握情况，而不是某个成员的个体原因，为团队成员建立有安全感的氛围，这样才能保证此维度的分析能持续进行下去。

(3) 维度示例：

未考虑到系统健壮性或其他非功能性需求 (Reason_unconsidered_non_functional_requirements)

6.自动化测试覆盖情况 (Original Automation Test)

(1) 维度定义：

描述该Bug相关的代码的自动化测试情况，自动化测试代码为何没有发现该Bug。包括单元/接口/端到端测试。

(2) 分析目的：

适当的自动化测试覆盖与适当的运行频率可以极大地提高问题代码的反馈效率，所以此维度可以用于识别系统自动化覆盖的情况。识别出自动化测试薄弱的功能/微服务后可以单抽时间对其补充必要的自动化测试。

(3) 维度示例：

7.发现的问题不属于Bug的场景(Timing_not_bug)

有时我们最终发现看到的问题不属于系统的Bug，我们可以把这种情况单独分作一类进行分析其出现的原因(Root Cause维度)。

当某种原因出现频率过高的时候，我们也需要采取对应的行动去减少此类的问题的出现，以防在大量的调查处理工作中浪费QA及团队其他成员的时间。

示例：

最后

虽然列出了这么多维度和原因，但是毕竟每个项目各有各的情况。所以在bug分析这件事上面，并没有适用于所有项目的模板。

但是不管分析的方式及维度如何，我们做Bug分析的目标是一致的：

所以，只要满足上面的目标而且适合项目现状的分析方式就是好的方式。

以上是我对于Bug分析维度的一些思考和归纳，欢迎大家指正或提出自己的见解。