在 從PDD薅羊毛事件想到DevOps那些事 文章中有一同學(xué)留言：

“關(guān)于測試人員的KPI這塊，這在行業(yè)上一直都是個梗，難解...”, 

的確感到這是一個問題，答應(yīng)為此寫篇文章來回答這個問題。

測試人員的KPI是一硬梗，

似乎無解，就像軟件工程沒有銀彈

感覺自己沒必要掉進這個坑里；

測試人員的KPI也要取決每個公司：

如何看待測試、測試人員

有上下文，case by case；

如果真正想破掉這個梗，

需要走進企業(yè)，深入調(diào)查分析

了解公司想要什么，就選擇衡量什么；

而且需要系統(tǒng)地定義度量體系，

如同我《全程軟件測試(第3版)》，

在第14.2小節(jié)，用了14頁來介紹測試過程的度量指標(biāo)。

KPI是一把雙刃劍

定義了正確的KPI，能夠提高大家的工作效率

定義錯誤的KPI，就會有錯誤的導(dǎo)向作用，

成也KPI，敗也KPI，

甚至有人說，正是KPI毀了Sony。

所以不少優(yōu)秀公司選了OKR（目標(biāo)與關(guān)鍵成果法）

廢話少說，進入正題。

KPI 是Key Performance Indicator的縮寫，即關(guān)鍵績效指標(biāo)，

用于衡量或管理員工績效的工具，

并與公司的戰(zhàn)略目標(biāo)掛鉤、聯(lián)系起來。

如果將KPI用于軟件測試人員的績效衡量，自然會取決于：

• 特定的公司所定義的關(guān)鍵商業(yè)目標(biāo)；

• 其對質(zhì)量的認(rèn)識，特別是對“質(zhì)量起什么作用”的認(rèn)識；

• 對軟件測試的態(tài)度、理解的程度

所以，不同的公司對測試人員績效考核的KPI自然不一樣，

僅僅看到用例數(shù)或缺陷數(shù)肯定是片面的，

僅僅看到測試自動化成果也是片面的。

真正有優(yōu)秀的質(zhì)量文化的公司可能不需要針對測試人員的特定KPI，

而是針對整個研發(fā)團隊設(shè)立KPI。

而沒有良好的質(zhì)量文化的公司即使實施了質(zhì)量相關(guān)的KPI，

也不一定有良好的效果。

在這篇文章后面的另一段留言，讓人印象深刻，算是佐證：

“經(jīng)常在想，一個做質(zhì)量相關(guān)工作的人本身的所做所為卻沒有質(zhì)量可言，真是有點諷刺。還在注重需求分析，認(rèn)真做測試設(shè)計的人其實離本質(zhì)最近。但是這么做卻沒有一點現(xiàn)實層面的好處。唯有一種良知，一種自我價值的實現(xiàn)，一種理想主義在苦苦支撐。也許無數(shù)次想投奔另一個陣營，但始終沒有說服自己?！?/span>

注重需求分析、認(rèn)真做測試設(shè)計的人其實離本質(zhì)最近，

應(yīng)該會帶來良好的效果，能被衡量出來，

即使這種衡量不是直接的。

如果真要用KPI衡量測試人員的績效，如何定義呢？

可以不考慮那些通用的KPI指標(biāo)，如：

發(fā)揚公司企業(yè)文化、創(chuàng)造價值、創(chuàng)新、

協(xié)作、知識分享、提升團隊凝聚力、

培養(yǎng)新人、服務(wù)客戶、個人發(fā)展?jié)摿Φ鹊?/span>

而只考慮測試工作自身的數(shù)量、質(zhì)量和效率

暫時也不考慮權(quán)重、優(yōu)先級等，

畢竟那是一個系統(tǒng)的工程，需要幾個月的時間才能做出來。

這里只能偷懶，簡單列出度量的指標(biāo)，讓你們各取所需。

而且如果真正這樣去衡量測試人員的KPI，

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

1. 測試的質(zhì)量

• 客戶滿意度

• 上線后出現(xiàn)的缺陷數(shù)所占比例（按級別）

• 所設(shè)計的測試（用例）的覆蓋率（看做了什么類型的測試、對覆蓋率的理解和要求）

• 需求、設(shè)計評審漏掉的問題或比例

• 無效用例/腳本百分比

• 用例或腳本執(zhí)行的穩(wěn)定性

• 被拒絕或延期的缺陷(誤報)百分比

• 重復(fù)的錯誤

• 違背流程或規(guī)范的次數(shù)
  

• 質(zhì)量改進速度
  

2. 測試的數(shù)量

• 評審了多少需求（文檔、用戶故事）

• 測試覆蓋了多少需求點

• 評審了多少設(shè)計

• 評審了多少代碼（含工具靜態(tài)分析）

• 設(shè)計了多少測試（用例）

• 開發(fā)了多少自動化測試腳本

• 執(zhí)行了多少測試（用例）

• 報告了多少缺陷
  

• 每天在測試上花了多少時間

• 數(shù)量增長率

3. 測試的有效性和效率

• 缺陷數(shù)/百個測試用例數(shù)

• 缺陷數(shù)/腳本KLOC

• man-hour/功能點（或用戶故事）

• 自動化測試百分比

• 缺陷存活時間
  

• 測試預(yù)算或投入占整個研發(fā)比重（適合團隊）
  

• 回歸測試所占比重
  

• 每天發(fā)現(xiàn)的缺陷數(shù)

• 每天設(shè)計的測試用例

• 每天開發(fā)的腳本行數(shù)

• 有效性提高速度

• 效率提高速度

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

• 測試專利申請或被批準(zhǔn)數(shù)

• 產(chǎn)品特性較大改進的建議被采納

• 測試過程較大改進的建議被采納

• 克服了某個測試難題

• 克服了某個測試瓶頸

• 一種新的且有效的測試策略

• 一種新的且有效的測試方法

• 發(fā)現(xiàn)新的缺陷模式（故障模式）
  

• 提出并設(shè)計了一款測試工具

• 開發(fā)實現(xiàn)了一款測試工具

• 解決了某種測試過程或結(jié)果的度量

• ......

（看完這些KPI，測試開發(fā)在里面只是其中幾項，并不是很突出）

如果你還覺得沒破這個梗，需要付費，

邀請作者專門去實地調(diào)查研究

制定方案，徹底破這個梗