我们公司正在组建测试部门，对于如何考核测试人员，如何制定考核标准

木木妹

这些是我原来用的一些资料，我做的那份，因为换工作再加上家里机器出问题维修给丢了，你看看这些资料对你有用嘛
测试计划合格率（计划的合理性、可执行性）
2、测试用例数以及合格率
3、测试报告质量
4、测试发现的缺陷比率（不是绝对的缺陷数目）
5、漏测问题数（没有被测试到的问题流出去，是影响测试绩效的，但不是很合理，因为有些是黑盒很难测试到的，尤其是分析系统，不是业务系统）
6、测试总结质量以及测试技能提升情况
7、其他（就看主管对你的看法了，比如工作态度啊之类的）
公司施行基于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数量，对于复杂的系统，测试大多都浮于表面，很难深入的测试到数据层面；毕竟一个复杂的数据测试可能要耗费上几天的功夫，但是有这几天的功夫，不如去发现更多的肤浅的问题；对于有责任心的测试人员当然不会这样，可是对于一味迎合考评的人员来说，无疑是个捷径；但是对于系统的质量来讲并没有什么好处；
     所以说考核很难做到绝对的公平，当然如果能在考核的时候，考虑到一些细节的问题，如何使考核政策更加完善才是我们追求的目标.

木木妹

这位说的很有道理，用TD8.0管理更实惠。这个工具的高级使用会让你的管理更加轻松。建议对工作态度做为考核的一部分，不仅仅考核工作效率。个人认为这是一个团队能不断引进新技术新思想的动力。