測試人員績效考核詳細

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17、于比較就使用缺陷 / 頁方式進行橫向?qū)Ρ?。文檔有效率 : 使用測試用例文檔進行測試時發(fā)現(xiàn)的系統(tǒng)測試缺陷數(shù)除于此文檔頁數(shù)。用于考察文檔是由 有效的指導(dǎo)了測試工作。公式：刀缺陷數(shù)（系統(tǒng)測試）（個）/刀測試用例文檔頁數(shù)（頁）參考指標：平均 2.18 個缺陷 / 頁 注意：如果存在測試人員在測試時創(chuàng)建新文檔用于輔助測試時應(yīng)包含這一部分。用例有效率 : 使用測試用例發(fā)現(xiàn)的全部缺陷除于測試用例數(shù)總和。這一指標是上一指標的補充指標，用 于考察用例質(zhì)量是否較高公式：刀缺陷數(shù)（系統(tǒng)測試）（個）/刀測試用例數(shù)（個）參考指標： 平均 0.59 個缺陷 / 用例，也就是說， 每執(zhí)行兩個用例才得到 1 個缺陷，各工程有

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

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

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

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

22、產(chǎn)品質(zhì)量高、模塊較小，否則，就是他的缺陷發(fā)現(xiàn)能力不如其他測試人員。當然，詳細分類中可以根據(jù) 發(fā)現(xiàn)重要缺陷的多少來定義缺陷發(fā)現(xiàn)能力。測試執(zhí)行中工作質(zhì)量相關(guān)指標 :缺陷數(shù)：為了更客觀度量，考慮到 bug 的嚴重性、技術(shù)難度、產(chǎn)品類型、模塊穩(wěn)定性等因素影響，不是 用“所發(fā)現(xiàn)的 bug 數(shù)量”，而是用“所獲得的 bug value （ 缺陷值） ”來度量，公式被定義為 :Bug_value=（PO_Bug_NumberX1.6 + P1_Bug_NumbeK1.4 + P2_Bug_NumbeK0.7 + P3_Bug_Numberx0.3） xWdxWsxWt其中：P0_Bug_Numbe： r 致

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

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

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

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

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

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

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

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

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

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

33、考核，就必須公開這些結(jié)果，而且考核具有導(dǎo)向型，不 要讓考核誤導(dǎo)了對質(zhì)量工作的追求才是最重要的?？己俗⒁馐马?:項目并不是一個月就能完成的，如每月進行，要考慮“可考核部分”為那些，挑選那些指標能夠橫向?qū)Ρ龋?然后分階段、分任務(wù)評定。參與測試的時間長短也要給予重視，除了上述量化指標外，測試人員整體投入時間長短也是很重要的，加班 也要作為特殊考慮因素，也許某個測試人員只參加了測試執(zhí)行 3 小時，各項指標都是良好的，但是不可能給 他比其他參與時間更長的人員更多的分數(shù)。這部分就是增加調(diào)整系數(shù)的原因。測試經(jīng)理的測試設(shè)計和執(zhí)行部分和項目測試人員一起考核，但是測試管理工作要單獨考核，作為另外的加分， 或者如文

34、章前面所述納入項目組給予考核。 因為測試經(jīng)理在項目測試中起著管理者和質(zhì)量保證負責人的角色， 不要把他和其他測試工程師平等對待?？己饲耙紤]項目的實際情況，不要盲目的輕易承諾測試組人員考核會和薪金或者淘汰機制掛鉤，否則考核會起到反效果。作為考核者要注意以下比例，也許有些沒有列入考核內(nèi)容，但是如下這些點可以指導(dǎo)測試。測試團隊發(fā)現(xiàn)的 bug 和所有 bug 之間的比例spec 設(shè)計造成的 bug重復(fù)或者誤提交的 bug 所占的比例每周發(fā)現(xiàn)的 bug 的趨勢圖Bug 嚴重等級的構(gòu)成比例Bug 從提交到解決的平均需要時間Bug 從解決到關(guān)閉的平均需要時間項目組測試人員考核的主要目的是在于激勵測試組測試人

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

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

37、體每個項目的測試工作投入情況，及作為后續(xù)測試工作量估算的原始數(shù)據(jù)。在項目到達一個階段后，將項目測試收集的數(shù)據(jù)進行匯總、統(tǒng)計。收集的數(shù)據(jù)除項目基本信息外，還包括工 作量、測試投入成本、項目規(guī)模、項目總成本、項目總工作量。主要分析測試在項目中的投入情況、成本情 況、各個測試任務(wù)的分配情況等。最后，根據(jù)對幾個項目的工作量、成本以及測試任務(wù)占項目總測試投入的比例分析后，得到測試團隊測試工作量估 算的簡易公式。可以根據(jù)這個簡易的公式進行測試的估算，方便測試計劃中關(guān)于工作量估算部分的編寫，避免在估 算工作量時缺乏依據(jù)。估算內(nèi)容主要包括：測試總?cè)肆Τ杀菊柬椖靠側(cè)肆Τ杀镜谋壤案黜棞y試任務(wù)的工作量分配 比例。

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