1、績效考核1. 測試團隊績效考核績效評估的的客體：是個體成員還是整個團隊。Pascerellayer 認為，團隊績效評價應以成員個人完成工作的狀況為基本依據，理由是激勵只能作用于個人而不是 群體；技能的提高和行為的改進最終必須落實到個人。若僅考核團隊績效，個體的努力得不到充分的肯定，就容易 造成社會懶散現象，即個體由于參加團隊工作，其工作效率比自己單獨工作時的效率反而大大降低。此現象一旦在 組織中蔓延開來，不僅會影響組織績效，還會毒害組織文化。同時，由于績效考核與薪酬及個人價值的實現相聯系， 因此，在團隊中，能力高的成員傾向于對個人績效的考核，從而得到更高的認可和報酬。Zingheim 和 Sc

2、huster 則認為對個人的考評應考慮團隊的整體績效，因為團隊的成功很大程度上依賴于團隊成員間 的團結合作，理解支持，若評估集中于個體層面，會導致個人主義盛行，忽視團隊的協作精神，阻礙信息、技能的 共享和績效的提高，降低團隊工作的優勢。因此在實際操作中，企業往往采取一種折中的方法，即按一定比例兼顧團隊和個人兩個層面的績效考核。從目前的 研究來看，還沒有一種很好的辦法可以科學地確定這個比例。但是，如果從團隊性質的差異、團隊所處的階段等方 面來考慮，那么至少可以確定考核的天平是更向個體的一極偏還是更向團體的一極偏。績效考核的內容：結果、行為還是能力。對于績效內涵存在著三種不同的觀點，即“績效是結果

3、” 、“績效是行為”和“績 效是能力”。 Bernardin 將績效定義為“在特定的時間內，由特定的工作職能活動產生的產出記錄，工作績效的總和相當于 關鍵和必要工作職能中等績效的總和（或平均值） ”，這是“績效是結果”的典型觀點。 Murphy 等人將績效定義為“一套 與組織或個體所工作的組織單位的目標相關的行為” 。近年來，以能力作為績效的觀點得到了廣泛的使用，這是以評估個 體所擁有的完成某項工作所具備的知識和能力的方式。伴隨著這三種觀點的誕生和發展，績效考核大致經歷了基于結果、 基于行為以及基于能力的三個考核發展過程。 雖然這三種觀點相互區別，且都是在否定前者的基礎之上產生的，但是， 如果

4、不帶入特定的環境，特定的組織，及組織發展的特定時期，那么三者之間并不存在絕對的優劣。如果組織下達的目標 非常清晰，基于結果的績效考核是最容易實施，也最有效；相反，如果目標模糊，無法準確衡量其結果，這種考核方式就 會失效。基于能力的考核方式理論上是從戰略管理的角度出發，最具有激勵效果和長期效應，最有利于組織不斷發展，但 在實際操作中卻很難達到效果。因為能力是無形的，它依附于個體，既受主觀因素的控制，也受各方面客觀因素的影響， 很難用標準化的方法衡量個體的能力，即使是方法對組織期望成員所具有的能力和特質作出了解釋，但這些解釋仍是描述 性模糊語言，在實際操作中仍然難以做到真正的科學公正。基于行為的績

5、效考核方法通過考核員工為實現既定的結果所必 須做出的行為來實現對結果的控制， 由于行為必然是建立在某種能力基礎之上的， 并且行為比能力更具有外顯性和可測性， 因此一定程度上，該方法兼顧了組織目標和個人能力。但是，績效考核中容易出現目標置換的現象，一味對行為測評會導 致成員將行為作為目標，進而影響實際目標的實現。因此，無論哪種考核方式，都有其適用的條件和要求，不存在一種絕 對好的方法。基于項目團隊生命周期的績效考核 :孵化誕生期 : 這是指團隊形成前到團隊正式形成的一個階段，是選擇合適的項目成員組成團隊的時期。 考核的客體是個人。團隊的首要任務是篩選項目組成員，根據項目目標的要求，選擇最為合適的

