1、測試團隊績效考核
績效評估的的客體：是個體成員還是整個團隊。
● Pascerellayer認為，團隊績效評價應以成員個人完成工作的狀況為基本依據，理由是激勵只能作用於個人而不是群體；技能的提高和行為的改進最終必須落實到個人。若僅考核團隊績效，個體的努力得不到充分的肯定，就容易造成社會懶散現象，即個體由於參加團隊工作，其工作效率比自己單獨工作時的效率反而大大降低。此現象一旦在組織中蔓延開來，不僅會影響組織績效，還會毒害組織文化。同時，由於績效考核與薪酬及個人價值的實現相聯系，因此，在團隊中，能力高的成員傾向於對個人績效的考核，從而得到更高的認可和報酬。
● Zingheim和Schuster則認為對個人的考評應考慮團隊的整體績效，因為團隊的成功很大程度上依賴於團隊成員間的團結合作，理解支持，若評估集中於個體層面，會導致個人主義盛行，忽視團隊的協作精神，阻礙信息、技能的共享和績效的提高，降低團隊工作的優勢。
● 因此在實際操作中，企業往往采取一種折中的方法，即按一定比例兼顧團隊和個人兩個層面的績效考核。從目前的研究來看，還沒有一種很好的辦法可以科學地確定這個比例。但是，如果從團隊性質的差異、團隊所處的階段等方面來考慮，那么至少可以確定考核的天平是更向個體的一極偏還是更向團體的一極偏。
績效考核的內容：結果、行為還是能力。對於績效內涵存在着三種不同的觀點，即“績效是結果”、“績效是行為”和“績效是能力”。Bernardin將績效定義為“在特定的時間內，由特定的工作職能活動產生的產出記錄，工作績效的總和相當於關鍵和必要工作職能中等績效的總和（或平均值）”，這是“績效是結果”的典型觀點。 Murphy等人將績效定義為“一套與組織或個體所工作的組織單位的目標相關的行為”。近年來，以能力作為績效的觀點得到了廣泛的使用，這是以評估個體所擁有的完成某項工作所具備的知識和能力的方式。伴隨着這三種觀點的誕生和發展，績效考核大致經歷了基於結果、基於行為以及基於能力的三個考核發展過程。？雖然這三種觀點相互區別，且都是在否定前者的基礎之上產生的，但是，如果不帶入特定的環境，特定的組織，及組織發展的特定時期，那么三者之間並不存在絕對的優劣。如果組織下達的目標非常清晰，基於結果的績效考核是最容易實施，也最有效；相反，如果目標模糊，無法准確衡量其結果，這種考核方式就會失效。基於能力的考核方式理論上是從戰略管理的角度出發，最具有激勵效果和長期效應，最有利於組織不斷發展，但在實際操作中卻很難達到效果。因為能力是無形的，它依附於個體，既受主觀因素的控制，也受各方面客觀因素的影響，很難用標准化的方法衡量個體的能力，即使是方法對組織期望成員所具有的能力和特質作出了解釋，但這些解釋仍是描述性模糊語言，在實際操作中仍然難以做到真正的科學公正。基於行為的績效考核方法通過考核員工為實現既定的結果所必須做出的行為來實現對結果的控制，由於行為必然是建立在某種能力基礎之上的，並且行為比能力更具有外顯性和可測性，因此一定程度上，該方法兼顧了組織目標和個人能力。但是，績效考核中容易出現目標置換的現象，一味對行為測評會導致成員將行為作為目標，進而影響實際目標的實現。因此，無論哪種考核方式，都有其適用的條件和要求，不存在一種絕對好的方法。
基於項目團隊生命周期的績效考核：
● 孵化誕生期：這是指團隊形成前到團隊正式形成的一個階段，是選擇合適的項目成員組成團隊的時期。
→ 考核的客體是個人。團隊的首要任務是篩選項目組成員，根據項目目標的要求，選擇最為合適的人選組成團隊，所以考核的對象是個人。
→ 考核的重點是能力。從項目團隊成立的目的來看，它一般是為了開發一種新產品或者提供一項新的服務，因此對成員的知識技能要求較高，需要成員具有較高的技術水平和知識儲備以及不斷學習和創新的能力。同時，成立項目團隊，意在發揮團隊快速響應和凝聚集體智慧的優勢，更加需要團隊成員間的相互合作相互支持，所以需要較為系統地考核成員的協調合作能力，包括，對團隊其它成員工作任務的認識、口頭交流、個人成長、問題解決、責任承擔、領導技能等等。因此，在選擇項目團隊成員的時候，通過對被選者專業技能、基本素質當然也包括過去的工作經歷和背景等各方面的考核，最終確定較為合適的人選。
● 成長期：這是團隊正式形成之后，團隊工作逐漸步入正軌，團隊成員開始通過個人努力和彼此的合作共同在所研究的項目上獲得初步的成就。
→ 考核的客體是團隊。團隊成立之初，成員合作的意識還沒有形成，工作的獨立性較強，此時的工作重點應該是營造一種信任、關懷、相互支持的合作氛圍。同時，項目也剛剛起步，沒有取得實質性的進展，個人的貢獻還無法准確衡量，在這種情況下，如果過多地衡量個人績效，特別是個人產出績效，不僅不利於合作精神的培養，也會由於准確性不高而使成員產生不公平感，從而對團隊工作形成抵觸情緒。注重團隊整體績效的考核，可以向整個團隊成員傳遞這樣一個信息，即必須注重團隊的整體效率，共同開發團隊能力。同時，對團隊績效的考核還可以提高團隊成員對自己團隊的自豪感和所有感，並不斷提高其認同感和歸屬感。
→ 考核的重點是行為。剛剛進入一個新的團隊，如果此前沒有進行過合作，成員之間會由於陌生感而信任度較低，彼此在溝通和交流上存在困難，需要相當一段時間的磨合，工作進度也很緩慢。如果不通過有意識的加強合作意識的培養，難么磨合期就會較長，從而影響目標的實現。因此在項目團隊進入成長期時，績效考核的重點應該放在對團隊成員行為的考核之上。績效考核不僅僅是一種過程的監督和事后的衡量，更是一種對員工行為進行引導的方式。作為一種信息的傳播途徑，通過評估的本身，反饋以及與薪酬的聯系，以直接或間接的方式告訴被考核者，組織鼓勵什么樣的行為、反對什么樣的行為，從而引導和鼓勵成員采用更加積極的態度和行為，主動參與團隊工作，加強團隊成員之間的合作和學習，使項目團隊盡快度過磨合期，向着一個良性的方向發展。
● 成熟期：進入成熟期，團隊工作進展順利，項目取得關鍵性的突破，團隊成員自由溝通，合作意識加強。
→ 考核的客體是個人。此時應該加大對個人績效考核的比重。因為項目已經取得一定的突破，目標接近實現，團隊成員的成果和貢獻相對比較清晰，可以較為准確的衡量，需要對其加以肯定。如果仍然只是停留於對團隊績效的整體考核，並以此為基礎進行利益分配，個體會逐漸產生不公平感，因為隨着項目工作的深入開展和目標的逐步實現，個人由於態度、能力、技術支持等諸多方面的差異，貢獻度的差距會逐步擴大，客觀上會有成員的貢獻大於其它人，如果不及時加以肯定和認可，那么就會挫傷這一部分核心成員的積極性。
→ 考核的重點是結果。成熟期的團隊首要任務是推動工作進展，以保證最終成果的實現。由於既有的工作方式已經基本形成，合作溝通的氛圍已經建立，如果仍然強調對個體行為的考核，會使成員將大部分的注意力投入到日常的工作行為和方式之上。事實上，鼓勵行為的本身並不是目的，關鍵是行為帶來的結果，合作和交流是團隊的基本工作手段，但手段不能代替目的，項目及時高效地完成才是項目團隊的存在目的。如果不以任務為導向而長期進行行為考核，容易使個體忽視目標和結果，影響工作的效率，例如，過分的注重溝通和交流，造成決策時議而不決，貽誤時機，或者意見趨中，成員過分尊重群體意見，不願表達自己突破性的想法和思路。
● 衰退期：項目目標已經基本實現，團隊即將解散，此時需要對整個項目團隊作一個綜合的評估。
→ 考核的客體兼顧個人和團隊。進入衰退期，績效考核一方面需要通過對項目團隊的整體績效作出評估，以考核項目的完成情況；另一方面，也需要對團隊成員績效作出公正科學的總結，這不僅決定成員能否取得公平的報酬，也是其進入另一個團隊的基礎。
→ 考核的重點主要是個人的綜合績效以及團隊的產出。項目團隊任務明確，業績是團隊成立的最終目的，因此在項目團隊解散之際，需要對目標的實現情況作一個綜合評估，以此判斷項目的成功與否。對個人也需要做一個總體的評價，尤其是產出和能力的評估，組織需要對此進行備案，成為以后的項目團隊選擇成員的重要根據。
2、測試人員績效考核
考核基於測試過程進行，因此必須在過程結束之后才能進行。由於工程是分布提交測試的，每月可以根據實際情況進行月考核，工程結束后或任務結束后再統一考核。按照傳統測試周期，測試過程分為：測試計划、測試設計和測試執行三個方面進行。測試計划屬於測試經理的范疇。測試人員主要是測試設計和測試執行。
測試人員的績效考核包括多個方面：
● 工作態度。包括工作責任心和工作積極性。
● 工作職責與期望達成度(注意：在工作安排前需求明確對應測試工程師的工作職責和對測試工程師的期望值，這里的工作職責一般是和管理相關的工作職責內容)。
● 工作內容考核。
→ 參與軟件開發過程的工作內容考核，比如參與需求和設計的評審，就需要對需求的理解上，對需求提出問題的質量上等作出評價。
→ 參與測試文檔的准備工作，如測試用例等，需要通過評審測試文檔來考核測試人員的能力。如評審測試用例的質量，對需求的覆蓋程度，可理解和執行等方面來判段測試人員的能力。
→ 執行測試的工作，需要從測試人員所發現的問題對測試人員進行評價。包括發現問題是復雜的還是簡單的，是隱藏較深的，還是一些表面的問題。包括問題的書寫上進行評價，問題的書寫是否詳細清晰，開發人員可以再現，還是含糊其詞，不明所以。一個問題是否寫多遍等。
→ 測試結果缺陷殘留，對於已經發布的產品，從用戶反饋問題考核測試人員的績效，但是這個可能需要的時間比較長；對於不同版本的測試，可從版本的漏檢進行統計。
→ 測試人員的溝通能力考核，包括缺陷在開發工程師中溝通的達成率和拒絕率。
● 工作效率與工作質量考核。
→ 測試設計中工作效率相關指標：
△ 文檔產出率：這項指標值主要為測試用例文檔頁數除於編寫文檔的有效時間獲得。用於考察測試人員測試用例文檔的生產率大小。
公式：∑測試用例文檔頁數（頁）/∑編寫測試用例文檔有效時間（小時）
參考指標：根據項目匯總得出平均在 1.14 頁 / 小時左右，高於此值為優，低於此值為差。
△ 用例產出率：這項指標值主要為上述指標值的補充，用於考察測試人員測試用例產出率大小。測試文檔頁數可能包含的冗余信息較多，因此要查看文檔中測試用例的多少。方法是測試用例文檔中測試用例編號總和數除於編寫文檔的有效時間。
公式：∑測試用例數（個） / ∑編寫測試用例文檔有效時間（小時）
參考指標：平均 4.21 個用例 / 小時
● 測試設計中工作質量相關指標：
→ 需求覆蓋率：計算測試用例總數之和除於與之一一對應的功能點數之和，主要查看是否有功能點遺漏測試的情況。
公式：∑測試用例數（個） / ∑功能點（個）
參考指標：100％。如果連功能指標都不能滿足 100 ％覆蓋，起碼說明測試不充分。這個指標收集起來相當困難，如果存在需求跟蹤矩陣或者測試管理工具能把用例與需求一一對應就容易得多。注意：有的功能是難於測試的，那么未能覆蓋到的需求要綜合分析，明確是測試人員遺漏？還是無法測試？這需要放入問題跟蹤表中進行后續跟蹤；另外，有的功能點包含的信息較多或者有的用例包含幾個功能點，這時只能把重復的功能點或重復用例按一個計，難於區分的要做說明。
→ 文檔質量：測試用例進行評審和同行評審發現的缺陷數，或者將此缺陷數除於文檔頁數算出比率。此指標考察測試人員文檔編寫的質量如何。
公式：∑缺陷數（評審和同行評審）（個） / ∑測試用例文檔頁數（頁）
參考指標：由於評審是發現的缺陷數是不固定的，因此，這個指標沒有可供參考的數值。如果缺陷數大小不能直接用於比較就使用缺陷 / 頁方式進行橫向對比。
→ 文檔有效率：使用測試用例文檔進行測試時發現的系統測試缺陷數除於此文檔頁數。用於考察文檔是由有效的指導了測試工作。
公式：∑缺陷數（系統測試）（個） / ∑測試用例文檔頁數（頁）
參考指標：平均 2.18 個缺陷 / 頁
注意：如果存在測試人員在測試時創建新文檔用於輔助測試時應包含這一部分。
→ 用例有效率：使用測試用例發現的全部缺陷除於測試用例數總和。這一指標是上一指標的補充指標，用於考察用例質量是否較高
公式：∑缺陷數（系統測試）（個） / ∑測試用例數（個）
參考指標：平均 0.59 個缺陷 / 用例，也就是說，每執行兩個用例才得到 1 個缺陷，各工程有所不同，可以自己實踐一下
→ 評審問題數：是否存在對需求理解、系統架構設計、系統設計等方面引起爭議的問題。體現出測試人員發現問題的深入層次，有利於產品質量的提高。
● 測試執行中工作效率相關指標：
→ 執行效率：利用測試用例文檔頁數除於此次系統測試執行的時間總和（不包含用例文檔編寫時間）。補充指標方法是用例的個數除於此次系統測試的時間總和。用於獲得工作中測試人員每小時執行測試的速度。
公式：∑測試用例文檔頁數（頁） / ∑執行系統測試的有效時間（小時）
∑測試用例數（個） / ∑執行系統測試的有效時間（小時）
參考指標：平均 0.53 頁 / 小時， 1.95 個用例 / 小時。即測試人員每小時執行半頁測試用例或者每小時執行 2 個測試用例。通過橫向比較，容易知道那位成員的執行效率較高。注意：執行效率高的不代表測試質量也高，甚至執行效率和測試質量成反比，所以后面工作質量的指標會補充這一部分的偏離。實際結果表明，用例執行效率高的成員，其缺陷發現率往往偏低，考核如果不將此納入進來也可以將其作為測試改進的一項重要數據進行收集。
→ 進度偏離度：檢查計划時間和實際時間的進度，方法是計划時間差額減去實際時間差額除於實際工時總和，用於考察測試人員進度情況，監控測試是否按照日程進行，是否滿足了工程的進度要求。
公式：∑（計划開始時間 - 實際開始時間）＋∑（計划結束時間 - 實際結束時間） / 總工時
參考指標：15％ 進度偏離是個相對的指標，可能偏離了 20 個工作日，但是對於一個長達半年時間的測試而言偏離天數比上整體測試所需天數不足 15 ％，可能偏離了 3 個工作日，但是對於一個只有 1 星期時間的測試已經超過了整個測試階段所需天數的 60 ％。
注意：計算時分子分母要保持一致，即開始或結束時間已經去除了非工作日時間，則總工時也要去除非工作日時間。因為制定計划時是根據每個公司的工作日來制定的，也就是說，考慮了非正常工作日的日程。
測試進度也是考核很重要的一步，如果沒有進度保證，所有的測試都存在風險，第一種方法是測試人員可以采用自下而上的方式向測試經理報告計划用時，這種方式風險比較少，個人根據自己能力大小確定，但是缺點是存在測試人員虛報可能性。另一種方法是測試經理進行估算后分配工作日程，這時估算是很重要的前提，除了依賴於測試經理的經驗外，對評估結果進行同行評審是很客觀可取的方法。
→ 缺陷發現率：測試人員各自發現的缺陷數總和除於各自所花費的測試時間總和。由於執行效率不能足夠代表測試人員是否認真工作，那么，每小時發現的缺陷數就是重要的考核指標，你的工作可以通過這項指標得到反饋。
公式：∑缺陷數（系統測試）（個） / ∑執行系統測試的有效時間（小時）
參考指標：平均 1.1 個缺陷 / 小時 假使有位測試人員沒有達到 1 小時發現 1 個缺陷，那么，除非產品質量高、模塊較小，否則，就是他的缺陷發現能力不如其他測試人員。當然，詳細分類中可以根據發現重要缺陷的多少來定義缺陷發現能力。
● 測試執行中工作質量相關指標：
→ 缺陷數：為了更客觀度量，考慮到bug的嚴重性、技術難度、產品類型、模塊穩定性等因素影響，不是用“所發現的bug數量”，而是用“所獲得的bug value (缺陷值)”來度量，公式被定義為：
Bug_value=（P0_Bug_Number × 1.6 + P1_Bug_Number× 1.4 + P2_Bug_Number× 0.7 + P3_Bug_Number×0.3）× Wd × Ws × Wt
其中：P0_Bug_Number：致命的（fatal）缺陷數量；P1_Bug_Number：嚴重的（critical）缺陷數量；P2_Bug_Number：一般的（major/normal）缺陷數量；P3_Bug_Number：次要的（minor）缺陷數量
Wd：技術難度系數，如Database， Enterprise Server， Java難度系數大，發現Bug不容易，Wd可以定在1.5 – 5.0
Ws：穩定性系數，全新模塊，Bug比較多，發現缺陷比較容易；版本越高，越穩定。Ws可以定在0.5 – 1.0， 假如以version 10.0為1.0， Version 1.0 = 1/100， Version 2.0 = 4/10， Version 3.0 = 9/100， …， ， Version 8.0 = 64/100， Version 8.0 = 81/100
Wt：產品類型系數，可根據實際情況和歷史數據來判斷。Wt也可以和Wd合並為一個系數。
→ 有效缺陷數/率：被拒絕和刪除的缺陷數總和，或者被拒絕和刪除的缺陷數總和除於缺陷總數。這項指標用於考察測試人員發現的、被確認為缺陷的缺陷數高低或者百分比，數和比率越低測試質量越高。
公式：∑缺陷數（系統測試中被拒絕和刪除的）（個）
∑缺陷數（系統測試中被拒絕和刪除的）（個） / ∑缺陷數（系統測試）（個）
參考指標：平均 21.9 ％（測試人員發現的每 100 個缺陷中平均有 22 個缺陷不被開發組確認、認為不是“缺陷”或者錯誤錄入缺陷）。有效缺陷比率容易給出，但是有效缺陷數具體數據要根據項目情況，無法給出可參考的數值。
注意：這項指標可能有不正確的情況，假使缺陷被拒絕和被刪除的原因不是因為測試人員誤操作和需求理解等自身錯誤引起，而是系統本身不能實現或者數據錯誤引起的，那么就要考慮剔除這部分。對於測試人員發現系統框架根本性的、初始化參數設置錯誤引發的、錯誤數據、錯誤環境等而開發人員因無法修正、可以通過改變環境而無需修改程序、重新導入數據、再次發布從而拒絕或刪除的缺陷，應給予此測試人員獎勵。
→ 嚴重缺陷率：這個比例用於彌補缺陷發現率的不足。主要是根據嚴重程度分類的缺陷數比全部缺陷或者有效缺陷數。一般而言，每個公司基本把缺陷嚴重程度分為嚴重、一般和微小，或者更細（通常等級數為奇數）。另外，可以對缺陷嚴重程度進行折算（嚴重：一般：微小 =1 ： 3 ： 5 ）通過折算可以得出權重，然后在計算測試人員分值。
公式：∑嚴重 / 一般 / 微小 / ∑缺陷數
∑嚴重 / 一般 / 微小 / ∑有效缺陷數
參考指標：嚴重 ~10% 一般 ~70% 微小 ~20% 。當測試人員發現的缺陷中嚴重錯誤比率越高，說明測試質量相對就好，通常嚴重程度缺陷數的分布呈正態分布。
→ 模塊缺陷率：這個指標主要是根據一個單獨測試模塊的缺陷數除於模塊本身功能點數得出來的。假使一個模塊是單獨測試的話，很容易可以和其他模塊進行指標橫向對比，參照對應的測試人員，得出所測試模塊的缺陷數，可以考察測試人員測試水平，也為開發考核提供數據。
公式：∑缺陷數（系統測試（個） / 功能點（個）
∑缺陷數（系統測試（個） / 子功能點（個）
參考指標 平均 3.74 個缺陷 / 功能點 1 個缺陷 / 子功能點
注意：有些功能點沒有子功能點，計算子功能點時要進行說明。
→ 遺漏缺陷率：發布后的線上故障，現階段測試相關的故障主要都是因為測試遺漏，有遺漏就說明我們的測試還是效率不高，可以改進。
公式：∑遺漏缺陷數 / (∑遺漏缺陷數 + ∑遺漏版本發現缺陷數)
→ Bug發現的時間點，bug曲線的收斂性，理想的效率高的模式應該是前多后少，慢慢收斂的，如果前期bug非常少，后期卻發現大量bug，那我們的前期效率就有問題。
→ 缺陷定位和可讀性： 可讀性內容包括Bug描述的規范性，分優秀、良好、普通與不合格，描述是否清晰，問題定位的附件是否完備等。如果一個測試人員只會通過頁面將現象表達出來，而無法定位這種現象是有什么引起的，或者無法定位該缺陷到底錯在何處，那么可以判定測試人員只是做了簡單的表面測試，並沒有對所發現問題進行分析定位。
● 對技術組(性能自動化和環境)測試人員效率的度量：
→ 自動化測試的引入和使用是否合理，不是每個項目都適合做自動化的，自動化並不能保證效率的提高，用5個小時開發的自動化腳本來替代3個小時的手工測試並不合算，自動化測試需要評審，按照項目的大小不同，必要的情況下才引入自動化測試。
→ 自動化測試，特別是性能測試結束之后，我們要分析部分測試結果，測試結果的分析水平，也可以作為衡量測試效率的一個指標。
● 對測試項目負責人的效率的度量：
→ 測試是否提早介入項目，例如FRD階段就介入，越早介入，越有利於測試，使測試人員更加熟悉整個項目，使問題早暴露，提高整體效率。
→ 開發提交測試的時候，標准是否合理，把關是否嚴格，如果開發的質量不行，堅決要退回，不然會影響測試的效率和進度。
→ 測試計划階段，評價測試計划的合理性，包括任務細化，細化的程度是否合理，任務順序，資源安排，任務分配合理，風險預估等等。
→ 項目結束后，評價項目進行階段中負責人的跟進情況，特殊情況處理，風險觸發之后的處理，資源協調，信息收集，共享，溝通，配合等等。
● 測試管理。
→ 計划質量：測試計划的評審缺陷數或比率，可以與其他同類型項目或數據庫平均指標進行對比。
∑缺陷數（評審和同行評審）（個） / ∑測試計划文檔頁數（頁）
→ 成本質量：成本度量主要放在工作量這塊。因為無論涉及工資還是獎金，都要和工作量掛上關系。成本質量主要是對測試活動的計划工作量總和比上實際的工作量數值總和。對測試人員考核的進度偏離已經考慮了進度因素，而工作量涉及的是成本因素。
公式：∑測試活動計划工作量（估算人日） / ∑測試活動的實際工作量（人日）
參考指標：原則上不能偏離計划的 ± 15 ％～ ± 20 ％。實際上，這個指標是對成本的一種度量。對於一個大的項目來說，估算值往往差距非常大，階段統計時可能有± 500 ％！！這時調整計划是很必要的，在最終階段取考慮計算平均估算值。一個測試經理必須對完成任務的成本進行有效控制。這兩項指標是相對容易量化的部分，而需要添加其他量化指標需要綜合考慮由項目經理和測試部部門經理給出標准，例如管理用時比率（整個項目測試期間管理時間占整個項目測試總時間）、系統整體缺陷數與其他同類型項目或數據庫平均指標進行對比等等。
● 考核具體方法：
→ 將各項指標進行匯總分析，得出總和表格，根據測試人員各項指標大小進行排行榜制作，如列出 1 、 2 、3、4 名。
→ 確定階段涉及的權重。例如將測試設計和測試執行權重各為 50 ％。其中，工作效率占 40 ％（即占所在階段 20 ％），工作質量占 60 ％（即占所在階段 30 ％）。
→ 確定每類指標的分值，然后每類指標達到平均標准給 100 ％，達不到或者超過根據 80 ％ ~120 ％比率給分。
→ 將比分統計出來后進行綜合評定，必要的話增加一些調整系數。
→ 最好將定性分析納入進來，采用問卷調查和項目經理評分制度給出定性指標分數，建議這部分權重不要超過 10 ％～ 15 ％以保證測試考核的可度量性。
→ 當所有考核分數給出之后，提醒一點的是，既然做了考核，就必須公開這些結果，而且考核具有導向型，不要讓考核誤導了對質量工作的追求才是最重要的。
● 考核注意事項：
→ 項目並不是一個月就能完成的，如每月進行，要考慮“可考核部分”為那些，挑選那些指標能夠橫向對比，然后分階段、分任務評定。
→ 參與測試的時間長短也要給予重視，除了上述量化指標外，測試人員整體投入時間長短也是很重要的，加班也要作為特殊考慮因素，也許某個測試人員只參加了測試執行 3 小時，各項指標都是良好的，但是不可能給他比其他參與時間更長的人員更多的分數。這部分就是增加調整系數的原因。
→ 測試經理的測試設計和執行部分和項目測試人員一起考核，但是測試管理工作要單獨考核，作為另外的加分，或者如文章前面所述納入項目組給予考核。因為測試經理在項目測試中起着管理者和質量保證負責人的角色，不要把他和其他測試工程師平等對待。
→ 考核前要考慮項目的實際情況，不要盲目的輕易承諾測試組人員考核會和薪金或者淘汰機制掛鈎，否則考核會起到反效果。
→ 作為考核者要注意以下比例，也許有些沒有列入考核內容，但是如下這些點可以指導測試。
△ 測試團隊發現的bug和所有bug之間的比例
△ spec設計造成的bug
△ 重復或者誤提交的bug所占的比例
△ 每周發現的bug的趨勢圖
△ Bug嚴重等級的構成比例
△ Bug從提交到解決的平均需要時間
△ Bug從解決到關閉的平均需要時間
項目組測試人員考核的主要目的是在於激勵測試組測試人員工作，鼓勵能者，鞭策落后；另外，還可以起到發現人才和查找不足的作用。考核中即要體現多勞多得的原則，也要體現公正性和合理性原則，獎罰分明才能有效促使質量管理工作的進步。要想考核得到滿意的效果，上述方法的重要的前提條件是：必須要在項目中充分收集相關的數據，包括采集缺陷數，記錄工時、提交詳細工作日志和進行文檔配置管理，沒有這些數據，定量分析就無從談起，測試人員考核也無從談起。
3、測試人員工作度量
測試度量主要從3部分開展工作： 一個是缺陷數據的統計分析，第二個是工作量的統計分析，第三個是測試工作量的估算。
● 缺陷的統計分析。主要是從缺陷嚴重性、優先級、模塊缺陷的分布、缺陷的收斂情況、缺陷的修復情況進行統計，並根據統計結果，進行一定的分析。
● 工作量的統計分析。
→ 日常工作量的記錄，這個由團隊成員自己編寫。在填寫工作記錄時，需要為每個工作記錄選擇相應的任務類型，並且工作任務持續時間最長不超過4小時。
→ 每星期統計本周團隊成員在各個項目中的投入情況。不僅讓自己了清楚，也讓上司了解測試部對於項目的支持情況。
→ 每半個月統計整個團隊的工作分配情況(但是數據是每周都填寫的)統計每個人在各個項目的工作量分配情況。這個和上面那個統計表的側重點不一樣，上面這個統計表側重在部門整體，現在這個表側重於個體。
→ 定期(如每周或半個月)將團隊成員在項目中的工作量投入情況記錄到項目工作量投入表中。這個表格主要用於統計具體每個項目的測試工作投入情況，及作為后續測試工作量估算的原始數據。
→ 在項目到達一個階段后，將項目測試收集的數據進行匯總、統計。收集的數據除項目基本信息外，還包括工作量、測試投入成本、項目規模、項目總成本、項目總工作量。主要分析測試在項目中的投入情況、成本情況、各個測試任務的分配情況等。
● 最后，根據對幾個項目的工作量、成本以及測試任務占項目總測試投入的比例分析后，得到測試團隊測試工作量估算的簡易公式。可以根據這個簡易的公式進行測試的估算，方便測試計划中關於工作量估算部分的編寫，避免在估算工作量時缺乏依據。估算內容主要包括：測試總人力成本占項目總人力成本的比例及各項測試任務的工作量分配比例。
4、效率提高
● 測試負責人與開發負責人共同對項目進度進行商討分析，作出合理的測試計划，並在測試執行過程中嚴格按照測試計划的進度和測試策略進行。
● 測試人員盡早的進入需求理解階段，充分理解需求文檔。
● 必要時做跟進測試，提高需求理解深度，可間接提高測試執行的效率；跟進測試，即系統測試之前的草稿版測試，需要與開發方溝通，讓其協助來執行。跟進測試的目的不是發現bug，而是熟悉系統環境，助於需求理解和測試設計。
● 盡量避免失敗的接收測試。一次版本無法接收，會浪費很多人力和時間，還會影響測試人員的測試熱情。
● 任務分配合理化。測試負責人應根據項目組成員的經驗和能力能個人因素，合理的分配測試任務，並將測試任務的模塊和時間詳細化，這樣有助於提高整個項目的測試效率。
● 測試工作從某種角度看，會很容易摻雜個人主觀意見，測試質量也受測試人員的責任感的因素影響，所以，培養良好的測試風格，提高測試人員的責任感，也能間接提高項目的測試效率。
● 慎重安排員工職務。管理者應該充分了解員工的特點，能力特長，個人氣質，以讓這些特質和分配的工作最佳配合，從而能夠達到更好的效果。這樣，員工也容易從高效的工作種找到樂趣，滿足感，成就感，得到鍛煉，同時很好地完成工作任務。
● 設定高績效工作標准：
→ 給員工制定一個一般人都很容易達到的“低標准”，讓員工覺得，你認為他能力不強，即使他努力達到了標准，也很難從工作中得到滿足感，因為這個工作標准其它人也很容易就達到。
→ 低的工作標准，讓大家很難打起精神努力工作，因為這很容易讓人覺得，這個事情根本不重要，它對公司，對部門重要性不夠，所以他們也不會將很大的精力投入到管理層認為不重要的工作中去，即使做好了，也是多余，因為這項工作本身部要求那么好。
→ 很多員工時間長了，很容易在潛意識中覺得，你分配給他的工作不重要，那么就意味着，他對這個團隊，對這個部門也不重要，他大好的青春應該能夠創造不俗的成績，產生希望尋求實現自己價值的團隊。本來最求成功的好員工，在這個的低標准工作中被浪費了，可惜。
● 提供員工自我控制方面的信息。這里的信息是指：讓員工知道自己所負責的工作，對公司，對團隊成功具有哪方面的意義。如果做砸了，對公司的損失是什么，對團隊影響有多壞。這樣，很容易讓員工對工作產生很強的責任感。
還有，這項工作達到何種程度可以認為完成出色，這樣，他可以自行按照高要求高效完成工作，以達到高績效。這些信息確實是非常必要。
● 提供員工參與機會以培養管理者的願景。要讓員工具有和團隊一起成功的自豪感，成就感，這樣，他會站在團隊集體利益的立場上看待自己的工作。那么如何賦予員工這種自豪感，成就感？當員工確實做了值得驕傲的時期是，他們才會覺得驕傲，否則就是不誠實，反而具有殺傷力。只有當員工確實有成就感時，他們才會有成就感，也只有當他們承擔了重要的任務時，才會真正覺得自己對團隊重要。真正的自豪感，成就感和受重視感是奠基於積極，負責地參與有關自己工作和團隊管理的決策。讓員工覺得團隊的成功有他重要的貢獻，如果他失敗了，那么團隊就會受牽連，他是團隊成功不可缺少的一份子，他和團隊是緊密聯系在一起的，那么他就會對團隊產生強烈的責任感，從而高績效，高要求地完成自己的工作。
5、測試團隊評估
測試團隊評估目標： 高效的提高軟件測試用例的覆蓋率。高效提高軟件測試用例的覆蓋度可分解為三個指標：
● 通過測試用例的復用。
● 以數據驅動的形式自動化測試用例。
● 通過有效的測試用例設計方法擴大覆蓋率。
軟件測試用例覆蓋率提高判斷條件：
● 現有測試用例進行了有效的管理，建立測試用例基線。
● 明確測試用例編寫的顆粒度，測試用例顆粒度可以跟代碼行數對應，可以跟功能點對應，組織內部測試用例顆粒度要統一，保證所有人員大致是一致的。
● 單個功能點都進行了有效的規整，確定最小測試范圍。保證單一個功能點進行了規整。
● 提高的方式放在功能點的組合和測試數據的增加上。
