为了更方便、真实的与大家探讨考核的内容，下面给大家列举一个之前做的绩效考核表作为参考，如表10-1和表10-2所示。

大家可以看到，在以上的绩效考核案例中，我没有把Bug数作为衡量标准来评价一个工程师是否优秀，因为这种评估方式往往起到反向效果。在进行绩效考核时，发现Bug的数量只能作为一个人参考，而Bug的质量才是真正要思考的。例如，一个人发现了50个Bug（但是无效Bug有30个，低级别的Bug有15个），这恰恰只能说明这个人在认真工作，却不能反映出这个人的技能水平。这样非但没有提高测试效率，反而增加了工作量。开发人员为了达到效率而费尽心机去完成代码编写，测试人员更是大多数时间浪费在浅显简单的Bug和提交Bug上面，而更重要、更有意义的工作却没有做，如测试计划编写、用例的编写和完善，日常测试工作的安排等。因为站在不同的角度，处于被不同的环境，对于问题的理解也不同，所以我们要多方面进行考核，如考核工作内容、擅长域和创新等。

下面介绍一下上面绩效考核的设计原则。

1、测试任务

测试任务是测试人员日常的工作，考核的内容包括一下几项。

（1）测试资料的质量。如测试计划、方案、用例和测试报告编写的质量和评审等。

（2）Bug的质量，主要评估提交的Bug描述是否准确可复现，发现Bug的严重程度是否高级。

（3）测试相关资源准备情况，如缺陷库、测试库以及测试环境，有没有在项目需要之前准备完毕。

2、擅长域

擅长域，顾名思义，即是一个人擅长的技能。擅长域与员工自身的职业规划相关，也与企业的战略目标息息相关。例如，小李的职业规划是往自动化测试方向发展，在填写擅长域时，往往与自动化测试工作相关，如使用自动化测试工具，提高工作效率等；小王职业规划是做性能测试工作，那么在填写擅长域时，则与性能测试相关的工作有关。用这种方式，不仅提高了员工的积极性，给了他们实现职业目标的机会，也给企业带来了很大的利益，因为让一个人做自己喜欢做的事情，效率永远最高。

3、创新能力

随着互联网的发展，技术也在不断的更新换代在很多情况下需要引进一些新技术核心知识，只有不断地创新，接受新知识，才能更好地提高测试团队的整体水平。

4、加分项

加分项包括工作量和测试用例复用率。

在工作中，多少会有一些临时项目或紧急任务。在这种情况下，如何去衡量工作量，主要都是通过一些紧急任务的完成情况来衡量，这种情况也能锻炼测试人员处理紧急项目的能力和技能水平。

在整个测试工作中，大部分时间都用来设计测试计划、方案或者测试用例，测试执行的时间占很少。测试用例复用可以节省更多的时间去完善测试案例的设计，提高工作效率。

5、工作态度

测试人员的考核绩效是在整个企业的绩效考核之下完成的，一个人的工作态度、规章制度执行情况，创新力和培养他人的能力息息相关。

工作态度主要考核敬业精神、责任心、主动性，团队协作、技能水平、学习培训意识和他领导满意度。

规章制度执行主要包括保密意识和成本意识。

目的：以软件最终质量的结果驱动开发过程的管理。

1、 需求满足度

计算方法：需求满意度 = 项目周期内满足的需求数 ÷ 项目周期内提交的软件需求数

评估方法：从用户的体验角度依据定稿的需求说明书内容进行评估（产品验收评估）

不合格定义：检测过程发现软件不具备需求说明书规定的功能或者质量要求

指标：需求满足度 = 100%

2、 缺陷关闭率

计算方法：缺陷关闭率 = 项目周期内实际缺陷解决数÷（项目周期内发现的新缺陷 + 计划关闭的缺陷数）

指标：

4-5级严重缺陷关闭率 100%

2-3级一般缺陷关闭率 80%

1级次要缺陷关闭率 不设指标

3、 缺陷关闭周期