6、人選組成團 隊，所以考核的對象是個人。考核的重點是能力。從項目團隊成立的目的來看，它一般是為了開發一種新產品或者提供一項新的服務，因 此對成員的知識技能要求較高，需要成員具有較高的技術水平和知識儲備以及不斷學習和創新的能力。同時， 成立項目團隊，意在發揮團隊快速響應和凝聚集體智慧的優勢，更加需要團隊成員間的相互合作相互支持， 所以需要較為系統地考核成員的協調合作能力，包括，對團隊其它成員工作任務的認識、口頭交流、個人成 長、問題解決、責任承擔、領導技能等等。因此，在選擇項目團隊成員的時候，通過對被選者專業技能、基 本素質當然也包括過去的工作經歷和背景等各方面的考核，最終確定較為合適的人選。成長

7、期 : 這是團隊正式形成之后，團隊工作逐漸步入正軌，團隊成員開始通過個人努力和彼此的合作共同在所研究 的項目上獲得初步的成就。考核的客體是團隊。團隊成立之初，成員合作的意識還沒有形成，工作的獨立性較強，此時的工作重點應該是營造一種信任、關懷、相互支持的合作氛圍。同時，項目也剛剛起步，沒有取得實質性的進展，個人的貢獻還無法準確衡量，在這種情況下，如果過多地衡量個人績效，特別是個人產出績效，不僅不利于合作精神的培養，也會由于準確性不高而使成員產生不公平感，從而對團隊工作形成抵觸情緒。注重團隊整體績效的考核，可以向整個團隊成員傳遞這樣一個信息，即必須注重團隊的整體效率，共同開發團隊能力。同時，對 團

8、隊績效的考核還可以提高團隊成員對自己團隊的自豪感和所有感，并不斷提高其認同感和歸屬感。考核的重點是行為。剛剛進入一個新的團隊，如果此前沒有進行過合作，成員之間會由于陌生感而信任度較低，彼此在溝通和交流上存在困難，需要相當一段時間的磨合，工作進度也很緩慢。如果不通過有意識的加強合作意識的培養，難么磨合期就會較長，從而影響目標的實現。因此在項目團隊進入成長期時，績效考核的重點應該放在對團隊成員行為的考核之上。績效考核不僅僅是一種過程的監督和事后的衡量，更是一種對員工行為進行引導的方式。作為一種信息的傳播途徑，通過評估的本身，反饋以及與薪酬的聯系，以直接或間接的方式告訴被考核者，組織鼓勵什么樣的行為

9、、反對什么樣的行為，從而引導和鼓勵成員采用更加積極 的態度和行為，主動參與團隊工作，加強團隊成員之間的合作和學習，使項目團隊盡快度過磨合期，向著一 個良性的方向發展。成熟期 : 進入成熟期，團隊工作進展順利，項目取得關鍵性的突破，團隊成員自由溝通，合作意識加強。考核的客體是個人。此時應該加大對個人績效考核的比重。因為項目已經取得一定的突破，目標接近實現，團隊成員的成果和貢獻相對比較清晰，可以較為準確的衡量，需要對其加以肯定。如果仍然只是停留于對團隊績效的整體考核，并以此為基礎進行利益分配，個體會逐漸產生不公平感，因為隨著項目工作的深入開展和目標的逐步實現，個人由于態度、能力、技術支持等諸多方面

