应用与度量之软件缺陷

草帽路飞UU

测试人员在每次版本迭代中，会对项目的整体质量有一个把控：对于项目常见的问题，开发经常犯的错误都会有所了解。


　　为了避免或者减少这样的错误或不规范的事情在发生，测试人员可以对缺陷进行分析总结，提出有针对性的预防意见及规避措施，以提高产品的质量。那么，可以从那几个方面进行缺陷分析呢？

　　一、可分析缺陷因子

　　1、缺陷严重程度

　　· Fatal(致命的)

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

　　· Critical(严重的)

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

　　· Major(重要的)

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

　　· Minor(次要的)

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

　　2、缺陷产生模块

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

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

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

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

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

　　· 按照应用服务进行划分

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

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

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

　　3、缺陷产生原因

　　· 需求设计问题

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

　　· 开发设计漏洞

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

　　· 代码编写漏洞

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

　　· 部署配置问题

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

　　4、缺陷产生阶段

　　需求分析：对应缺陷产生余需求分析设计阶段。

　　开发设计：对应缺陷产生于开发详细设计阶段。

　　开发自测：开发自测产生的缺陷。

　　产品部署：安装过程中发现的缺陷。

　　提测阶段：需求测试阶段。

　　上线应用：线上反馈的问题，更多来源于客户。

　　5、缺陷类型

　　·服务接口

　　·数据计算

　　· 数据校验

　　· 数据显示

　　· 业务功能

　　· 业务流程

　　· 参数配置

　　· 安全问题

　　· 性能问题

　　6、缺陷修复周期

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

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

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

　　· Fatal(致命的) ：当天内修复

　　· Critical(严重的) ：两天修复

　　· Major(重要的)：一周内修复

　　· Minor(次要的)：根据其它问题的修复情况，如有剩余时间，可按需修复

　　7、缺陷修复率

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

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

　　8、缺陷责任人

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

　　9、缺陷投入

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

　　二、缺陷分析维度

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

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

　　1、缺陷等级



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

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

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



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

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

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




各模块缺陷等级分布：



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

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



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

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



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

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



三、总结

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

　　缺陷分析与度量工作是一个需要积累的过程，最终的目的还是通过不同维度不同图表的分析，更多量化的来评判软件的质量。从而帮助项目成员认识到问题，并在后续版本迭代或新项目中有序规避。