看完點個贊唄，難道想白嫖不成？更多內容請訪問微信公眾號 ：三國測，掃碼關注喲！
原文鏈接：http://www.cnblogs.com/zishi/p/6856204.html
眾所周知，在IT行業中技術人員的KPI考評一直是比較模糊的，尤其測試人員，更遑論自動化測試人員這個更細化的分支。
為了橫向比較自動化測試人員的工作量，也同時衡量自動化測試的工作效率和質量，我們團隊根據各個自動化隊員的反饋和綜合，對設計和維護工作加入了考評系統，綜合整理出目前這套的自動化考評原則。
KPI分為四個方面，Workload、Quality、Difficulty和Urgent task，下面是詳細解釋：
基礎工作量Workload Score：
工作量在case任務創建的時候就會划分出來，根據每個case可能花費的開發時間和優先級會定一個工作量數值（0.1~1之間），舉個例子，常規測試的case優先級最高工作量也最大，每個算 1分，以此類推，以下是詳細的表格：
|
|
UI |
API |
Design |
APP&H5 |
| P1 |
1 |
0.1 |
0.1 |
1 |
| P2 |
0.3 |
0.1 |
0.1 |
0.3 |
質量維度Quality Score：
字面理解就是上傳case的代碼質量，每個上傳的case我們都會有review, 然后根據實際代碼質量會有一個質量系數，系數如下：
| High |
Middle |
Low |
| 1.2 |
1 |
0.8 |
難度維度Difficulty Score：
因為case的難易程度差別很大，因此在任務發布的時候會有一個難易度的說明，最終分值就是 Priority * Quality* Difficulty
| Hard |
Middle |
Easy |
| 1.5 |
1 |
0.5 |
舉例說明，小明選擇了難度系數為1的任務，包含一個P2用例，代碼review之后得到質量為1.2的評價，那么最終分值就是 1*0.3*1.2 = 0.36
在進行KPI考評的時候，就可以按照個人得分進行排序，一目了然。
臨時任務Urgent task Score：
臨時性的任務，顧名思義是不定期發布的，比如項目變更引起的用例維護、框架代碼調整等等。
最后關於任務發布：
任務原則上是每兩周發布一次，原則上是個人自由認領，不過也會有個人專屬任務，所以認領的時候還是要先看清楚。任務期限內如果由於個人原因無法完成的，任務會收回重新分配。
作者原創技術文章，轉載請注明出處
看完點個贊唄，難道想白嫖不成？更多內容請訪問微信公眾號 ：三國測，掃碼關注喲！