10、的差異，貢獻度的差距會逐步擴大，客觀上 會有成員的貢獻大于其它人，如果不及時加以肯定和認可，那么就會挫傷這一部分核心成員的積極性。考核的重點是結果。成熟期的團隊首要任務是推動工作進展，以保證最終成果的實現。由于既有的工作方式已經基本形成，合作溝通的氛圍已經建立，如果仍然強調對個體行為的考核，會使成員將大部分的注意力投入到日常的工作行為和方式之上。事實上，鼓勵行為的本身并不是目的，關鍵是行為帶來的結果，合作和交流是團隊的基本工作手段，但手段不能代替目的，項目及時高效地完成才是項目團隊的存在目的。如果不以任務為導向而長期進行行為考核，容易使個體忽視目標和結果，影響工作的效率，例如，過分的注重溝通和

11、 交流，造成決策時議而不決，貽誤時機，或者意見趨中，成員過分尊重群體意見，不愿表達自己突破性的想 法和思路。衰退期 : 項目目標已經基本實現，團隊即將解散，此時需要對整個項目團隊作一個綜合的評估。考核的客體兼顧個人和團隊。進入衰退期，績效考核一方面需要通過對項目團隊的整體績效作出評估，以考 核項目的完成情況；另一方面，也需要對團隊成員績效作出公正科學的總結，這不僅決定成員能否取得公平 的報酬，也是其進入另一個團隊的基礎。考核的重點主要是個人的綜合績效以及團隊的產出。項目團隊任務明確，業績是團隊成立的最終目的，因此在項目團隊解散之際，需要對目標的實現情況作一個綜合評估，以此判斷項目的成功與否。對

12、個人也需要做一個總體的評價，尤其是產出和能力的評估，組織需要對此進行備案，成為以后的項目團隊選擇成員的重要 根據。2. 測試人員績效考核考核基于測試過程進行， 因此必須在過程結束之后才能進行。 由于工程是分布提交測試的， 每月可以根據實際情況進行月 考核，工程結束后或任務結束后再統一考核。按照傳統測試周期，測試過程分為：測試計劃、測試設計和測試執行三個方面進 行。測試計劃屬于測試經理的范疇。測試人員主要是測試設計和測試執行。測試人員的績效考核包括多個方面 :工作態度。包括工作責任心和工作積極性。工作職責與期望達成度 （注意: 在工作安排前需求明確對應測試工程師的工作職責和對測試工程師的期望值，

13、這里的 工作職責一般是和管理相關的工作職責內容 ） 。工作內容考核。 參與軟件開發過程的工作內容考核，比如參與需求和設計的評審，就需要對需求的理解上，對需求提出問題 的質量上等作出評價。參與測試文檔的準備工作，如測試用例等，需要通過評審測試文檔來考核測試人員的能力。如評審測試用例 的質量，對需求的覆蓋程度，可理解和執行等方面來判段測試人員的能力。執行測試的工作，需要從測試人員所發現的問題對測試人員進行評價。包括發現問題是復雜的還是簡單的， 是隱藏較深的，還是一些表面的問題。包括問題的書寫上進行評價，問題的書寫是否詳細清晰，開發人員可 以再現，還是含糊其詞，不明所以。一個問題是否寫多遍等。測試結

14、果缺陷殘留，對于已經發布的產品，從用戶反饋問題考核測試人員的績效，但是這個可能需要的時間 比較長；對于不同版本的測試，可從版本的漏檢進行統計。測試人員的溝通能力考核，包括缺陷在開發工程師中溝通的達成率和拒絕率。工作效率與工作質量考核。測試設計中工作效率相關指標 :文檔產出率 : 這項指標值主要為測試用例文檔頁數除于編寫文檔的有效時間獲得。用于考察測試人員測 試用例文檔的生產率大小。公式：刀測試用例文檔頁數（頁）/刀編寫測試用例文檔有效時間（小時）參考指標：根據項目匯總得出平均在 1.14 頁 / 小時左右，高于此值為優，低于此值為差。用例產出率 : 這項指標值主要為上述指標值的補充，用于考察測

