随着企业对软件测试的不断重视，测试团队的规模也越来越大，测试相关的岗位也在逐渐增多，测试工程师、测试leader、高级性能测试工程师等等。如何对不同岗位的测试人员实施科学、合理、公正的考核，已成为测试管理工作的一个重点和难点。如果你是测试经理，你是如何对你的团队进行业绩考核的？如果你是测试工程师，你现在被考核的标准是什么？而你期望的标准又是什么？欢迎大家讨论交流。


感谢会员huior 提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！



非常感谢各位会员积极参与，截止至4月18日17：30分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在下周内送出。

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	godn_1981	当当购物卡50元	14#
二等奖	忘记了	300论坛积分	6#
	duola1119		18#
三等奖	yolander	100论坛积分	10#
	anhuibing		11#
	stillying		17#

在传统的IPD-CMM流程中，定了几个指标：比如，测试用例的设计效率，测试用例的执行效率，每一轮测试发现的问题数，问题级别数等；但是越来越多的项目表明，传统的CMM项目一旦转测试后，测试的轮次就变的不可控了，前期不断积累的质量问题会随着测试人员对所测试特性了解的深入而逐渐表现出来，很多情况下会表现为：第一轮测试时问题单很少，而到了第二轮以后，问题单就会出现“井喷”现象

这导致了软件的发布周期被延长了，但是达不到质量目标又无法发布，于是，测试人员需要提前介入，参与系统规格以及方案设计的评审、E2E测试用例的输出、ST以及SDV用例的输出以及执行；相应的，对测试人员的考评指标也有了变化，测试人员负责某特性的最终交付，转回归测试的轮次数等（越少越好）

仅仅通过数据统计来进行绩效考核纯属恶搞
当然数据确实可以起到一些参考作用
但是人和机器是有区别的
考60分的人和考59分的人在绩效上一定是有什么本质区别么？

有资格评定具体测试人员的应该是leader或者主管
只有他们才最了解自己手下测试工程师的工作情况
外部应该是对整个项目团队或者测试团队进行考核

至于具体的考核评定方式
小企业可以采取在一定基础上的相对评定
大企业的话可以有一个基本的定性考核
然后由各个级别的主管分别进行比较细致的定性评定
标准要根据实际情况来制订
总之一大堆数字是不可取的
别的不说
这种统计出来的数字可信度就很成问题


补充说明：
我还记得上次说过管理者要做的四件事情：
1 雇佣正确的人
2 分配合适的事情给他们做
3 保持他们的积极性
4 使你的团队拥有足够的凝聚力

在制定绩效考核规则时一定要记得这是为这四点服务的
（唔。。主要是3 保持他们的积极性。 另外，可能会对4有一定影响……）

[ 本帖最后由 puchonghui 于 2008-4-11 21:28 编辑 ]

绩效当然是有一些量化指标的，因为项目本身就应该是可度量的
主观的考评以及周边同事的评价个人认为只能够作为评测的一个维度，而不是全部

提交缺陷总数
提交非缺陷数量
提交有效缺陷数
提交缺陷分类数
回归缺陷数
争议缺陷数
非独立测试发现的缺陷占比
严重缺陷所占比例
设计执行用例数（日平均值）
用例有效性
工具掌握能力
缺陷描述
工作态度
沟通能力
学习能力
团队精神
业务知识
问题解决
执行力
沟通能力
工作热情
责任心
顾客意识
合作
品质

提交缺陷总数
提交非缺陷数量
提交有效缺陷数
提交缺陷分类数
回归缺陷数
争议缺陷数
非独立测试发现的缺陷占比
严重缺陷所占比例
设计执行用例数（日平均值）
用例有效性
---------------------------------
不赞同以Bug数量或执行case量作为考核标准。要不然测试就变以味。纯粹为了bug量也提交bug,为执行量而执行case。测试本身最主要的不是为了测试而测试，而是为了提高产品质量，保证软件开发周期的整个过程。
就算每天你提交了100个bug,那又有什么意义？这只能说明Dev的水平急需提高。一个好的测试人员是应该把问题发现在开发前期，尽可能的减少不必要的bug.预防重于事后的发现和修补。要不然测试人员永远无法从高bug量和高regression test的泥潭中解脱出来。特别是对于一些快速开发的项目。

