我补充一下：
1. 1.2项目延期率：我们公司目前的考核制度里，这是一个很重要的因素，项目出现延期整个项目组每个成员的绩效都会受到影响；
2. 2.2 bug的数量和质量：这个我更看重的是提交bug的质量，不同严重程度的bug比重不同。
引用14楼的回答：
回答软件测试考核的问题
鄙人从事软件测试好几年了，也一直为该问题困扰，每次项目作完了，感觉大家都表现还马马虎虎。但是项目却感觉总不是那么完美，既然存在问题，说明测试人员的考核做的不到位，所以最近痛定思痛，也咨询了一些在微软和IBM做测试的朋友，结合自己多年来的实践，得出如下核心考核指标，和大家共享。
测试人员主要是三个方面。
第一，整体工作效率。第二，工作结果。第三，过程控制。（针对测试主管或组长）
1.整体工作效率
1.1有效工作时间
主要check指标是每日实际工作时间，按照Ms的标准，一个测试工程师的每天的有效工作时间应该在70%以上。如果只有50%或以下的有效工作时间，那么不能成为好的测试工程师，因为他有能力做得更好。
1.2是否在制定时间内完成工作任务
主要check指标是进度偏离度。主要是和测试计划相比，有多少的延期。这个指标计算是：计划时间/实际需用时间。
当然，本指标未考虑其他因素，如开发人员窝工导致的delay。
2.工作结果
2.1测试用例的数量和质量
a，测试用例的数量
主要考核指标是用例编写速度，考核办法是测试用例的个数/写用例所用时间。
b，测试用例的质量
主要考核指标是用例编写质量，用于考察文档是由有效的指导了测试工作。考核办法是来自用例的bug数目/总bug数目，应该是70%以上才算是质量比较好的用例。
2.2bug的数量和质量
a，bug提交的数量
主要考核指标是提交bug的数量，这个指标根据项目不同而定，不好给出固定经验值。
b，bug的质量
主要考核指标是提交bug的质量，即提交的bug，严重程度和，发现路径的复杂程度
c，发现bug的阶段
主要考核指标是提交bug的时间段，具体执行是统计在测试的每个阶段，发现bug的比例，特别是严重的bug发现的早晚
2.3是否及时验证关闭bug
主要考核指标是验证关闭bug的及时度
2.4测试自动化程度及收效
主要考核指标是，测试中自动化运用的含量，也就是测试技术含量，成果如何？
2.5所负责模块的产品总体质量以及用户反馈
这个总体质量是产品发布之后一段时间才能得出结论，主要是市场，用户对产品的质量、稳定性、性能的反馈。
考核的主要指标是两个。
a，根据市场反馈（由经理定性考核）
b，根据测试人员提交的bug和用户反馈的bug之间的比例，比例越大，说明测试质量相对越高。当然前提是必须划清楚客户的新需求，或者对spec设计方面的抱怨。
3.过程改进
考核点，是纵向对比，相比上一个项目，在质量控制上和测试进度进程上有否进步。包括测试方法，提升质量的手段，测试数据记录，用例更新等等有没有改进。
该项具体考核方法也是经理来根据测试组在过程中具体表现，来定性打分。
还包括测试人员在测试过程中的学习能力。这个也是定性。
4.考核注意事项
4.1统计bug的注意事项
5.其它注意事项
作为考核者要注意以下比例，也许有些没有列入考核内容，但是如下这些点可以指导测试。
a，测试团队发现的bug和所有bug之间的比例
b，spec设计造成的bug
c，重复或者误提交的bug所占的比例
d，每周发现的bug的趋势图
e，Bug严重等级的构成比例
f，Bug从提交到解决的平均需要时间
g，Bug从解决到关闭的平均需要时间
[ 本帖最后由 saxifrage 于 2008-4-17 15:24 编辑 ] 如果我是测试经理，我会看我的团队在一定时间内的成绩从而进行业绩考核
我现在被考核的标准就是所取得的成绩，毕竟在这个商业化的世界里，所有人的目标都是如何赚钱，这也符合发展的方向，多劳多得，少劳少得，我同意拿成绩来考核！ 看来偶的这个问题不太受“欢迎”哦，快颁奖了，候选人才这么多 我只想说,这个问题很歹毒!~~~目前我还没听说国内有哪个企业能把测试工程师的考评做的很好的~~~~~:victory:
会员huior 不愧是高手,问出了众多测试管理人员心中共同的疑惑,呵呵~~~
期待好的回答~~~~
回复 26# 的帖子
本周的评奖已经结束，但回答仍在继续，期待更好的回答 我不懂为什么需要这样的绝对量化标准来对个人进行考核作为公司来讲，提高效益是通过团队来实现的
非要对个人分个三六九等还怎么凝聚一个团队呢
作为老板，永远都不知道一个测试团队里的一个测试工程师每天到底干了哪些事情。 那又如何对他考评呢？
作为测试主管，记录数据当然是必要的。 但是这些数据是作为一种度量以及为今后的项目前期工作提供一个参照，绝对不能作为什么死板的考核标准。 一个团队中每个人所起的作用是不同的。 有些人看似没有产生多少业绩，但是他在团队中可以起到一种无法衡量的推动作用。 你如何通过数据来考核这种人？
14#这种回答就是典型的拿人当机器来管的
而且很多是有问题的
1 测试用例的质量
这个是现在很大的一个误区：认为一定要发现bug的用例才是个好的用例
这句话本身确实有道理。 但是拿这个当考核标准的话，很可能使得设计用例的人一心想要设计出能够发现那些“难于发现的缺陷”的用例，陷入到了一种片面当中去。 忽略了对测试需求必要的覆盖。
2 bug的质量
个人看法这纯粹是在纸上谈兵。 不知道14#能否解释下什么才是高质量的bug？ 或者回答我一个问题：一个bug发现界面上的一个按钮位置错了，另外一个bug发现表单全为空值时提交会crash，这两个bug哪个质量高？
3 是否及时验证关闭bug
这个在项目中会和很多客观因素相关，怎么能作为考核标准-_-
4有效工作时间
有效工作时间要参照ms的标准，为啥不在工作环境和员工薪水方面也参照下ms的标准呢？ 我可以非常肯定的说：90%以上的公司没有给员工提供一个合适的工作环境。
另外根据我多年工作经验可以告诉你：一个人是不可能连续8小时集中精神保持相同的高效率进行开发或者测试工作的。你所谓的有效工作时间增加可以让员工工作得更多更快，但是会让他们效率更低质量更差。
回复 28# 的帖子
说的有道理。不过有时候拿数据说话，也是不得已而为之。试想一下，如果采用PERT的方法来考核，如果下属有人有异议，岂不是更没有办法服众？继续期待更好的答案！
28#太幼稚了
每一种行业都有考核办法，每一个行业的从业人员都有高下之分，当然很多东西是要定性的，也就是说不是所有的东西都可以量化的，但是如果不能挑出一些可以量化的关键指标，就是KPI，那么测试人员根本没有办法考核？如果你手下5个测试人员，都在做同一个项目，如果没有一些量化的指标，请问你如何进行升降奖惩？吃大锅饭显然不是办法。另外，我要说的是，任何一个考核的前提都是说，找准核心指标，就是说哪些指标确实能反映问题，哪些指标确实能体现你的工作效率，工作质量。
我在14#所发的帖子就是我个人根据多年的实践，参考一些大公司的做法，所提炼出来的一些指标。
当然在具体考核的时候总归是有很多的客观因素，不是硬性照搬，但是总归得有些核心指标。我一向认为测试人员的考核很难进行，但是不能因为难就不做，并且确实有一些指标可以使不同的测试人员有高下之分的。 考核是很全面,可是由谁来评估呢? 测试人员的作用，是为了保证产品的质量，那么，在测试中发现的bug的数量及质量，当然就是考核的首要指标。
发现产品的bug，如果bug得不到开发人员的认可或不能及时的解决，那么，发现的这个bug就没有价值，因为没有因此提高产品的质量
，所以，我认为考核的第二指标，就是bug的解决率。
测试人员和研发人员，在某种程度来说，就是对立的两个工作角色，而为了测试的顺利进行，测试人员及开发人员的友好和睦关系，直接
影响到了测试的执行效果，因此，有效的沟通及测试人员工作的态度也非常重要，这是考核的第三指标。
事实上，能否有效的进行测试，和一个人的工作态度及其相关，只有有耐心，有责任心，才能把这份工作做好，呵呵，写到这里，我感觉责任心和耐心的
好像比发现的bug重要性还高些 ：）
剩下的，还有测试人员的学习能力等等等等，其实都很重要 我们的测试工作考核这方面也存在困扰 原帖由 puchonghui 于 2008-4-20 10:10 发表 http://bbs.51testing.com/images/common/back.gif
2 bug的质量
个人看法这纯粹是在纸上谈兵。 不知道14#能否解释下什么才是高质量的bug？ 或者回答我一个问题：一个bug发现界面上的一个按钮位置错了，另外一个bug发现表单全为空值时提交会crash，这两个bug哪个质量高？
写得清楚就都是好bug，写得一点逻辑都没有，就都是不好的bug :call: 能说到测试人员 的绩效考核问题，看来你们的测试工作已经比较正规划了，羡慕中....
在一个速制的软件项目中进行测试真是件永无天日的工作，像这种较正规的测试团队提交的bug是否及时的被开发人员kill掉了呢？
既然说到对测试人员的绩效考核，是否开发这边也有相应的考核制度？
只有开发人员 修改了bug，自己才可进行验证测试、回归测试，似乎测试人员总是被开发人员牵着鼻子走，如果他们不合作或不及时，我们的工作简直就是白瞎，这样的工作岂不是很郁闷
[ 本帖最后由 cjchm 于 2008-5-21 11:02 编辑 ]
共同学习，只为了软件测试人员和这个岗位能被更多的人视为重点。
说的很好哦，说的还是蛮全面的，相信你也是一名不错的测试人员噢，我是刚刚做测试，希望以后能多多指教。一起努力！ 对待工作的态度，BUG数量+质量，自己工作能力的提升，自己对测试团队的贡献（知识、心得、经验的共享）回复 28# 的帖子
puchonghui说的问题，都是很实际的问题。有些方案看其来很让人兴奋，实际上可实施性并不高；
有些数据看起来很漂亮，实际上并不能反应客观事实。
不管什么样的方案，要想发挥预期的作用，关键有几点：
1，可以得到大家的一致认可和支持。
2，得到严格的执行。
3，执行中可以不断的完善。
实际工作中，恐怕没有几个考核方案能够达到预期的目标。
我们为什么要考核？？
考核只是一种手段，但是，绝不是唯一的手段。千万不要为了考核而考核。
实际的工作，不仅仅是测试，都不是像考核标准那样死板，有很多工作，或者问题，都是考核标准以外的，无法用数据来衡量的。而这些无法衡量的东西，有时可能很重要。 一个为了数据而工作的人，很可能不是好员工
[原创]如何有效的考核测试人员
[原创]如何有效的考核测试人员当前国内很多公司对测试存在普通的认识不足，经常听到许多公司拿Bug的数量来考核测试人员的唯一方法，哪么我要说“测试人员的考核不是仅仅看Bug的！"
如何有效的考核测试人员？好的考核能激励测试人员，提高工作效率；相反“不公正”的考核，则会降低工作效率,引起测试人员的不满！本文作者以实际的测试管理工作经验结合当前公司的特点制定了以下措施，相信肯定有很多测试人员会产生共鸣！
1 工作态度
通常由“协作性”，“积分性”“责任心”三部分组成，每部分为4档：优秀，良好，合格，差
2 对公司产品业务流程了解程度
通常分为4档：精通，熟悉，了解，不清晰
3 测试技术(手工+自动化)
通常分类“手工测试”和“自动化测试”,其中两个大类又细分技术难度为：难，一般，容易
通常初级，中级，高级，测试组长等是依据职位的定义性质不同来考核，每个职位等级分为"优秀"，“良好”，"合格","差"：
如初级测试工程师重点考查“Bug”的数量和严重性，用例的编写覆盖，Bug Report的规范性等
5 测试文档
编写用例个数/修改用例个数，测试用例覆盖度，新增用例个数，用例的难度
编写测试报告的质量,通常分为"优秀"，“良好”，“合格”，“差”几等
6 Bug数据
通常用发现Bug的(数量，有效和无效，发现/解决比率，运营/测试环境数据评比)
7 测试是否尊守流程
通常分为(优，良，合格，差)
8 团队贡献
通常这项做为激励大家，如XXX人兄给大家培训“httpwatch工具”，依据培训效果分为"优秀"，“良好”，“合格”，分别对应相应的分值。
如小马哥给部门建议XXX项目需求评审Checklist.doc，这些均可
以上仅仅是考核的几个大的方面，当然在实施具体考核过程中，还需结合公司具体的要求！
原文贴子：http://www.cnblogs.com/mayingbao/archive/2006/11/26/572954.html?updated=1
[ 本帖最后由 卖烧烤的鱼 于 2008-6-26 16:31 编辑 ]
