软件缺陷数据度量和分析：从到达率到修复率的全方位解析

软件缺陷数据度量和分析：从到达率到修复率的全方位解析

引用

CSDN

1.

https://blog.csdn.net/qq_21007209/article/details/126628337

缺陷报告是软件测试的重要产出之一，通过量化分析的形式制作缺陷报告，可以帮助研发团队更好地发现问题并进行过程改进。本文将结合一个实际项目案例，详细阐述缺陷数据度量和分析的方法论。

项目背景

该项目为一个COTS产品的定制性二次开发项目，计划周期为4个月，实际完成时间为6个月，总体人员不到10人，采用持续集成、高速迭代的研发方式。

1. 缺陷到达率分析

缺陷到达率指的是单位时间内报出的缺陷数量。下图按照每月报出的缺陷数量进行了统计，并按严重级别进行了分类。

解析：

1. 缺陷到达率在前四个月内呈明显下降趋势
2. 五月份的缺陷量回升主要体现在低严重级缺陷数量上
3. 缺陷数的严重级别成正态分布
4. 六月份缺陷明显回升

结合项目实际分析：后两个月的bug数量上升主要是因为在这段时间引入了集中的回归测试和验收测试。客户报出的缺陷方面，严重级偏高，这可能是因为客户对缺陷严重级别的理解与研发团队的理解不一致所造成的，需要加强沟通。

2. 缺陷移除率分析

缺陷移除率指的是在研发各阶段明确和解决的本阶段引入的缺陷的比例。在软件测试的基础理论中强调，软件测试应该尽早介入项目，并用静态测试方法对各阶段产出进行测试。

解析：

1. 需求阶段缺陷移除率较低，说明需求评审工作的缺失
2. 验收阶段报出需求问题数量可观，说明需求团队与用户的沟通不畅
3. 单元测试整体发现缺陷数过低
4. 测试以外的人员缺陷报告数较低

通过实际项目调查发现，团队中除测试小组的其他人员存在不爱报bug的倾向。实际上，项目的质量应该与团队所有人员都息息相关，而不仅仅是测试团队的任务。

3. 缺陷分布率分析

缺陷分布率指的是针对不同功能模块所报出的缺陷数量。

解析：

1. 商品浏览模块报出的总体缺陷量较多
2. 支付模块报出严重缺陷较多

为了更准确地表述各模块的质量特征，可以对不同严重级别的缺陷进行加权处理。例如，严重缺陷权值5，关键缺陷权值3，其他权值1。

4. 缺陷修复率分析

缺陷修复率指的是在一定单位时间内，报出的、被修复的以及遗留的缺陷数量的对比。

解析：

1. 缺陷报出数量在经历了稳定下降之后，在项目后期迎来了回升
2. 开发团队的bug修复能力在4月份出现滑坡，据调查是因为开发核心人员受到了抽调
3. 项目收尾时的bug遗留数量不容乐观，主要是由于最后两个月报出bug数量激增造成

5. 缺陷修复轮次统计

缺陷修复轮次统计通过统计缺陷被激活的次数，来观察缺陷都需要经过多少轮的修复才能被关闭。

解析：

1. 项目大部分缺陷经历了多次修复
2. 反映了开发与测试团队存在一定程度的沟通问题
3. 部分原因在于测试团队的测试描述不充分

6. 缺陷有效率统计

缺陷有效率指的是报出的缺陷中有效缺陷的百分比。

解析： 可以明显看到，测试环境问题已经很大程度影响到了测试的有效率

7. 阶段缺陷分布统计

阶段缺陷分布指的是在一定时间阶段内，汇报的bug严重级别上的分布情况。

解析： 5月份有明显的次严重级bug数上升，6月份有最严重级bug数上升

8. 缺陷类型分布统计

解析： 大部分缺陷类型集中为功能性，可能揭示了在其他质量指标的关注不足

9. 测试活动缺陷率统计

解析：

1. 系统测试的效率并没有想象中的那么高（200多个缺陷中，只有不到40%来源于系统测试阶段）
2. 外部测试的缺陷数令人担忧（实际上指的是UAT测试的结果）
3. 回归测试和探索性测试发现了系统测试没有发现的问题，说明他们都是非常有效而且必要的测试活动

总结与建议

1. 采样样本数量偏小会导致数据随机性偏大，如果项目规模够大，采样样本更多，缺陷数据度量分析才能更准确地反映项目测试过程状态和产品质量特性。
2. 缺陷数据度量不应仅在项目结尾阶段进行，而应在测试过程报告中就引入，以便更好地对测试和研发过程进行反馈，达到过程改进的效果。
3. 为了收集到更多有用的缺陷数据，需要在缺陷信息的定义上进行更详细的规范，例如要求开发明确填写缺陷产生的根源阶段。