15、試人員測試用例產出率大小。測試文檔 頁數可能包含的冗余信息較多， 因此要查看文檔中測試用例的多少。 方法是測試用例文檔中測試用例編 號總和數除于編寫文檔的有效時間。公式：刀測試用例數（個）/刀編寫測試用例文檔有效時間（小時）參考指標：平均 4.21 個用例 / 小時測試設計中工作質量相關指標 :需求覆蓋率 : 計算測試用例總數之和除于與之一一對應的功能點數之和，主要查看是否有功能點遺漏測 試的情況。公式：刀測試用例數（個）/刀功能點（個）參考指標： 100。如果連功能指標都不能滿足 100 覆蓋， 起碼說明測試不充分。 這個指標收集起來 相當困難， 如果存在需求跟蹤矩陣或者測試管理工具能把用例

16、與需求一一對應就容易得多。 注意：有的 功能是難于測試的， 那么未能覆蓋到的需求要綜合分析， 明確是測試人員遺漏？還是無法測試？這需要 放入問題跟蹤表中進行后續跟蹤； 另外， 有的功能點包含的信息較多或者有的用例包含幾個功能點， 這 時只能把重復的功能點或重復用例按一個計，難于區分的要做說明。文檔質量 : 測試用例進行評審和同行評審發現的缺陷數，或者將此缺陷數除于文檔頁數算出比率。此指 標考察測試人員文檔編寫的質量如何。公式：刀缺陷數（評審和同行評審）（個）/刀測試用例文檔頁數（頁）參考指標： 由于評審是發現的缺陷數是不固定的，因此，這個指標沒有可供參考的數值。 如果缺陷數大 小不能直接用于比

17、較就使用缺陷 / 頁方式進行橫向對比。文檔有效率 : 使用測試用例文檔進行測試時發現的系統測試缺陷數除于此文檔頁數。用于考察文檔是由 有效的指導了測試工作。公式：刀缺陷數（系統測試）（個）/刀測試用例文檔頁數（頁）參考指標：平均 2.18 個缺陷 / 頁 注意：如果存在測試人員在測試時創建新文檔用于輔助測試時應包含這一部分。用例有效率 : 使用測試用例發現的全部缺陷除于測試用例數總和。這一指標是上一指標的補充指標，用 于考察用例質量是否較高公式：刀缺陷數（系統測試）（個）/刀測試用例數（個）參考指標： 平均 0.59 個缺陷 / 用例，也就是說， 每執行兩個用例才得到 1 個缺陷，各工程有所不

18、同， 可以自己實踐一下評審問題數 : 是否存在對需求理解、系統架構設計、系統設計等方面引起爭議的問題。體現出測試人員 發現問題的深入層次，有利于產品質量的提高。測試執行中工作效率相關指標 :執行效率 : 利用測試用例文檔頁數除于此次系統測試執行的時間總和 （不包含用例文檔編寫時間） 。補充 指標方法是用例的個數除于此次系統測試的時間總和。用于獲得工作中測試人員每小時執行測試的速 度。公式：刀測試用例文檔頁數（頁）/刀執行系統測試的有效時間（小時）刀測試用例數（個）/刀執行系統測試的有效時間（小時）參考指標： 平均 0.53 頁 / 小時， 1.95 個用例 / 小時。即測試人員每小時執行半頁測

19、試用例或者每 小時執行 2 個測試用例。通過橫向比較，容易知道那位成員的執行效率較高。注意：執行效率高的不 代表測試質量也高， 甚至執行效率和測試質量成反比， 所以后面工作質量的指標會補充這一部分的偏離。 實際結果表明， 用例執行效率高的成員， 其缺陷發現率往往偏低， 考核如果不將此納入進來也可以將其 作為測試改進的一項重要數據進行收集。進度偏離度 : 檢查計劃時間和實際時間的進度，方法是計劃時間差額減去實際時間差額除于實際工時總 和，用于考察測試人員進度情況，監控測試是否按照日程進行，是否滿足了工程的進度要求。公式：刀（計劃開始時間-實際開始時間）+刀（計劃結束時間-實際結束時間）/總工時參

