测试人员的考评
公司施行基于Bug数量的考核（Bug数量占到了个人考核绩效得分的70%），引起了大家不同程度的争议。下边谈谈我个人的看法：首先，把Bug数量做为考核测试人员水平的杠杆是否合适？什么是软件测试：为了发现程序的错误而执行程序的过程。那么，选择Bug数量去考核无疑是正确的，这点我非常赞同。并不是因为在公司统计公布的测试人员测试出的Bug数量中，我的名字名列前茅就支持这样的政策，实则是有如下原因：
1、测试出的Bug数量反应了一个人一段时期之内的工作量，一个Bug耗费的工作量围绕着Bug的生命周期主要集中在如下几个方面：发现、交流确认、回归验证、关闭Bug；自然，越多的Bug需要处理，那么工作量越大，一个人的工作量越大，考核得分高也是应该的；
2、测试出的Bug数量多，从一个侧面反应了一个人的测试水平。为什么同样的质量水平的产品，有的人测试出的Bug数量多，有的人少呢？实则是因为对于需求、设计的理解水平的高低决定了测试人员测试的功能点的覆盖程度不一、深入程度不一。经验老道的测试人员能够统筹全局，找到整个系统的测试重点，然后再逐步深入，挖掘细节问题，直到数据方面的测试，这样的情况下，测试不仅仅是黑盒测试，而是趋于黑白盒之间的灰盒测试，那么自然发现的Bug也就越多了。
3、Bug数量越多，也反应了一个人工作效率的高低，这点就不多说了。
那么为什么又存在那么多的争议呢，分析了一下，有如下原因：
1、职责不分，不管管理人员、自动化测试人员、产品测试人员、项目测试人员都实行一刀切的政策，全部按照Bug数量这个硬指标去执行，自然不大合适；
2、Bug的数量有了，但是质量如何还是值得商榷；为了追求高的Bug数量，有的人甚至抄袭其他人的测试结果，这样造成众多的重复问题；另外一个问题就是出现很多不是错误的Bug，这些不是错误的Bug不仅仅反应了测试人员的业务能力不高，另外也白白的占用了开发人员的工作量；
3、再一点，因为追求Bug数量，对于复杂的系统，测试大多都浮于表面，很难深入的测试到数据层面；毕竟一个复杂的数据测试可能要耗费上几天的功夫，但是有这几天的功夫，不如去发现更多的肤浅的问题；对于有责任心的测试人员当然不会这样，可是对于一味迎合考评的人员来说，无疑是个捷径；但是对于系统的质量来讲并没有什么好处；
所以说考核很难做到绝对的公平，当然如果能在考核的时候，考虑到一些细节的问题，如何使考核政策更加完善才是我们追求的目标. 是的。对测试人员的考评标准中，人测试员发现的Bug数量 是一个因素，但不是唯一的一个因素。我建议 把测试人员发现的Bug的质量（严重程度）、测试人员的工作态度、完成的测试用例的情况、对团队的贡献（合作精神）等也考虑进去。毕竟考核的目的是为了提高整个团队的工作效率。这样的考核才合理。 说的好 我做的考核制度是按照这些来打分做的：工作量、工作效率、文档质量、bug质量、用例质量、出勤率、团队贡献、工作主动性、进步情况共9项。个人觉得不能单一按照bug数量来考核，否则弊大于利，甚至起到反激励的效果，曾经面试的一个测试人员离开他所在公司的原因就是因为公司用bug数量来考核。 受益匪浅啊 感谢分享 我发现我的文档完劝没有跟上我的 测试水平要好好努力修改的了 我做的考核制度是按照这些来打分做的：工作量、工作效率、文档质量、bug质量、用例质量、出勤率、团队贡献、工作主动性、进步情况共9项。个人觉得不能单一按照bug数量来考核，否则弊大于利，甚至起到反激励的效果，曾经面试的一个测试人员离开他所在公司的原因就是因为公司用bug数量来考核。 不太清楚，以后应该会知道吧 我们公司测试绩效考核也是多指标的，因为在制定绩效的时候我很反对以BUG数量进行考核 学习了 我认为LZ对测试的职能理解不到位，我所认为的评测过程的本质是“发现被测软件的质量，并无限趋近于软件的真实质量”，因此对于一个已经经过千锤百炼的软件，和一个垃圾软件，哪个发现的缺陷更多；一个10000个功能的软件和一个100个功能的软件，哪个问题更多；由此我认为只要是评测后得出的软件质量和经过长期用户使用而反馈的质量差异最小化才是测试的最终职能，本来问题很少，并且发现的可能性就小，那么没查出来也属于正常，用户都不认为是问题的东西，你认为是问题，只能说明你丢失了最根本的依据！正确地讲应该以通过率与用户使用反馈的通过率做比对，比较其中的差异，作为评价业绩绩效的标准！ BUG数量很讨厌的，这样的话很多测试人员会因为绩效的原因不去找一些难出现但是对软件质量很重要的BUG，而关注一些鸡毛蒜皮的东西
页:
[1]
