软件测试BUG等级权重分配新说
作者:网络转载 发布时间:[ 2012/3/30 13:58:26 ] 推荐标签:
随着测试行业的发展,测试队伍的不断壮大,测试规范也变得越来越完善
周五下午开周例会,大家讨论一个了确定一个很有意思的问题,那是Bug的权重分配问题。
几年前,公司对于测试人员的工作评估主要是依据该测试人员发现bug数目
而现在,我们将bug分为了若干等级,分别为致命,严重,一般,提示,建议等等,并将这些等级分别附一个权重,后的测试人员的工作评估是按照后的权重值来计算的。
Bug等级 |
权重 |
致命 |
3 |
严重 |
2 |
一般 |
1 |
提示 |
0.5 |
建议 |
0.25 |
例如,我发现了2个致命的bug,4个提示的bug,3个建议的bug,后的成绩=2*3+0*2+0*1+4*0.5+3*0.25=8.75
这种方法的评估显然比起第一种方法要科学了许多,因为发现了致命的bug能给公司挽回的损失要多很多,也在一定的程度上鼓励测试人员多去发现致命的bug
其实目前很多公司都在采取这种评估方式,但是,会后我也在思考,有没有更好的方法来评估测试人员的工作呢?
我想是有的,试想,如果我们将这权重倒过来分配给这些等级的bug会如何?化成表格则是这样
bug等级 | 权重 |
致命 | 0.25 |
严重 | 0.5 |
一般 | 1 |
提示 | 2 |
建议 | 3 |
我们都知道,bug等级的评定在一定程度上也是根据bug发现的难易程度来确定的。这种根据bug发现的难易程度来分配权重的方式可能会更加贴近我们的实际工作。对于致命的bug,一般是会阻塞接下来的测试的进行,测试人员一定会给与跟踪直至其被解决。而对于建议的bug,需要测试人员花更多的时间去思考,是一种更加积极的工作态度,更是一种客户导向观念深入到骨髓的体现,这样级别的bug,公司应该要鼓励测试人员去挖出来,才能使产品越做越好。
也许我想这样的评估方式也需要基于一定的前提,那是该公司的产品已经做的比较成熟了,如果对于某产品,还停留在实现基本功能的情况下,当然第二种方式会更加符合。
本文内容不用于商业目的,如涉及知识产权问题,请权利人联系SPASVO小编(021-61079698-8054),我们将立即处理,马上删除。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11热门文章
常见的移动App Bug??崩溃的测试用例设计如何用Jmeter做压力测试QC使用说明APP压力测试入门教程移动app测试中的主要问题jenkins+testng+ant+webdriver持续集成测试使用JMeter进行HTTP负载测试Selenium 2.0 WebDriver 使用指南