项目部人员考核标准
一、工作态度
二、工作能力
如有侵权请联系告知删除，感谢你们的配合！
测试部门KPI考核指标(绩效考核)
测试部门 KPI 考核指标（绩效考核） 评分标准说明MAX 权重SCORE 工作内容和 0.3 质量（ 60%） 9-10分：需求理解无 误，并能提出需求疑完整理解需求，出 点 。现疑问能及时与 需求熟7-8 分：完整理解需 产品经理确认， 完 求 。成测试时不能出10 10% 1 悉程 度 4-6 分：理解需求，现对主要功能点 上线后无重大 BUG。的需求存在误差 0-3 ：上线后有重大 问的问题。 题 9-10分：平均覆盖率 达到 95% 测试 用 7-8 分：平均覆盖率 达到 90% 例覆 盖10 30% 3 4-6 分：平均覆盖率 度 达到 80% 0-3 ：平均覆盖率未 达 到 80% 9-10分：测试用例设 计优化，结构清晰，可执行性高，描述简 测试用洁明了 可测试性7-8 分：测试用例完 例完 成完整性10 10% 1 整，可执行性一般 质量描述简洁明了 4-6 分：测试用例基 本完整 0-3 ：测试用例不完 善，可执行性 差 10 分：提交 BUG 都为 需要修改的 BUG。 7-8 分：有1-2 个无确实为系统BUG。
有效 效 BUG 至于是否已修 改、 10 20% 2 BUG 率 4-6 分：有 3-5 个无 延后修改、 不处理 效 BUG 皆不考虑。 0-3 ：有 5 个以上 无效 BUG
9-10 分： BUG 描述 规 范清晰，简洁明了， 能有效按步骤重现 7-8 分： BUG 描述一 BUG 描 般，能有效按步骤重 现 10 5% 0.5 述质量 4-6 分：BUG 描述与实 际有出入，通过沟通 能重现 0-3 ：BUG 描述混 乱， 不能理解 9-10 分：测试报告 清 晰明确并能及时发 出，重点问题能在报 测试报 告中体现。 7-8 分：测试报告及 10 10% 1 告质量 时发出，包含基本内 容。 4-6 分：有测试报告 0-3 ：无测试报告 10 分： 0 个产品未 按 时完成 按时完 7-8 分：1 个产品未 按 成工单 时完成 非测试个人原因 10% 1 的测试 4-6 10 分：2-4 个产品未 导致测试延后的 工作 按时完成 0-3 ：5 个以上产品 未 按时完成 9-10 分：及时关注 产 品研发进度及 BUG 状 态，有问题时能及时 反映，推动测试进行 7-8 分：经提醒后， 进度更 能更新产品进度及 产品进度跟踪， 产 新，BUGBUG 状态 品状态维护， 产品 10 5% 0.5 跟踪 4-分：产品进度没 BUG 状态更新等
测试人员绩效考核详细
绩效考核 1.测试团队绩效考核 绩效评估的的客体：是个体成员还是整个团队。 ?Pascerellayer认为，团队绩效评价应以成员个人完成工作的状况为基本依据，理由是激励只能作用于个人而不是群体；技能的提高和行为的改进最终必须落实到个人。若仅考核团队绩效，个体的努力得不到充分的肯定，就容易 造成社会懒散现象，即个体由于参加团队工作，其工作效率比自己单独工作时的效率反而大大降低。此现象一旦在 组织中蔓延开来，不仅会影响组织绩效，还会毒害组织文化。同时，由于绩效考核与薪酬及个人价值的实现相联系，因此，在团队中，能力高的成员倾向于对个人绩效的考核，从而得到更高的认可和报酬。 ?Zingheim和Schuster则认为对个人的考评应考虑团队的整体绩效，因为团队的成功很大程度上依赖于团队成员间的团结合作，理解支持，若评估集中于个体层面，会导致个人主义盛行，忽视团队的协作精神，阻碍信息、技能的 共享和绩效的提高，降低团队工作的优势。 ?因此在实际操作中，企业往往采取一种折中的方法，即按一定比例兼顾团队和个人两个层面的绩效考核。从目前的研究来看，还没有一种很好的办法可以科学地确定这个比例。但是，如果从团队性质的差异、团队所处的阶段等方 面来考虑，那么至少可以确定考核的天平是更向个体的一极偏还是更向团体的一极偏。 绩效考核的内容：结果、行为还是能力。对于绩效内涵存在着三种不同的观点，即“绩效是结果”、“绩效是行为”和“绩效是能力”。Bernardin将绩效定义为“在特定的时间内，由特定的工作职能活动产生的产出记录，工作绩效的总和相当于关键和必要工作职能中等绩效的总和（或平均值）”，这是“绩效是结果”的典型观点。 Murphy等人将绩效定义为“一套与组织或个体所工作的组织单位的目标相关的行为”。近年来，以能力作为绩效的观点得到了广泛的使用，这是以评估个体所拥有的完成某项工作所具备的知识和能力的方式。伴随着这三种观点的诞生和发展，绩效考核大致经历了基于结果、基于行为以及基于能力的三个考核发展过程。虽然这三种观点相互区别，且都是在否定前者的基础之上产生的，但是，如果不带入特定的环境，特定的组织，及组织发展的特定时期，那么三者之间并不存在绝对的优劣。如果组织下达的目标非常清晰，基于结果的绩效考核是最容易实施，也最有效；相反，如果目标模糊，无法准确衡量其结果，这种考核方式就会失效。基于能力的考核方式理论上是从战略管理的角度出发，最具有激励效果和长期效应，最有利于组织不断发展，但在实际操作中却很难达到效果。因为能力是无形的，它依附于个体，既受主观因素的控制，也受各方面客观因素的影响，很难用标准化的方法衡量个体的能力，即使是方法对组织期望成员所具有的能力和特质作出了解释，但这些解释仍是描述性模糊语言，在实际操作中仍然难以做到真正的科学公正。基于行为的绩效考核方法通过考核员工为实现既定的结果所必须做出的行为来实现对结果的控制，由于行为必然是建立在某种能力基础之上的，并且行为比能力更具有外显性和可测性，因此一定程度上，该方法兼顾了组织目标和个人能力。但是，绩效考核中容易出现目标置换的现象，一味对行为测评会导致成员将行为作为目标，进而影响实际目标的实现。因此，无论哪种考核方式，都有其适用的条件和要求，不存在一种绝对好的方法。 基于项目团队生命周期的绩效考核: ?孵化诞生期: 这是指团队形成前到团队正式形成的一个阶段，是选择合适的项目成员组成团队的时期。 ?考核的客体是个人。团队的首要任务是筛选项目组成员，根据项目目标的要求，选择最为合适的人选组成团 队，所以考核的对象是个人。 ?考核的重点是能力。从项目团队成立的目的来看，它一般是为了开发一种新产品或者提供一项新的服务，因 此对成员的知识技能要求较高，需要成员具有较高的技术水平和知识储备以及不断学习和创新的能力。同时， 成立项目团队，意在发挥团队快速响应和凝聚集体智慧的优势，更加需要团队成员间的相互合作相互支持， 所以需要较为系统地考核成员的协调合作能力，包括，对团队其它成员工作任务的认识、口头交流、个人成 长、问题解决、责任承担、领导技能等等。因此，在选择项目团队成员的时候，通过对被选者专业技能、基 本素质当然也包括过去的工作经历和背景等各方面的考核，最终确定较为合适的人选。 ?成长期:这是团队正式形成之后，团队工作逐渐步入正轨，团队成员开始通过个人努力和彼此的合作共同在所研究
测试人员绩效评价标准
测试人员绩效评价标准
测试人员绩效评价方法版本记录： 文件状态： [√] 草稿 [ ] 正式发布 [ ] 正在修改当前 版本： 1.0 作 者： 徐涛 完成 日期： 2004-9-28 签收 人： 签收 日期： 1编写目的 本文档是对独立测试人员的绩效考核从测试能力方面进行考核的依据，其它考核的标准参照支持服务中心的部门考核大纲，该标准仅作为整体考核标准中的综合考核的一部分。
2适用范围 本标准适用于软件测试人员的考核。 3 评价标准与原则 3.1提交BUG的数量和执行测试用例的数量 测试中发现的BUG数量: 1)同一个项目组内，提交bug数 2)每人日提交的bug数 3.2测试人员发现的问题的本身价值 1)Bug的严重程度是衡量bug的质量的一个重要因素，好的bug应该是极端严重的，对系统造成极大危害的。 2)Bug的双方面评判，对于bug的价值开发人员在另外一个角度上进行评判。 3.3、测试文档的质量 测试文档的质量往往是测试人员的测试水平的反映，只有对系统进行了充分的、深入测试的测试人员才能写出高质量测试报告，说明测试的全面性和测试过程的质量 3.4 测试技能水平 1）测试用例设计水平 2）测试工具掌握使用水平 3）测试结果分析判断水平
3.5测试技能以外的综合能力 考察一个测试人员的责任心，如果一个测试人员工作不符责任，随意敷衍，即使提交的问题单数量多，也不能证明他测试的质量高。其次积极的工作态度是提高测试质量，和整体团队风气的关键，沟通能力直接影响测试的工作效率与不同部门间的合作分工。 1）工作态度 2）沟通能力 3）钻研能力 4）团队合作能力 4考核办法一览表
测试绩效考核
测试绩效考核 篇一：测试人员绩效考核详细 绩效考核 1.测试团队绩效考核 绩效评估的的客体：是个体成员还是整个团队。 ?Pascerellayer认为，团队绩效评价应以成员个人完成工作的状况为基本依据，理由是激励只能作用于个人而不是群体；技能的提高和行为的改进最终必须落实到个人。若仅考核团队绩效，个体的努力得不到充分的肯定，就容易造成社会懒散现象，即个体由于参加团队工作，其工作效率比自己单独工作时的效率反而大大降低。此现象一旦在组织中蔓延开来，不仅会影响组织绩效，还会毒害组织文化。同时，由于绩效考核与薪酬及个人价值的实现相联系，因此，在团队中，能力高的成员倾向于对个人绩效的考核，从而得到更高的认可和报酬。?zingheim和Schuster则认为对个人的考评应考虑团队的整体绩效，因为团队的成功很大程度上依赖于团队成员间的团结合作，理解支持，若评估集中于个体层面，会导致个人主义盛行，忽视团队的协作精神，阻碍信息、技能的共享和绩效的提高，降低团队工作的优势。?因此在实际操作中，企业往往采取一种折中的方法，即按一定比例兼顾团队和个人两个层面的绩效考核。从目前的研究来看，还没有一种很好的办法可以科学地确定这个比例。但是，如果从团队性质的差
异、团队所处的阶段等方面来考虑，那么至少可以确定考核的天平是更向个体的一极偏还是更向团体的一极偏。 绩效考核的内容：结果、行为还是能力。对于绩效内涵存在着三种不同的观点，即“绩效是结果”、“绩效是行为”和“绩效是能力”。Bernardin 将绩效定义为“在特定的时间内，由特定的工作职能活动产生的产出记录，工作绩效的总和相当于关键和必要工作职能中等绩效的总和（或平均值）”，这是“绩效是结果”的典型观点。murphy等人将绩效定义为“一套与组织或个体所工作的组织单位的目标相关的行为”。近年来，以能力作为绩效的观点得到了广泛的使用，这是以评估个体所拥有的完成某项工作所具备的知识和能力的方式。伴随着这三种观点的诞生和发展，绩效考核大致经历了基于结果、基于行为以及基于能力的三个考核发展过程。虽然这三种观点相互区别，且都是在否定前者的基础之上产生的，但是，如果不带入特定的环境，特定的组织，及组织发展的特定时期，那么三者之间并不存在绝对的优劣。如果组织下达的目标非常清晰，基于结果的绩效考核是最容易实施，也最有效；相反，如果目标模糊，无法准确衡量其结果，这种考核方式就会失效。基于能力的考核方式理论上是从战略管理的角度出发，最具有激励效果和长期效应，最有利于组织不断发展，但在实际操作中却很难达到效果。因为能力是无形的，它依附于个体，既受主观因素的控制，也受各方面客观因素的影响，很难用标准化的方法衡量个体的能力，即使是方法对组织期望成员所具有的能力和特质作出了解释，但这些解释仍是描述性模糊语言，在实际操作中仍然难以做到真正的科
测试人员绩效评价标准
测试人员绩效评价方法 版本记录： 1编写目的 本文档是对独立测试人员的绩效考核从测试能力方面进行考核的依据，其它考核的标准参照支持服务中心的部门考核大纲，该标准仅作为整体考核标准中的综合考核的一部分。 2适用范围 本标准适用于软件测试人员的考核。 3 评价标准与原则 3.1提交BUG的数量和执行测试用例的数量
测试中发现的BUG数量: 1)同一个项目组内，提交bug数 2)每人日提交的bug数 3.2测试人员发现的问题的本身价值 1)Bug的严重程度是衡量bug的质量的一个重要因素，好的bug应该是极端严重的，对系统造成极大危害的。 2)Bug的双方面评判，对于bug的价值开发人员在另外一个角度上进行评判。 3.3、测试文档的质量 测试文档的质量往往是测试人员的测试水平的反映，只有对系统进行了充分的、深入测试的测试人员才能写出高质量测试报告，说明测试的全面性和测试过程的质量 3.4 测试技能水平 1）测试用例设计水平 2）测试工具掌握使用水平 3）测试结果分析判断水平 3.5测试技能以外的综合能力 考察一个测试人员的责任心，如果一个测试人员工作不符责任，随意敷衍，即使提交的问题单数量多，也不能证明他测试的质量高。其次积极的工作态度是提高测试质量，和整体团队风气的关键，沟通能力直接影响测试的工作效率与不同部门间的合作分工。 1）工作态度 2）沟通能力 3）钻研能力 4）团队合作能力 4考核办法一览表
注：缺陷分类算法： A*(1+加权系统)/(A+B+C+D+E)*20 B*(1+加权系统)/(A+B+C+D+E)*20 C*(1+加权系统)/(A+B+C+D+E)*20 D*(1+加权系统)/(A+B+C+D+E)*20 E*(1+加权系统)/(A+B+C+D+E)*20
测试部绩效考核方案【最新版】
测试部绩效考核方案 考核工作事项及流程 1、季度工作总结。部门员工完成《员工季度工作总结》 2、部门考核。按照考核工作要求，组织员工考评，填写《季度员工绩效考核互评》，部门领导填写《季度员工绩效考核表》 3、考核结果审定。部门领导审核。 4、绩效沟通。考核结果公布后，有部门经理、组长进行绩效沟通工作 5、考核工作总结。对本部门员工绩效考核情况进行总结，并提交部门年度考核工作总结报 告以便于持续改进工作 6、考核兑现。对考核结果进行兑现 考核指标
1.完成工作量(10%) a)季度内在整个小组中完成的工作量最高 b)季度内在整个小组中完成的工作量较高 c)季度内在整个小组中完成的工作量一般 d)季度内在整个小组中完成的工作量最低 2.测试的水平(15%) a)测试过程质量令人放心，基本能全部测出一般情况下的bug外，还能测出隐藏很深的bug，项目交给他进行测试把关很放心，在整个测试组来说，相对是最好的 b)测试过程质量较好，基本能全部测出一般情况下的bug，隐藏很深的bug偶尔能测出，在整个测试组来说，出于中上水平 c)测试过程质量一般，能测试出大部分一般情况下的bug，但总觉得欠火候，在整个测试组内来说，处于中间水平
d)测试过程质量很差，有明显的bug没有测试出来，在整个测试组内来说，相对很差 3.测试用例质量(15%) a)测试用例编写质量很好，编写的内容除少量细节外，一般一次可通过，在整个测试组来说，相对是最好的 b)测试用例编写质量较好，编写的内容虽然有时候通不过，但明显看出是经过认真思考了的 c)测试用例编写质量一般，虽然由于能力有限，存在比较多的问题，但文档需要描述的各个方面都已经想到了，在整个项目组内来说，处于中间水平 d)测试用例编写质量很差，文档只是设计到了梗概，很多细节都没有描述到，讨论后修改的结果也不理想，要修改多次，或者因为别的原因，没有达到要求还是放过去，在整个测试组内来说，是相对最差的 4.缺陷描述(10%)
测试人员考核表
测试人员考核方案 一、测试设计 （一）工作效率相关指标 1、文档产出率： 这项指标值主要为测试用例文档页数除于编写文档的有效时间获得。用于考察测试人员测试用例文档的生产率大小 ∑测试用例文档页数（页） / ∑编写测试用例文档有效时间（小时） 参考指标：根据项目汇总得出平均在 1.14 页 / 小时左右，高于此值为优，低于此值为差 2、用例产出率： 这项指标值主要为上述指标值的补充，用于考察测试人员测试用例产出率大小。测试文档页数可能包含的冗余信息较多，因此要查看文档中测试用例的多少。方法是测试用例文档中测试用例编号总和数除于编写文档的有效时间∑测试用例数（个） / ∑编写测试用例文档有效时间（小时） 参考指标：平均 4.21 个用例 / 小时 （二）工作质量相关指标 1、需求覆盖率: 计算测试用例总数之和除于与之一一对应的功能点数之和，主要查看是否有功能点遗漏测试的情况。 ∑测试用例数（个） / ∑功能点（个） 参考指标： 100 ％。如果连功能指标都不能满足 100 ％覆盖，起码说明测试不充分。 2、文档质量： 测试用例进行评审和同行评审发现的缺陷数，或者将此缺陷数除于文档页数算出比率。此指标考察测试人员文档编写的质量如何。 ∑缺陷数（评审和同行评审）（个） ∑缺陷数（评审和同行评审）（个） / ∑测试用例文档页数（页）
参考指标：由于评审是发现的缺陷数是不固定的，因此，这个指标没有可供参考的数值。如果缺陷数大小不能直接用于比较就使用缺陷 / 页方式进行横向对比。 3、文档有效率： 使用测试用例文档进行测试时发现的系统测试缺陷数除于此文档页数。用于考察文档是由有效的指导了测试工作。 ∑缺陷数（系统测试）（个） / ∑测试用例文档页数（页） 参考指标：平均 2.18 个缺陷 / 页 4、用例有效率： 使用测试用例发现的全部缺陷除于测试用例数总和。这一指标是上一指标的补充指标，用于考察用例质量是否较高。 ∑缺陷数（系统测试）（个） / ∑测试用例数（个） 参考指标：平均 0.59 个缺陷 / 用例 二测试执行 （一）工作效率相关指标 1、执行效率： 利用测试用例文档页数除于此次系统测试执行的时间总和（不包含用例文档编写时间）。补充指标方法是用例的个数除于此次系统测试的时间总和。用于获得工作中测试人员每小时执行测试的速度。 公式：∑测试用例文档页数（页） / ∑执行系统测试的有效时间（小时） ∑测试用例数（个） / ∑执行系统测试的有效时间（小时） 参考指标：平均 0.53 页 / 小时， 1.95 个用例 / 小时。 2、进度偏离度： 检查计划时间和实际时间的进度，方法是计划时间差额减去实际时间差额除于实际工时总和，用于考察测试人员进度情况，监控测试是否按照日程进行，是否满足了工程的进度要求。 公式：∑（计划开始时间 - 实际开始时间）＋∑（计划结束时间 - 实际结
软件测试工程师考核标准
目标： 为了增强部门测试工程师考核的合理性、科学性，特制定本准则，根据本准则来完成对部门所有测试工程师的考核 目前部门测试团队共有11人，进行多个项目执行的软件测试工作，同时承担着部门大量的随机测试任务、性能测试任务、自动化测试任务 在每一项考核中我们都增加了考核的权数，每个文档、用例、Bug的提交都需要与权数相乘以后才是最终的得分，所有的得分相加将是测试工程师的最终得分 指标： 1、提交测试相关文档的质量 当前部门软件测试过程主要体现测试计划、测试用例、测试报告（会有多个）几个文档，故而对文档的考核将主要依据这几个文档来完成，对文档的质量的考核将在加分、扣分中阐述，文档的质量不满足要求会出现被扣分的情况，但是扣分最多只能扣除本文档带来积分（一般一个文档1分） 文档的考核权数为1 文档总分= 所有文档的总数×0.5 2、测试设计的质量 当前在部门测试过程中，测试设计的工作比重已经逐步增多，从而带来了大量的测试设计工作，测试设计的好坏将直接决定着部门测试水平的高下；我们的测试设计分为测试项和测试用例，由于当前测试管理平台还有待改进，测试用例设计文档中对测试项和测试用例没有严格的区别，故而很难定义、分解两者，目前按照统一的标准来考核 测试设计的考核权数为0.1 测试用例总分= 所有测试用例的总数×0.1 3、Bug的提交情况 对测试中发现的Bug进行分类和定义的目的，是为测试工程师的评价提供量化依据，为Bug的有效性提供参考。在考核过程中，所有的Bug统计都基于项目组确认是Bug的前提下，项目组不认定是Bug的不记入有效Bug中、同时不记入考核积分。 前提保证：目前所有的Bug每个月都会统一汇总公布，故而减少了非正常原因被拒绝的Bug数量，提高了项目经理、BA工程师对Bug的处理准确性 ? 一级Bug（系统崩溃）
项目部人员考核细则模版
xxxx安置区项目部 工作目标考核细则 为全面落实《xx市2014年市区城建重点项目考核办法》，根据集团公司统一安排，特制定xxxxx项目部工作目标考核细则。 一、考核目的 考核目的是全面推进xxxxx项目建设进展，充分体现按劳分配原则，提高项目部全体人员工作积极性。 二、考核对象 考核对象为青年南路旧城改造安置区项目部全体人员：xxxxxxxxxxxxxx 三、人员分工 根据项目建设需要，项目部人员分工如下： 项目统筹小组：xxxxxx 项目工作组现场负责人：xxx 1、第一工程小组：xxxxx，负责1#-6#楼质量、安全及进度。 2、第二工程小组：xxxxx，负责7#-11#楼质量、安全及进度。 3、安装工程组：xx，负责1#-11#楼水、电、暖通等安装、对接及变更工作。 4、配套协调组：xxxxx，负责项目配套工程方案对接、协调及合同草拟等工作。 5、造价控制组：xxxx，负责项目概、预算编制及工程投资控制
等工作。 6、工程监督组：xxxxx，负责与政府部门及项目小组对接与协调；考核资料收集、整理、报送等工作。 四、考核目标 考核分为月度考核和年度考核。 月度考核目标为上报集团工程例会的月度工作计划； 年度考核目标为上墙公布的内控进度计划和上报市政府的进度计划进行综合考核。 内控进度计划具体为： 1#、2#、10#、11#楼：二十八层主体结构 3#楼：二十七层主体结构 4#楼：二十六层主体结构 5#楼：二十五层主体结构 6#、7#楼：二十二层主体结构 8#楼：二十七层主体结 9#楼：结构封顶上报市政府进度计划为：1#-11#楼均完成二十二层结构主体（9#楼主体封顶）。 （注：以上楼层数均为除双层地下室外的自然层） 五、考核机构 由xx公司工程管理部派员组成考核小组,xxx同志担任组长。 六、考核程序 考核采取两个项目小组自查、代建单位核查、集团公司全面检
软件测试人员绩效考核详细
1、测试团队绩效考核 绩效评估的的客体：是个体成员还是整个团队。 ●Pascerellayer认为，团队绩效评价应以成员个人完成工作的状况为基本依据，理由是激励只能作用于个人而不是群体；技能的提高和行为的改进最终必须落实到个人。若仅考核团队绩效，个体的努力得不到充分的肯定，就容易造成社会懒散现象，即个体由于参加团队工作，其工作效率比自己单独工作时的效率反而大大降低。此现象一旦在组织中蔓延开来，不仅会影响组织绩效，还会毒害组织文化。同时，由于绩效考核与薪酬及个人价值的实现相联系，因此，在团队中，能力高的成员倾向于对个人绩效的考核，从而得到更高的认可和报酬。 ●Zingheim和Schuster则认为对个人的考评应考虑团队的整体绩效，因为团队的成功很大程度上依赖于团队成员间的团结合作，理解支持，若评估集中于个体层面，会导致个人主义盛行，忽视团队的协作精神，阻碍信息、技能的共享和绩效的提高，降低团队工作的优势。 ●因此在实际操作中，企业往往采取一种折中的方法，即按一定比例兼顾团队和个人两个层面的绩效考核。从目前的研究来看，还没有一种很好的办法可以科学地确定这个比例。但是，如果从团队性质的差异、团队所处的阶段等方面来考虑，那么至少可以确定考核的天平是更向个体的一极偏还是更向团体的一极偏。 绩效考核的内容：结果、行为还是能力。对于绩效内涵存在着三种不同的观点，即“绩效是结果”、“绩效是行为”和“绩效是能力”。Bernardin将绩效
定义为“在特定的时间内，由特定的工作职能活动产生的产出记录，工作绩效的总和相当于关键和必要工作职能中等绩效的总和（或平均值）”，这是“绩效是结果”的典型观点。Murphy等人将绩效定义为“一套与组织或个体所工作的组织单位的目标相关的行为”。近年来，以能力作为绩效的观点得到了广泛的使用，这是以评估个体所拥有的完成某项工作所具备的知识和能力的方式。伴随着这三种观点的诞生和发展，绩效考核大致经历了基于结果、基于行为以及基于能力的三个考核发展过程。？虽然这三种观点相互区别，且都是在否定前者的基础之上产生的，但是，如果不带入特定的环境，特定的组织，及组织发展的特定时期，那么三者之间并不存在绝对的优劣。如果组织下达的目标非常清晰，基于结果的绩效考核是最容易实施，也最有效；相反，如果目标模糊，无法准确衡量其结果，这种考核方式就会失效。基于能力的考核方式理论上是从战略管理的角度出发，最具有激励效果和长期效应，最有利于组织不断发展，但在实际操作中却很难达到效果。因为能力是无形的，它依附于个体，既受主观因素的控制，也受各方面客观因素的影响，很难用标准化的方法衡量个体的能力，即使是方法对组织期望成员所具有的能力和特质作出了解释，但这些解释仍是描述性模糊语言，在实际操作中仍然难以做到真正的科学公正。基于行为的绩效考核方法通过考核员工为实现既定的结果所必须做出的行为来实现对结果的控制，由于行为必然是建立在某种能力基础之上的，并且行为比能力更具有外显性和可测性，因此一定程度上，该方法兼顾了组织目标和个人能力。但是，绩效考核中容易出现目标置换的现象，一味对行为测评会导致成员将行为作为目标，进而影响实际目标的实现。因此，无论哪种考核方式，都有其适用的条件和要求，不存在一种绝对好的方法。
软件测试人员绩效考核详细
1 、测试团队绩效考核 绩效评估的的客体：是个体成员还是整个团队。 ●Pascerellayer 认为，团队绩效评价应以成员个人完成工作的状况为基本依据，理由是激励只能作用于个人而不是群体；技能的提高和行为的改进最终必须落实到个人。若仅考 核团队绩效，个体的努力得不到充分的肯定，就容易造成社会懒散现象，即个体由于参加 团队工作，其工作效率比自己单独工作时的效率 反而大大降低。此现象一旦在组织中蔓延开来，不仅会影响组织绩效，还会毒害 组织文化。同时，由于绩效考核与薪酬及个人价值的实现相联系，因此，在团队 中，能力高的成员倾向于对个人绩效的考核，从而得到更高的认可和报酬。 ●Zingheim 和 Schuster 则认为对个人的考评应考虑团队的整体绩效，因为团队的成功很大程度上依赖于团队成员间的团结合作，理解支持，若评估集中于个体层面，会导致个人 主义盛行，忽视团队的协作精神，阻碍信息、技能的共享和绩效的提高，降低团队工作的优势。 ●因此在实际操作中，企业往往采取一种折中的方法，即按一定比例兼顾 团队和个人两个层面的绩效考核。从目前的研究来看，还没有一种很好的办法可以科学地确 定这个比例。但是，如果从团队性质的差异、团队所处的阶段等方面来考虑，那么至少可以 确定考核的天平是更向个体的一极偏还是更向团体的一极偏。 绩效考核的内容：结果、行为还是能力。对于绩效内涵存在着三种不同的观点，即“绩效是结果”、“绩效是行为”和“绩效是能力”。Bernardin 将绩效
定义为“在特定的时间内，由特定的工作职能活动产生的产出记录，工作绩效的 总和相当于关键和必要工作职能中等绩效的总和（或平均值）”，这是“绩效是 结果”的典型观点。Murphy 等人将绩效定义为“一套与组织或个体所工作的 组织单位的目标相关的行为”。近年来，以能力作为绩效的观点得到了广泛的使用，这是以评估个体所拥有的完成某项工作所具备的知识和能力的方式。伴随着 这三种观点的诞生和发展，绩效考核大致经历了基于结果、基于行为以及基于能力的三个考核发展过程。？虽然这三种观点相互区别，且都是在否定前者的基础 之上产生的，但是，如果不带入特定的环境，特定的组织，及组织发展的特定时期，那么三者之间并不存在绝对的优劣。如果组织下达的目标非常清晰，基于结果的绩效考核是最容易实施，也最有效；相反，如果目标模糊，无法准确衡量其 结果，这种考核方式就会失效。基于能力的考核方式理论上是从战略管理的角度 出发，最具有激励效果和长期效应，最有利于组织不断发展，但在实际操作中却 很难达到效果。因为能力是无形的，它依附于个体，既受主观因素的控制，也受 各方面客观因素的影响，很难用标准化的方法衡量个体的能力，即使是方法对组织期望成员所具有的能力和特质作出了解释，但这些解释仍是描述性模糊语言， 在实际操作中仍然难以做到真正的科学公正。基于行为的绩效考核方法通过考核 员工为实现既定的结果所必须做出的行为来实现对结果的控制，由于行为必然是建立在某种能力基础之上的，并且行为比能力更具有外显性和可测性，因此一定程度上，该方法兼顾了组织目标和个人能力。但是，绩效考核中容易出现目标置 换的现象，一味对行为测评会导致成员将行为作为目标，进而影响实际目标的实现。因此，无论哪种考核方式，都有其适用的条件和要求，不存在一种绝对好的 方法。
软件测试工程师绩效评估表word版本
软件测试工程师绩效评估表 一．软件测试工程师职责： 1 与软件产品部配合完成软件需求分析讨论，并根据需求说明书制定《项目测试（计划） 方案》；编写《测试用例》；建立测试环境； 2 负责研发部门各开发组研发的软件产品开发过程和投入运营之前的新增软件和修改 软件的模块测试和系统测试；建立、推广并维护实施软件版本管理系统； 3 使用并维护软件缺陷管理系统mantis，负责软件问题解决过程跟踪记录，提交《mantis 报告》； 4 负责推广实施软件开发文档规范化工作，管理研发产品相关文档； 5 负责配合软件研发部门等对于新项目软件或修改升级项目软件的测试工作，并提供测 试报告； 6 负责监督软件开发流程的执行，并负责提出软件开发过程改进建议，提高软件产品质 量。 7 与开发工程师和研发部门交流报告任务进展情况，并提出最近的测试需求； 8 测试部负责制订测试计划、测试用例和测试实施方案，项目主负责人安排测试与对应 的开发人员交流完成测试执行工作；及时提交准确、完整的《项目测试报告》； 9 项目主负责人负责开发流程管理和人力资源、测试用软硬件资源调配，需要与研发之 外的部门定期交流掌握下周或近期可能测试任务； 10外部接口都由测试部主管负责完成，与其他项目组和产品部门协调项目进度； 二．软件测试的不确定性： 1 软件测试的目的就是使软件的错误不断趋进于零，但软件的错误是永远找不完的； 2 开始测试时，可能软件使用1个小时就出现10个错误；测试修正后1个小时出现一 个错误，继续修正，继续测试，直到约一个月出现一个错误。这时这个出错几率已经通过终结评审可以接受了。那么测试就结束了。移植成功之后测试工作由开发部门来维护。 3 测试一些成熟的游戏或应用，测试过程中很难发现大量的缺陷；而测试一些不成熟 的游戏或应用，在测试前期，会出现大量的问题；这样就导致不同的工程师发现不同数量的bug； 4 软件测试的进度首先会按照测试计划逐步进行，但是在测试过程中，测试进度会随研 发部门的进度而调整；所以积极的与研发部门交流、协调测试中的问题是相当必要的。 三．测试工作最低成功标准及测试工程师考核内容： 测试工作的最终目标就是发现客户可能发现的所有错误。如果移植测试在使用第一天就发现了你没测试出来的错误，那测试是失败的。如果使用了很久（如几个月）才出现错误，那说明测试还是成功的。 测试工程师考核内容： 1 测试工程师比开发工程师更了解产品；（产品各模块总体把握能力）
测试人员考核标准
一、目标 为了增强部门测试工程师考核的合理性、科学性，特制定本准则，根据本准则来完成对部门所有测试工程师的考核 在每一项考核中我们都增加了考核的权数，每个文档、用例、Bug的提交都需要与权数相乘以后才是最终的得分，所有的得分相加将是测试工程师的最终得分 二、指标 1、提交测试相关文档的质量（10） 在测试的过程中测试文档能够在一定程度上体现测试人员的测试能力水平，而当前软件测试过程主要会产生测试计划、测试用例、测试报告（会有多个）几个文档，故而对文档的考核将主要依据这几个文档来完成，对文档的质量的考核将在加分、扣分中阐述，文档的质量不满足要求会出现被扣分的情况，但是扣分最多只能扣除本文档带来积分（一般一个文档1分） 文档的考核权数为1 文档总分= 所有文档的总数×0.5 2、测试设计的质量（10） 当前在测试过程中，测试设计的工作比重已经逐步增多，从而带来了大量的测试设计工作，测试设计的好坏将直接决定着部门测试水平的高下；我们的测试设计分为测试项和测试用例，由于测试用例设计文档中对测试项和测试用例没有严格的区别，故而很难定义、分解两者，目前按照统一的标准来考核 测试设计的考核权数为0.1 测试用例总分= 所有测试用例的总数×0.1 3、Bug的提交情况（70） 对测试中发现的Bug进行分类和定义的目的，是为测试工程师的评价提供量化依据，为Bug的有效性提供参考。在考核过程中，所有的Bug统计都基于项目组确认是Bug的前提下，项目组不认定是Bug的不记入有效Bug中、同时不记入考核积分。 ? 一级Bug考核权数：0.8
? 二级Bug考核权数：0.5 ? 三级Bug考核权数：0.3 ? 四级Bug考核权数：0.2 Bug总分= 一级Bug总数×1 + 二级Bug总数×0.8 + 三级Bug总数×0.5 + 四级Bug总数×0.2 4、综合素质（10） 包括工作能力、沟通能力、自学能力、团队协作能力 5、加减分项 5.1加分 说明：加分只能当月加分，不能一个输出多次重复加分，最多一次只能加3分 1）对其他同事培训 2）提出项目过程中的问题反馈： 一般问题：0.2 严重问题：0.4 测试过程改进问题：0.6说明：由于目前还没有严格的问题严重程度的定义，故而暂时由测试负责人指定加分额度。 5.2减分 说明：对于每一个输出内容的减分不能超过输出产生的所能产生的所有积分，如一个文档的减分不能超过1分，一个五级Bug的减分不能超过0.1分 5.2.1文档 文档没有按照规范书写，文档质量低下（考核结果主要来源于项目经理对文档的认可度）
检测公司员工绩效考核管理办法
检测公司员工绩效考核管理办法 第一条为加强公司内部管理，全面了解、评估员工的工作绩效，充分调动员工的工作积极性，提高工作效率，增强企业活力，确保公司生产、经营活动持续有效进行，本着公平、公正、公开及奖惩分明的原则，结合公司实际情况，制订本办法。 第二条考核目的 通过考核，全面评价员工各项工作的表现，使员工了解自己的工作表现与所得报酬、待遇的关系，获得努力向上、持续改进的动力。通过考核，以达到表彰先进，鞭策后进的目的。 第三条考核对象 1、凡公司在册的全部员工均属考核对象; 2、公司副总经理、总工程师(技术负责人)、质量负责人由公司总经理及执行董事进行考核; 第四条考核组织领导 公司成立员工绩效考核领导小组，负责员工绩效考核工作。考核领导小组成员如下: 组长: 副组长: 成员: 第五条考核内容 员工绩效考核分季度考核和年度考核。 第六条季度考核
1、每季度考核一次，季度末进行。考核分为“劳动纪律”、“仪器设备与环境卫生”、“工作态度和工作质量”、“团结协作与员工诚信”及“技术水平与能力”五大要素共29个指标组成季度考核体系。 2、季度考核总分值为100分，各要素分值分别为“劳动纪律”25分，“仪器设备与环境卫生”15分，“工作质量和工作态度”35分，“团结协作与员工诚信”20分，“技术水平与能力”5分。详见表一。 3、季度考核分A、B、C、D、E五个等级进行评定。 其中:“工作出色”评定为A级，考核得分为100分(含)以上;“良好”评定为B级，得分95(含),99分;“称职”评定为C级，得分90(含),94分;“需要改进”评定为D级，得分85(含),89分;“不尽人意”评定为E级，得分84分(含)以下。 第七条年度综合考核 1、年度综合考核工作在当年底(12月下旬)或次年初(元月上旬)进行。考核包括“季度考核平均等级”、“领导评议等级”及“群众评议等级”三大部分。三大部分考核等级权重分别为60%、30%及10%，“员工绩效领导评议表”、“ 员工绩效群众评议表”、“年度员工绩效综合评定汇总表”详见表二、表三、表四。 2、季度考核平均等级的确定:季度考核平均等级按四个季度考核等级综合评定。其评定方法为:将各季度考核得分相加除以4后得到相应分值，将所得分值对应A、 B、C、D、E五个等级确定季度考核平均等级。 3、“员工绩效领导评议等级”、“ 员工绩效群众评议等级”及“年度员工绩效综合评定汇总表”中各要素及综合评价均分为A、B、C、D、E五个等级(分值同季度考核规定)，年度综合评定考核时，按相应等级及权重计算综合得分，并确定最终等级。 第八条考核程序
软件测试工程师业绩评估标准
软件测试工程师业绩评估标准 Testing：Liuying 2007-01-30 一．软件测试工程师职责： 1 与软件产品部配合完成软件需求分析讨论，并根据需求说明书制定《项目测试（计划）方案》；编 写《测试用例》；建立测试环境； 2 负责研发部门各开发组研发的软件产品开发过程和投入运营之前的新增软件和修改软件的模块测 试和系统测试；建立、推广并维护实施软件版本管理系统； 3 使用并维护软件缺陷管理系统Bugzilla，负责软件问题解决过程跟踪记录，提交《buglist报告》； 4 负责推广实施软件开发文档规范化工作，管理研发产品相关文档； 5 负责配合软件运维部门等对于新业务软件或修改升级业务软件的上线测试工作，并提供上线测试报 告； 6 负责监督软件开发流程的执行，并负责提出软件开发过程改进建议，提高软件产品质量。 7 与开发工程师和研发部门交流报告任务进展情况，并提出最近的测试需求； 8 测试部门经理负责制订测试计划、测试用例和测试实施方案，安排测试工程师与对应的开发人员交 流完成测试执行工作；及时提交准确、完整的《项目测试报告》； 9 测试部经理负责开发流程管理和人力资源、测试用软硬件资源调配，需要与研发之外的部门定期交 流掌握下周或近期可能测试任务； 10外部接口都由测试部经理负责完成，与其他项目组和产品部门协调项目进度； 二．软件测试的不确定性： 1 软件测试的目的就是使软件的错误不断趋进于零，但软件的错误是永远找不完的； 2 开始测试时，可能软件使用1个小时就出现10个错误；测试修正后1个小时出现一个错误，继续 修正，继续测试，直到约一个月出现一个错误。这时这个出错几率客户已经可以接受了（如win98系统）。那么测试就结束了。交货之后测试工作由客户来进行（使用过程中）。 3 测试一些成熟的模块，测试过程中很难发现大量的缺陷；而测试一些不成熟的模块，在测试前期， 会出现大量的问题；这样就导致不同的工程师发现不同数量的bug； 4 软件测试的进度首先会按照测试计划逐步进行，但是在测试过程中，测试进度会随研发部门的进度 而调整；所以积极的与研发部门交流、协调测试中的问题是相当必要的。 三．测试工作最低成功标准及测试工程师考核内容： 测试工作的最终目标就是发现客户可能发现的所有错误。如果客户在使用第一天就发现了你没测试出来的错误，那测试是失败的。如果使用了很久（如几个月）才出现错误，那说明测试还是成功的。 测试工程师考核内容： 1 测试工程师比开发工程师更了解产品；（产品各模块总体把握能力） 2 测试工程师能从客户的角度来检测软件的功能；（用户身份） 3 测试工程师获取资料，使得编制的测试用例更切合测试的重点、难点以及关注点； （编写测试用例） 4 测试工程师比开发工程师更容易发现产品的问题；（不同的思维模式）
IT测试部员工绩效评估
IT测试部员工绩效评估 为度量测试部员工工作质量，达到持续提高的目标，特制定本考核标准 a 测试部工作每半年考核一次，考核结果作为员工技能水平，工作质量的评估依据，影响年终奖金分配。 ―、修订方法： 考核标准每半年修订一次，如对考核标准及评分比例持有异议，可以提出修改建议，经测试部全休会议讨论，2/3同意即可接纳更新。 修订在考核之后2周内进行，并在下一轮考核中使用。本轮考核使用修订前的标准。 二、评分方式： 按照公共要求和各种工作本身特有的要求进行评分。 评分釆用排队法。举例说明，如果在该项目中有10人进行比较，你的分数排笫2,你的分数就是0.8。如果大家都一样，大家的分数都是0.5。 没有对比的项目，按照实际成绩与承诺成绩的对比进行评分，例如，年中承诺认证按时通过率80%，实际做到了 90%，评分就是90%/80%*0.5=0.5625。没有承诺成绩的，按0.5计算。 总分按照涉及的项目的比例乘以该项分数得到。在部门内排队。 三、考核标准： ? 公共要求50%: 1工作任务按时完成率20% 由项目经理和测试主管打分。 项目中如果由于别人的工作导致测试工作延后，不能按期交付，只计算测试工作实际的执行时间。 工作按时完成率=计划时间/实际使用时间。 取各项工作按时完成宇的平均分排队 2工作文档质量10% 项目经理和测试主管打分 文档缺陷数<3为3分：淸晰准确，缺陷数<10为2分：其余1分。取提交文档的平均分排队。 缺陷只包含技术性的错误，不包含错别字，如：描述产生的歧义，测试方案考虑不周，遗漏测试内容等 文档包含：测试方案，测试用例，测试报告，问题分析报告，生产资料包，治具使用说明，工厂测试程序使用说明（工厂测试程序升级说明不纳入考核)，器件认证的测试标准。 每篇文档打分，取各人的文档平均分进行比较。 3 技术共享10%
研发测试人员绩效考核奖励细则v
研发人员绩效考核奖励细则 一、考核目的 为了更好完善公司各项目管理机制，保障研发项目的按期、高效、高质完成，同时进一步促进研发部门员工自身的发展，结合研发人员的工作特点，特制定本方案。 二、适用范围 公司研发所有员工，具体包括智能硬件产品组、电商组、APP组、大数据组转正员工。（当月15 日（含当天）前转正本月考核，15 日后转正的次月考核） 三、考核周期：月度考核 四、考核方法与原则 4.1考核方法 采用部门考核的方法（以产品为单位，产品负责人对其下属员工的进度、质量、规范性、工作态度及能力等方面进行评估）； 4.2考核原则 采用行为考核与结果考核相结合。 五、考核内容与评分标准（详见附件一文件《研发人员绩效考核表》） 六、考核实施 6.1计划沟通阶段 6.2计划实施阶段 6.3考核阶段 考核者根据被考核者在考核期内的工作表现和考核标准，对被考核者评分，同时被考核者也需根据个人在考核期内的工作表现和考核标准进行自评。 考核者的直接上级及主管领导对考核结果进行审核，并负责处理考核评估过程中所发生的争议。
各部门每月 10 日前组织绩效面谈会议，将上月考核结果反馈给被考核者，并讨论绩效改进的方式和途径。 七、绩效工资与考核结果运用 7.1绩效工资运用 7.2绩效考核结果运用 7.2.1绩效面谈 考核者每月5日前对被考核者上月度的工作绩效进行总结，填写附件二《绩 效考核面谈表》，并指出被考评者有待改进的地方，从而进行差距分析，确保绩效的持续改进，同时共同制定下月的绩效目标。 等级 A B C D 定义 卓越 优秀 合格 差 实际表现显着超出预期目标 实际表现超出预期目标，取得出色成绩 实际表现基本达到预期目标 实际表现未达到预期目标，有严重 失误 得分 100（含）分+ 90（含）-100分 60（含）—90分 59(含)分以下 分布比例 20% 70% 10%或至少有1人 绩效工资系数 1.5 1.2 1 0.5 7.2.3相关奖励 1）根据年度 12 个月的平均得分，作为员工薪资调整、职位晋升、岗位培训的决策 依据。 岗位职级 绩效工资与薪酬占比 对应薪酬级别范围 技术专家/高级管理 30% L5-M3 资深测试/研发/项目经理 25% L3- L4/M1-M2 高级测试/开发工程师 20% L3 中级测试/开发工程师 15% L2 初级测试/开发工程师 10% L1