作者|
在软件开发交付环节中，不免会出现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剖析维度的一些思索和演绎，欢迎大家斧正或提出自己的见地。