软件测试人员绩效考核详细

1 、测试团队绩效考核

绩效评估的的客体：是个体成员还是整个团队。

●Pascerellayer 认为，团队绩效评价应以成员个人完成工作的状况为基本依据，理由是激励只能作用于个人而不是群体；技能的提高和行为的改进最终必须落实到个人。若仅考

核团队绩效，个体的努力得不到充分的肯定，就容易造成社会懒散现象，即个体由于参加

团队工作，其工作效率比自己单独工作时的效率

反而大大降低。此现象一旦在组织中蔓延开来，不仅会影响组织绩效，还会毒害

组织文化。同时，由于绩效考核与薪酬及个人价值的实现相联系，因此，在团队

中，能力高的成员倾向于对个人绩效的考核，从而得到更高的认可和报酬。

●Zingheim 和 Schuster 则认为对个人的考评应考虑团队的整体绩效，因为团队的成功很大程度上依赖于团队成员间的团结合作，理解支持，若评估集中于个体层面，会导致个人

主义盛行，忽视团队的协作精神，阻碍信息、技能的共享和绩效的提高，降低团队工作的优势。

●因此在实际操作中，企业往往采取一种折中的方法，即按一定比例兼顾

团队和个人两个层面的绩效考核。从目前的研究来看，还没有一种很好的办法可以科学地确

定这个比例。但是，如果从团队性质的差异、团队所处的阶段等方面来考虑，那么至少可以

确定考核的天平是更向个体的一极偏还是更向团体的一极偏。

绩效考核的内容：结果、行为还是能力。对于绩效内涵存在着三种不同的观点，即“绩效是结果”、“绩效是行为”和“绩效是能力”。Bernardin 将绩效

定义为“在特定的时间内，由特定的工作职能活动产生的产出记录，工作绩效的

总和相当于关键和必要工作职能中等绩效的总和（或平均值）”，这是“绩效是

结果”的典型观点。Murphy 等人将绩效定义为“一套与组织或个体所工作的

组织单位的目标相关的行为”。近年来，以能力作为绩效的观点得到了广泛的使用，这是以评估个体所拥有的完成某项工作所具备的知识和能力的方式。伴随着

这三种观点的诞生和发展，绩效考核大致经历了基于结果、基于行为以及基于能力的三个考核发展过程。？虽然这三种观点相互区别，且都是在否定前者的基础

之上产生的，但是，如果不带入特定的环境，特定的组织，及组织发展的特定时期，那么三者之间并不存在绝对的优劣。如果组织下达的目标非常清晰，基于结果的绩效考核是最容易实施，也最有效；相反，如果目标模糊，无法准确衡量其

结果，这种考核方式就会失效。基于能力的考核方式理论上是从战略管理的角度

出发，最具有激励效果和长期效应，最有利于组织不断发展，但在实际操作中却

很难达到效果。因为能力是无形的，它依附于个体，既受主观因素的控制，也受

各方面客观因素的影响，很难用标准化的方法衡量个体的能力，即使是方法对组织期望成员所具有的能力和特质作出了解释，但这些解释仍是描述性模糊语言，

在实际操作中仍然难以做到真正的科学公正。基于行为的绩效考核方法通过考核

员工为实现既定的结果所必须做出的行为来实现对结果的控制，由于行为必然是建立在某种能力基础之上的，并且行为比能力更具有外显性和可测性，因此一定程度上，该方法兼顾了组织目标和个人能力。但是，绩效考核中容易出现目标置

换的现象，一味对行为测评会导致成员将行为作为目标，进而影响实际目标的实现。因此，无论哪种考核方式，都有其适用的条件和要求，不存在一种绝对好的

方法。

基于项目团队生命周期的绩效考核：

● 孵化诞生期：这是指团队形成前到团队正式形成的一个阶段，是选择合

适的项目成员组成团队的时期。

→ 考核的客体是个人。团队的首要任务是筛选项目组成员，根据项目目标

的要求，选择最为合适的人选组成团队，所以考核的对象是个人。

→ 考核的重点是能力。从项目团队成立的目的来看，它一般是为了开发一种新产品或者提供一项新的服务，因此对成员的知识技能要求较高，需要成员具

有较高的技术水平和知识储备以及不断学习和创新的能力。同时，成立项目团队，

意在发挥团队快速响应和凝聚集体智慧的优势，更加需要团队成员间的相互合作相互支持，所以需要较为系统地考核成员的协调合作能力，包括，对团队其它成

员工作任务的认识、口头交流、个人成长、问题解决、责任承担、领导技能等等。

因此，在选择项目团队成员的时候，通过对被选者专业技能、基本素质当然也包

括过去的工作经历和背景等各方面的考核，最终确定较为合适的人选。

● 成长期：这是团队正式形成之后，团队工作逐渐步入正轨，团队成员开

始通过个人努力和彼此的合作共同在所研究的项目上获得初步的成就。

→ 考核的客体是团队。团队成立之初，成员合作的意识还没有形成，工作

的独立性较强，此时的工作重点应该是营造一种信任、关怀、相互支持的合作氛围。同时，项目也刚刚起步，没有取得实质性的进展，个人的贡献还无法准确衡

量，在这种情况下，如果过多地衡量个人绩效，特别是个人产出绩效，不仅不利

于合作精神的培养，也会由于准确性不高而使成员产生不公平感，从而对团队工

作形成抵触情绪。注重团队整体绩效的考核，可以向整个团队成员传递这样一个

信息，即必须注重团队的整体效率，共同开发团队能力。同时，对团队绩效的考

核还可以提高团队成员对自己团队的自豪感和所有感，并不断提高其认同感和归属感。

→ 考核的重点是行为。刚刚进入一个新的团队，如果此前没有进行过合作，

成员之间会由于陌生感而信任度较低，彼此在沟通和交流上存在困难，需要相当一段时间的磨合，工作进度也很缓慢。如果不通过有意识的加强合作意识的培养，难么磨合期就会较长，从而影响目标的实现。因此在项目团队进入成长期时，绩效考核的重点应该放在对团队成员行为的考核之上。绩效考核不仅仅是一种过程的监督和事后的衡量，更是一种对员工行为进行引导的方式。作为一种信息的传播途径，通过评估的本身，反馈以及与薪酬的联系，以直接或间接的方式告诉被

考核者，组织鼓励什么样的行为、反对什么样的行为，从而引导和鼓励成员采用

更加积极的态度和行为，主动参与团队工作，加强团队成员之间的合作和学习，

使项目团队尽快度过磨合期，向着一个良性的方向发展。

● 成熟期：进入成熟期，团队工作进展顺利，项目取得关键性的突破，团

队成员自由沟通，合作意识加强。

→ 考核的客体是个人。此时应该加大对个人绩效考核的比重。因为项目已经取得一定的突破，目标接近实现，团队成员的成果和贡献相对比较清晰，可以较为准确的衡量，需要对其加以肯定。如果仍然只是停留于对团队绩效的整体考

核，并以此为基础进行利益分配，个体会逐渐产生不公平感，因为随着项目工作

的深入开展和目标的逐步实现，个人由于态度、能力、技术支持等诸多方面的差

异，贡献度的差距会逐步扩大，客观上会有成员的贡献大于其它人，如果不及时

加以肯定和认可，那么就会挫伤这一部分核心成员的积极性。

→ 考核的重点是结果。成熟期的团队首要任务是推动工作进展，以保证最

终成果的实现。由于既有的工作方式已经基本形成，合作沟通的氛围已经建立，

如果仍然强调对个体行为的考核，会使成员将大部分的注意力投入到日常的工作

行为和方式之上。事实上，鼓励行为的本身并不是目的，关键是行为带来的结果，

合作和交流是团队的基本工作手段，但手段不能代替目的，项目及时高效地完成才是项目团队的存在目的。如果不以任务为导向而长期进行行为考核，容易使个体忽视目标和结果，影响工作的效率，例如，过分的注重沟通和交流，造成决策

时议而不决，贻误时机，或者意见趋中，成员过分尊重群体意见，不愿表达自己

突破性的想法和思路。

● 衰退期：项目目标已经基本实现，团队即将解散，此时需要对整个项目

团队作一个综合的评估。

→ 考核的客体兼顾个人和团队。进入衰退期，绩效考核一方面需要通过对项目团队的整体绩效作出评估，以考核项目的完成情况；另一方面，也需要对团队成员绩效作出公正科学的总结，这不仅决定成员能否取得公平的报酬，也是其

进入另一个团队的基础。

→ 考核的重点主要是个人的综合绩效以及团队的产出。项目团队任务明确，业绩是团队成立的最终目的，因此在项目团队解散之际，需要对目标的实现情况

