这个问题太好了，也是一直困扰我的一个问题。
理论上都好说，实际工作中怎么都不好衡量的。
姑且只能靠bug数，最为直观，可度量。那么用bug数评价，我觉得比较单一。应该是
bug数、有效bug数、用例数、用例数评审通过情况这几点综合评价。
用例很多地方都不写出来，那么只能看bug数了。
现在还是人治的公司比较多吧，对测试的考核真的比较难，测试的工作的质量的高低很大的取决于系统开发质量的高低，就是说没个人做事情的起点是不一样的，所以很难评判。
进入公司两年多，领导貌似重视测试，但其实对测试有什么重视。问领导对测试如何考核，说来说去还是只看重技术能力。个人觉得，测试人员的技术能力确实很重要，但其他方面也不忽视的，例如：
1.个人能力，包括业务分析能力、沟通协作能力、测试人员应备技术能力
2.工作绩效，包括任务完成度、执行力度、工作效率、工作质量
3.学习与反思的能力，这个无论对公司或者对个人都是极其重要的。
本帖最后由 zhyb_2008 于 2011-2-17 17:18 编辑
想的太复杂了
管理的最终目的是简单，有效，考核也只是管理的一部分
做为测试管理人员，
把表现形成做的简单一些就好！复杂了也浪费时间。
真正复杂的，也就是那些制订的部门工作计划，是不是做好，做完了!
这些工作计划指标，会分配到测试部的每个成员，以结果为导向进行。如果测试部在公司的考核是不合格的，意味着有些员工的考核肯定是不合格的；同样，员工的考核如果不合适，那部门有的指标也好不到哪儿去。
我的考核方式：
部门有工作计划考核指标，把部门的分解到每个员工，进行考核，完事。
当然，员工的日常工作状态，方式方法，都有相应的标准监管，这是考核的前提。
我们最后的考核，只考核结果！
给两个附件，可以参考，共同学习，有更好的方式，给我留言，共同进步。
针对不同岗位的测试工程师，有不同的分解指标。各人的考核指标在季度之初，是管理人员和每个人，协商后完成的，是要签字画押的！公司测试部门没多少人，就经理一个个面谈。人多的，测试主管完成，测试总监审查一遍完事。
不知道什么是客观，什么是主观，每个测试人员在其位，就要谋其职，把自己的指标做好就行。如果指标做好了，管理人员还不满意，那说明管理人员订的部门指标就有问题！如果指标没有做好，那就没得说了，个人能力问题，待观察！
先回一贴在仔细看，我怎么记得，这个话题是我最先展开的啊！！！！不过我展开的主题不是这个，我发表的是奖罚制度KPI，其实咱俩的主题都一个意思 就是考核嘛呵呵
回复 4# huxb_dowant
我比较同意这位同学的。
我暂时经验，但是我认为公司考核，是判断一个人是否有价值，能否给公司带来利润，如果可以，那就是合格的，不能的话，就是失败的。
回复 24# zhyb_2008
我看了楼上的2个文档考核内容，我觉得都特别的形式化，对个人来说是把bug率作为唯一标准的！
关于测试部 管理层，针对部门员工的工作安排、员工的工作指导方面、以及对于本部门与其他相关部门的沟通等方面的考核我没有在文档中看到，其实这个也算管理层考核的范围！
对于个人来说除了文档中涉及到的每天测试多少个bug、通过率以外，因为不清楚你们项目的规模情况，应该还涉及测试人员对项目的需求理解 与相关人员的沟通（项目经理、开发人员等），每个季度是否有新的内容研究或者有好的内容分享，还有就是对新的员工对各系统的熟悉情况，员工对本部门是否有好的意见或建议这些是可以作为加分项的！每个季度不紧要有减分还得有加分，作为员工的响应奖励！
我们这边的季度考核表，在整体不变的情况下，针对每个员工每个季度的考核表都会有不同程度的变化
受教了
本帖最后由 zhyb_2008 于 2011-2-24 15:00 编辑
回复 28# lienahu
看来你还不了解什么是测试过程，什么是结果，考核是结果，监督的是过程。如果把过程和结果全去考核，你感觉很全面，结果到最后，发现什么都没考到！
当然，不同公司，公司制度，部门制度规范，等，不同，也不一定都是完善的，所以，这些只是暂时适合我这儿的测试管理。也不是一成不变，以后慢慢调，逐渐进步。一口气也吃不成胖子。
另外，这两个表是本来就有缺陷的，原版有些公司的其他方面的，是不能发的。只是一个形式主义的参考。大家想看，就看看，然后自己发挥，不想看，就不用理会。
本身也只是想强调一个问题：就是测试过程很精采，达到的结果却很重要，以结果进行考核，一般没错。
观望
有这么难吗？首先，bug数量，以及误报比例（不是bug的，重复的，无法再现的），不同级别bug的提交时间，比如有些很严重的bug到很晚才发现，而且相关代码是很久没修改过的，说明这个bug很早就有，但是一直没有发现，以及，每个产品结束后，相关测试人员进行内部交流，比如参与测试的几个人就自己负责的功能和模块进行讲解总结，负责整个产品的测试人员作为一个集体向所有参与这个产品的团队进行汇报，体现对这个产品的了解程度，客观上，即使没有发现很多bug，测试人员也应该在项目结束时对产品了解的足够深入，这就表明，虽然我没有提交很多bug，但是我很了解这个产品，而且我该走到的功能和case都做过了，所以bug少不是我不努力，而是开发人员确实很少犯错误。综合以上各种方式，只要测试人员通过各种方式表明，我对这个产品很理解，那么无论bug多少，都可以算是进行了合格的测试
再追加一句：公司追求的是利益，在此前提下谁能为公司创造利益（直接或者间接都行），谁的绩效就好，回报就 ...
jackleipm 发表于 2011-2-13 10:16 http://bbs.51testing.com/images/common/back.gif
这个真未必，你找到100个bug，都是很极端的情况下才有可能出现的
我只找到20个，全部都是正常使用就能遇到的
数量不是问题，还有个重要性问题
测试人员的绩效考核的确比较难以做到公平和平衡，前面站友提出BUG不合理，站在软件测试角度是不合理，但是站 ...
jackleipm 发表于 2011-2-13 10:10 http://bbs.51testing.com/images/common/back.gif
那就是说，越是垃圾的开发人员，越是有助于测试人员立功受奖了？
这个话题确实不能给出标准答案。因为每个公司情况不同，测试在其中位置又是不同，这就很难给出一个大家都认可的答案。下面谈谈自己的想法。
首先，需要确定自己公司的考核指标。
1.确定所在测试工作的产出物。比如测试需求分析、测试计划、测试方案、测试脚本、测试用例、测试报告、缺陷等等。
2.针对公司的实际业务，把产出物排列优先级，并结合可度量性确定考核内容。比如测试方案、测试用例、测试报告等。
3.针对考虑的内容，明确考核指标。尽可能做到用数字说话。
其次，是测试人员的执行力。说白一点，就是对工作的态度。是否能专心投入。
再次，就是完成工作所需要的知识、技能、工具和方法的考核。这方面的考核已经比较成熟，是比较容易操作的。
总之，通过以上3点的思路，并把握以数据说话的原则来考核测试人员，不论对公司领导，还是对测试人员都是能接受的。
考核方面很多，根据不同的情况进行考核。每个公司都有自己的标准，根据实际来衡量一个测试人员的水平。单纯用BUG来去衡量是不正确的。看深度和涉及的方面是否符合软件的需求等等。
无论是从BUG量还是从BUG质量(严重性)来考核我觉得都是不妥的，依据的前提是假定所有被测对象存在相当量及相当严重性的问题，这样才能通过不同测试人员发现的BUG量及严重性来区别评价，但怎么来保证不同测试人员的测试功能存在相当量及相当严重性的bug呢？让程序员设计出样的不同的功能模块出来也是比较困难的，即使可以，也仅仅是为了考核测试人员而设计的，背离了测试工作的本质。
考核应该从最终的结果评价作为主要考虑，再通过主观的一些东西，如学习、思考建议、知识共享等方式上去加分。
最终是通过考核让每个人有前进的动力和方向，而不是为了得到一个好看的分数。
最好的考察就是工作中用到的技能如何！
其他都是浮云！
例如：有的公司做的项目是纯国内的，把英语列为考核指标，有毛用！
总之一句话，用到什么就考察什么！其他都是浮云！
哇嘎嘎
:loveliness:
