软件测试绩效考核

1.提交的问题单数量、测试执行用例数量，尚未发现的问题数；

2.对测试人员发现问题的价值进行评估；

3.对测试文档的质量进行评估；

4.测试人员的综合能力，如责任心，沟通能力等。

5.测试人员对系统的需求的熟悉程度！

我所在公司主要是从以下几个方面来衡量的：

1 产能，比如所以天key多少bug，一天写多少测试用例来衡量

2 出货成功与否，当然是否成功要看自己公司怎么制定的规则了

3 工作态度， 沟通能力， 自学、钻研能力， 团队协作能力等等方面

4 工作贡献度，主要是各部门和团队的知识的分享。

对测试人员的考核确实不太容易。我们公司做了6，7 年了，考核标准是年年一个样，呵呵，有点头痛。

建议从一下几个方面考核：

1. bug数量，等级；

2. 员工技能；

3. 外语水平（多数公司可以不用这条）；

4. 职务与工作量。

5. 工作态度；

6. 工作成绩；

每一个测试经理都面临这样的问题，如何对测试人员进行绩效考核。因为测试人员参与的工作不单一，需要的技能也各种各样，考核测试人员的绩效似乎不是很容易的事，除了一般需要考核的对工作的态度，工作的责任心，积极性这些方面以外，还有一些其它方面的内容。

要想对测试人员进行考核，就需要开始工作的时侯明确测试人员的职责，对测试人员的期望等，一个团队中不同的测试人员可能职责不同，比如测试负责人，测试设计人员，自动化测试人员，普通测试人员等，那么对这些人的期望也是不同的，进行绩效考核的时候需要根据对测试人员的期望进行考核，而这些职责和期望测试人员也是很明确的。

测试人员可能参与不同的软件开发过程，比如需要参与需求和设计的评审，那么也需要对这些工作进行考核，比如需求评审时可以从测试人员对需求的理解上，测试人员对需求提出的问题的质量上等作出评价。

如果需要测试人员准备测试文档，如测试用例等，那么可以通过评审测试文档来考核一个测试人员的能力。如评审测试用例的质量，对需求的覆盖程度，可理解和执行等方面来判段一个测试人员的能力。

对于执行测试的测试人员来说，可以从测试人员所发现的问题对测试人员进行评价。测试人员所发现的问题是复杂的还是简单的，是隐藏比较深的，还是一些表面的问题。还可以从问题的书写上进行评价，问题的书写是否详细清晰，开发人员可以再现，还是含糊其词，不明所以。或者测试人员书写的问题是否是自己的操作问题，一个问题是否写多遍等。

而对于已经发布的产品，也可以从用户反馈的问题来考核测试人员的绩效，

但是这个可能需要的时间比较长。

测试人员的沟通能力也是考核的一个方面，无论是书面的还是口头的，测试人员都应该有较好的沟通能力。

另外测试人员的接受指示，把握细节的能力也应该进行考核，测试经理希望把任务分配给可以按照指示完成的人来完成，如果测试人员自行其事，即使技术能力比较强也对工作无益。

当然我想不同的公司的绩效考核制度不同，不能一概而论，自己总结而已。

想想这个问题，测试人员的绩效考核，有几个公司做了？又有几个公司做好了？即使强制做了，下面的人员全部接受吗？

　　我也经历过做绩效考核的公司，基本存在以下弊端：

　　1、浮于形式型。

　　公司要求这么做，部门就这么做了。做了以后并不影响个人的利益。

　　2、经理一人独断型

　　无论有没有具体考核内容，但经理不理会这些，自己凭自己的主观最后打分。

　　3、不公平型

　　没有经过实践，就相当的觉得以数据说话最公平，于是就以执行用例数，发现缺陷数等为标准。我亲自经历过这样的事，自从

　　以发现缺陷数为重要考核标准后，大家都争着测文档，一个错别字提一个缺陷。。。。何必呢？

　　4、敢怒不敢言型

　　这种是与工资挂钩的，或者末尾淘汰。他们考核的无非也是从工作量，积极度和看得见的数据，

　　整不好，你在埋头苦干，却告诉你被淘汰了。怪谁呢，只怪你不会做面子工程。

　　绩效考核大家都理解，提高效率，提高质量，说白了就是节约成本。

　　我觉得绩效考核有几个工作外的东西必须考虑进去。

　　1、文化背景

　　一个国家的文化背景。在中国就不适合做互评的考核，让同事一起打分。就象让你指出别人的缺陷一样让人不知所措。

　　一个公司的文化背景。公司的文化氛围，团队氛围。

　　2、公司发展定位

　　人力资源管理上讲，一个处于迅速发展期的公司，不适合做严格的管理制度和考核办法，公司应该鼓励员工去积极的发挥个人能力，因为公司要靠这个迅速发展；而一个处于稳定期的公司，却要通过比较严格的制度来维持这种稳定；处于衰败期的公司，最需要制定严格的制度来控制成本。

　　3、公司测试制度的完善程度

　　一个测试团队如果连最基本的测试制度都没有（我指的是测试体系方面），比如你连鉴定缺陷等级的细则都没有，连有（无）效测试 用例的标准都没有，你凭什么来统计这些数据？

　　4、测试团队对考核制度的支持情况

　　如果被考核的人都觉得制度不公平，太片面的话，那最好别执行了，心理抵制比

言行抵制更可怕。

　　鉴于上述，我想公司给测试人员做绩效考核，要根据具体情况来实施。

　　下面我分析的要考核那几方面：

　　1、工作量：

　　这是无可厚非的，不干活的人是没有绩效的。

　　2、工作质量：

　　写出无效用例多，提交的缺陷开发看不懂等，负责测试的模块有

明显的重要缺陷却视而不见。（注意不能以偶尔现象为准则）

　　3、工作态度：

　　这点很容易理解，就是不好好干活，应付任务。

　　4、工作角色。

　　为什么说只凭工作量不公平呢，因为测试是分角色的，比如测试组长，他可能很多精力放在沟通和进度跟踪，缺陷跟踪

　　等其他方面，而执行的用例较少。所以不同角色不通对待。

　　5、贡献度。

　　在工作过程中，凭自己的特长，为公司测试过程改进，测试方法提高，测试团队建设做出突出贡献者。比如编写出测试工具，极大提高测试效率。

　　6、挽救风险。

　　比如测试已经结束，但他还是凭着怀疑精神坚持自主测试，在上线前测试出重大问题。

　　总之，测试部门考核的目的是为了提高测试水平，规范测试流程，约束自由懒散者，鼓励个人智慧的发挥等。所以，

　　我觉得范有违这个目的的考核，还是不做的好。

考核等级：

1、A级（优秀级）95—100分　工作成绩优异，有创新性成果。

2、B级（良好级）85—94分　 工作成果达到目标任务要求标准，且成绩突出。

3、C级（合格级）75—84分　 工作成果均达到目标任务要求标准。

4、D级（较差级）60—74分　 工作成果未完全达到目标任务要求标准，但经努力可以达到。

5、E级（极差级）64分以下　 工作成果均未达到目标任务要求标准，经督导而未改善的。

七、考核结果的应用（工资指基本工资）

1、月业绩考核成绩将作为员工年终评比以及职务和工资升降与奖金的重要依据。各分公司经理不再有直接给下属销售人员定奖金的权力，当本公司编制内各级岗位遇有空缺或公司扩编增加员工额时，凡考核成绩优异人员将予先递补。

2、月业绩考核成绩为A级者，当月工资额多发原有工资的5%。

3、月业绩考核成绩为B级者，当月工资额多发原有工资的2%。

4、月业绩考核成绩为C级者，享受全额工资。

5、月业绩考核成绩为D级者，当月扣除工资额的50%，并给予留用一个月处理。如下月考核不合格，给予辞退处理。

6、月考核成绩为E级者，当月奖金全部扣除，并给予留用一个月处理。如下月考核仍不合格，给予辞

退处理。

7、连续5个月业绩考核成绩为A，或全年累计8个A者，下年工资额增加5%。

8、全年业绩考核成绩达到10个A者，下年度工资额增加10%。

测试部门绩效考评标准

作者：网络转载 发表于：[ 2011-2-28 15:47:22 ]

一、 专业素质得分：绩效 60% MAX分值 100

1、用例进度（15分）：

A、要求：制定checklist，包括3个时间点（第一次发送用例、邮件评审后第二次发送用例、组内评审后第三次发送最终用例）。checklist和3次的输出一起发送，例如邮件内容为checklist时间点，附件为用例或会议记录。如有临时紧急工作穿插，checklist及时修订发送。（以月度版本为单位）

B、评分标准：

（1）每个时间点按照checklist提前完成，+5。

（2）终稿时间按照checklist提前完成，+3。

（3）按checklist终稿时间按时完成，为基础分10分。

（4）如果终稿时间有所delay，扣除2分。

2、用例质量（25分）：

A、要求：主要按照测试用例的遗漏点进行扣分制算法。整体分包括了策划功能面用例设计、技术实现面用例设计、格式细节面用例设计和系统漏洞面发现及游戏性考虑设计。以上评审内容包括邮件评审和会议评审，重复的补充点不重复扣除分数。

B、评分标准：

（1）在评审中，功能点（包括策划和程序面）用例设计缺失，一点扣除2分。

（2）在评审中，重点漏洞的测试点考虑缺失，一点扣除1分。

（3）在评审中，细节考虑缺失，一点扣除0.2分。

3、测试流程（15分）：

A、要求：根据版本计划安排制定测试计划checklist（第一轮测试完成时间、bug回归完成时间、第二轮测试完成时间）。根据每日日报的时间点来进行check，是否有delay的问题存在。

B、评分标准：

（1）每个时间点按照checklist提前完成，+5。

（2）最后一个时间点按照checklist提前完成，+3。

（3）最后完成时间点按照checklist按时完成，为10分。

（4）最后完成时间点delay，为8分。

4、测试质量（25分）：

A、要求：根据测试用例和在测试中考虑的异常测试点的遗漏，以满分制按照遗漏bug等级进行扣分，遗漏bug包括第二轮测试中发现的bug和外网玩家提交的bug。如果在第二轮测试中按照发现的新增bug根据bug的等级进行加分。Bug扣除分数按照bugtrace的提交等级划分按照测试组定义的bug分类等级划分。进入计算的bug属于大家公投可重现的bug，无法重现或难于重现的bug不计入bug扣分记录。

B、评分标准：

（1）遗漏致命bug，一个扣除2分。

（2）遗漏严重bug，一个扣除1分。

（3）遗漏一般bug，一个扣

除0.2。

（4）在运营期项目均采取此项分数，对于非运营期项目，主要为发现bug加分机制，加分分数为基础分22分+以上对应等级分数的一半。

（5）第二轮测试发现以上等级bug同等加分，无上限分值限制。

5、测试接口人（7分）：

A、要求：按照版本的工作内容，进行工作日报和出档邮件的输出以及测试进度的跟进。以上责任为项目测试接口人，但是具体执行为轮流得版本当前负责人。

B、评分标准：

（1）完成每日测试日报，内容包括测试进度和计划以及版本情况和bug情况反馈等，1分。

（2）出档邮件发送和出档情况跟进督促，1分。

（3）加壳情况和预更新配置情况跟进督促，1分。

（4）对于版本测试用例完成后的GM指令需求和工具需求的一个收集整理和输出，以及对提交bug的规范检查和跟进指导，2分；

（5）对于版本结束后放到外网体验一周后的运营质量的总结和问题的总结，以及后继解决方案的输出，2分；

（6）以上各项如有疏漏和时间的delay不得分。

6、用例补充加分（10分）：

A、要求：根据现有的用例补充，包括邮件补充和用例评审会议补充，进行加分的一项分数。用例补充，包括评审会上的提出点均作为加分项目进行鼓励，包括提出问题，如果有助于理解实现上的问题也作为补充项目。

B、评分标准：

（1）补充用例的点是构成用例编写人扣分的点的，给与扣除分数同等加分，即对方扣除1分，则第一个补充的人+1分，这也是鼓励大家尽快回复的一项，先补充的先得分，调动积极性。

（2）在用例邮件回复和评审会中提出关键性问题的，给与对应严重程度的加分。

（3）本项得分累计加分不超过10分。

（4）第一个后重复补充的不算分，机会给跑在最前面的人。

7、工具需求和整理使用加分（3分）：

A、要求：根据现有测试中发现的问题，或者是新增系统中的提高质量和效率的，或者是对原有系统常重复使用的功能的测试，能从方法上提出工具的实际需求，并且能给对应测试开发人员提出具体的实现的一个想法和方案，共同完成工具或者流程建设上的方法。

B、评分标准：

（1）切实利用率和开发时间性价比较高，或者能总结现有工具给出新的优化方案，切实优化后大家好评一致，将直接给分。

（2）此项加分由项目接口人提出，统计大家意见后，直接加3分。

二、专业得分：绩效 60% MAX分值 100

1、考勤得分：考勤 15% MAX分值 100

2、 执行得分：执行能力 15% MAX分值 100

考核内容【补充】：

1） 个人制定根据组内计划制定合理的个

人计划，积极主动的执行各类需求，根据优先级合理安排工作内容，按照计划按时完成既定目标。

2） 很好的把握工作进度和推动影响自己进度的相关步骤的前进，以期能够很好的达到自己的既定目标。

3） 发现问题能及时调整偏差。根据变动能迅速调整目标，很好的关注问题的重点和细节的改进。

4） 能够推动某一类规范/流程的执行。

3、沟通得分：沟通能力 10% MAX分值 100

考核内容【补充】：

1）工作中同组的工作沟通和流程沟通以及经验分享。

2）能很好的组内沟通很好的促进需求的理解和任务的执行。

3）能协助组内新员工或者其他员工在某一个方面的工作和学习。

4）跨组的沟通能比较好的提出解决方案并且反馈问题。

5）跨组沟通中达到双方可接受的方案并记录在案，并以解决问题的心态去面对出现的问题。