我觉得不要这么复杂吧
测试人员的考核是很多方面的。。经常有不公平的情况存在。而且，最重要的，我觉得要让测试人员知道考核结果啊。
我们公司很怪，考核完了，什么也不说，也不通知 。你到年底也不知道公司考核的到底是个什么标准，什么结果。。 项目组自评表
评价指标
典型行为或事件举例（参照标准）
自评得分
自评说明
上级评分
上级说明
最终得分
严格认真
（1分）由于不严格不认真，导致工作出现了疏漏，且没有及时补救；
（2分）工作出现了问题，但能够积极补救，不推卸责任；
（3分）按本岗位工作要求做，没有出现工作疏漏；
（4分）发现他人的工作疏漏，告知对方，并协助其补救；
（5分）严格认真地履行岗位职责，发现隐患，并预先采取措施，避免问题的发生。
主动高效
（1分）被动执行上级安排的工作，遇到困难被动等待，对工作中的问题视而不见；
（2分）反应工作中的困难和问题，但没有改进建议；——至少没有主动去思考问题，
（3分）主动调动各方面资源，以达成目标；
（4分）工作中主动发现问题，提出有价值的改进建议；
（5分）独立提出确实可行的解决方案，并推进实施，并取得良好的成效。
服务意识
（1分）不关心客户的需求和感受，对客户提出的需求没有响应。
（2分）在上级要求和客户投诉的压力下，为客户解决问题；
（3分）积极响应客户意见投诉，及时满足客户的需求；
（4分）主动征询客户的意见与感受，并以友善愉悦的态度提供服务；
（5分）提供的服务，超乎客户期望的满意度。
团队协作
（1分）不与团队成员沟通，完全按照个人设想来工作；
（2分）告知团队成员自己的设想，但不响应团队成员提出的建议和要求，固执己见；
（3分）能够认真听取团队成员的意见，修正个人的工作设想；
（4分）当他与团队成员意见发生分歧的时候，不仅能够听取对方的意见，而且能够提出有价值的建议；
（5分）在协助对方获得成功，并达成团队整体目标的同时，实现个人目标；
纪律意识
上班时间是否经常打私人电话或发送短信（经常的定义为：考核周期内5分钟以上的打私人电话或发短信达9次或以上）；
是否经常迟到、早退（经常的定义为：考核周期内10分钟以上的迟到和早退达9次或以上）；
上班时间是否浏览与工作无关的网站；
上班时间是否看报纸、杂志和与工作无关的书籍；
上班时间是否大声喧哗或吵闹；
（以上每一项行为，否为1分，是为0分）
学习总结
（1分）多次出现相同的失误；
（2分）能够不出现相同的失误，但不能防范于未燃；
（3分）在工作中学习，能够从失误中吸取教训，举一反三；
（4分）有意识地学习岗位要求的知识、技能，和业界先进的经验，并在工作中加以实践；
（5分）在岗位要求的知识技能以外，还主动学习与他相关的知识技能，工作能力明显提高；
合计
项目组内部互评表——测试方面一、
完成工作量情况
A、
季度内在整个测试组中完成的工作量最高；
B、
季度内在整个测试组中完成的工作量较高（处于中间水平之上）；
C、
季度内在整个测试组中完成的工作量一般（处于中间水平）；
D、
季度内在整个测试组中完成工作量较低（处于中间水平之下）；
E、
季度内在整个测试组中完成工作量最低。
二、
测试过程质量
A、
测试过程质量令人放心, 基本能全部测出一般情况下的Bug外，还能测出隐藏很深的Bug，项目交给他进行测试把关很放心，在整个测试组来说，相对是最好的；
B、
测试过程质量较好, 基本能全部测出一般情况下的Bug，隐藏很深的Bug偶尔能测出，在整个测试组内来说，处于中间水平之上；
C、
测试过程质量一般，能测出大部分一般情况下的Bug，但总觉得欠火候，在整个测试组内来说，处于中间水平；
D、
测试过程质量较差,有些一般情况下的Bug都不能够测出来，或者总是那下某个功能点，在整个测试组内说，处于中间水平之下；
E、
测试过程质量极差, 有些明显的Bug都不能够测试出来，在整个测试组内来说，相对是最差的。
说明：
指提交功能测试开始到项目最终发布的测试过程质量。有些人测试过程质量很好，总体上能够把基本问题全部揪出来，而且还能够揪出一些隐藏很深的问题（当然，我们不能指望揪出所有的问题）。而且还有很重要的一点，这些人能够很早的把问题发现，而不是等到快最后来发现（不是说快最后的时候发现问题不提）。其实，作为一个开发人员，还是很欢迎测试揪出问题来的，但缺很厌烦快到最后了，才把它揪出来，心里总会想，为什么不早发现呢。而有些人测试过程质量就很差，很多很基本的Bug都测不出来，而且还丢三落四的。搞得最后都提心吊胆的发布系统。
其实，测试过程质量，虽然表现在整个开始测试到最终发布的过程，但实际上与前期准备工作还是很有关系的，就像系统实现过程质量与需求和分析设计的质量很有关系一样。测试准备工作做得好，测试用例想的很周到，编写得很全面，而且能够按照测试用例认真逐个执行，再加上实际测试过程的一些功底，测试过程质量就会明显的好。
三、
测试用例编写质量
A、
测试用例编写质量很好，编写的内容除少量细节外，一般一次可通过，在整个测试组来说，相对是最好的；
B、
测试用例编写质量较好，编写的内容虽然有些时候通不过，但明显看出，是经过认真思考了的，在整个测试组内来说，处于中间水平之上；
C、
测试用例编写质量一般，虽然由于能力有限，存在比较多的问题，但文档需要描述的各个方面都已经想到了，在整个项目组内来说，处于中间水平；
D、
测试用例编写质量较差，其内问题较多，且需要描述的好多方面，都没有提及。不过经过讨论后，修改的质量很好，在整个项目组内来说，处于中间水平之下；
E、
测试用例编写质量很差，文档只是涉及到了梗概，很多细节都没描述到，讨论后修改的结果也不理想，要修改多次，或者因为别的原因，没有达到要求还是放过去。在整个测试组内来说，是相对最差的。
说明：
指测试用例提交评审的质量。有些人写文档前想的很周全，文档也写得很仔细，提交出来的文档基本上一遍就可以通过。而有些人写的文档，提交出来讨论，一遍未通过，讨论完了改，改了再讨论，而且很多细节也没有写出来，搞得负责审核的人，最后没办法，就直接改。因为叫当事人改，还不如审核人自己改来得省心。当然，测试用例的编写质量，在测试过程中会反映出来。
[ 本帖最后由 阿七 于 2009-3-6 11:24 编辑 ] 一个季度考核一次 1.bug数量、严重重度、优先级等比例
2.有效bug与总bug数的比例
3.根据实际情况（如：阶段性测试），对bug把握程度是否恰当，下阶段的bug点数
4.无效bug数的比例
5.跟踪bug情况
6.所提bug的深度、广度
7.遇到有歧义bug是否有强的说服力
回复 23# 的帖子
阿七的答案比较实用点。之前曾给测试部门做过一个绩效模型，改天发上来。 懂得软件工程的人都明白数据积累的意义，其中很重要的一条就是便于对个人能力和特质进行衡量。没有经过长期的数据积累是不可能进行有效的绩效考核的。 所谓的绩效考核纯粹都是一些欺上瞒下的形式主义。
23#的表格就是个典型例子。 整个表格都充满了含糊不清的界定，比如第一项：
由于不严格不认真，导致工作出现了疏漏，且没有及时补救；
工作出现了问题，但能够积极补救，不推卸责任；
1 如果我尝试去补救了，怎么才算及时？怎么样又算不及时？
2 事实上碰到问题只要不先想着推责任，首先去积极补救就行。 如果确实是别人的责任，当然应该别人为后果负责。
还有什么迟到早退，只有分不清人跟机器的区别的人才会拿这种弱智标准去衡量技术人员。 至于规定迟到10分钟更是拍脑袋的扯谈，难道这和迟到9分59秒有什么本质区别么？ 只要我该做的事情做好了，你管我什么时候来什么时候走。
不想多说了，忠告喜爱类似考核的人： 如果没有一定量的数据积累，不要去试图做什么个人的绩效考核（上级有要求的话自己想办法应付），把实际精力致力于有效的团队建设才是正道。 我们这里是多个人员共同打分。 对于测试人员的绩效考核确实是一个很头疼的问题。我觉得应该是主客观相结合，个人发展和项目/部门利益相结合来考量。
主观的评定主要是根据部门主管，项目主管，项目测试组内部，项目其他组的综合评定来定性\定量评定。评定的依据应该包括工作态度，主观的工作能力，学习能力，管理和领导能力，沟通能力等等。为了在主观评定中尽量减少由于个人喜好导致的评定不合理，可以由HR或公司层面制定一个评定指导，根据每一项来打分。
客观的评定则主要是根据统计数据来进行评定。包括工作量（用例编写数量，自动化测试用例数量，执行用例数量，发现缺陷数量等等），工作质量（缺陷遗漏率等）的评定。客观评定可以最大程度的减少人为因素在评定中的影响，但是随着软件行业的发展，软件复杂度的提升，个人英雄主义已经逐渐被团队精神所取代，所以客观评定还是应该和主观评定相结合。
我想说的很重要的一点是个人发展和项目/部门利益相结合的考量。
对于软件行业来讲，人毫无疑问是决定性的因素。我们在整个管理过程中，对人的尊重也是越来越重要的一个方面。当然在绩效考核中我们不仅要考虑项目/部门利益，也需要考虑到员工个人的意愿。这就需要在制定考核目标和进行考核的过程中充分听取被考核者的意见。在项目\部门利益保证的前提下，我们应该尽量满足个人发展的要求，为个人发展提供有利的环境和条件，把考核转变成为帮助员工实现个人发展的一个催化剂，只有这样，才能使公司和部门获得最大的人力资源效益。 原帖由 puchonghui 于 2009-3-6 23:23 发表 http://bbs.51testing.com/images/common/back.gif
懂得软件工程的人都明白数据积累的意义，其中很重要的一条就是便于对个人能力和特质进行衡量。
没有经过长期的数据积累是不可能进行有效的绩效考核的。 所谓的绩效考核纯粹都是一些欺上瞒下的形式主义。
23#的表格就是个典型例子。 整个表格都充满了含糊不清的界定，比如第一项：
由于不严格不认真，导致工作出现了疏漏，且没有及时补救；
工作出现了问题，但能够积极补救，不推卸责任；
1 如果我尝试去补救了，怎么才算及时？怎么样又算不及时？
2 事实上碰到问题只要不先想着推责任，首先去积极补救就行。 如果确实是别人的责任，当然应该别人为后果负责。
还有什么迟到早退，只有分不清人跟机器的区别的人才会拿这种弱智标准去衡量技术人员。 至于规定迟到10分钟更是拍脑袋的扯谈，难道这和迟到9分59秒有什么本质区别么？ 只要我该做的事情做好了，你管我什么时候来什么时候走。
不想多说了，忠告喜爱类似考核的人： 如果没有一定量的数据积累，不要去试图做什么个人的绩效考核（上级有要求的话自己想办法应付），把实际精力致力于有效的团队建设才是正道。
１ 及时... 比如你在ｔｅｓｔ一直没测试出来，等模拟部署的时候，才测试出来．导致程序又要修改，重新ｔｅｓｔ到模拟到真实部署
而不及时 就是你在真实部署完了 ，好久都没测试出来，导致客户使用出了问题
２ 至于迟到问题， 我们公司是用ＯＡ系统考勤，不是用打卡机，所以定义了１０分钟为迟到时间，比如你迟到了９分针５９秒．ＯＫ 我不算你迟到．但是要扣考勤分．而且类似这样３次，就直接扣钱，但是迟到１０分钟１秒．ｓｏｒｒｙ了 你迟到了，直接扣钱了.
３ 我不知道你为什么这样愤世嫉俗，也不知道你高人说的"把实际精力致力于有效的团队建设"是如何做到的，我只知道公司必须要有刚性的制度和人性化的管理才能使团队有序．
４ 另外想说的是，越是害怕考核的人，越是无能的人．生怕别人发现自己的缺点．
完了... 看样子你会跟帖ｊｊｗｗ的．．． 好贴，谢谢！ 说白了，就是要看考核的最终目的！
大家都知道，考核的最终结果难免会在工资上提现！
一个没有人情味的公司是不太可能的，一个没有人情味的主管也是不太可能的，考核带有片面和主观性，导致结果也不是很让人满意或者不公平！
考核的形式是以奖励形式还是淘汰制度只能根据公司实际情况出发
我觉得大家讨论来讨论区的实际意义并不是很大，从根本上来说，大部分人只关注一个地方：工资！
从根本上来说，如果你的工资比别人高不少，那你去搞末尾淘汰制度吧，如果你的工资跟别人差不多，还是不要去搞这个末尾淘汰的，免得人员都走光了，不是我偏激，这是事实，不管怎么考核，都有不公平的，比如说用发现BUG的数量来考核，又不是所有测试人员测试同一个模块来发现BUG率的比较，而且不同人测试不同模块甚至系统，而BUG多少主要是靠程序员的程序把握，虽然测试人员很重要，但是程序员如果控制得很好，BUG可能就会很少了，甚至很那发现。 才看到
学习一下吧 作为一个测试人员，受教了。 学习中！ 初来咋到，还 希望 多多指教 啊 ！
页:
1
[2]
