Bug等级权重分配

随着测试行业的发展，测试队伍的不断壮大，测试规范也变得越来越完善

周一上午开周例会，大家讨论一个了确定一个很有意思的问题，那就是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，公司应该要鼓励测试人员去挖出来，才能使产品越做越好。

也许我想这样的评估方式也需要基于一定的前提，那就是该公司的产品已经做的比较成熟了，如果对于某产品，还停留在实现基本功能的情况下，当然第二种方式会更加符合。

-----------以上是转载的信息

  关于bug的致命、严重、一般、提示、建议的定义还是比较含糊的。

  那该如何来定义这些bug的等级呢？

  比如说，页面文字说明写错了，这该归类为什么等级的bug,