软件缺陷分析-软件测试之犯罪心理学

作为一名测试人员，最大的成就就是像福尔摩斯一样，利用超强的观察力，严密的逻辑推理能力，迅速找出软件的"罪犯"，将其绳之以法。可是在成为"福尔摩斯"之前，观察力、逻辑推理能力，是需要不断训练的。这篇文章实际就是软件测试的"犯罪心理学"(初级版)：利用软件缺陷数据，对缺陷进行分类汇总，计算缺陷分析指标，进而发现软件生命周期的各个阶段的不足，制定相应改进方法，增强软件过程人为活动的规范性，最终目标提升软件交付质量，提升测试效率

一、缺陷管理库

缺陷管理库记录了缺陷相关的资料，为缺陷分析提供了详细的信息，而只有正确的信息，才能保障正确的分析结果。

1.1 缺陷定义

软件缺陷是指在产品说明、设计、编码阶段中的任何不足。一般要求将需求评审、设计评审、代码检查、测试、项目组内部发现、用户反馈等几种手段发现的缺陷都统一记录在缺陷跟踪系统中，进行统一管理、统计。而目前很多项目缺陷跟踪系统中往往只包含了测试阶段的缺陷统计，在此基础上的缺陷分析势必存在局限性。

1.2 缺陷信息

为了便于缺陷定位、跟踪和修改，需要收集尽量多的有效信息，比较常见的缺陷信息如下：

• 缺陷描述
  • 被测产品信息：比如App名称、版本号
  • 测试环境：wifi、数据网络、测试环境、生产环境
  • 测试机型：机型、系统版本号
  • 测试步骤
  • 预期及实际结果
  • 复现概率
  • 测试辅助信息：截图、视频、日志
• 缺陷状态
• 缺陷优先级：标识处理和修正软件缺陷的先后顺序指标
• 缺陷严重程度
• 缺陷发生的组件
• 缺陷创建时间
• 缺陷发现人
• 缺陷责任修改人
• 缺陷修复时间
• 缺陷产生原因

在提交缺陷时，需要遵循以下5个原则：

• 准确性：缺陷每个组成部分描述准确，不会产生误解
• 完整性：复现该缺陷完整的步骤、截图、日志
• 一致性：按照一致的格式书写全部缺陷信息
• 简洁性：只包含必不可少的信息，不包括任何多余的内容
• 清晰性：每个组成部分的描述清晰，易于理解

这一步其实可以理解成培养测试人员的观察能力，信息收集能力。只有不断观察、收集正确信息，才可以为后续的侦查做好准备工作。

二、缺陷分析

缺陷分析是在形成缺陷管理库的基础上，对缺陷进行宏观及微观纬度的分析。通过缺陷分析，发现各种类型缺陷发生的概率，确定缺陷集中的区域，明确缺陷的发展趋势，追踪和分析缺陷产生的原因。在此分析基础上，对软件生命周期中各个角色、项目流程做改善和优化，提高软件测试质量，提升测试效率。

缺陷分析仅仅是一种手段，而非最终目的。利用缺陷分析结论，反思和回溯缺陷产生的各个阶段，思考如何避免类似问题，不再踩坑，在下次测试中得到提升，才是我们想要的结果。同样的，缺陷分析的成果是一个持续改进优化闭环的过程，它是测试人员潜移默化中测试能力的提升，也是项目流程中各个角色共同保障产品质量意识的推动。例如缺陷分析发现很多需求缺陷是到测试阶段才发现，那么就有必要加大需求评审力度；缺陷分析发现开发修复缺陷引入新缺陷比例很高，那么开发团队在修复缺陷的时候要考虑到对周边区域的影响，并且要通知相关区域的专家加强代码审查。当然测试团队也要尽可能多的在相关区域做一些回归测试。大家可以结合自身项目来利用缺陷分析优化项目实践。

三、宏观缺陷分析技术

宏观缺陷分析是指对缺陷信息进行分类和汇总，利用统计的方法计算分析相关指标，编写缺陷分析报告的活动。宏观缺陷分析的方法很多，这里主要关注缺陷发展趋势分析、缺陷分布状况分析、缺陷注入-发现分析。

3.1 缺陷发展趋势分析

项目管理中一项非常重要但十分困难的工作就是平衡进度、质量和成本。测试人员可以提供缺陷提交、缺陷修复的趋势图表，帮助管理者从中发现一些简单的缺陷发展趋势（这种缺陷可以是本文论述的广义缺陷发现手段确定的，也可以是单纯的测试手段发现的），从而了解软件质量趋势。
这里给出一个常用的分析图，x轴代表时间，y轴代表以下四种类型缺陷的数量：

• 发现数：累计的所有被发现bug的数量
• 关闭数：累计的所有被关闭bug的数量
• 日（期）发现数：当日（期）发现的缺陷数量
• 日（期）关闭数：当日（期）关闭的缺陷数量

