前言

寫本篇的原因很簡單，18年結(jié)束了，要給自己及其他小伙伴做下總結(jié)；

以前呢，都是自己做總結(jié)，圍繞的無非就是對團隊的貢獻，個人成長；

但是現(xiàn)在不一樣，需要幫小伙伴做總結(jié)，也需要為測試團隊做總結(jié)，突然覺得壓力山大，而且也要給優(yōu)秀同學(xué)提名獎項；

因此，就有了本篇的內(nèi)容，目的很簡單，測試崗在評績效時，到底有哪些維度？

業(yè)務(wù)測試

測試崗位的分工，粗略分為業(yè)務(wù)測試跟測試開發(fā)，兩者因崗位的不同，而要求自然也會有區(qū)別，這里就先聊聊業(yè)務(wù)測試；

從結(jié)論而言，業(yè)務(wù)測試肯定是第一位的，是產(chǎn)品的基礎(chǔ)，因此圍繞業(yè)務(wù)會有很多衍生品，比如性能、兼容性、穩(wěn)定性、安全等等，盡管如此，業(yè)務(wù)測試還是最重要的；

而在業(yè)務(wù)測試過程，考查的是什么？

• 思考問題的角度，如用戶角度、測試角度、運營角度；
• 測試基礎(chǔ)知識，比如目的、原則、模型、項目流程、用例設(shè)計方法、測試方法和類型；

上面提交到的測試基礎(chǔ)知識，這里補一下：

知識點說明目的發(fā)現(xiàn)程序中存在的錯誤、為反饋信息做準(zhǔn)備；原則盡早進行軟件測試、所有的測試都要追溯到用戶需求、需要在有限的時間跟資源進行完全測試、測試是證明軟件存在問題、關(guān)注測試中集群現(xiàn)象、避免測試的隨意性；模型V模型、W模型；流程需求評審、測試計劃、用例設(shè)計、執(zhí)行測試用例設(shè)計方法黑盒（等價類劃分、邊界值）、白盒（語句、判定、條件、路徑覆蓋）；測試方法和類型按代碼可見程序劃分（黑盒、白盒、灰盒）、項目流程階段劃分（單元、集成、系統(tǒng)、驗收測試）、按執(zhí)行過程上花覅需要人工干預(yù)（手工、自動化）、其他維度（冒煙、回歸、隨機、壓力、負(fù)載、性能）

傳統(tǒng)的業(yè)務(wù)測試，從用戶角度和測試角度思考問題，價值體現(xiàn)在扎實的測試基礎(chǔ)知識、發(fā)現(xiàn)問題的敏感性、業(yè)務(wù)知識的專業(yè)性、業(yè)務(wù)提議的建設(shè)性。

隨著敏捷、快速迭代的興起，對業(yè)務(wù)測試的要求越來越高**，縮小問題范圍、精準(zhǔn)定位原因，節(jié)約開發(fā)耗時**成為業(yè)務(wù)測試的另一種價值體現(xiàn)。

考核點

如果非要說考核，個人覺得有幾點：

• 工作質(zhì)量；
• 工作效能；
• 工作積極性；

工作質(zhì)量

這里面包括用例質(zhì)量、系統(tǒng)質(zhì)量等方面進行考核；

用例質(zhì)量，可以用總有效缺陷除以用例總數(shù)，得出單位用例的缺陷檢測率，用以考核用例的質(zhì)量；
系統(tǒng)質(zhì)量，主要考察有效缺陷質(zhì)量、缺陷漏測率、有效缺陷比、各級別缺陷比重等指標(biāo)；
復(fù)制代碼

工作效能

主要考核測試人員整體工作效率；

主要指標(biāo)包括：

• 設(shè)計效率；
• 設(shè)計覆蓋率；
• 執(zhí)行效率；
• 執(zhí)行覆蓋率；
• 是否在指定時間內(nèi)完成工作任務(wù)（主要考察實際和計劃的偏離度）

積極性

主要考核測試人員溝通、學(xué)習(xí)等方面的能力。