作一个综合评估，以此判断项目的成功与否。对个人也需要做一个总体的评价，

尤其是产出和能力的评估，组织需要对此进行备案，成为以后的项目团队选择成

员的重要根据。

2、测试人员绩效考核

考核基于测试过程进行，因此必须在过程结束之后才能进行。由于工程是分布提交测试的，每月可以根据实际情况进行月考核，工程结束后或任务结束后再

统一考核。按照传统测试周期，测试过程分为：测试计划、测试设计和测试执行

三个方面进行。测试计划属于测试经理的范畴。测试人员主要是测试设计和测试

执行。

测试人员的绩效考核包括多个方面：

● 工作态度。包括工作责任心和工作积极性。

●工作职责与期望达成度(注意：在工作安排前需求明确对应测试工程师的

工作职责和对测试工程师的期望值，这里的工作职责一般是和管理相关的工作职

责内容 )。

● 工作内容考核。

→ 参与软件开发过程的工作内容考核，比如参与需求和设计的评审，就需

要对需求的理解上，对需求提出问题的质量上等作出评价。

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

→ 执行测试的工作，需要从测试人员所发现的问题对测试人员进行评价。

包括发现问题是复杂的还是简单的，是隐藏较深的，还是一些表面的问题。包括问题的书写上进行评价，问题的书写是否详细清晰，开发人员可以再现，还是含糊其词，不明所以。一个问题是否写多遍等。

→ 测试结果缺陷残留，对于已经发布的产品，从用户反馈问题考核测试人员的绩效，但是这个可能需要的时间比较长；对于不同版本的测试，可从版本的

漏检进行统计。

→ 测试人员的沟通能力考核，包括缺陷在开发工程师中沟通的达成率和拒

绝率。

● 工作效率与工作质量考核。

→ 测试设计中工作效率相关指标：

△ 文档产出率：这项指标值主要为测试用例文档页数除于编写文档的有效时

间获得。用于考察测试人员测试用例文档的生产率大小。

公式：∑测试用例文档页数（页） / ∑编写测试用例文档有效时间（小时）

参考指标：根据项目汇总得出平均在 1.14 页 / 小时左右，高于此值为优，低于此值为差。

△ 用例产出率：这项指标值主要为上述指标值的补充，用于考察测试人员测试用例产出率大小。测试文档页数可能包含的冗余信息较多，因此要查看文档中测试用例的多少。方法是测试用例文档中测试用例编号总和数除于编写文档的有

效时间。

公式：∑测试用例数（个）/ ∑编写测试用例文档有效时间（小时）

参考指标：平均 4.21 个用例/ 小时

● 测试设计中工作质量相关指标：

→ 需求覆盖率：计算测试用例总数之和除于与之一一对应的功能点数之和，

主要查看是否有功能点遗漏测试的情况。

公式：∑测试用例数（个）/ ∑功能点（个）

参考指标： 100 ％。如果连功能指标都不能满足100 ％覆盖，起码说明测试不充分。这个指标收集起来相当困难，如果存在需求跟踪矩阵或者测试管理工具能把用例与需求一一对应就容易得多。注意：有的功能是难于测试的，那么未能覆盖到的需求要综合分析，明确是测试人员遗漏？还是无法测试？这需要放入

问题跟踪表中进行后续跟踪；另外，有的功能点包含的信息较多或者有的用例包

含几个功能点，这时只能把重复的功能点或重复用例按一个计，难于区分的要做说明。

→ 文档质量：测试用例进行评审和同行评审发现的缺陷数，或者将此缺陷

数除于文档页数算出比率。此指标考察测试人员文档编写的质量如何。

公式：∑缺陷数（评审和同行评审）（个）/ ∑测试用例文档页数（页）

参考指标：由于评审是发现的缺陷数是不固定的，因此，这个指标没有可供

参考的数值。如果缺陷数大小不能直接用于比较就使用缺陷/ 页方式进行横向

对比。

→ 文档有效率：使用测试用例文档进行测试时发现的系统测试缺陷数除于

此文档页数。用于考察文档是由有效的指导了测试工作。

公式：∑缺陷数（系统测试）（个）/ ∑测试用例文档页数（页）

参考指标：平均 2.18 个缺陷/ 页

注意：如果存在测试人员在测试时创建新文档用于辅助测试时应包含这一部

分。

→ 用例有效率：使用测试用例发现的全部缺陷除于测试用例数总和。这一

指标是上一指标的补充指标，用于考察用例质量是否较高

公式：∑缺陷数（系统测试）（个）/ ∑测试用例数（个）

参考指标：平均 0.59 个缺陷 / 用例，也就是说，每执行两个用例才得到 1 个缺陷，各工程有所不同，可以自己实践一下

→ 评审问题数：是否存在对需求理解、系统架构设计、系统设计等方面引

起争议的问题。体现出测试人员发现问题的深入层次，有利于产品质量的提高。

● 测试执行中工作效率相关指标：

→ 执行效率：利用测试用例文档页数除于此次系统测试执行的时间总和（不包含用例文档编写时间）。补充指标方法是用例的个数除于此次系统测试的时间

总和。用于获得工作中测试人员每小时执行测试的速度。

公式：∑测试用例文档页数（页）/ ∑执行系统测试的有效时间（小时）∑测试用例数（个）/ ∑执行系统测试的有效时间（小时）

参考指标：平均0.53 页 / 小时， 1.95 个用例 / 小时。即测试人员每小

时执行半页测试用例或者每小时执行 2 个测试用例。通过横向比较，容易知道那位成员的执行效率较高。注意：执行效率高的不代表测试质量也高，甚至执行效率和测试质量成反比，所以后面工作质量的指标会补充这一部分的偏离。实际

结果表明，用例执行效率高的成员，其缺陷发现率往往偏低，考核如果不将此纳

入进来也可以将其作为测试改进的一项重要数据进行收集。

→ 进度偏离度：检查计划时间和实际时间的进度，方法是计划时间差额减

去实际时间差额除于实际工时总和，用于考察测试人员进度情况，监控测试是否

按照日程进行，是否满足了工程的进度要求。

公式：∑（计划开始时间- 实际开始时间）＋∑（计划结束时间- 实际结束时间）/ 总工时

参考指标： 15 ％进度偏离是个相对的指标，可能偏离了20 个工作日，但是对于一个长达半年时间的测试而言偏离天数比上整体测试所需天数不足

15 ％，可能偏离了 3 个工作日，但是对于一个只有 1 星期时间的测试已经超

过了整个测试阶段所需天数的60 ％。

注意：计算时分子分母要保持一致，即开始或结束时间已经去除了非工作日

时间，则总工时也要去除非工作日时间。因为制定计划时是根据每个公司的工作

日来制定的，也就是说，考虑了非正常工作日的日程。

测试进度也是考核很重要的一步，如果没有进度保证，所有的测试都存在风

险，第一种方法是测试人员可以采用自下而上的方式向测试经理报告计划用时，

这种方式风险比较少，个人根据自己能力大小确定，但是缺点是存在测试人员虚

报可能性。另一种方法是测试经理进行估算后分配工作日程，这时估算是很重要

的前提，除了依赖于测试经理的经验外，对评估结果进行同行评审是很客观可取

的方法。

→ 缺陷发现率：测试人员各自发现的缺陷数总和除于各自所花费的测试时间总和。由于执行效率不能足够代表测试人员是否认真工作，那么，每小时发现

的缺陷数就是重要的考核指标，你的工作可以通过这项指标得到反馈。

公式：∑缺陷数（系统测试）（个）/ ∑执行系统测试的有效时间（小时）

参考指标：平均 1.1 个缺陷 / 小时假使有位测试人员没有达到 1 小时发现 1 个缺陷，那么，除非产品质量高、模块较小，否则，就是他的缺陷发现能

力不如其他测试人员。当然，详细分类中可以根据发现重要缺陷的多少来定义缺

陷发现能力。

● 测试执行中工作质量相关指标：

→缺陷数：为了更客观度量，考虑到 bug 的严重性、技术难度、产品类型、模块稳定性等因素影响，不是用“所发现的 bug 数量”，而是用“所获得的 bug value ( 缺陷值 )”来度量，公式被定义为：

Bug_value= （ P0_Bug_Number × 1.6 + P1_Bug_Number × 1.4 +

P2_Bug_Number × 0.7 + P3_Bug_Number ×0.3 ）× Wd × Ws × Wt 其中： P0_Bug_Number ：致命的（ fatal ）缺陷数量； P1_Bug_Number ：严重的（ critical ）缺陷数量； P2_Bug_Number ：一般的（ major/normal ）缺