计算方法：缺陷关闭周期 = AVG（实际缺陷关闭时间 – 缺陷发现时间）（天）

指标：

严重缺陷关闭周期 按周统计变化趋势，不设指标

一般缺陷关闭周期 按周统计变化趋势，不设指标

4、 【缺陷密度】项目需求平均缺陷发现率

计算方法：项目需求平均缺陷发现率 = 该项目缺陷数÷用例行数 × 100行

单位：XXX个/百行

指标：缺陷密度= 95%

1-3级缺陷发现率 不设指标

TRW公司 (汽车，航空) 软件度量指标 (部分)

•返工积压 未完成的返工代码行数/源代码总行数

•返工稳定性 总返工代码行数一已返工代码总行数

•返工比率 返工代码行数/源代码总行数

MIL/SOFTQUAL美军标软件质量评估

•吞吐量

•响应时间

•存储利用率

•缺陷密度

•错误平均间隔时间

•计算精度

•直接访问效率

•有效通信带宽

AT&T和 Bellcore

•内部发现的累计故障密度

•客户发现的累计故障密度

•发现的严重故障总数

*关闭严重故障的平均时间

•严重故障仍然开放的时间

•领域总修改

微软公司

•缺陷总数

•每个例程的缺陷数

*每千行代码中的平均缺陷数

•平均故障时间间隔

•编译器检测出的错误数量

缺陷数据与缺陷属性的函数。

如缺陷状态分布情况，缺陷严重性分布情况，缺陷模块分布情况等。

还有缺陷产生原因分布情况，缺陷关闭方式分布情况。

一般是饼图，每种情况的百分比以及缺陷数。

用处：可以评估开发所做的努力，判断测试完成标准。

按各种状态将缺陷计数作为时间的函数显示。

趋势报告可以是累计的，也可以是非累计的。

X轴：时间

Y轴：新建的bug数，关闭的bug数

展示一个bug处于某个状态的时间长短，比如new，open，resolved等等状态。

从而了解处理这些缺陷的时间进度情况。

缺陷密度 = 缺陷数量 / 软件规模

潜在缺陷概数 = (100% - 发布前缺陷去处率) * 缺陷密度

平均失效时间 = 软件持续运行时间 / 缺陷数量

缺陷检出率 = 某阶段当时发现的缺陷 / 属该阶段的全部缺陷 * 100%

发布前缺陷去处率 = 发布前发现的缺陷 / (发布前发现的缺陷 + 软件运行的前3个月发现的缺陷)* 100%

缺陷修正率 = 修复过程中未引发其他问题的缺陷数 / 被修复缺陷的总数 *100%

平均修复时间 = ∑缺陷修复时间 / 缺陷数量

平均修复成本 = 开发人员的平均人力成本 * 平均修复时间

相对返工成本 = 返工的工作量 / 项目总工作量 *100%

1）测试活动尽量提前，通过及时消除开发前期阶段引入的缺陷，防止这些缺陷遗留并放大到后续环节。

2）通过对已有缺陷进行分析，找出产生这些缺陷的技术上的不足和流程上的不足，通过对这些不足进行改进，防止类似缺陷再次发生。

工作内容和质量-考核标准1

工作内容和质量-考核标准2

工作内容和质量-考核标准3

工作效率考核

素质能力考核

加减分项

模板仅供参考

对于工作多年的测试同学而言，KPI考核这肯定再熟悉不过了。

有些公司一年一次，我们公司半年一次，一年两次。

这里我分享下我认为的考核要点。

1、这半年内，你的测试工作是否按流程规范执行。并进行简单描述。

2、这半年内的工作成果展示：具体做了那些事，高度总结。

3、整体上线产品质量如何？这点很重要。

4、日常工作中是否积极主动做好本职工作，推进项目进度。

5、项目和测试组内，团队合作能力如何？

6、工作过程中，个人做了哪些突出业绩的事情。比如个人某方面技能提升后，大幅度提高了产品质量和测试效率，降低了人工成本。

大概就从这几个方面入手，能量化的尽量用数据支撑