从测试角度度量项目质量的7个维度

“严重Bug”指的是在项目中,优先级为A和B的Bug。由于我们公司用的JIRA不像Bugzilla那样,对Bug分为“严重程度”和“优先级”两个维度,因此我们在报Bug时根据情况综合这两点的影响,统一以“优先级”来衡量Bug级别。A级Bug是指程序无法正常运行或者是测试无法正常进行;B级是指各个主要功能模块出现用户不可接受的错误。C级和D级大多也是一些功能方面的问题,还有一些用户体验易用性的问题,用户可以接受少量这种类型的Bug。 1、严重bug数 / 测试用例数   这个维度代表了一个项目的严重bug数量是否正常,让测试用例参与计算,是为了平衡规模不同的项目的数据。   2、第三轮系统测试出现的严重bug数 / 严重bug总数   由于需求变更和项目并行比较常见,又不可避免,因此目前我们的测试流程尽可能的控制不超过四轮系统测试,四轮的目标分别是:发现bug、验证bug并响应变更、继续验证Bug、稳定回归。如果在第三轮系统测试时,还出现大量严重bug,那说明可能是之前的测试做的不到位,或者有新的变更,再或者开发修改缺陷带来的成本太高,肯定是不正常的,也会对第四轮的回归带来巨大风险。因此这个数字应该要控制在一个很低的水平。   3、被重开的严重bug / 严重bug总数   重开指开发修复缺陷后,测试验证不通过,或者是已经关闭的Bug又复发。这个维度也应该被控制在一个很低的水平,如果偏高,说明开发修复bug的效率偏低,代码不稳定,发布后出现bug的几率可能会增加。   4、第二轮、第三轮测试用例平均通过率   因为第二轮和第三轮的目标就是修复bug,所以如果第三轮结束的时候,严重bug全部被修复,并且第三轮没有出现新的严重bug,那么可以说项目的质量是非常稳定的。这里判定第二轮、第三轮用例通过与否的标准,就是看这两轮测试结束时,如果有严重bug没有关闭,那相关的测试用例就是failed。此外,C、D级bug如果没有关闭,除非有确定的用例与之对应,否则不会影响用例的通过率。   5、测试工作量(人月) / 测试用例数   这个维度代表投入的测试资源是否充足,这里的工作量,指的是从测试设计到测试执行的所有人月数。如果数字过低,说明测试资源紧张,无法保证测试质量;如果过高,说明有可能测试效率低,测试负责人需要进行解释。   6、严重bug平均关闭时间(天)   bug 关闭时间,指bug从创建开始,到close为止,经过的时间,要精确到小数点后1位。只有状态是closed的bug,才会计算关闭时间。平均关闭时间的计算方法也很简单,把所有closed严重bug求平均值即可。这个维度代表项目组解决bug的效率,如果时间太长,说明项目组对bug重视不够,或者开发组资源不足。   7、已修复Bug / Bug总数   这个维度代表测试人员所报Bug的总体修复率,如果修复率过低说明在测试过程中对于项目的控制出现了问题,可能是在测试过程中产品变更过于频繁,对变更的控制不合理,或者测试组对于项目的理解有偏差,项目经理和测试负责人需要给出解释。

转载于:https://www.cnblogs.com/qileilove/archive/2012/01/09/2317414.html

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值