图1：缺陷分析发展趋势图

3.2 缺陷分布状况分析

3.2.1 缺陷严重程度分布

缺陷严重程度度量有助于识别不同严重程度缺陷在所有缺陷中的比重，有助于开发测试人员资源的计划和分配。
这里给出一个常用的缺陷严重程度分析图，x轴代表时间，y轴代表各严重级别的缺陷数量。

图2：缺陷严重程度分布图

通过缺陷严重程度图表，分析各严重程度缺陷发现趋势，判断产品质量是否趋于稳定。如果高严重程度的缺陷大量增加通常意味着产品质量出现问题。

3.2.2 缺陷模块分布

按照缺陷对应的产品组成部分来汇总缺陷数据，利用这样的分布，可以找出我们产品高危模块，针对高危模块，调整测试策略。

3.2.3 ODC（正交缺陷分析）

正交缺陷分类法（Orthogonal Defect Classification，ODC）介绍了一种不同于大家常用的非常有效的软件缺陷分类及分析方法，它定义了八个正交的缺陷属性用于对缺陷的分类。所谓正交性是指缺陷属性之间不存在关联性，各自独立，没有重叠的冗余信息。

• 对于缺陷提交者，他需要给这个缺陷分配“活动（Activity）”、“触发（Trigger）”、“影响（Impact）”这三个属性。
  • Activity：项目生命周期的一个阶段，该缺陷发生在该阶段，例如需求、设计、代码阶段，即缺陷发现阶段
  • Trigger：可以理解成测试的手段
  • Impact：对用户的影响，例如安全性、易用性
• 当一个开发人员关闭一个缺陷时，他可以分配“阶段（Age）”、“来源（Source）”、“限定符（Qualifier）”、“类型（Type）”以及“目标（Target）”这五个属性。
  • Age：描述缺陷对应的代码属于新代码，旧代码，还是修复bug引入
  • Source：定义缺陷来源，是自身代码问题，还是第三方代码导致
  • Qualifier：指明了所进行的修复应归于缺失，错误或者还是外来的代码或者信息
  • Type：缺陷真正的原因，例如初始化、算法等
  • Target：描述缺陷是由于设计还是编码引入，即缺陷注入阶段

关于ODC分析方法，需要结合实际项目，对不同属性进行筛选，优化不同属性对应的值。
软件缺陷分析方法：ODC 这篇文章中详细解释了ODC各属性及对应的值。

3.3 缺陷注入-发现矩阵

利用缺陷的两个重要属性：缺陷发现阶段、缺陷注入阶段，分析缺陷数据，绘制出"缺陷注入-发现矩阵"，从中分析项目生命周期各个环节的质量，优化相关流程。

• 缺陷移除率：（本阶段发现的缺陷数/本阶段注入的缺陷数)*100%，它反映的是该活动阶段的缺陷清除能力
• 缺陷泄漏率：（下游发现的本阶段的缺陷数/本阶段注入的缺陷总数）*100%，它反映的是本阶段质量控制措施落实的成效

图3：缺陷注入-发现矩阵

如上图例子，需求阶段一共注入了34个缺陷，需求评审时只发现了4个，设计过程中发现了15个，编码和单元测试阶段发现了12个，系统测试阶段发现3个。这样，需求阶段的缺陷移除率 4/34*100%=11.76%。这个结果说明，我们需要重新审视需求评审，加大需求评审力度。另外，编码阶段的缺陷大部分依赖于系统测试发现，很显然，项目开发过程中的单元测试和集成测试活动开展不够深入。我们可以进一步分析这些系统测试出来的测试缺陷，是不是可以被更前端的评审/测试/设计讨论活动所替代。

四、微观缺陷分析技术

微观缺陷分析是指从单个有价值的缺陷入手，追踪和分析缺陷产生的本质原因。
并不是所有的缺陷都有必要去做微观缺陷分析，因此首先需要挑选"合适的缺陷"。这里给出几点建议

• 选择典型有代表性的：同类型的一系列问题
• 选择有发现难度：积累缺陷库，对测试用例做补充
• 选择有推广意义的：该缺陷很普遍，可以推广到其他业务线

再挑选合适的缺陷后，我们紧接着需要收集该缺陷相关的有效信息进行下一步缺陷原因分析。这些缺陷信息包括提交缺陷时信息，同时也包括和开发讨论获取的信息。

接着就是追踪缺陷产生的真正原因。网络上有很多总结的分析方法，有"望、闻、问、切"诊断法，有"5W"法，还有"探案分析法"。其实个人觉得在这一步骤中，更多需要积累经验，善于追根究底，多问为什么，多理解产品实现逻辑，产品设计思路，有了这些基础之后，合理的推理分析即可。
下面这两篇文章是非常好的结合实践总结的微观缺陷分析，大家可以通过他们的分析积累经验。

不会做bug分析？套路走起~

缺陷分析的正逆向