软件缺陷的应用与度量

测试人员在每次版本迭代中，会对项目的整体质量有一个把控：

对于项目常见的问题，开发经常犯的错误都会有所了解。

为了避免或者减少这样的错误或不规范的事情在发生，测试人员可以对缺陷进行分析总结，

提出有针对性的预防意见及规避措施，以提高产品的质量。

那么，可以从那几个方面进行缺陷分析呢？

一、可分析缺陷因子

1、缺陷严重程度

• Fatal(致命的)

致命的错误，造成系统崩溃、死机，或造成数据丢失、主要功能完全丧失等。

• Critical(严重的)

严重错误，指功能模块或特性没有实现，主要功能部分丧失，次要功能全部丧失，或致命的错误声明。

• Major(重要的)

不太严重的错误，如次要功能模块丧失、提示信息不够准确、用户界面差和操作时间长等。

• Minor(次要的)

一些小问题如有个别错别字、文字排版不整齐等，对功能几乎没有影响，软件产品仍可使用。

2、缺陷产生模块

记录对应模块，所产生的缺陷，不同的项目<模块>的颗粒度不一样，可视情况选择。

• 按照系统子模块进行划分

颗粒度较细，适用于小型项目，20个模块左右的适用此维度。

• 按按照大组件模块进行划分

颗粒度适中，适用于中型项目，一个组件下面有多个模块，组件个数5+以上。

• 按照应用服务进行划分

颗粒度较大，适合微服务类型项目，但不建议超过20+以上的分类。

• 按照前端、后端、接口服务等进行划分

颗粒度太大，不建议使用，问题主要分为为前端、后端、对外接口。

3、缺陷产生原因

• 需求设计问题

模糊不清的需求、说不明白的PRD、分析不到位等

• 开发设计漏洞

设计缺失、功能遗漏、场景未考虑、容错性不高等

• 代码编写漏洞

纯属开发个人技能不娴熟、编码质量不高、方法函数应用补数量、调试脚本未清除等。

• 部署配置问题

配置方案不完整、集成出错、配置缺失遗漏、受其它外在资源的影响等。

4、缺陷产生阶段

1. 需求分析：对应缺陷产生余需求分析设计阶段
2. 开发设计：对应缺陷产生于开发详细设计阶段
3. 开发自测：开发自测产生的缺陷
4. 产品部署：安装过程中发现的缺陷
5. 提测阶段：需求测试阶段
6. 上线应用：线上反馈的问题，更多来源于客户

5、缺陷类型

1. 服务接口
2. 数据计算
3. 数据校验
4. 数据显示
5. 业务功能
6. 业务流程
7. 参数配置
8. 安全问题
9. 性能问题

6、缺陷修复周期

对应不同严重程度问题的解决效率与周期。

根据大型网站的可用性指标0,999-0.999999，对于致命性问题的修复时间限定在5分钟到500分钟之间不等。

不过日常生产过程中，没有这么高的要求，但高效率的团队尽量要做到：致命性问题当天内要得到解决；严重问题两天内得到解决；

• Fatal(致命的) ：当天内修复
• Critical(严重的) ：两天修复
• Major(重要的)：一周内修复
• Minor(次要的)：根据其它问题的修复情况，如有剩余时间，可按需修复

7、缺陷修复率

整个项目阶段所产生的缺陷的修复情况统计，可对比历史项目或版本的数据。

可统计维度：对应模块问题的修复率、对应缺陷等级问题的修复率、对应责任人产生缺陷的修复率等等。

8、缺陷责任人

对应缺陷的责任人：可能是产品、开发、项目、测试、运维或客户自身。

9、缺陷投入

各职能人员在缺陷上的投入，包含产品、研发、测试、运维等。

二、缺陷分析维度

上述缺陷因子中，单一因子的分析，这里就不多介绍，使用中直接使用饼图分析即可。

重点从多因子组合的情况有哪些维度可以分析统计。

1、缺陷等级

2、缺陷等级&缺陷责任人

根绝不同缺陷等级进行预设分数，结合缺陷责任人产生缺陷的数量进行分数评估。

对项目组各成员对产品质量的“贡献”，有数据上的评判--可参考。

3、缺陷等级&缺陷产生模块&缺陷修复率

根绝不同缺陷等级进行预设分数，结合对用模块产生缺陷的数量进行分数评估。

对项目各功能模块质量有一个量化的认识，便于针对性的开展质量改进与分析总结。

各模块缺陷等级分布

4、缺陷产生模块&缺陷类型

分析模块缺陷数量以及对应什么问题类型较多，便于后续版本或项目有意识规避类似问题，引起相关人员的重视。

 5、缺陷等级&缺陷产生阶段

分析各阶段不同等级缺陷分布情况。

 

6、缺陷产生阶段&缺陷等级&缺陷投入

在缺陷产生阶段及缺陷等级的基础上延伸，可以统计各阶段在缺陷上的消耗。

三、总结

上述的因子还可以扩充，缺陷的应用分析也还有很多维度，不局限与上述列到的内容。

缺陷分析与度量工作是一个需要积累的过程，最终的目的还是通过不同维度不同图表的分析，更多量化的来评判软件的质量。

从而帮助项目成员认识到问题，并在后续版本迭代或新项目中有序规避。