引言

    经常会听到有人讨论，某某一个月发现了500多条bug，还有谁一天发现了100多条bug，公司的绩效是根据bug量多量少来衡量等问题，但是，我们能仅从bug量上就看出来一个人的工作质量吗？显而易见，这样太过片面了。

    首先，bug量显示了哪些问题，代表了什么？在这里我们认为bug多的软件质量可能不好，为什么说是可能，而不是肯定，因为这里面缺少了参照点，下面将从bug量配合查看的因素来进行分析。

一、Bug等级

    bug量多需要配合bug等级来看，如果1、2级别的bug很多，那明显就是版本质量差了，开发缺少自测流程。一般来说，1、2级别的bug比例应该占4%以下最好，具体根据不同项目组来。同时3、4级别的bug也要看下比例，具体要看对bug等级的定义。

二、有效bug率

    bug量需要配合有效bug率来看，不然一大堆无效bug，只是为了增加数量，其实一点用处也没有。bug有效率低，不仅降低了测试效率，也会造成测试开发配合满意度降低，造成整体项目进度滞后，所以bug有效率很关键，常规测试的bug有效率在92%以上最好。对应优化率，也需要控制比例，以此来判断是否是产品需求问题还是对软件理解度不够问题。

三、Bug激活率

    bug量多也要配合bug激活率来看，bug激活多了，需要找找原因是测试描述不清晰，还是开发没理解。bug激活率到底有多大影响？以100个bug为例，激活率为10%，等于开发需要解决110（100+100*10%）个bug，测试要回归110个bug，这样造成测试效率低并且提高了项目质量风险。一般bug激活率是严格控制在10%以下。

四、需求

    bug量多更要配合需求来看，这就需要在提交bug时，关联需求，这样就可以知道或者证明80%的bug来自于20%的模块。需求多，bug分布平均，不代表质量差；但需求少，bug量多，那质量一定很差。所以在测试报告中，一定要有模块bug的统计，以便在后续的测试过程中，模块问题多的开发，其负责的模块需要多测。

五、时间范围

    bug量多需要配合测试时间范围来看。如果每个月平均100条，那不算多，属于正常输出，如果突然一个月500条，就需要关注以下是什么原因造成的了，是工作量变大，还是软件质量存在问题。

结论

    bug量的考察需要综合以上考虑，虽说bug量并不能直接体现出一个人的能力，但从侧面也会反映出来工作量。比如：A每天提交30个bug，B每天提交100个bug，这里面涉及到的紧张感和工作压力还有耗费的精力，肯定是B会比较累，所以bug量会在绩效考核上占据一定的比例。但是切记，考虑问题不要只考虑单一因素，当数据突然变化，就需要去了解是否有问题，做任何事情都需要有数据作为依托，这样大家才会信服，团队配合度才会高，工作起来就会顺利。