陷数量； P3_Bug_Number ：次要的（ minor ）缺陷数量

Wd ：技术难度系数，如Database ， Enterprise Server ， Java 难度系数大，发现 Bug 不容易， Wd 可以定在 1.5 – 5.0

Ws ：稳定性系数，全新模块， Bug 比较多，发现缺陷比较容易；版本越高，

越稳定。Ws 可以定在 0.5 –1.0 ，假如以 version 10.0 为 1.0 ， Version 1.0 = 1/100 ， Version 2.0 = 4/10 ， Version 3.0 = 9/100 ，?，， Version 8.0

= 64/100 ， Version 8.0 = 81/100

Wt ：产品类型系数，可根据实际情况和历史数据来判断。Wt 也可以和 Wd

合并为一个系数。

→有效缺陷数 / 率：被拒绝和删除的缺陷数总和，或者被拒绝和删除的缺陷

数总和除于缺陷总数。这项指标用于考察测试人员发现的、被确认为缺陷的缺陷

数高低或者百分比，数和比率越低测试质量越高。

公式：∑缺陷数（系统测试中被拒绝和删除的）（个）

∑缺陷数（系统测试中被拒绝和删除的）（个） / ∑缺陷数（系统测试）（个）

参考指标：平均 21.9 ％（测试人员发现的每100 个缺陷中平均有22 个缺陷不被开发组确认、认为不是“缺陷”或者错误录入缺陷）。有效缺陷比率容

易给出，但是有效缺陷数具体数据要根据项目情况，无法给出可参考的数值。

注意：这项指标可能有不正确的情况，假使缺陷被拒绝和被删除的原因不是

因为测试人员误操作和需求理解等自身错误引起，而是系统本身不能实现或者数

据错误引起的，那么就要考虑剔除这部分。对于测试人员发现系统框架根本性的、初始化参数设置错误引发的、错误数据、错误环境等而开发人员因无法修正、可

以通过改变环境而无需修改程序、重新导入数据、再次发布从而拒绝或删除的缺

陷，应给予此测试人员奖励。

→ 严重缺陷率：这个比例用于弥补缺陷发现率的不足。主要是根据严重程

度分类的缺陷数比全部缺陷或者有效缺陷数。一般而言，每个公司基本把缺陷严

重程度分为严重、一般和微小，或者更细（通常等级数为奇数）。另外，可以对

缺陷严重程度进行折算（严重：一般：微小=1 ： 3 ： 5 ）通过折算可以得

出权重，然后在计算测试人员分值。

公式：∑严重 / 一般 / 微小 / ∑缺陷数

∑严重 / 一般 / 微小 / ∑有效缺陷数

参考指标：严重~10% 一般 ~70% 微小 ~20% 。当测试人员发现的缺陷中严重错误比率越高，说明测试质量相对就好，通常严重程度缺陷数的分布呈

正态分布。

→ 模块缺陷率：这个指标主要是根据一个单独测试模块的缺陷数除于模块本身

功能点数得出来的。假使一个模块是单独测试的话，很容易可以和其他模块进行指标横向对比，参照对应的测试人员，得出所测试模块的缺陷数，可以考察测试人员测试水平，也为开发考核提供数据。

公式：∑缺陷数（系统测试（个）/ 功能点（个）

∑缺陷数（系统测试（个）/ 子功能点（个）

参考指标平均 3.74 个缺陷/ 功能点 1 个缺陷/ 子功能点

注意：有些功能点没有子功能点，计算子功能点时要进行说明。

→ 遗漏缺陷率：发布后的线上故障，现阶段测试相关的故障主要都是因为

测试遗漏，有遗漏就说明我们的测试还是效率不高，可以改进。

公式：∑遗漏缺陷数/ ( ∑遗漏缺陷数 + ∑遗漏版本发现缺陷数 )

→Bug 发现的时间点， bug 曲线的收敛性，理想的效率高的模式应该是前多后少，慢慢收敛的，如果前期 bug 非常少，后期却发现大量 bug ，那我们的前期效率就有问题。

→缺陷定位和可读性：可读性内容包括 Bug 描述的规范性，分优秀、良好、普通与

不合格，描述是否清晰，问题定位的附件是否完备等。如果一个测试

人员只会通过页面将现象表达出来，而无法定位这种现象是有什么引起的，或者无法定位该缺陷到底错在何处，那么可以判定测试人员只是做了简单的表面测试，并没有对所发现问题进行分析定位。

●对技术组 (性能自动化和环境 )测试人员效率的度量：

→ 自动化测试的引入和使用是否合理，不是每个项目都适合做自动化的，

自动化并不能保证效率的提高，用 5 个小时开发的自动化脚本来替代 3 个小时的手工测试并不合算，自动化测试需要评审，按照项目的大小不同，必要的情况

下才引入自动化测试。

→ 自动化测试，特别是性能测试结束之后，我们要分析部分测试结果，测

试结果的分析水平，也可以作为衡量测试效率的一个指标。

● 对测试项目负责人的效率的度量：

→测试是否提早介入项目，例如FRD 阶段就介入，越早介入，越有利于测

试，使测试人员更加熟悉整个项目，使问题早暴露，提高整体效率。

→ 开发提交测试的时候，标准是否合理，把关是否严格，如果开发的质量

不行，坚决要退回，不然会影响测试的效率和进度。

→ 测试计划阶段，评价测试计划的合理性，包括任务细化，细化的程度是

否合理，任务顺序，资源安排，任务分配合理，风险预估等等。

→ 项目结束后，评价项目进行阶段中负责人的跟进情况，特殊情况处理，

风险触发之后的处理，资源协调，信息收集，共享，沟通，配合等等。

● 测试管理。

→ 计划质量：测试计划的评审缺陷数或比率，可以与其他同类型项目或数

据库平均指标进行对比。

∑缺陷数（评审和同行评审）（个）/ ∑测试计划文档页数（页）

→ 成本质量：成本度量主要放在工作量这块。因为无论涉及工资还是奖金，

都要和工作量挂上关系。成本质量主要是对测试活动的计划工作量总和比上实际的工作量数值总和。对测试人员考核的进度偏离已经考虑了进度因素，而工作量涉及的是成本因素。

公式：∑测试活动计划工作量（估算人日）/ ∑测试活动的实际工作量（人日）

参考指标：原则上不能偏离计划的± 15 ％～± 20 ％。实际上，这个指标是对成本的一种度量。对于一个大的项目来说，估算值往往差距非常大，阶段

统计时可能有±500 ％！！这时调整计划是很必要的，在最终阶段取考虑计算

平均估算值。一个测试经理必须对完成任务的成本进行有效控制。这两项指标是相对容易量化的部分，而需要添加其他量化指标需要综合考虑由项目经理和测试

部部门经理给出标准，例如管理用时比率（整个项目测试期间管理时间占整个项

目测试总时间）、系统整体缺陷数与其他同类型项目或数据库平均指标进行对比

等等。

● 考核具体方法：

→ 将各项指标进行汇总分析，得出总和表格，根据测试人员各项指标大小

进行排行榜制作，如列出1、2、3、4名。

→ 确定阶段涉及的权重。例如将测试设计和测试执行权重各为中，工作效率占 40 ％（即占所在阶段 20 ％），工作质量占在阶段 30 ％）。

50 ％。其60 ％（即占所

→ 确定每类指标的分值，然后每类指标达到平均标准给或者超

过根据 80 ％ ~120 ％比率给分。

100 ％，达不到→ 将比分统计出来后进行综合评定，必要的话增加一些调整系数。

→ 最好将定性分析纳入进来，采用问卷调查和项目经理评分制度给出定性

指标分数，建议这部分权重不要超过10 ％～ 15 ％以保证测试考核的可度量性。

→ 当所有考核分数给出之后，提醒一点的是，既然做了考核，就必须公开

这些结果，而且考核具有导向型，不要让考核误导了对质量工作的追求才是最重

要的。

● 考核注意事项：

→ 项目并不是一个月就能完成的，如每月进行，要考虑“可考核部分”为

那些，挑选那些指标能够横向对比，然后分阶段、分任务评定。

→ 参与测试的时间长短也要给予重视，除了上述量化指标外，测试人员整

体投入时间长短也是很重要的，加班也要作为特殊考虑因素，也许某个测试人员只参加了测试执行 3 小时，各项指标都是良好的，但是不可能给他比其他参与

时间更长的人员更多的分数。这部分就是增加调整系数的原因。

