测试人员的绩效考核，看看你有哪些没作好

　　在项目中，测试人员考核每每成为项目经理和测试经理的一个难题，怎样评估测试人员的工做？怎样定义测试质量的差异？本文经过从事测试工做多年中对不一样项目的数据收集和网上有限资料的参考分析，思考总结出一套可行的方法，在此提供给你们。

       长期以来，如何考核测试人员的工做是富有争论的话题， 一个理想化的方法是收集测试阶段以后项目阶段的缺陷来肯定系统测试的质量。可是，这种方法的不可操做性在于：一是维护和实施阶段的缺陷难于收集；二是缺陷贯穿产品的整个使用周期，没法穷尽，难于将时间段分割开来比较；三是成本过于庞大，时间跨度过长，起不到有效激励的做用。能不能就在项目过程当中寻找能够评价测试人员工做的方法呢？就这这个思路，本人摸索出一套有效的办法。

 　　首先声明的是，第一，这套考核方发在一个功能点估算超过 10000 个的项目中通过实践，可是对于小项目而言，可能缺乏足够的数据和必要性；第二，项目组内考核的成功不能意味着在测试部门内能够采用相似的考核方法，仅提供一种参考方法，部门考核可能更多考虑投入工程的工做量大小和任务分配重要性；第三，除了量化指标外，测试人员工做态度、工做能动性和技术学习意愿要经过定性分析来获得。

　　项目组测试人员考核主要包括工做效率和工做质量两大块，工做效率用于考察活动，而工做质量用于考察产出物质量。因为考核基于测试过程进行，所以必须在过程结束以后才能进行。固然，因为工程是分布提交测试的，每个月能够根据实际状况进行月考核，工程结束后或任务结束后在统一考核。按照传统测试周期，测试过程分为：测试计划、测试设计和测试执行三个方面进行。测试计划属于测试经理的范畴，在最后讨论。测试人员主要是测试设计和测试执行，测试经理的考核可包含在测试人员的考核内，固然，这部分考核也能够归入项目组中进行。考核指标以下：

 

一 测试设计

 

工做效率相关指标

文档产出率 这项指标值主要为测试用例文档页数除于编写文档的有效时间得到。用于考察测试人员测试用例文档的生产率大小。

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

　　参考指标：根据项目汇总得出平均在 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 个缺陷，那么，除非产品质量高、模块较小，不然，就是他的缺陷发现能力不如其余测试人员。固然，详细分类中能够根据发现重要缺陷的多少来定义缺陷发现能力。

 

工做质量相关指标

 有效缺陷数 / 率 被拒绝和删除的缺陷数总和，或者被拒绝和删除的缺陷数总和除于缺陷总数。这项指标用于考察测试人员发现的、被确认为缺陷的缺陷数高低或者百分比，数和比率越低测试质量越高。

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

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

 　　参考指标：平均 21.9 ％（测试人员发现的每 100 个缺陷中平均有 22 个缺陷不被开发组确认、认为不是“缺陷”或者错误录入缺陷）。有效缺陷比率容易给出，可是有效缺陷数具体数据要根据项目状况，没法给出可参考的数值。

 注意：这项指标可能有不正确的状况，假使缺陷被拒绝和被删除的缘由不是由于测试人员误操做和需求理解等自身错误引发，而是系统自己不能实现或者数据错误引发的，那么就要考虑剔除这部分。对于测试人员发现系统框架根本性的、初始化参数设置错误引起的、错误数据、错误环境等而开发人员因没法修正、能够经过改变环境而无需修改程序、从新导入数据、再次发布从而拒绝或删除的缺陷，应给予此测试人员奖励。

 

严重缺陷率 这个比例用于弥补缺陷发现率的不足。主要是根据严重程度分类的缺陷数比所有缺陷或者有效缺陷数。通常而言，每一个公司基本把缺陷严重程度分为严重、通常和微小，或者更细（一般等级数为奇数）。另外，能够对缺陷严重程度进行折算（严重：通常：微小 =1 ： 3 ： 5 ）经过折算能够得出权重，而后在计算测试人员分值，在此不冗述

 公式：∑严重 / 通常 / 微小 / ∑缺陷数

 ∑严重 / 通常 / 微小 / ∑有效缺陷数

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

 模块缺陷率 这个指标主要是根据一个单独测试模块的缺陷数除于模块自己功能点数得出来的。假使一个模块是单独测试的话，很容易能够和其余模块进行指标横向对比，参照对应的测试人员，得出所测试模块的缺陷数，能够考察测试人员测试水平，也为开发考核提供数据。

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

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

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

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

 

