软件缺陷的应用与度量

发表于:2022-11-22 09:29

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:喵说测试    来源:知乎

分享:
  测试人员在每次版本迭代中,会对项目的整体质量有一个把控:对于项目常见的问题,开发经常犯的错误都会有所了解。
  为了避免或者减少这样的错误或不规范的事情在发生,测试人员可以对缺陷进行分析总结,提出有针对性的预防意见及规避措施,以提高产品的质量。那么,可以从那几个方面进行缺陷分析呢?
  一、可分析缺陷因子
  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、缺陷产生阶段&缺陷等级&缺陷投入
  在缺陷产生阶段及缺陷等级的基础上延伸,可以统计各阶段在缺陷上的消耗。
  三、总结
  上述的因子还可以扩充,缺陷的应用分析也还有很多维度,不局限与上述列到的内容。
  缺陷分析与度量工作是一个需要积累的过程,最终的目的还是通过不同维度不同图表的分析,更多量化的来评判软件的质量。从而帮助项目成员认识到问题,并在后续版本迭代或新项目中有序规避。
  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
精选软件测试好文,快来阅读吧~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号