• 測試過程中問題的反饋；
• 解決測試過程中出現(xiàn)問題的能力；
• 在項目階段測試完成后的真空期進行測試學(xué)習(xí)的能力；
• 查看研發(fā)設(shè)計文檔， 進一步了解需求，再進行需求分析和用例設(shè)計；
• 各種提高效率的產(chǎn)出，比如流程優(yōu)化、過程改進、自動化、腳本、工具等；
• 主動學(xué)習(xí)測試?yán)碚摶蛳嚓P(guān)技術(shù)；

特別注意

這里特別說明，不能用bug數(shù)量來做kpi，因為不同同學(xué)分工不同，產(chǎn)品功能都不一樣，什么bug數(shù)量，bug嚴(yán)重度，設(shè)計，執(zhí)行，維護用例的數(shù)目都不是合適的考核指標(biāo)。

另外，如果遇到一個能力差的研發(fā)，那kpi絕對是第一的，變相的，測試就希望研發(fā)的能力越差越好，同時，亂報Bug的情況會增加，最后可能會影響項目進度；

最終產(chǎn)物

整理下，如下圖，bug數(shù)個人不贊成，但實際有不少公司都是有這個指標(biāo)的，因此還是列出來的，建議不要使用；

站在更高點的角度，就變成這樣：

測試開發(fā)

業(yè)務(wù)測試因為有明確的業(yè)務(wù)方需求，因為工作成果度量是很明確的，那測試開發(fā)崗呢？

首先要明確一個概念，測試開發(fā)崗核心是提高內(nèi)部效率，如開發(fā)各種平臺，讓數(shù)據(jù)更清晰、能讓項目各角色更順暢的交付；

測試開發(fā)的客戶是內(nèi)部團隊，因此必須懂/熟悉業(yè)務(wù)，知道團隊痛點，具備測試跟開發(fā)的思維，不然，不為業(yè)務(wù)服務(wù)的工具都是虛的；

節(jié)省時間

某同學(xué)A每天要花2小時做一件事，如果把這件事工具化，那就能節(jié)省該同學(xué)2小時，如果有10個同學(xué)也需要做這事，那么這工具就節(jié)省了20個小時了；

這個時間怎么算？常規(guī)的做法就是次數(shù) * 耗時；

眼看這個維度是很合理的，jb也嘗試過一段時間，但是最后會發(fā)現(xiàn)一個問題，就是這個指標(biāo)不好度量，還是上面的例子，同學(xué)A的2個小時空閑出來了，還是就需要做其他事情了，其他事情可能會導(dǎo)致他更加忙了，那從項目的角度，比原來更忙了，哪里算效率提升了，久而久之，大家都覺得這個指標(biāo)不靠譜了；

另外，工具的推動，也是極其困難的，做工具跟做產(chǎn)品是一樣的，都是一邊迭代一邊優(yōu)化，如果沒有用戶，這個工具就成了一句空話了；

如何吸引更多的用戶？就需要去推動，花更多的時間在寫文檔上、培訓(xùn)，試點等一系列操作；

次數(shù)

一個好的工具，只要能真的解決問題，肯定會有用戶，而且會經(jīng)常使用，站在這個角度，用次數(shù)來做指標(biāo)，是一個方向；

各種成本

如果這個工具能帶來收益，或者減少支持，比如原來用的是收費第三方應(yīng)用，現(xiàn)在是用內(nèi)部的，這部分費用就節(jié)省下來了，也是一個指標(biāo)；

其他

除了次數(shù)，還有很多指標(biāo)：

• 問題發(fā)現(xiàn)數(shù)，如自動化；
• 工具平臺穩(wěn)定性；
• 口碑；
• 需求數(shù)；
• 使用情況；

小結(jié)

好了，說到這里，也差不多了，簡單總結(jié)下指標(biāo)吧；

對于業(yè)務(wù)測試：

• 工作質(zhì)量；
• 工作效能；
• 工作積極性；

對于測試開發(fā)：

• 節(jié)省時間；
• 使用次數(shù)；
• 問題發(fā)現(xiàn)數(shù)，如自動化；
• 工具平臺穩(wěn)定性；
• 口碑；
• 需求數(shù)；
• 使用情況；