20、考指標： 15 進度偏離是個相對的指標，可能偏離了 20 個工作日，但是對于一個長達半年時間的 測試而言偏離天數比上整體測試所需天數不足 15 ，可能偏離了 3 個工作日，但是對于一個只有 1 星期時間的測試已經超過了整個測試階段所需天數的 60 。注意：計算時分子分母要保持一致， 即開始或結束時間已經去除了非工作日時間， 則總工時也要去除非 工作日時間。 因為制定計劃時是根據每個公司的工作日來制定的， 也就是說， 考慮了非正常工作日的日 程。測試進度也是考核很重要的一步， 如果沒有進度保證， 所有的測試都存在風險， 第一種方法是測試人員 可以采用自下而上的方式向測試經理報告計劃用時， 這種方

21、式風險比較少， 個人根據自己能力大小確定， 但是缺點是存在測試人員虛報可能性。 另一種方法是測試經理進行估算后分配工作日程， 這時估算是很 重要的前提，除了依賴于測試經理的經驗外，對評估結果進行同行評審是很客觀可取的方法。缺陷發現率 : 測試人員各自發現的缺陷數總和除于各自所花費的測試時間總和。由于執行效率不能足夠 代表測試人員是否認真工作， 那么，每小時發現的缺陷數就是重要的考核指標， 你的工作可以通過這項 指標得到反饋。公式：刀缺陷數（系統測試）（個）/刀執行系統測試的有效時間（小時）參考指標：平均 1.1 個缺陷 / 小時 假使有位測試人員沒有達到 1 小時發現 1 個缺陷，那么，除非

22、產品質量高、模塊較小，否則，就是他的缺陷發現能力不如其他測試人員。當然，詳細分類中可以根據 發現重要缺陷的多少來定義缺陷發現能力。測試執行中工作質量相關指標 :缺陷數：為了更客觀度量，考慮到 bug的嚴重性、技術難度、產品類型、模塊穩定性等因素影響，不是 用“所發現的 bug 數量”，而是用“所獲得的 bug value （ 缺陷值） ”來度量，公式被定義為 :Bug_value= （ PO_Bug_NumberX 1.6 + P1_Bug_NumbeK 1.4 + P2_Bug_NumbeK 0.7 + P3_Bug_Numberx 0.3 ） x Wd x Ws x Wt其中： P0_Bu

23、g_Numbe：r 致命的（ fatal ）缺陷數量； P1_Bug_Numbe：r 嚴重的（ critical ）缺陷數量； P2_Bug_Numbe： 般的（major/normal ）缺陷數量；P3_Bug_Number 次要的（minor ）缺陷數量 Wd:技術難度系數，如 Database, Enterprise Server, Java 難度系數大，發現 Bug不容易，Wd可以定在 1.5- 5.0Ws:穩定性系數，全新模塊，Bug比較多，發現缺陷比較容易；版本越高，越穩定。Ws可以定在0.5 -1.0， 假如以 version 10.0 為 1.0, Version 1.0 =

24、1/100, Version 2.0 = 4/10, Version 3.0 =9/100,Version 8.0 = 64/100, Version 8.0 = 81/100Wt:產品類型系數，可根據實際情況和歷史數據來判斷。Wt也可以和Wc合并為一個系數。有效缺陷數 /率:被拒絕和刪除的缺陷數總和， 或者被拒絕和刪除的缺陷數總和除于缺陷總數。 這項指標 用于考察測試人員發現的、被確認為缺陷的缺陷數高低或者百分比，數和比率越低測試質量越高。公式：刀缺陷數（系統測試中被拒絕和刪除的）（個）刀缺陷數（系統測試中被拒絕和刪除的）（個）/刀缺陷數（系統測試）（個）參考指標：平均 21.9 （測試人員

