测试人员的KPI，这个梗究竟如何破？

在 从PDD薅羊毛事件想到DevOps那些事 文章中有一同学留言：

“关于测试人员的KPI这块，这在行业上一直都是个梗，难解...”, 

的确感到这是一个问题，答应为此写篇文章来回答这个问题。

 

测试人员的KPI是一硬梗，

似乎无解，就像软件工程没有银弹

感觉自己没必要掉进这个坑里；

测试人员的KPI也要取决每个公司：

如何看待测试、测试人员

有上下文，case by case；

如果真正想破掉这个梗，

需要走进企业，深入调查分析

了解公司想要什么，就选择衡量什么；

而且需要系统地定义度量体系，

如同我《全程软件测试(第3版)》，

在第14.2小节，用了14页来介绍测试过程的度量指标。

KPI是一把双刃剑

定义了正确的KPI，能够提高大家的工作效率

定义错误的KPI，就会有错误的导向作用，

成也KPI，败也KPI，

甚至有人说，正是KPI毁了Sony。

所以不少优秀公司选了OKR（目标与关键成果法）

废话少说，进入正题。

KPI 是Key Performance Indicator的缩写，即关键绩效指标，

用于衡量或管理员工绩效的工具，

并与公司的战略目标挂钩、联系起来。

如果将KPI用于软件测试人员的绩效衡量，自然会取决于：

• 特定的公司所定义的关键商业目标；

• 其对质量的认识，特别是对“质量起什么作用”的认识；

• 对软件测试的态度、理解的程度

所以，不同的公司对测试人员绩效考核的KPI自然不一样，

仅仅看到用例数或缺陷数肯定是片面的，

仅仅看到测试自动化成果也是片面的。

真正有优秀的质量文化的公司可能不需要针对测试人员的特定KPI，

而是针对整个研发团队设立KPI。

而没有良好的质量文化的公司即使实施了质量相关的KPI，

也不一定有良好的效果。

在这篇文章后面的另一段留言，让人印象深刻，算是佐证：

“经常在想，一个做质量相关工作的人本身的所做所为却没有质量可言，真是有点讽刺。还在注重需求分析，认真做测试设计的人其实离本质最近。但是这么做却没有一点现实层面的好处。唯有一种良知，一种自我价值的实现，一种理想主义在苦苦支撑。也许无数次想投奔另一个阵营，但始终没有说服自己。”

注重需求分析、认真做测试设计的人其实离本质最近，

应该会带来良好的效果，能被衡量出来，

即使这种衡量不是直接的。

 

如果真要用KPI衡量测试人员的绩效，如何定义呢？

可以不考虑那些通用的KPI指标，如：

发扬公司企业文化、创造价值、创新、

协作、知识分享、提升团队凝聚力、

培养新人、服务客户、个人发展潜力等等

而只考虑测试工作自身的数量、质量和效率

暂时也不考虑权重、优先级等，

毕竟那是一个系统的工程，需要几个月的时间才能做出来。

这里只能偷懒，简单列出度量的指标，让你们各取所需。

而且如果真正这样去衡量测试人员的KPI，

那些实实在在做事的人不会被委屈，而是能得到肯定。

 

1. 测试的质量

• 客户满意度

• 上线后出现的缺陷数所占比例（按级别）

• 所设计的测试（用例）的覆盖率（看做了什么类型的测试、对覆盖率的理解和要求）

• 需求、设计评审漏掉的问题或比例

• 无效用例/脚本百分比

• 用例或脚本执行的稳定性

• 被拒绝或延期的缺陷(误报)百分比

• 重复的错误

• 违背流程或规范的次数

• 质量改进速度

 

2. 测试的数量

• 评审了多少需求（文档、用户故事）

• 测试覆盖了多少需求点

• 评审了多少设计

• 评审了多少代码（含工具静态分析）

• 设计了多少测试（用例）

• 开发了多少自动化测试脚本

• 执行了多少测试（用例）

• 报告了多少缺陷

• 每天在测试上花了多少时间

• 数量增长率

 

3. 测试的有效性和效率

• 缺陷数/百个测试用例数

• 缺陷数/脚本KLOC

• man-hour/功能点（或用户故事）

• 自动化测试百分比

• 缺陷存活时间

• 测试预算或投入占整个研发比重（适合团队）

• 回归测试所占比重

• 每天发现的缺陷数

• 每天设计的测试用例

• 每天开发的脚本行数

• 有效性提高速度

• 效率提高速度

 

4. 有哪些突出的成绩或事件

• 测试专利申请或被批准数

• 产品特性较大改进的建议被采纳

• 测试过程较大改进的建议被采纳

• 克服了某个测试难题

• 克服了某个测试瓶颈

• 一种新的且有效的测试策略

• 一种新的且有效的测试方法

• 发现新的缺陷模式（故障模式）

• 提出并设计了一款测试工具

• 开发实现了一款测试工具

• 解决了某种测试过程或结果的度量

• ......

（看完这些KPI，测试开发在里面只是其中几项，并不是很突出）