基于缺陷数据的度量与分析

         软件的度量分析一直是个虚幻的话题,因为软件的开发过程毕竟不能和制造业相比,后者的过程中所产生的数据是非常有类比性的,从而度量也变得容易一些。如何在软件开发过程中抽象出可度量且具有实际使用意义的属性确实非常值得思考。

         目前所在的公司是一家美资企业,没有实际意义上的QA,虽然我自身的角色被定义为QA,但其实质上是Tester。那么没有QA,也就没有专门负责收集、统计、分析数据的专职人员,过程的控制和提升更是无从谈起。

         怎样利用现有的资源,从中提取有用的数据,来度量并分析被测系统的质量可靠性、组织效能、过程能力,并为以后的过程能力的提升做好必要的数据分析准备呢?

         作为Tester,平时工作中接触的最多的莫过于bug库,我们是否可以从中抽取数据并加以分析呢?答案是肯定的。值得庆幸的是这种数据来源的获取方式显得非常容易,几乎有测试的软件公司都有自己的bug库。

 

第一部分:从整体来统计并分析数据本身所包含的信息

         自身参加的测试项目采用了开源工具Jira来管理bug库,其自带了很多有用的数据统计报表功能,使用起来非常方便,下面举例说明,其中涉及到公司项目的信息一并略去。如果所在公司所使用的Bug库管理工具没有类似统计功能,那么可以抽出数据放在Minitab这样的专业化数据分析工具中加以出图。

1.          Recently Created Issues Report(最近提交缺陷报告)

说明:

绿色柱体含义为某一天提交的bug数,绿色柱体中重合的红色柱体表示该天提交的所有bug中到目前统计时间点为止所剩余的未解决掉的bug数。

Recently Created Issues Report

分析:

如果某一天的提交的bug数量非常多,说明这一天提交的测试版本中可能是添加了某个新的功能点,且该功能点处于不稳定状态 ;还一种可能就是开发的某一处的修改带来了连锁反应,将其它稳定之处也连带改的不稳定了,从而注入了新的bug(在实际的工作中,确实遇到过这样的问题,开发为了修改一个bug,将起先版本中稳定的功能点也改坏了)。

 

2.          Created vs Resolved Issues Report(缺陷提交与解决报告):

说明:

·           红色曲线表示随日期增加所提交bug数累计分布,绿色线条表示随日期增加所解决bug数累计分布。

·           末端一处两曲线呈水平分布,是因为恰逢中国新年。

Created vs Resolved Issues Report

分析:

·         Bug累计数随日期的增加还在持续的快速增长,并且红色曲线斜率多处区域大于45°,说明产品仍存在较多缺陷,质量并没有稳定下来。

·         两条曲线斜率多处区域均大于45°,说明测试和开发的效率都还是不错的

·         因为质量还没有稳定,所以项目测试暂时不能被关闭

 

其他情况:

情况一:两条曲线之间的间距越来越小,且红色曲线的斜率趋于平缓

分析:质量越来越稳定,且可以预见两条曲线有交织的可能性,可以考虑关闭项目测试。

 

情况二:两条曲线之间的间距越来越大,且红色曲线斜率并没有放缓趋势

分析:产品质量比较差,需要及时做出修改和调整,使产品质量相对稳定下来。

 

情况三:两条曲线之间间距稳定,但是曲线斜率趋于平缓

分析:开发遇到了技术挑战,效率开始降低。由于模块不能及时发布,同时也影响了测试效率。

 

3.         

  • 3
    点赞
  • 13
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值