25、發現的每 100 個缺陷中平均有 22 個缺陷不被開發組確認、認為 不是“缺陷” 或者錯誤錄入缺陷） 。有效缺陷比率容易給出，但是有效缺陷數具體數據要根據項目情況， 無法給出可參考的數值。注意：這項指標可能有不正確的情況， 假使缺陷被拒絕和被刪除的原因不是因為測試人員誤操作和需求 理解等自身錯誤引起， 而是系統本身不能實現或者數據錯誤引起的， 那么就要考慮剔除這部分。 對于測 試人員發現系統框架根本性的、 初始化參數設置錯誤引發的、 錯誤數據、 錯誤環境等而開發人員因無法 修正、 可以通過改變環境而無需修改程序、 重新導入數據、 再次發布從而拒絕或刪除的缺陷， 應給予此 測試人員獎勵。嚴重缺陷

26、率 : 這個比例用于彌補缺陷發現率的不足。主要是根據嚴重程度分類的缺陷數比全部缺陷或者 有效缺陷數。一般而言，每個公司基本把缺陷嚴重程度分為嚴重、一般和微小，或者更細（通常等級數 為奇數）。另外，可以對缺陷嚴重程度進行折算（嚴重：一般：微小 =1 ： 3 ： 5 ）通過折算可以得 出權重，然后在計算測試人員分值。公式：刀嚴重/ 一般/微小/刀缺陷數刀嚴重/ 一般/微小/刀有效缺陷數參考指標： 嚴重 10% 一般 70% 微小 20% 。當測試人員發現的缺陷中嚴重錯誤比率越高， 說明測試 質量相對就好，通常嚴重程度缺陷數的分布呈正態分布。模塊缺陷率 : 這個指標主要是根據一個單獨測試模塊的缺陷數

27、除于模塊本身功能點數得出來的。假使一 個模塊是單獨測試的話， 很容易可以和其他模塊進行指標橫向對比， 參照對應的測試人員， 得出所測試 模塊的缺陷數，可以考察測試人員測試水平，也為開發考核提供數據。公式：刀缺陷數（系統測試（個）/功能點（個）刀缺陷數（系統測試（個）/子功能點（個）參考指標 平均 3.74 個缺陷 / 功能點 1 個缺陷 / 子功能點 注意：有些功能點沒有子功能點，計算子功能點時要進行說明。 遺漏缺陷率 : 發布后的線上故障， 現階段測試相關的故障主要都是因為測試遺漏， 有遺漏就說明我們的 測試還是效率不高，可以改進。公式：刀遺漏缺陷數/ （刀遺漏缺陷數+刀遺漏版本發現缺陷數）

28、Bug 發現的時間點， bug 曲線的收斂性，理想的效率高的模式應該是前多后少，慢慢收斂的，如果前期bug非常少，后期卻發現大量 bug,那我們的前期效率就有問題。缺陷定位和可讀性：可讀性內容包括Bug描述的規范性，分優秀、良好、普通與不合格，描述是否清晰， 問題定位的附件是否完備等。 如果一個測試人員只會通過頁面將現象表達出來， 而無法定位這種現象是 有什么引起的，或者無法定位該缺陷到底錯在何處，那么可以判定測試人員只是做了簡單的表面測試， 并沒有對所發現問題進行分析定位。對技術組 （性能自動化和環境 ）測試人員效率的度量 : 自動化測試的引入和使用是否合理，不是每個項目都適合做自動化的，自

29、動化并不能保證效率的提高，用5個小時開發的自動化腳本來替代 3個小時的手工測試并不合算，自動化測試需要評審，按照項目的大小不同， 必要的情況下才引入自動化測試。 自動化測試，特別是性能測試結束之后，我們要分析部分測試結果，測試結果的分析水平，也可以作為衡量 測試效率的一個指標。對測試項目負責人的效率的度量 :測試是否提早介入項目，例如 FRD階段就介入，越早介入，越有利于測試，使測試人員更加熟悉整個項目， 使問題早暴露，提高整體效率。開發提交測試的時候，標準是否合理，把關是否嚴格，如果開發的質量不行，堅決要退回，不然會影響測試 的效率和進度。測試計劃階段，評價測試計劃的合理性，包括任務細化，細

