测试群里前几天异常火热的在讨论测试Bug量，某某一年发现了将近1000条，谁一个月发现了500+条，我们的绩效是根据Bug量多少来衡量等等；今天我们就来论一论Bug量的含义；
首先Bug量显示了哪些问题，代表了什么？基础的我们先从量说起，量变引起质变，没错，就是引起了软件质量的变化，也就是有可能是软件质量不好，为什么说可能，因为这缺少了需求，还有时间因素对比，那我们来看下Bug量跟哪些因素配合查看，会产生什么反应?
1.从Bug量多配合等级来看，如果1，2级Bug很多，那一看就是版本质量差了，这时肯定流程存在问题了，缺少冒烟测试，开发质量绩效考核等，简单的可以理解，1,2级Bug的比例应该占在4% 以下是最好的，具体根据不同项目组来，一定要设一个阀值，这个关系着测试效率，测试质量，也关系整体项目进度；3级，4级的Bug也要看下比例，具体要看下对Bug等级的定义；
2.Bug量多也要配合这有效Bug率来看，不然一大堆无效Bug，只是为了增加量，其实一点用处也没有，只有敷衍了没睁开眼的上级，Bug有效率低，不仅降低了测试效率，也会造成测试开发配合满意度降低，整体项目进度滞后，还可能会有摩擦，所以Bug有效率很关键，常规测试的Bug有效率在92% 以上最好；对于优化率，可提高率型的Bug也要注意比例，来判断是否是产品需求问题还是对软件理解度不够问题；
3.Bug量多也要配合Bug激活率来看，Bug激活多了，是测试描述不好还是开发看不懂，天天有意来“骚扰”测试妹子，让测试妹子无法静下心来干活。Bug激活率代表着什么？最简单的，如你发现了100条Bug，激活率为10%，等于开发需要解决110（100+100*10%)Bug，测试要多回归10条，而且不是在同一轮，这样造成测试效率低并且提高了项目质量风险；一般Bug激活率是严格控制在10% 以下；
4.Bug量多也要配合着需求来看，这个就需要定义和关联好需求，直接Bug关联需求，这样就可以知道或者证明80%的Bug来自于20%模块，需求多，Bug分布平均，就不代表质量差，但需求少，Bug量多，那一定质量很差，测试在刷Bug，特别对于领导只看Bug量，特别有用；所以在测试报告中一定有对这一块的分析，为什么？除了为什么,找到原因以后，其实我们会对这个需求模块开发的人员，产品人员会贴一个不靠谱的标签，以后这些人负责要多测，一定要费心，跟踪好；
5.Bug量多也要配合着时间曲线来看，如每个月平均100条，那不多，正常输出，如果突然一个月上500,那就要注意下是什么问题，提醒你去关注了，是否这个月的工作量大，还是软件质量存在问题；
综合以上，就是我对Bug量的一个看法，不会从一个单一的因素看问题，不过我想说对于Bug量多少在绩效考核一定会占据一定的比例，最简单的是：一个人A1天提交30条Bug,跟一个人B一天提交100条Bug，这里面涉及到的紧张感和工作压力跟耗费的工作精力，肯定会B比较累，所以权重就会高一点，绩效往往的最粗糙的方式就是对比。但记得对比或者考虑的不要只考虑单一因素，当数据有变高的情况，就需要你去了解是否有问题。所以这里我也建议各位做测试管理的，需要有一个质量大盘，需要有自己的团队数据，做任何事除了内容上的叙述，也要有数据作为依托，这样大家信服感才会高，团队配合度才会高，工作起来就会顺利。
