过来领你的Bug之“缺陷分析“篇

提到Bug，软件缺陷，除了记录一个问题出现的现象和原因以外，对于一个或者多个Bug的分析也非常重要，本文讲述了Bug分析的目的，介绍了IBM的ODC缺陷分析法，已提供给需要进行缺陷分析的测试小伙伴们参考。

Bug记录平台介绍
Bug分析目的
ODC缺陷分析法

Bug记录平台介绍

Bug记录平台，用比较文绉绉的话说是软件缺陷跟踪系统（Defect Tracking System， DTS）是软件测试管理系统的核心部分。这里拿华为的缺陷管理系统来举例，网易以及其他互联网公司大部分会使用比较轻量级的开源平台比如Jira平台等。共同之处是对软件缺陷处理过程有一些最基本的要求，大概包括以下几个方面：

1）整个处理过程应该是闭合的，即确保每一个被发现的问题在过程中都能得到解决，在整个过程中追踪缺陷的状态，问题记录在整个周期内都得到维护；
简单来说可以理解为Bug的状态流转，例如创建、进行中、已解决、关闭等。

2）每一个被发现的软件缺陷都应该按类别和优先级进行分类；

3）对软件缺陷的改正应该进行验证，以确保问题确实被解决、不利的影响已经被消除，并且解决该问题所引起的变化不会带来新的问题。

软件项目团队的全体成员就以软件缺陷跟踪系统（DTS）为工作的参照物，形成良好的工作流程和运行机制，构建如下所示的软件测试管理体系：

1.测试人员向缺陷跟踪系统报告新bug，在新版本上执行回归测试验证bug是否正确修改；

2.开发人员每天浏览属于自己需要修改的bug，修正bug后及时更新bug的状态；

3.项目经理及部门经理根据缺陷跟踪系统的bug分布信息，跟踪和控制软件开发过程；

4.技术支持人员根据缺陷跟踪系统的bug状况，估计软件的发布期限。

BUG生命周期全流程：
测试人员提交BUG->开发人员处理->测试回归->关闭。
问题单提交必填属性有：Bug主题、描述、重要性、测试类型、是否线上bug、影响的版本、经办人、回归人等。

Bug分析目的

一、对测试执行过程进行度量和评估，给出版本质量评估及开发测试改进建议。

•1.通过分析特定模块的缺陷发展趋势来给出模块的质量情况。包括缺陷数量增长趋势和关闭缺陷数量的增长趋势。原则上同一个模块的缺陷数量增长趋势是下降的，即缺陷收敛。

•2.通过分析缺陷所在的模块分布、缺陷引入的阶段点对开发活动及后续的测试活动加以调整和改进，例如模块缺陷多、且大多数是因为设计原因导致的需要考虑该模块是否需要重构，并且测试活动需要加大投入，缺陷少的模块需要综合评估测试覆盖情况，如果覆盖度高说明质量较好，如果覆盖度低需要加大测试投入力度。

二、漏测分析及改进措施

•对于缺陷的控制点分析，查看缺陷是否能在这个阶段之前就可以提前控制，例如线上问题明显需要分析漏测，还有就是集成或验收中发现的考虑是否能够提前到联调冒烟环节中发现。补齐相关的测试点。

三、其他项目/模块横向学习

•通过别人提交的好的问题单的学习，检视自己测试设计是否可以加入同样的场景以补充自己的测试遗漏。

下面介绍几种典型的缺陷分析法

ODC缺陷分析法

IBM的ODC缺陷分析（正交缺陷分析法Orthogonal Defect Classification）
所谓正交性是指缺陷属之间不存在关联性，各自独立，没有重叠的冗余信息。

•固有属性：缺陷类型，缺陷归属，缺陷来源，缺陷根因，结果影响。

•过程属性：发现阶段/活动/时间/人，缺陷表征，优先级，难度。

•统计属性：特性级/子系统级/版本级，测试阶段。

•关联属性：用例有效性，发现成本。

ODC分析-因果

1）测试类型比例分析（功能，性能，异常，稳定性，兼容性、安全）

•分析目的：版本测试策略偏差分析，特性稳定程度

•输出：风险及测试执行策略调整。

•例如某个模块的功能缺陷比例非常高，一种原因是其他类型的测试设计或执行不足，另一种原因是特性基础稳定性较差，存在风险。例如某个模块或项目的异常和压力缺陷比例较高，一方面说明这两部分的测试较充足，另一方面需要结合具体原因看是否缺陷引入的点，如果引入点比较集中则需要改进相关的开发活动（例如都是算法逻辑问题，或设计引入问题等需要增强代码检视或者设计比重）。

2）测试严重程度比例分析
•分析目的：对于缺陷严重等级较高的模块分布情况进行分析，聚焦高风险模块。

•输出：问题&风险列表&高风险及缺陷严重分布较多的模块

•3）触发场景分析（单运行覆盖&多运行覆盖&压力覆盖） •分析目的：版本测试充分性分析，测试设计分析改进

•输出：风险&测试执行策略调整

•例如如果某个项目的大多数缺陷都是因为单运行覆盖触发的，则考虑是否交互测试设计较弱，需要强化相关的测试设计。

•4）版本周期内缺陷趋势图分析

缺陷是否随着迭代开发周期收敛，即迭代开始的时候新功能测试会触发较多的问题单，缺陷率也会上升，随着迭代进行，开发开始着手修复问题，测试开始回归问题，问题单数目会呈现下降的趋势。如果没有合入新功能，但每轮测试问题单数量都不收敛的话，需要考虑是否缺陷修复引入问题过多，或者设计上有严重问题需要进行软件重构。

ODC分析-过程

1）根源对象比例分析（软件接口，设计规格，CODE，LCD等）
•目的：版本开发活动质量评估，聚焦需求，设计的比例。

2）缺陷年龄比例（新开发，修改引入，优化重写，早期版本）
•目的：
•修改引入多-引入根因分析
•早期版本多-漏测分析
3）缺陷引入点分析（需求活动，设计活动，实现活动，管理）
•修改内容的技术特征归类分析，用于过程改进。

ODC分析-漏测

1）集成测试漏测根源
•测试需求，测试设计，测试策略，测试执行
•针对漏测的阶段点进行重点审视，考虑补充和强化的措施。
2）集成功能测试设计
•功能点遗漏，交互遗漏，兼容性/对接遗漏
•针对设计漏测的类型对相应的类型测试分析加以强化和补充。

小结

以上分别介绍了Bug记录平台介绍、Bug分析目的以及ODC缺陷分析法。虽然概念和思路都不是新鲜的内容，但是仍然适用于目前大多数场景中。
另外自动拉取缺陷的信息汇总数据内容并实时展示出来也非常重要，减少人肉拉取数据的时间成本以及降低出错概率。
一般来说会有一些跟缺陷录入平台匹配的质量数仓平台或者质量报告平台可以来做这件事情，

后续敬请期待-》过来领你的Bug之质量数仓篇。

看完别忘了点赞转发收藏！你的支持是我更新的动力！谢谢~
后续另一篇大概会在明后天放出噢如果有兴趣欢迎私信我一起讨论