30、化的程度是否合理，任務順序，資源安排，任務 分配合理，風險預估等等。項目結束后，評價項目進行階段中負責人的跟進情況，特殊情況處理，風險觸發之后的處理，資源協調，信 息收集，共享，溝通，配合等等。測試管理。計劃質量:測試計劃的評審缺陷數或比率，可以與其他同類型項目或數據庫平均指標進行對比。刀缺陷數（評審和同行評審）（個）/刀測試計劃文檔頁數（頁）成本質量 : 成本度量主要放在工作量這塊。因為無論涉及工資還是獎金，都要和工作量掛上關系。成本質量主 要是對測試活動的計劃工作量總和比上實際的工作量數值總和。對測試人員考核的進度偏離已經考慮了進度 因素，而工作量涉及的是成本因素。公式：刀測試活動計劃工作

31、量（估算人日）/刀測試活動的實際工作量（人日）參考指標：原則上不能偏離計劃的土 15 %±20 %。實際上，這個指標是對成本的一種度量。對于一個大的項目來說，估算值往往差距非常大，階段統計時可能有± 500 ！這時調整計劃是很必要的，在最 終階段取考慮計算平均估算值。一個測試經理必須對完成任務的成本進行有效控制。這兩項指標是相對容易 量化的部分，而需要添加其他量化指標需要綜合考慮由項目經理和測試部部門經理給出標準，例如管理用時 比率（整個項目測試期間管理時間占整個項目測試總時間） 、系統整體缺陷數與其他同類型項目或數據庫平均 指標進行對比等等。考核具體方法 :將各項指標進行

32、匯總分析， 得出總和表格， 根據測試人員各項指標大小進行排行榜制作， 如列出 1 、2 、3 、 4 名。確定階段涉及的權重。例如將測試設計和測試執行權重各為 50 %。其中，工作效率占 40 %（即占所在階 段 20 %），工作質量占 60 %（即占所在階段 30 %）。確定每類指標的分值， 然后每類指標達到平均標準給 100 %，達不到或者超過根據 80 % 120 %比率給分。 將比分統計出來后進行綜合評定，必要的話增加一些調整系數。最好將定性分析納入進來，采用問卷調查和項目經理評分制度給出定性指標分數，建議這部分權重不要超過10 %15 %以保證測試考核的可度量性。當所有考核分數給出之

33、后，提醒一點的是，既然做了考核，就必須公開這些結果，而且考核具有導向型，不 要讓考核誤導了對質量工作的追求才是最重要的。考核注意事項 :項目并不是一個月就能完成的，如每月進行，要考慮“可考核部分”為那些，挑選那些指標能夠橫向對比， 然后分階段、分任務評定。參與測試的時間長短也要給予重視，除了上述量化指標外，測試人員整體投入時間長短也是很重要的，加班 也要作為特殊考慮因素，也許某個測試人員只參加了測試執行 3 小時，各項指標都是良好的，但是不可能給 他比其他參與時間更長的人員更多的分數。這部分就是增加調整系數的原因。測試經理的測試設計和執行部分和項目測試人員一起考核，但是測試管理工作要單獨考核，

34、作為另外的加分， 或者如文章前面所述納入項目組給予考核。 因為測試經理在項目測試中起著管理者和質量保證負責人的角色， 不要把他和其他測試工程師平等對待。考核前要考慮項目的實際情況，不要盲目的輕易承諾測試組人員考核會和薪金或者淘汰機制掛鉤，否則考核會起到反效果。作為考核者要注意以下比例，也許有些沒有列入考核內容，但是如下這些點可以指導測試。測試團隊發現的bug和所有bug之間的比例spec設計造成的bug重復或者誤提交的bug所占的比例每周發現的bug的趨勢圖Bug嚴重等級的構成比例Bug從提交到解決的平均需要時間Bug從解決到關閉的平均需要時間項目組測試人員考核的主要目的是在于激勵測試組測試人