三 测试管理

 开头提到对测试经理的考核就复杂一些，除了测试经理参与测试设计和执行外，还要考察他的测试管理能力，即测试计划阶段工做，其中

 计划质量 测试计划的评审缺陷数或比率，能够与其余同类型项目或数据库平均指标进行对比。

 公式：∑缺陷数（评审和同行评审）（个）

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

 

成本质量 成本度量主要放在工做量这块。由于不管涉及工资仍是奖金，都要和工做量挂上关系。成本质量主要是对测试活动的计划工做量总和比上实际的工做量数值总和。对测试人员考核的进度偏离已经考虑了进度因素，而工做量涉及的是成本因素。

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

 　　参考指标：原则上不能偏离计划的 ± 15 ％～ ± 20 ％。实际上，这个指标是对成本的一种度量。对于一个大的项目来讲，估算值每每差距很是大，阶段统计时可能有± 500 ％！！这时调整计划是很必要的，在最终阶段取考虑计算平均估算值。一个测试经理必须对完成任务的成本进行有效控制。

 这两项指标是相对容易量化的部分，而须要添加其余量化指标须要综合考虑由项目经理和测试部部门经理给出标准，例如管理用时比率（整个项目测试期间管理时间占整个项目测试总时间）、系统总体缺陷数与其余同类型项目或数据库平均指标进行对比等等。

 

考核具体方法：

  1 ．将各项指标进行汇总分析，得出总和表格，根据测试人员各项指标大小进行排行榜制做，如列出 1 、 2 、 3 、 4 名。

 2 ．肯定阶段涉及的权重。例如将测试设计和测试执行权重各为 50 ％。其中，工做效率占 40 ％（即占所在阶段 20 ％），工做质量占 60 ％（即占所在阶段 30 ％）。

 3 ．肯定每类指标的分值，而后每类指标达到平均标准给 100 ％，达不到或者超过根据 80 ％ ~120 ％比率给分

 4 ．将比分统计出来后进行综合评定，必要的话增长一些调整系数。

 5 ．最好将定性分析归入进来，采用问卷调查和项目经理评分制度给出定性指标分数，建议这部分权重不要超过 10 ％～ 15 ％以保证测试考核的可度量性。

 当全部考核分数给出以后，提醒一点的是，既然作了考核，就必须公开这些结果，并且考核具备导向型，不要让考核误导了对质量工做的追求才是最重要的。

 

考核注意事项：

 

1 ．项目并非一个月就能完成的，如每个月进行，要考虑“可考核部分”为那些，挑选那些指标可以横向对比，而后分阶段、分任务评定。

 2 ．参与测试的时间长短也要给予重视，除了上述量化指标外，测试人员总体投入时间长短也是很重要的，加班也要做为特殊考虑因素，也许某个测试人员只参加了测试执行 3 小时，各项指标都是良好的，可是不可能给他比其余参与时间更长的人员更多的分数。这部分就是增长调整系数的缘由。

 3 ．测试经理的测试设计和执行部分和项目测试人员一块儿考核，可是测试管理工做要单独考核，做为另外的加分，或者如文章前面所述归入项目组给予考核。由于测试经理在项目测试中起着管理者和质量保证负责人的角色，不要把他和其余测试工程师平等对待。

 4 ．考核前要考虑项目的实际状况，不要盲目的轻易承诺测试组人员考核会和薪金或者淘汰机制挂钩，不然考核会起到反效果。

 

项目组测试人员考核的主要目的是在于激励测试组测试人员工做，鼓励能者，鞭策落后；另外，还能够起到发现人才和查找不足的做用。考核中即要体现多劳多得的原则，也要体现公正性和合理性原则，奖罚分明才能有效促使质量管理工做的进步。要想考核获得满意的效果，上述方法的重要的前提条件是：必需要在项目中充分收集相关的数据，包括采集缺陷数，记录工时、提交详细工做日志和进行文档配置管理，没有这些数据，定量分析就无从谈起，测试人员考核也无从谈起。

不懂技术的管理不是好管理，附上接口测试相关资料供阅：

连接：https://pan.baidu.com/s/1R1gIyktM2CqTSlZSnUppWQ 提取码：rn4z