前言
寫本篇的原因很簡單，18年結束了，要給自己及其他小夥伴做下總結；
以前呢，都是自己做總結，圍繞的無非就是對團隊的貢獻，個人成長；
但是現在不一樣，需要幫小夥伴做總結，也需要為測試團隊做總結，突然覺得壓力山大，而且也要給優秀同學提名獎項；
因此，就有了本篇的內容，目的很簡單，測試崗在評績效時，到底有哪些維度？
業務測試
測試崗位的分工，粗略分為業務測試跟測試開發，兩者因崗位的不同，而要求自然也會有區別，這裡就先聊聊業務測試；
從結論而言，業務測試肯定是第一位的，是產品的基礎，因此圍繞業務會有很多衍生品，比如效能、相容性、穩定性、安全等等，儘管如此，業務測試還是最重要的；
而在業務測試過程，考查的是什麼？
- 思考問題的角度，如使用者角度、測試角度、運營角度；
- 測試基礎知識，比如目的、原則、模型、專案流程、用例設計方法、測試方法和型別；
上面提交到的測試基礎知識，這裡補一下：
| 知識點 | 說明 |
|---|---|
| 目的 | 發現程式中存在的錯誤、為反饋資訊做準備； |
| 原則 | 儘早進行軟體測試、所有的測試都要追溯到使用者需求、需要在有限的時間跟資源進行完全測試、測試是證明軟體存在問題、關注測試中叢集現象、避免測試的隨意性； |
| 模型 | V模型、W模型； |
| 流程 | 需求評審、測試計劃、用例設計、執行測試 |
| 用例設計方法 | 黑盒（等價類劃分、邊界值）、白盒（語句、判定、條件、路徑覆蓋）； |
| 測試方法和型別 | 按程式碼可見程式劃分（黑盒、白盒、灰盒）、專案流程階段劃分（單元、整合、系統、驗收測試）、按執行過程上花覅需要人工干預（手工、自動化）、其他維度（冒煙、迴歸、隨機、壓力、負載、效能） |
傳統的業務測試，從使用者角度和測試角度思考問題，價值體現在紮實的測試基礎知識、發現問題的敏感性、業務知識的專業性、業務提議的建設性。
隨著敏捷、快速迭代的興起，對業務測試的要求越來越高**，縮小問題範圍、精準定位原因，節約開發耗時**成為業務測試的另一種價值體現。
考核點
如果非要說考核，個人覺得有幾點：
- 工作質量；
- 工作效能；
- 工作積極性；
工作質量
這裡麵包括用例質量、系統質量等方面進行考核；
用例質量，可以用總有效缺陷除以用例總數，得出單位用例的缺陷檢測率，用以考核用例的質量；
系統質量，主要考察有效缺陷質量、缺陷漏測率、有效缺陷比、各級別缺陷比重等指標；
複製程式碼工作效能
主要考核測試人員整體工作效率；
主要指標包括：
- 設計效率；
- 設計覆蓋率；
- 執行效率；
- 執行覆蓋率；
- 是否在指定時間內完成工作任務（主要考察實際和計劃的偏離度）
積極性
主要考核測試人員溝通、學習等方面的能力。
- 測試過程中問題的反饋；
- 解決測試過程中出現問題的能力；
- 在專案階段測試完成後的真空期進行測試學習的能力；
- 檢視研發設計文件， 進一步瞭解需求，再進行需求分析和用例設計；
- 各種提高效率的產出，比如流程優化、過程改進、自動化、指令碼、工具等；
- 主動學習測試理論或相關技術；
特別注意
這裡特別說明，不能用bug數量來做kpi，因為不同同學分工不同，產品功能都不一樣，什麼bug數量，bug嚴重度，設計，執行，維護用例的數目都不是合適的考核指標。
另外，如果遇到一個能力差的研發，那kpi絕對是第一的，變相的，測試就希望研發的能力越差越好，同時，亂報Bug的情況會增加，最後可能會影響專案進度；
最終產物
整理下，如下圖，bug數個人不贊成，但實際有不少公司都是有這個指標的，因此還是列出來的，建議不要使用；
站在更高點的角度，就變成這樣：
測試開發
業務測試因為有明確的業務方需求，因為工作成果度量是很明確的，那測試開發崗呢？
首先要明確一個概念，測試開發崗核心是提高內部效率，如開發各種平臺，讓資料更清晰、能讓專案各角色更順暢的交付；
測試開發的客戶是內部團隊，因此必須懂/熟悉業務，知道團隊痛點，具備測試跟開發的思維，不然，不為業務服務的工具都是虛的；
節省時間
某同學A每天要花2小時做一件事，如果把這件事工具化，那就能節省該同學2小時，如果有10個同學也需要做這事，那麼這工具就節省了20個小時了；
這個時間怎麼算？常規的做法就是次數 * 耗時；
眼看這個維度是很合理的，jb也嘗試過一段時間，但是最後會發現一個問題，就是這個指標不好度量，還是上面的例子，同學A的2個小時空閒出來了，還是就需要做其他事情了，其他事情可能會導致他更加忙了，那從專案的角度，比原來更忙了，哪裡算效率提升了，久而久之，大家都覺得這個指標不靠譜了；
另外，工具的推動，也是極其困難的，做工具跟做產品是一樣的，都是一邊迭代一邊優化，如果沒有使用者，這個工具就成了一句空話了；
如何吸引更多的使用者？就需要去推動，花更多的時間在寫文件上、培訓，試點等一系列操作；
次數
一個好的工具，只要能真的解決問題，肯定會有使用者，而且會經常使用，站在這個角度，用次數來做指標，是一個方向；
各種成本
如果這個工具能帶來收益，或者減少支援，比如原來用的是收費第三方應用，現在是用內部的，這部分費用就節省下來了，也是一個指標；
其他
除了次數，還有很多指標：
- 問題發現數，如自動化；
- 工具\平臺穩定性；
- 口碑；
- 需求數；
- 使用情況；
小結
好了，說到這裡，也差不多了，簡單總結下指標吧；
對於業務測試：
- 工作質量；
- 工作效能；
- 工作積極性；
對於測試開發：
- 節省時間；
- 使用次數；
- 問題發現數，如自動化；
- 工具\平臺穩定性；
- 口碑；
- 需求數；
- 使用情況；
就這樣吧，謝謝大家~