→ 测试经理的测试设计和执行部分和项目测试人员一起考核，但是测试管

理工作要单独考核，作为另外的加分，或者如文章前面所述纳入项目组给予考核。

因为测试经理在项目测试中起着管理者和质量保证负责人的角色，不要把他和其他测试工程师平等对待。

→ 考核前要考虑项目的实际情况，不要盲目的轻易承诺测试组人员考核会

和薪金或者淘汰机制挂钩，否则考核会起到反效果。

→ 作为考核者要注意以下比例，也许有些没有列入考核内容，但是如下这

些点可以指导测试。

△测试团队发现的bug 和所有 bug 之间的比例

△spec 设计造成的 bug

△重复或者误提交的 bug 所占的比例

△每周发现的 bug 的趋势图

△Bug 严重等级的构成比例

△Bug 从提交到解决的平均需要时间

△Bug 从解决到关闭的平均需要时间

项目组测试人员考核的主要目的是在于激励测试组测试人员工作，鼓励能者，鞭策落后；另外，还可以起到发现人才和查找不足的作用。考核中即要体现多劳

多得的原则，也要体现公正性和合理性原则，奖罚分明才能有效促使质量管理工作的进步。要想考核得到满意的效果，上述方法的重要的前提条件是：必须要在

项目中充分收集相关的数据，包括采集缺陷数，记录工时、提交详细工作日志和

进行文档配置管理，没有这些数据，定量分析就无从谈起，测试人员考核也无从

谈起。

3、测试人员工作度量

测试度量主要从 3 部分开展工作：一个是缺陷数据的统计分析，第二个是

工作量的统计分析，第三个是测试工作量的估算。

● 缺陷的统计分析。主要是从缺陷严重性、优先级、模块缺陷的分布、缺

陷的收敛情况、缺陷的修复情况进行统计，并根据统计结果，进行一定的分析。

● 工作量的统计分析。

→ 日常工作量的记录，这个由团队成员自己编写。在填写工作记录时，需

要为每个工作记录选择相应的任务类型，并且工作任务持续时间最长不超过 4 小时。

→ 每星期统计本周团队成员在各个项目中的投入情况。不仅让自己了清楚，也让上司了解测试部对于项目的支持情况。

→每半个月统计整个团队的工作分配情况(但是数据是每周都填写的)统计每个人在各个项目的工作量分配情况。这个和上面那个统计表的侧重点不一样，

上面这个统计表侧重在部门整体，现在这个表侧重于个体。

→定期 (如每周或半个月 )将团队成员在项目中的工作量投入情况记录到项

目工作量投入表中。这个表格主要用于统计具体每个项目的测试工作投入情况，

及作为后续测试工作量估算的原始数据。

→ 在项目到达一个阶段后，将项目测试收集的数据进行汇总、统计。收集

的数据除项目基本信息外，还包括工作量、测试投入成本、项目规模、项目总成

本、项目总工作量。主要分析测试在项目中的投入情况、成本情况、各个测试任

务的分配情况等。

● 最后，根据对几个项目的工作量、成本以及测试任务占项目总测试投入

的比例分析后，得到测试团队测试工作量估算的简易公式。可以根据这个简易的公式进行测试的估算，方便测试计划中关于工作量估算部分的编写，避免在估算

测试部门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 状态更新等

最实用的软件开发团队绩效考核制度.

软件开发团队 绩效考核制度 湖南XX科技发展有限公司

目录 1目的 (1) 2方法和原则 (1) 3适用范围 (1) 4绩效考核 (1) 5项目考核内容和各阶段考核所占权重 (1) 6项目目标调整 (2) 7项目考核内容 (2) 7.1、项目进度考核 (3) 7.2、项目质量考核 (3) 7.3、项目客户满意度考核 (4) 7.4、技术资料汇总考核 (4) 9项目成员考核 (4) 10考核中的沟通与绩效考核 (5)

1目的 为更好地完善公司项目管理和软件团队内部管理机制，保证项目的按期、高效、高质完成，促进团队和员工自身的发展，特制订本制度。 2方法和原则 1、绩效考核采用项目考核和个人考核相结合的方法，以项目考核为主，个人考核为辅。 （1）、项目考核是指以项目为单位，在项目过程中，对项目所涉及的团队的阶段工作成果进行评估；在项目完结后，对参与项目的人员进行绩效考核。 （2）、个人考核是指以团队为单位，项目负责人对其项目成员的工作业绩、工作态度、团队合作等方面进行评估。 2、项目考核采用主要采用定量的原则，个人考核主要采用定性的原则。 3适用范围 本制度适用于软件开发团队所有员工。 4绩效考核 1、项目考核，项目考核分为二级考核体制，即项目考核和项目成员考核。 （1）、项目考核：项目正式立项后，由项目经理拟定《项目目标任务单》（附件1），确定项目组在该项目中项目进度、项目质量、客户满意度和技术资料汇总目标，由项目经理和项目负责人签字确认。 相应项目按照需求分析、软件设计、程序编码、软件测试、运行维护五个阶段依据《项目进度考核表》（附件2）、《项目质量考核表》（附件3）、《项目客户满意度考核表》（附件4）和《项目技术资料汇总考核表》（附件5），对项目开发情况进行评分。 （2）、项目成员考核：项目负责人接到项目后，依据项目任务单，分配任务到本组相关员工。在该项目完结后，由成员直属上司依据《项目个人工作业绩考核表》（附件6），综合项目考核得分采取强制分布，对员工项目个人业绩进行评分。 （3）、年底进行个人年度绩效考核，综合《项目个人工作业绩考核表》（附件6）及《工作态度考核表》（附件7）、《工作能力考核表》（附件8）综合评分，由项目经理填写《年度绩效考核表》（附件9）。 5项目考核内容和各阶段考核所占权重 1、项目考核内容分为项目进度、项目质量、客户满意度和技术资料汇总四个方面，其

测试人员绩效考核详细

绩效考核 1.测试团队绩效考核 绩效评估的的客体：是个体成员还是整个团队。 ?Pascerellayer认为，团队绩效评价应以成员个人完成工作的状况为基本依据，理由是激励只能作用于个人而不是群体；技能的提高和行为的改进最终必须落实到个人。若仅考核团队绩效，个体的努力得不到充分的肯定，就容易 造成社会懒散现象，即个体由于参加团队工作，其工作效率比自己单独工作时的效率反而大大降低。此现象一旦在 组织中蔓延开来，不仅会影响组织绩效，还会毒害组织文化。同时，由于绩效考核与薪酬及个人价值的实现相联系，因此，在团队中，能力高的成员倾向于对个人绩效的考核，从而得到更高的认可和报酬。 ?Zingheim和Schuster则认为对个人的考评应考虑团队的整体绩效，因为团队的成功很大程度上依赖于团队成员间的团结合作，理解支持，若评估集中于个体层面，会导致个人主义盛行，忽视团队的协作精神，阻碍信息、技能的 共享和绩效的提高，降低团队工作的优势。 ?因此在实际操作中，企业往往采取一种折中的方法，即按一定比例兼顾团队和个人两个层面的绩效考核。从目前的研究来看，还没有一种很好的办法可以科学地确定这个比例。但是，如果从团队性质的差异、团队所处的阶段等方 面来考虑，那么至少可以确定考核的天平是更向个体的一极偏还是更向团体的一极偏。 绩效考核的内容：结果、行为还是能力。对于绩效内涵存在着三种不同的观点，即“绩效是结果”、“绩效是行为”和“绩效是能力”。Bernardin将绩效定义为“在特定的时间内，由特定的工作职能活动产生的产出记录，工作绩效的总和相当于关键和必要工作职能中等绩效的总和（或平均值）”，这是“绩效是结果”的典型观点。 Murphy等人将绩效定义为“一套与组织或个体所工作的组织单位的目标相关的行为”。近年来，以能力作为绩效的观点得到了广泛的使用，这是以评估个体所拥有的完成某项工作所具备的知识和能力的方式。伴随着这三种观点的诞生和发展，绩效考核大致经历了基于结果、基于行为以及基于能力的三个考核发展过程。虽然这三种观点相互区别，且都是在否定前者的基础之上产生的，但是，如果不带入特定的环境，特定的组织，及组织发展的特定时期，那么三者之间并不存在绝对的优劣。如果组织下达的目标非常清晰，基于结果的绩效考核是最容易实施，也最有效；相反，如果目标模糊，无法准确衡量其结果，这种考核方式就会失效。基于能力的考核方式理论上是从战略管理的角度出发，最具有激励效果和长期效应，最有利于组织不断发展，但在实际操作中却很难达到效果。因为能力是无形的，它依附于个体，既受主观因素的控制，也受各方面客观因素的影响，很难用标准化的方法衡量个体的能力，即使是方法对组织期望成员所具有的能力和特质作出了解释，但这些解释仍是描述性模糊语言，在实际操作中仍然难以做到真正的科学公正。基于行为的绩效考核方法通过考核员工为实现既定的结果所必须做出的行为来实现对结果的控制，由于行为必然是建立在某种能力基础之上的，并且行为比能力更具有外显性和可测性，因此一定程度上，该方法兼顾了组织目标和个人能力。但是，绩效考核中容易出现目标置换的现象，一味对行为测评会导致成员将行为作为目标，进而影响实际目标的实现。因此，无论哪种考核方式，都有其适用的条件和要求，不存在一种绝对好的方法。 基于项目团队生命周期的绩效考核: ?孵化诞生期: 这是指团队形成前到团队正式形成的一个阶段，是选择合适的项目成员组成团队的时期。 ?考核的客体是个人。团队的首要任务是筛选项目组成员，根据项目目标的要求，选择最为合适的人选组成团 队，所以考核的对象是个人。 ?考核的重点是能力。从项目团队成立的目的来看，它一般是为了开发一种新产品或者提供一项新的服务，因 此对成员的知识技能要求较高，需要成员具有较高的技术水平和知识储备以及不断学习和创新的能力。同时， 成立项目团队，意在发挥团队快速响应和凝聚集体智慧的优势，更加需要团队成员间的相互合作相互支持， 所以需要较为系统地考核成员的协调合作能力，包括，对团队其它成员工作任务的认识、口头交流、个人成 长、问题解决、责任承担、领导技能等等。因此，在选择项目团队成员的时候，通过对被选者专业技能、基 本素质当然也包括过去的工作经历和背景等各方面的考核，最终确定较为合适的人选。 ?成长期:这是团队正式形成之后，团队工作逐渐步入正轨，团队成员开始通过个人努力和彼此的合作共同在所研究