以上是我本人的一些想法，就事论事而以。并没想要针对谁。如有说错的地方，还请iori见谅。

这也是我目前面临的问题，公司应该怎么样合理，科学考核测试人员的工作？测试人员被考核的标准是什么？比较难界定，看看大家有什么好办法

发现1个系统架构设计方面存在的缺陷和隐患，远比发现几个普通界面的显示问题要有价值的多。因此，在对测试人员进行评价时，必须区分不同问题的重要性和价值。

1、首先，是考核的环境是否适合，如果公司仍然存在一个动荡的环境，人员流失率很高的情况下，是不适合的。
2、如果外部环境具备，那么要分清考核的目标是什么？测试的效率？测试人员的自觉性？
3、不同的公司文化采取不同的考核方法是最好的。建议是将关键事件做为考核指标，其它的数据考核起来非常的麻烦，而且让
所有的人员对数字非常的厌恶。

我觉得五楼的同行列出的统计项中，对测试执行的工作已经涵盖的比较全面了，但是缺少对测试设计这块工作的关注，事实上，我认为测试人员的优劣，或者是否有发展和提升的空间，很大程度上也取决于他的测试设计能力
如：
评审testcase是否覆盖了系统需求中的全部功能；
评审testscenario是否覆盖了用户需求的全部业务流程；
测试设计是否有效规避了大多数的风险（除部分无法用测试这种手段进行风险控制的）；
此外，对测试缺陷提交数进行考核时，要结合问题的等级、再现频率、状态等予以计分，不能仅仅核计问题的数量，当测试人员提交的问题质量较高时，相应的分数也应该有所体现，对测试错误，提交无效问题等，需要考虑增加负分，提高测试人员提交问题的谨慎率。
对测试漏出率也应有所统计，也就是说当系统测试结束后，提交外部测试，或者用户验收测试时，统计返回问题，分析这些问题被测试人员遗漏的原因，同时也需考虑增加或更新测试设计，以覆盖这部分内容，这样做不仅仅是为了对测试人员有所评价，更主要的是可以借此提高测试能力，减少测试盲点，为下一步的工作做好准备。
最后，还需要考察测试人员的工作责任心，积极性，以及学习能力，好的测试人员要耐得住寂寞，细心，并有精益求精和较真的精神，还要有原则，能够坚持自我，在循环往复的工作中，仍能精神抖擞，不会对错误视若不见，学习能力强，因为好的测试人员要比开发人员更了解整个系统，对业务知识的掌握要比开发人员更丰富，这样，你才能以一个权威的面貌去面对开发人员，这时你提出的问题，开发人员也才更容易接受
以上是针对项目中测试人员的表现予以评价的几个观察点，如果是对测试人员的职级胜任能力进行评价，可能还要考虑的更多

[ 本帖最后由 yolander 于 2008-4-14 16:19 编辑 ]

对团队的考核，主要是这几个方面：第一、项目上线后客户的反应情况，这直接关系到领导对你所在团队的打分；第二、项目结项以后项目经理对测试团队的评价；第三、在测试过程中，我们会对测试团队的文档进行评审，这包括测试计划、测试方案以及是否在一些关键时间点提交了测试报告，还有就是在项目开始测试前，需要测试团队进行对所做项目的相关功能模块进行业务演讲，领导需要了解测试团队是否已经完全理解了需求和业务；第四、对测试团队人员提交的周报，主管需要对其进行跟踪并打分；第五、测试主管以及经理会对你在测试过程中的积极性以及和开发人员的交流情况、以及是否及时反应一些关键问题对你所做团队进行“工作态度”打分。现在我所在的公司基本上是按照这些对一个具体的项目进行打分的，另外在年终的时候基本上就是项目+项目的总分了，呵呵，当然还有公司规定的一些别的方面。

个人认为这个还得取决于公司简历比较健全的考核机制
如设立：测试人员需要每天提交测试日报，测试记录，缺陷个数。通过对这些数据的考核，加上组员和leader的综合打分进行业绩考核~~