35、員工作，鼓勵能者，鞭策落后；另外，還可以起到發現人才和查 找不足的作用。考核中即要體現多勞多得的原則，也要體現公正性和合理性原則，獎罰分明才能有效促使質量管理工作的 進步。要想考核得到滿意的效果，上述方法的重要的前提條件是：必須要在項目中充分收集相關的數據，包括采集缺陷數, 記錄工時、提交詳細工作日志和進行文檔配置管理，沒有這些數據，定量分析就無從談起，測試人員考核也無從談起。3. 測試人員工作度量測試度量主要從3部分開展工作：一個是缺陷數據的統計分析，第二個是工作量的統計分析，第三個是測試工作量的估算。 缺陷的統計分析。主要是從缺陷嚴重性、優先級、模塊缺陷的分布、缺陷的收斂情況、缺陷的修復情

36、況進行統計， 并根據統計結果，進行一定的分析。工作量的統計分析。日常工作量的記錄，這個由團隊成員自己編寫。在填寫工作記錄時，需要為每個工作記錄選擇相應的任務類 型，并且工作任務持續時間最長不超過4小時。每星期統計本周團隊成員在各個項目中的投入情況。不僅讓自己了清楚，也讓上司了解測試部對于項目的支持情況。每半個月統計整個團隊的工作分配情況（但是數據是每周都填寫的）統計每個人在各個項目的工作量分配情況。這個和上面那個統計表的側重點不一樣，上面這個統計表側重在部門整體，現在這個表側重于個體。定期（如每周或半個月）將團隊成員在項目中的工作量投入情況記錄到項目工作量投入表中。這個表格主要用 于統計具體每

37、個項目的測試工作投入情況，及作為后續測試工作量估算的原始數據。在項目到達一個階段后，將項目測試收集的數據進行匯總、統計。收集的數據除項目基本信息外，還包括工 作量、測試投入成本、項目規模、項目總成本、項目總工作量。主要分析測試在項目中的投入情況、成本情 況、各個測試任務的分配情況等。最后，根據對幾個項目的工作量、成本以及測試任務占項目總測試投入的比例分析后，得到測試團隊測試工作量估 算的簡易公式。可以根據這個簡易的公式進行測試的估算，方便測試計劃中關于工作量估算部分的編寫，避免在估 算工作量時缺乏依據。估算內容主要包括：測試總人力成本占項目總人力成本的比例及各項測試任務的工作量分配 比例。測試

38、任務比例測試任務比例測試任務比例熟悉系統需求5%測試計劃3.5%測試需求7.5%測試用例15%測試執行40%測試報告4%測試管理7%溝通、會議4%測試環境搭建2%性能測試9%驗收測試4%4. 效率提高測試負責人與開發負責人共同對項目進度進行商討分析，作出合理的測試計劃，并在測試執行過程中嚴格按照測試 計劃的進度和測試策略進行。測試人員盡早的進入需求理解階段，充分理解需求文檔。 必要時做跟進測試，提高需求理解深度，可間接提高測試執行的效率；跟進測試，即系統測試之前的草稿版測試， 需要與開發方溝通，讓其協助來執行。跟進測試的目的不是發現bug，而是熟悉系統環境，助于需求理解和測試設計。盡量避免失敗的接收測試。一次版本無法接收，會浪費很多人力和時間，還會影響測試人員的測試熱情。任務分配合理化。測試負責人應根據項目組成員的經驗和能力能個人因素，合理的分配測試任務，并將測試任務的 模塊和時間詳細化，這樣有助于提高整個項目的測試效率。測