软件测试工程师绩效评估表

软件测试工程师绩效评估表 一．软件测试工程师职责: 1 与软件产品部配合完成软件需求分析讨论,并根据需求说明书制定《项目测试(计划) 方案》;编写《测试用例》;建立测试环境; 2 负责研发部门各开发组研发的软件产品开发过程与投入运营之前的新增软件与修改 软件的模块测试与系统测试;建立、推广并维护实施软件版本管理系统; 3 使用并维护软件缺陷管理系统mantis,负责软件问题解决过程跟踪记录,提交《mantis 报告》; 4 负责推广实施软件开发文档规范化工作,管理研发产品相关文档; 5 负责配合软件研发部门等对于新项目软件或修改升级项目软件的测试工作,并提供测 试报告; 6 负责监督软件开发流程的执行,并负责提出软件开发过程改进建议,提高软件产品质 量。 7 与开发工程师与研发部门交流报告任务进展情况,并提出最近的测试需求; 8 测试部负责制订测试计划、测试用例与测试实施方案,项目主负责人安排测试与对应 的开发人员交流完成测试执行工作;及时提交准确、完整的《项目测试报告》; 9 项目主负责人负责开发流程管理与人力资源、测试用软硬件资源调配,需要与研发之 外的部门定期交流掌握下周或近期可能测试任务; 10外部接口都由测试部主管负责完成,与其她项目组与产品部门协调项目进度; 二.软件测试的不确定性: 1 软件测试的目的就就是使软件的错误不断趋进于零,但软件的错误就是永远找不完 的; 2 开始测试时,可能软件使用1个小时就出现10个错误;测试修正后1个小时出现一个 错误,继续修正,继续测试,直到约一个月出现一个错误。这时这个出错几率已经通过终结评审可以接受了。那么测试就结束了。移植成功之后测试工作由开发部门来维护。 3 测试一些成熟的游戏或应用,测试过程中很难发现大量的缺陷;而测试一些不成熟的 游戏或应用,在测试前期,会出现大量的问题;这样就导致不同的工程师发现不同数量的bug; 4 软件测试的进度首先会按照测试计划逐步进行,但就是在测试过程中,测试进度会随研 发部门的进度而调整;所以积极的与研发部门交流、协调测试中的问题就是相当必要的。 三.测试工作最低成功标准及测试工程师考核内容: 测试工作的最终目标就就是发现客户可能发现的所有错误。如果移植测试在使用第一天就发现了您没测试出来的错误,那测试就是失败的。如果使用了很久(如几个月)才出现错误,那说明测试还就是成功的。 测试工程师考核内容:

测试绩效考核

测试绩效考核 篇一：测试人员绩效考核详细 绩效考核 1.测试团队绩效考核 绩效评估的的客体：是个体成员还是整个团队。 ?Pascerellayer认为，团队绩效评价应以成员个人完成工作的状况为基本依据，理由是激励只能作用于个人而不是群体；技能的提高和行为的改进最终必须落实到个人。若仅考核团队绩效，个体的努力得不到充分的肯定，就容易造成社会懒散现象，即个体由于参加团队工作，其工作效率比自己单独工作时的效率反而大大降低。此现象一旦在组织中蔓延开来，不仅会影响组织绩效，还会毒害组织文化。同时，由于绩效考核与薪酬及个人价值的实现相联系，因此，在团队中，能力高的成员倾向于对个人绩效的考核，从而得到更高的认可和报酬。?zingheim和Schuster则认为对个人的考评应考虑团队的整体绩效，因为团队的成功很大程度上依赖于团队成员间的团结合作，理解支持，若评估集中于个体层面，会导致个人主义盛行，忽视团队的协作精神，阻碍信息、技能的共享和绩效的提高，降低团队工作的优势。?因此在实际操作中，企业往往采取一种折中的方法，即按一定比例兼顾团队和个人两个层面的绩效考核。从目前的研究来看，还没有一种很好的办法可以科学地确定这个比例。但是，如果从团队性质的差

异、团队所处的阶段等方面来考虑，那么至少可以确定考核的天平是更向个体的一极偏还是更向团体的一极偏。 绩效考核的内容：结果、行为还是能力。对于绩效内涵存在着三种不同的观点，即“绩效是结果”、“绩效是行为”和“绩效是能力”。Bernardin 将绩效定义为“在特定的时间内，由特定的工作职能活动产生的产出记录，工作绩效的总和相当于关键和必要工作职能中等绩效的总和（或平均值）”，这是“绩效是结果”的典型观点。murphy等人将绩效定义为“一套与组织或个体所工作的组织单位的目标相关的行为”。近年来，以能力作为绩效的观点得到了广泛的使用，这是以评估个体所拥有的完成某项工作所具备的知识和能力的方式。伴随着这三种观点的诞生和发展，绩效考核大致经历了基于结果、基于行为以及基于能力的三个考核发展过程。虽然这三种观点相互区别，且都是在否定前者的基础之上产生的，但是，如果不带入特定的环境，特定的组织，及组织发展的特定时期，那么三者之间并不存在绝对的优劣。如果组织下达的目标非常清晰，基于结果的绩效考核是最容易实施，也最有效；相反，如果目标模糊，无法准确衡量其结果，这种考核方式就会失效。基于能力的考核方式理论上是从战略管理的角度出发，最具有激励效果和长期效应，最有利于组织不断发展，但在实际操作中却很难达到效果。因为能力是无形的，它依附于个体，既受主观因素的控制，也受各方面客观因素的影响，很难用标准化的方法衡量个体的能力，即使是方法对组织期望成员所具有的能力和特质作出了解释，但这些解释仍是描述性模糊语言，在实际操作中仍然难以做到真正的科

软件研发部绩效考核办法

软件研发部绩效考核方案 为加强对软件研发部门员工的技术能力、所做贡献的客观准确评价，以项目实效为导向，建立良性的技术晋升激励机制，特制订本绩效考核方案，本方案适用于软件研发部软件工程师、软件测试工程师、研发助理及质量工程师人员，具体如下： 一、岗位工资结构及绩效考核基数： 薪酬分配方式：岗位工资制。岗位工资结构：基本工资（月薪标准的50%）+岗位工资（月薪标准的30%）+绩效工资（月薪标准的20%）+交通补贴+伙食补贴+奖励考核+加班费+其他福利补贴。 绩效考核方案以绩效工资即月薪标准的20%作为考核基数，考核周期为每月进行一次考核，每月根据考核评估的总分值核算绩效工资，绩效工资核算根据考核总分值进行上下浮动， 对应绩效考核总分值兑现为月度绩效工资为： 二、绩效考核指标、考评标准、权重 将所有岗位的绩效考核指标内容分为工作业绩、工作态度、工作能力三部分，分别占有相应权重。

