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

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

 

1、缺陷管理库

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

1.1 缺陷定义

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

 

1.2 缺陷信息

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

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

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

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

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

 

2、缺陷分析

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

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

 

3、宏观缺陷分析技术

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

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%。这个结果说明，咱们须要从新审视需求评审，加大需求评审力度。另外，编码阶段的缺陷大部分依赖于系统测试发现，很显然，项目开发过程当中的单元测试和集成测试活动开展不够深刻。咱们能够进一步分析这些系统测试出来的测试缺陷，是否是能够被更前端的评审/测试/设计讨论活动所替代。

4、微观缺陷分析技术

微观缺陷分析是指从单个有价值的缺陷入手，追踪和分析缺陷产生的本质缘由。
并非全部的缺陷都有必要去作微观缺陷分析，所以首先须要挑选"合适的缺陷"。这里给出几点建议

• 选择典型有表明性的：同类型的一系列问题
• 选择有发现难度：积累缺陷库，对测试用例作补充
• 选择有推广意义的：该缺陷很广泛，能够推广到其余业务线
• 再挑选合适的缺陷后，咱们紧接着须要收集该缺陷相关的有效信息进行下一步缺陷缘由分析。这些缺陷信息包括提交缺陷时信息，同时也包括和开发讨论获取的信息。

接着就是追踪缺陷产生的真正缘由。网络上有不少总结的分析方法，有"望、闻、问、切"诊断法，有"5W"法，还有"探案分析法"。其实我的以为在这一步骤中，更多须要积累经验，善于追根究底，多问为何，多理解产品实现逻辑，产品设计思路，有了这些基础以后，合理的推理分析便可。
下面这两篇文章是很是好的结合实践总结的微观缺陷分析，你们能够经过他们的分析积累经验。

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

缺陷分析的正逆向

原文做者：桃子妈咪 原文连接：http://www.jianshu.com/p/1bb7ff2d7c6f