版本质量总结的纬度

发表于:2018-1-05 13:41

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

 作者:alice_tl    来源:简书

分享:
  3.2、bug级别和模块分布
  一般情况下,用例和bug的级别可分为四级,这是大多数公司对于用例和bug级别的标准定义:
  当各等级的 bug占比严重出现偏差时,需要分析具体原因。如果紧急和高的bug过多,可能是开发质量太不过关。如果是低的bug过多,可能是产品需求设计不够好,或者是测试同学发现深度bug的能力欠缺。
  在软件开发中有着八二原则:80%的bug是由20%的代码造成的,90%的停机是由10%(甚至更少)的缺陷造成的。bug总是集中爆发在某几部分代码中,特别是严重的bug。
  bug数排前或者 bug 等级偏高的几个模块,即不稳定模块,不仅是开发和测试的关注重点,是重构和回归测试的依据,也是一个研发项目要改善和提升的重点模块。并且可以针对各个模块的bug具体原因进行分析,比如是CMS配置问题、代码质量问题、接口设计不合理、还是需求规则不明确导致的问题,从而针对性的一一改善。
  3.3、bug责任人分布
  可以从bug提交人、bug引入者、前端、后端问题几个详细维度去分析。如果项目区分了前端开发、后端开发、H5开发,则还要区分下对应的责任人。
  从bug责任分布,可以明显的看出测试同学的bug数排名,以及开发的bug数排名。对于代码的质量、测试和开发同学的工作能力、以及工作量投入产出评估都具有参考价值。
  3.4、bug生命周期和生长趋势
  bug生命周期以bug创建日期算,bug关闭日期结束。各个项目、各个测试阶段都会有bug生命周期的标准,比如某个项目SIT测试期间要求bug日清,那么bug的生命周期正常情况下应该不超过24H。
  bug生长趋势是指一个项目或版本进行期间,每日bug增长和关闭的曲线。理想的项目流程中,新增和关闭的bug曲线伴随着项目的进行应当是有个一致坡度的增幅和减幅的。
  正常情况下,80%以上的bug应该在模块化测试及STORY阶段被发现,SIT集成期间发现与集成有关的bug,而UAT和PVT期间发现的bug数应该极少趋向于零。
  假设一个项目的bug生长曲线见下图:
  并且测试阶段对应为:
  STORY: 6.6-8.7
  SIT:8.8-8.10
  UAT:7.31-8.15
  那么可以看到bug曲线反馈的现象:
  bug增长曲线来看:
  a) STORY阶段发现的bug数逐渐增加,暴露出了项目组80%以上的bug。
  b) SIT期间bug数在5个以下。
  c) UAT期间bug数有少量的增加,可能是因为客户反馈的需求或者是测试遗漏的bug。需要重点分析。
  但从关闭曲线来看:开发前期极少解决问题,到STORY尾声和SIT期间才大量修复问题。现象是不合理的,在项目后期极大的加重了开发和测试的压力。那么是什么原因导致的这种不合理现象,是否可以改善?
  3.5、典型bug案例
  另外还可以从一些典型bug案例上进行分析。比如:
  选择比较有特性难以发现的bug,分析一下测试的方法和测试粒度
  选择测试用例未覆盖的bug,根据bug补充测试案例
  4、线上用户反馈
  4.1、问题反馈
  收集市场和各种反馈渠道上用户的问题,对整个版本的质量进行一个更加深入的了解,毕竟测试期间能够覆盖的机型,能够覆盖的场景还是有限的,不可能模拟到大千用户。
  分析Crash日志,进行分析和归类,快速相应解决问题。
  4.2、运营数据
  关注版本的留存、日活、月活、停留时长等是另一个纬度对版本质量的分析。
  总之,从版本总结的角度,追溯项目流程中涉及到的各个角色,各个环节,各个bug,各个踩过的坑,思考后续如何避免类似问题,在下次测试中得到提升,在下个版本的项目流程中进行优化改善,提高质量和效率才是根本目的。

上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
22/2<12
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号