（二）工作态度考核关键指标（100分，权重15%）

（三）工作能力考核关键指标（100分，权重15%） （四）对项目开发和部门相关工作作出特殊贡献的给予加分的项目

对于项目开发和部门相关工作作出特殊贡献的给予加分的由部门负责人和分管副总进行评定，给予加分的需对加分项目和贡献情况进行说明，加分不得超过20分。 关键绩效考核指标总分值=工作业绩考核关键指标评分*70%+工作态度考核关键指标评分*15%+工作能力考核关键指标评分*15%+对项目开发和部门相关工作作出特殊贡献的加分。 二、其他工作指标考核内容 1、部门日常工作要求的事项完成情况考评：对其上级领导安排的工作和本岗位工作职责范围内的工作、工作态度等根据完成的时间和质量要求、工作态度好坏进行考核评定，非常优秀的可给予20-100元奖励，非常差的给予20-100元考核，此项奖励考核由部门负责人和分管副总进行评定，所有奖励考核均由分管副总审核。 2、部门所要求参与的会议/活动/培训等的参与次数及学习成果考评：公司和部门安排的会议/活动/培训要求相关人员必须参加的无特殊情况而无故不参加的给予20-50元考核，对于培训后组织的定期和不定期的培训考试，考试成绩不及格者按每次考核20-50元考核，对于以上考核属于个人特殊情况需减免考核的报请减免请示部门负责人和分管副总进行审批。 3、为了提高开发效率，积极鼓励提供好的建议，产品思路或方式方法，对于采纳的建议，如根据其执行方案对产品架构及公司发展起到明显改进效应的，将给予一定的奖励，奖励金额由分管副总和总经理进行确定。 4、产品研发项目奖励：根据产品研发项目计划，在计划进度内按质按量完成研发项目的，经测试验收合格的给予研发团队500-5000元奖励，奖励分配由该项目负责人和分管副总按照项目小组成员的贡献进行分配。 5、由公司制度对应的考核项目对其进行的奖励和考核，奖罚金额由制度所对应的管理部门依据制度条款进行确定。 6、员工个人对于部门和公司管理、产品、安装、销售等提出建议、提升、创新变革措施等/为公司生产经营做出突出贡献的，公司予以认可采纳的给予员工200-2000元奖励；同时给公司造成重大影响或损失的给予50-1000元考核，奖罚金额由总经理进行审定后确定，各部门和个人可进行奖励申请报批。 7、公司评定的优秀员工奖励：按照公司相关评定标准和奖励额度政策和通知执行。 8、其他需奖励和考核的项目：其他需进行奖励和考核的项目由奖励考核人进行提请，报由部门负责人、分管副总、总经理进行审批后确定。 三、关于绩效考核结果的反馈、申诉、处理和绩效面谈

软件测试技术与测试KPI考核体系探究

龙源期刊网 https://www.sodocs.net/doc/429569265.html, 软件测试技术与测试KPI考核体系探究 作者：魏娜娣吕晓晴霍利岭边玲武新慧 来源：《中国市场》2016年第28期 [摘要] 文章依托企业主流软件测试流程及软件测试核心技术，探究IT企业软件测试团队中现有的考核标准及规范，进而构建对接一线测试工程师岗位的KPI考核体系，并结合KPI指标及关键点，进一步优化测试知识架构，提升应用型人才培养质量及软件测试行业整体技术水平。 [关键词] 软件测试流程；KPI；考核体系；教学体系 [DOI] 10.13939/https://www.sodocs.net/doc/429569265.html,ki.zgsc.2016.28.101 1 软件测试重要性及KPI考核体系构建意义 软件测试是保证软件质量的一重要手段，其在软件生命周期中的重要性日益凸显。IT企 业对软件测试人才需求量不断增多，软件测试岗位迅速扩张。 基于软件测试人才需求旺盛的现状，推进基于KPI的多元化绩效考核体系的管理模式并在试点企业中试行和同步改进，将有助于最大限度地调动工程师的工作热情、提高效率。此外，高校软件测试人才的培养往往注重知识的提升、技术的锻炼，而易忽视综合素质的培养。据企业测试人才绩效考核体系的要求，映射到软件测试体系化教学中，进一步优化软件测试教学体系，改进教学知识与技能架构，从而提升高校人才培养及实习就业质量，校企对接更加紧密。 2 软件测试KPI考核现状及应对策略 2.1 科学管理技能尚有不足 IT企业管理层往往为技术出身，具有技术背景和深厚技术功底做支撑，但对于企业管 理、团队管理领域大多未经历过系统的学习，故在管理技能和技巧上较为欠缺。据了解，一些测试经理仅关注软件缺陷的发现与跟踪，在程序员提交完整系统后才开展测试工作，从而忽略了规范化的软件测试流程及需求评审、测试计划制订、测试用例设计、测试环境构建、测试实施、测试总结与评估等关键环节的管理与人员技能的考核，与一线岗位工作内容严重脱节。 2.2 不同岗位同标准导致KPI指标雷同 不同岗位工作内容及考查点存在差异，应依据软件测试工程师、自动化测试工程师、性能测试工程师、测试组长、测试经理等分岗位、分级别制定不同层次的考核标准。否则无法高效引导，指导各岗位履行岗位职责。

测试部绩效考核方案【最新版】

测试部绩效考核方案 考核工作事项及流程 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、及时、公正地对员工过去一段时间的工作绩效进行评估，肯定成绩，发现问题，为下一阶段工作的绩效改进做好准备。 2、为员工职业发展计划的制定和员工的薪酬待遇以及相关的教育培训提供人事信息与决策依据。 3、将人事考核转化为一种管理过程，在同方形成一个员工与公司双向沟通的平台，以增进管理效率。 三、考核原则 1、以公司与员工签订的工作任务目标及相关的管理指标，和员工实际工作中的客观事实为基本依据； 2、以员工考核制度规定的内容、程序和方法为操作准则； 3、以全面、客观、公正、公开、规范为核心考核理念。 四、适用对象 本制度适用公司副院长以下所有人员（副院长以上人员另制定考核办法），另有下列情况人员不在考核范围内： 1、试用期内,尚未转正员工 2、连续出勤不满六个月或考核前休假停职六个月以上 3、兼职、特约人员 五、考核时间安排 考核类别考核时间复核时间考核终定时间 年中考核7月2日到6日7月9日到13日7月16日 年度考核1月7日到11日1月14日到18日1月21日 六、考核办法 （1）公司的考核标准主要是从业绩和能力态度两方面考察，共分两张考评表，一张目标任务考核表，一张能力态度考核表，不同部门类的员工，目标任务考核表格式相同，但能力态度考核表会根据部门不同考评标准做相应调整。

（2）目标任务考评表根据年初制定的任务完成情况进行评价，满分100分，半年度考核时，每项任务完成50%以上认为该任务目标完成，年度考核时完成100%以上认为该任务目标完成。全部任务目标完成70%以上，得100分，完成60%-70%，得80分，完成50%-60%，得60分，完成30%-50%，得40分，完成10%-30%，得20分，10%以下，得0分。该考评表先由员工自评、再由主管领导复核，以主管领导的复核结果为准。 （3）能力态度考评表满分100分，根据所设项目进行打分，最后根据所有项目分数计算总分。该考评表由员工直接领导、分管院领导以及人力资源部领导分别打分，取平均分作为最后得分。 （4）员工最后考评得分=目标任务考评表得分*70%+能力态度考评表得分*30%。 七、考核评价 按员工考核总分，划分为“特优”、“优秀”、“中等”、“有待提高”、“急需提高”五等级，并作如下界定： 等级优秀良好中等有待提高急需提高 考核总分85分以上70-85分60-70分50-60分50分以下 八、考核申诉 1、考核申诉是为了使考核制度完善化和在考核过程中真正做到公开、公正、合理而设定的特殊程序。 2、部属与直接主管讨论考核内容和结果后，如有异议，可先向部门主管提出申诉，由部门主管进行协调；如部门主管协调后仍有异议，可向人力资源部门会提出申诉，由人力资源部门专员进行调查协调。 3、考核申诉的同时必须提供具体的事实依据。 九、考核与奖惩 1、优秀员工：奖金奖励或上调工资，有职务晋升机会时优先考虑； 2、良好员工：奖金奖励，在机会适当时，可考虑职务晋升； 3、中等员工：不作调整； 4、有待提高员工：罚款或下调工资； 5、急需提高员工：下调工资或解聘。 十、附则 1、本制度的解释权归人力资源部。 2、本制度自公布之日起执行 2

