有用的bug评价标准


原标题:有用的bug评价标准

当测试发现BUG时,它的意义不仅在于修复这个BUG本身,通过一些有用的Bug评价方法,还能实现软件质量控制、决策测试是否终止等诸多妙用。

几个有用的Bug评价标准包括:

  • 修正率 。 项目组修正Bug的速度被称为修正率 。 这个指标可用于判断交付里程碑是否会受到影响。 因为如果项目组修正Bug的速率落后于测试Bug生成的速率,而且所有新生成的Bug都必须进行修正,项目就无法交付。
  • 新生成Bug与已核准Bug的比率 。 知道新生成Bug和已分类Bug的比率,有助于帮助估计未生成的Bug。 一般而言,Bug的级别和数量会随着时间而下降。 而原始的生成率无法告诉你这些。
  • Bug的存活时间 。 Bug的平均存活时间表明了项目组对于Bug的响应能力,Bug存活时间越长,表明项目组处理Bug的响应能力越差,项目组可能有很多其他任务在忙; 而Bug存活时间越短,表明项目组主要忙于处理Bug。 通过这个数据可以调整项目组成员的工作重心。
  • 每位开发人员负责多少Bug 。 了解这个指标是因为开发团队要负载平衡,每个开发人员在投入到开发和修正Bug上的时间比例应该是很接近的。
  • 错误反馈比 。 Bug修正而引起的回归率称为错误反馈比(Fault Feedback Ratio,FFR)。 如果每个已经修正的Bug会引起另外两个Bug,FFR就是2.0 。 根据Weinberg的观点, 0.1到0.3的FFR是基本可以接受的比率;任何高于此范围的值都意味着必须要提高质量 (并且/或者步调必须减慢)。 多数的Bug数据库都允许把新的Bug链接到已经存在的Bug上,使之可能追踪FFR值。

以上是微软公司曾经使用的一些Bug评价标准。

Bug数据用处多,可对进度做预测

团队管理少不了,控制质量没话说

免费咨询:提供朋友圈、成交,广告、招商文案策划、优化服务,立刻加微信:57807073

版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站不拥有所有权,不承担相关法律责任。如发现有侵权/违规的内容, 联系QQ15101117,本站将立刻清除。