不同项目负责不同的测试模块存在或发现的bug数目也是不同的
有些测试更需要技术，有些可能参考需求文档就能测
而把测试用例等文档也拿来考核更是不合理的

应该由测试组长和测试经理 有工作态度和工作努力情况等来考核
新手很努力但发现问题少，老手很了解业务，技术又高发现的自然多
就不能定结论说新手业绩差

态度
上进心
责任心
团队合作心
学习能力
这些才更重要

鄙人从事软件测试好几年了，也一直为该问题困扰，每次项目作完了，感觉大家都表现还马马虎虎。但是项目却感觉总不是那么完美，既然存在问题，说明测试人员的考核做的不到位，所以最近痛定思痛，也咨询了一些在微软和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从解决到关闭的平均需要时间

目前我们公司的考核指标：
1、技术
2、工作能力
3、工作态度
4、合作能力
5、上级的评价


[ 本帖最后由 lucky_snow 于 2008-4-15 17:44 编辑 ]

作为测试工程师 可以有：
测试设计能力，测试脚本编写能力，沟通能力；
具体比如，发现BUG能力(数量，质量）、漏测问题（数量，严重程度），对团队的技术贡献等等。

严重反对目前的以工作时间来度量

上述的所有项我们的绩效考核表里都包括,呵呵,但主要以BUG总数,有效BUG数,无效BUG数,BUG的级别高低,以及漏测率,执行用例效率,工作时长,编写用例的发现BUG数为主.
个人认为存在以下蔽端:
1.测试工程师为了提BUG而提BUG,有些开发已在下个版本改过了,再提上来,只是浪费大家的时间
2.BUG级别越高对测试的考核越有利,虽然有BUG级别定义,但仍存在提高级别,造成不公平因素.
3.由于项目不同,BUG数量肯定也不同.
4.开发和测试的绩效考核是对立的,造成一定程度的不和.
5.工作时长只能助长加班,但不一定有效率.
6.有时为了跟踪一个BUG浪费好长时间,是不是就放弃,找些容易的BUG提.

解决方案暂未想到~~~~苦恼中~~~

这个问题不好回答，但是看了14楼给予的答复，非常的佩服
  14楼的兄弟所回答的应该都已经包括了，如果在重述就没有意义了，在此我想补充几点。
LZ的问题中提到“业绩”这个词，没有创造出价值的人不会有业绩，通俗的讲没有给老板挣钱的人你就没有业绩，我要说的就是：得到公司高管的认可或得到过嘉奖应该是一个重要的指标
   看到大家似乎都将测试人员定位在测试执行人的角色，但却都忽略了测试经理这个角色，那么换个角度，测试经理在高管的眼中也应该算是一个测试人员，或者测试经理本人应该对自己也应该有一个特殊的业绩考核标准。
    1。工作计划制定的是否到位，是否分配到每个人、每天、每时。
    2。工作计划的可执行程度
    3。项目估计总BUG数
    4。项目实际总BUG数
    5。估计误差（实际总BUG数/估计总BUG数×100%）
    6。领导能力和服从领导的态度
    7。领悟能力
    8。计划能力
    9。指挥能力
    10。控制能力
    11。协调能力
    12。授权能力
    13。判断能力
    14。创新能力

刚刚做完软件测试人员的考核。如果这个贴能早点出就好了。
对测试人员的考核，我个人觉得主要从以下几方面考虑：
1、测试的质量
2、测试的效率
3、测试的进度偏差
4、测试流程执行情况

我们现在暂时的考核指标有以下几个：
1、上线后系统的故障时间
2、测试项目的验收通过率
3、软件缺陷的发现率
4、软件流程的执行
除了这几个测试指标外，还有一些如工作态度、学习能力、主动性等方面的考核
请大家指正。谢谢！

仅从提交的bug单数量、执行测试用例数量来判断这种做法显然缺乏全面性，bug单的数量只是评估测试质量的一个方面，我们更需要看总实际的测试质量，所以考核测试人员工作绩效应该考察：
1、bug单的质量
2、测试的难度
3、bug单的级别
4、测试文档的质量
5、测试人员的综合素质