软件部绩效考核规范

软件部绩效考核方案 第一部分、考核对象 研发全体人员 第二部分、工作职责 一、项目经理 与客户方对接需求，合理分配内部资源，统筹所负责项目的整体规划，监控跟踪开发过程进度，着手解决棘手问题，并应对突发情况对项目整体计划做出调整。 二、开发人员（程序员、中级程序员、高级程序员） 根据需求文档，在项目经理的任务划分负责范围内，按效率每天完成固定功能的编码工作，并承担该部分的维护工作。 三、测试人员 按指定的文档编写测试用例，并对相关项目进行单元，集成及系统测试工作。 四、美工人员 负责直接和客户沟通UI方面的相关业务，并针对所负责项目的软件交互进行美术及交互设计,并按需切图，主要输出产物为牵引图，UI指引，拓展图，PSD原图，及切图。

第三部分、开发及测试人员的考核内容（初，中，高） 一、质量考核 1. 度量指标 质量度量主要是根据度量指标来进行评价的；质量指标是指软件开发程序缺陷率（bug的数量）。 2. 度量指标计算方法 （1）度量指标评分标准 根据软件开发程序的缺陷率（bug量）来确定，缺陷率越高，其评价分就越低。 （2）缺陷率来源 主要是软件经过测试组测试后，所产生的测试报告； ◆软件交付使用后一年内产生的软件维护记录表; ◆开发人员的缺陷率考核，主要依据测试报告和软件维 护记录； ◆测试人员的缺陷率考核，依据软件维护记录。 （3）缺陷率单位

以程序单元为单位，相比较而得出缺陷率的值（原理：缺陷数/单元总数）。这里所指的程序单元，是WBS分解后的内容。 （4）开发人员缺陷率计算方法 根据测试报告和软件维护记录中的缺陷类别，分别统 计各类别的缺陷率，然后依据度量指标的计分标准表 来打分。 错误级别发现难易开发难易缺陷数计算公式为：Total = ∑(Ci*Fi*Ki)； 缺陷率计算公式为：V = Total / U； 其中 i=1,2,...n代表每个缺陷； U代表开发人员负责的、已完成且已被测试的程序单元总数； C代表缺陷所对应的缺陷级别的权重系数；通常权重系数以"一般"缺陷 级别作为基数（权数设为1），"轻微"缺陷级别可不用计算缺陷率（权数 设为0）。 序号缺陷级别权数备注 1致命3死机，数据丢失，主要功能组完全丧失，系统悬 挂 2严重2主要功能丧失，导致严重的问题 3一般1次要功能丧失，不太严重，如提示信息不太准确 4轻微0微小的问题，对功能几乎没有影响，产品及属性

石油天然气公司操作服务人员绩效考核指导意见精修订

石油天然气公司操作服务人员绩效考核指导意 见 SANY标准化小组 #QS8QHH-HHGX8Q8-GNHHJ8-HHMHGN#

中国石油天然气公司操作服务人员绩效考核指导意见 ? 第一章第一章总则 第一条第一条为适应中国石油天然气股份有限公司（以下简称股份公司）新体制需要，有效开发和利用劳动力资源，提高队伍 整体素质，增强员工的责任、风险意识，调动员工生产（工作）积极 性，促进企业生产发展和劳动效率不断提高，根据国家有关规定和股 份公司实际，制定本指导意见。 第二条第二条本意见适用于签订一年以上有固定期限或无固定期限劳动合同，并在操作、服务岗位上工作的员工。 第三条第三条实行绩效考核应遵循的原则： （一）（一）以业绩考核为重点的原则。对操作、服务人员以完成本工种（岗位）工作中的业绩考核重点，兼顾技术业务水平和工作表 现考核，引导员工把主要精力放在完成生产（工作）任务上。 （二）（二）公平、公正、公开考核的原则。考核指标客观、科学、规范；考核方法、程序简便易行、操作性强；考核工作公开，对所 有被考核对象一视同仁；考核标准、程序、结果公开、透明，考核结果 及时向职工反馈。 （三）（三）考核结果与员工利益挂钩的原则。将考核结果与员工薪酬和续订、终止、解除劳动合同等个人实际利益挂钩，促使员工通 过考核更好地了解对其工作的评价，发扬优点，克服不足，不断提高自 身素质和业务水平。 第二章第二章考核办法 第四条第四条绩效考核的内容包括：工作业绩、技术业务水平和工作表现三个方面。工作业绩权重为60%，技术业务水平权重 为20%，工作表现权重为20%。 （一）（一）工作业绩 1、1、有具体生产（工作）任务指标的员工，主要考核工作数量、 工作质量和工作量饱满程度三个指标。工作数量可根据不同工种（岗位）特点确定考核的具体内容，如实物指标、价值指标、工时定额指标等。工作数量权重30%，工作质量权重35%，工作量饱满程度权重30%。 2、2、无具体生产（工作）任务数量、质量指标的员工（如后勤服 务人员，值班人员等），主要考核岗位职责履行情况、工作效率和工作量饱满程度三个指标。履行岗位职责情况权重40%，工作效率权重30%，工作量饱满程度30%。 （二）（二）技术业务水平 主要考核工作熟练程度、技能等级和解决问题的能力三个方面。工作熟练程度权重40%，技能等级权重30%，解决问题的能力权重30%。 （三）（三）工作表现

软件测试工程师考核标准

目标： 为了增强部门测试工程师考核的合理性、科学性，特制定本准则，根据本准则来完成对部门所有测试工程师的考核 目前部门测试团队共有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（系统崩溃）

研发测试人员绩效考核奖励细则

研发人员绩效考核奖励细则 一、考核目的 为了更好完善公司各项目管理机制，保障研发项目的按期、高效、高质完成，同时进一步促进研发部门员工自身的发展，结合研发人员的工作特点，特制定本方案。 二、适用范围 公司研发所有员工，具体包括智能硬件产品组、电商组、APP组、大数据组转正员工。（当月 15 日（含当天）前转正本月考核，15 日后转正的次月考核） 三、考核周期：月度考核 四、考核方法与原则 考核方法 采用部门考核的方法（以产品为单位，产品负责人对其下属员工的进度、质量、规范性、工作态度及能力等方面进行评估）； 考核原则 采用行为考核与结果考核相结合。 五、考核内容与评分标准（详见附件一文件《研发人员绩效考核表》） 六、考核实施 计划沟通阶段 计划实施阶段

考核阶段 考核者根据被考核者在考核期内的工作表现和考核标准，对被考核者评分，同时被考核者也需根据个人在考核期内的工作表现和考核标准进行自评。 考核者的直接上级及主管领导对考核结果进行审核，并负责处理考核评估过程中所发生的争议。 各部门每月 10 日前组织绩效面谈会议，将上月考核结果反馈给被考核者，并讨论绩效改进的方式和途径。 七、绩效工资与考核结果运用 绩效工资运用 绩效考核结果运用 绩效面谈 考核者每月5日前对被考核者上月度的工作绩效进行总结，填写附件二《绩 效考核面谈表》，并指出被考评者有待改进的地方，从而进行差距分析，确保绩效的持续改进，同时共同制定下月的绩效目标。

相关奖励 1）根据年度 12 个月的平均得分，作为员工薪资调整、职位晋升、岗位培训的决策依据。 2）连续3个月，研发人员的进度考核为满分的，当月在绩效得分中奖励加分 5 分，连续3个月，研发人员的代码质量考核为满分的，当月在绩效得分中奖励奖励 10分。 3）培训：年度绩效考核得分在 85 分（含）以上的员工，有资格享有公司安排的提升培训，年度绩效考核得分在 70 分以下的员工，可以申请相关培训，经人力行政部批准后参加。 相关处罚 1）首次月度考核得分在 59 分（含）以下的，由直属领导进行绩效面谈，对其绩效成绩进行差距分析及进行相应的培训辅导； 2）通过部门培训仍连续 2 个月绩效考核得分在 59 分（含）以下的，公司根据员工实际业绩产出给予相应的调整（降职/降薪/解除劳动合同） 员工的绩效工资发放

软件测试人员绩效考核详细

1、测试团队绩效考核 绩效评估的的客体：是个体成员还是整个团队。 ●Pascerellayer认为，团队绩效评价应以成员个人完成工作的状况为基本依据，理由是激励只能作用于个人而不是群体；技能的提高和行为的改进最终必须落实到个人。若仅考核团队绩效，个体的努力得不到充分的肯定，就容易造成社会懒散现象，即个体由于参加团队工作，其工作效率比自己单独工作时的效率反而大大降低。此现象一旦在组织中蔓延开来，不仅会影响组织绩效，还会毒害组织文化。同时，由于绩效考核与薪酬及个人价值的实现相联系，因此，在团队中，能力高的成员倾向于对个人绩效的考核，从而得到更高的认可和报酬。 ●Zingheim和Schuster则认为对个人的考评应考虑团队的整体绩效，因为团队的成功很大程度上依赖于团队成员间的团结合作，理解支持，若评估集中于个体层面，会导致个人主义盛行，忽视团队的协作精神，阻碍信息、技能的共享和绩效的提高，降低团队工作的优势。 ●因此在实际操作中，企业往往采取一种折中的方法，即按一定比例兼顾团队和个人两个层面的绩效考核。从目前的研究来看，还没有一种很好的办法可以科学地确定这个比例。但是，如果从团队性质的差异、团队所处的阶段等方面来考虑，那么至少可以确定考核的天平是更向个体的一极偏还是更向团体的一极偏。 绩效考核的内容：结果、行为还是能力。对于绩效内涵存在着三种不同的观点，即“绩效是结果”、“绩效是行为”和“绩效是能力”。Bernardin将绩效

定义为“在特定的时间内，由特定的工作职能活动产生的产出记录，工作绩效的总和相当于关键和必要工作职能中等绩效的总和（或平均值）”，这是“绩效是结果”的典型观点。Murphy等人将绩效定义为“一套与组织或个体所工作的组织单位的目标相关的行为”。近年来，以能力作为绩效的观点得到了广泛的使用，这是以评估个体所拥有的完成某项工作所具备的知识和能力的方式。伴随着这三种观点的诞生和发展，绩效考核大致经历了基于结果、基于行为以及基于能力的三个考核发展过程。？虽然这三种观点相互区别，且都是在否定前者的基础之上产生的，但是，如果不带入特定的环境，特定的组织，及组织发展的特定时期，那么三者之间并不存在绝对的优劣。如果组织下达的目标非常清晰，基于结果的绩效考核是最容易实施，也最有效；相反，如果目标模糊，无法准确衡量其结果，这种考核方式就会失效。基于能力的考核方式理论上是从战略管理的角度出发，最具有激励效果和长期效应，最有利于组织不断发展，但在实际操作中却很难达到效果。因为能力是无形的，它依附于个体，既受主观因素的控制，也受各方面客观因素的影响，很难用标准化的方法衡量个体的能力，即使是方法对组织期望成员所具有的能力和特质作出了解释，但这些解释仍是描述性模糊语言，在实际操作中仍然难以做到真正的科学公正。基于行为的绩效考核方法通过考核员工为实现既定的结果所必须做出的行为来实现对结果的控制，由于行为必然是建立在某种能力基础之上的，并且行为比能力更具有外显性和可测性，因此一定程度上，该方法兼顾了组织目标和个人能力。但是，绩效考核中容易出现目标置换的现象，一味对行为测评会导致成员将行为作为目标，进而影响实际目标的实现。因此，无论哪种考核方式，都有其适用的条件和要求，不存在一种绝对好的方法。

14-华为员工考核管理办法(附整套评分表及操作说明)

★★★机密员工考核管理办法

目录 第一章总则 (2) 第二章考核组织和管理 (2) 第三章考核程序 (4) 第四章季度考核 (8) 第五章年度考核 (10) 第六章申诉及其处理 (12) 第七章附则 (13) 附件一季度考核流程图 (14) 附件二考核评分表及填表说明 (14) 附件三考核指标评定表 (25) 附件四考核统计表 (32) 附件五考核申诉流程图和表格 (40)

第一章总则 第一条为促进公司管理现代化，建立科学的管理制度，充分发挥每位员工的积极性和创造性，结合公司实际情况，特制定本办法。 第二条适用范围 XXXA东环有限公司（以下简称公司）的所有员工均需参加考核。总经理由董事会负责考核，不在本办法考核范围之内。 公司员工分成4个职系，即管理职系、专业技术职系、行政事务职系和营销职系。 考核对象具体分为高层管理、中层管理、专业技术、行政事务、营销等各类人员。 第三条考核目的 员工考核的目的在于评价和开发。评价的目的为了正确估价员工的行为和绩效，以便适时给予奖惩，如提薪、发奖金、晋升等。开发的目的在于提高员工的素质，如更新员工知识结构与技能、激发创造力等，最终提高员工的绩效，从而有效提升公司的整体绩效。 第四条考核原则 （一）以提高员工绩效为导向； （二）定性与定量考核相结合； （三）多角度考核； （四）公平、公正、公开。 第五条考核用途 考核结果的用途主要体现在以下几个方面： （一）薪酬分配； （二）职务升降； （三）岗位调动； （四）员工培训。 第二章考核组织和管理 第六条考核周期 考核分为季度考核和年度考核。其中季度考核于各季度结束后十日内完成；年度考

软件测试人员绩效考核详细

1 、测试团队绩效考核 绩效评估的的客体：是个体成员还是整个团队。 ●Pascerellayer 认为，团队绩效评价应以成员个人完成工作的状况为基本依据，理由是激励只能作用于个人而不是群体；技能的提高和行为的改进最终必须落实到个人。若仅考 核团队绩效，个体的努力得不到充分的肯定，就容易造成社会懒散现象，即个体由于参加 团队工作，其工作效率比自己单独工作时的效率 反而大大降低。此现象一旦在组织中蔓延开来，不仅会影响组织绩效，还会毒害 组织文化。同时，由于绩效考核与薪酬及个人价值的实现相联系，因此，在团队 中，能力高的成员倾向于对个人绩效的考核，从而得到更高的认可和报酬。 ●Zingheim 和 Schuster 则认为对个人的考评应考虑团队的整体绩效，因为团队的成功很大程度上依赖于团队成员间的团结合作，理解支持，若评估集中于个体层面，会导致个人 主义盛行，忽视团队的协作精神，阻碍信息、技能的共享和绩效的提高，降低团队工作的优势。 ●因此在实际操作中，企业往往采取一种折中的方法，即按一定比例兼顾 团队和个人两个层面的绩效考核。从目前的研究来看，还没有一种很好的办法可以科学地确 定这个比例。但是，如果从团队性质的差异、团队所处的阶段等方面来考虑，那么至少可以 确定考核的天平是更向个体的一极偏还是更向团体的一极偏。 绩效考核的内容：结果、行为还是能力。对于绩效内涵存在着三种不同的观点，即“绩效是结果”、“绩效是行为”和“绩效是能力”。Bernardin 将绩效

定义为“在特定的时间内，由特定的工作职能活动产生的产出记录，工作绩效的 总和相当于关键和必要工作职能中等绩效的总和（或平均值）”，这是“绩效是 结果”的典型观点。Murphy 等人将绩效定义为“一套与组织或个体所工作的 组织单位的目标相关的行为”。近年来，以能力作为绩效的观点得到了广泛的使用，这是以评估个体所拥有的完成某项工作所具备的知识和能力的方式。伴随着 这三种观点的诞生和发展，绩效考核大致经历了基于结果、基于行为以及基于能力的三个考核发展过程。？虽然这三种观点相互区别，且都是在否定前者的基础 之上产生的，但是，如果不带入特定的环境，特定的组织，及组织发展的特定时期，那么三者之间并不存在绝对的优劣。如果组织下达的目标非常清晰，基于结果的绩效考核是最容易实施，也最有效；相反，如果目标模糊，无法准确衡量其 结果，这种考核方式就会失效。基于能力的考核方式理论上是从战略管理的角度 出发，最具有激励效果和长期效应，最有利于组织不断发展，但在实际操作中却 很难达到效果。因为能力是无形的，它依附于个体，既受主观因素的控制，也受 各方面客观因素的影响，很难用标准化的方法衡量个体的能力，即使是方法对组织期望成员所具有的能力和特质作出了解释，但这些解释仍是描述性模糊语言， 在实际操作中仍然难以做到真正的科学公正。基于行为的绩效考核方法通过考核 员工为实现既定的结果所必须做出的行为来实现对结果的控制，由于行为必然是建立在某种能力基础之上的，并且行为比能力更具有外显性和可测性，因此一定程度上，该方法兼顾了组织目标和个人能力。但是，绩效考核中容易出现目标置 换的现象，一味对行为测评会导致成员将行为作为目标，进而影响实际目标的实现。因此，无论哪种考核方式，都有其适用的条件和要求，不存在一种绝对好的 方法。