軟件測試工程師績效評估表正式版

1、軟件測試工程師績效評估表正式版軟件測試工程師績效評估表軟件測試工程師職責(zé)：1 與軟件產(chǎn)品部配合完成軟件需求分析討論， 并根據(jù)需求說明書制定 項目測試 （計劃） 方案；編寫測試用例 ；建立測試環(huán)境；2 負責(zé)研發(fā)部門各開發(fā)組研發(fā)的軟件產(chǎn)品開發(fā)過程和投入運營之前的新增軟件和修改 軟件的模塊測試和系統(tǒng)測試；建立、推廣并維護實施軟件版本管理系統(tǒng)；3 負責(zé)推廣實施軟件開發(fā)文檔規(guī)范化工作，管理研發(fā)產(chǎn)品相關(guān)文檔；4 負責(zé)配合軟件研發(fā)部門等對于新項目軟件或修改升級項目軟件的測試工作， 并提供測 試報告；5 負責(zé)監(jiān)督軟件開發(fā)流程的執(zhí)行， 并負責(zé)提出軟件開發(fā)過程改進建議， 提高軟件產(chǎn)品質(zhì) 量。6 與開發(fā)工程師和研發(fā)

2、部門交流報告任務(wù)進展情況，并提出最近的測試需求；7 測試部負責(zé)制訂測試計劃、 測試用例和測試實施方案， 項目主負責(zé)人安排測試與對應(yīng) 的開發(fā)人員交流完成測試執(zhí)行工作；及時提交準確、完整的項目測試報告 ；8 項目主負責(zé)人負責(zé)開發(fā)流程管理和人力資源、測試用軟硬件資源調(diào)配，需要與研發(fā)之 外的部門定期交流掌握下周或近期可能測試任務(wù)；9 外部接口都由測試部主管負責(zé)完成，與其他項目組和產(chǎn)品部門協(xié)調(diào)項目進度；軟件測試的不確定性：1 軟件測試的目的就是使軟件的錯誤不斷趨進于零，但軟件的錯誤是永遠找不完的；2 開始測試時，可能軟件使用 1 個小時就出現(xiàn) 10 個錯誤；測試修正后 1 個小時出現(xiàn)一 個錯誤，繼續(xù)修正

3、，繼續(xù)測試，直到約一個月出現(xiàn)一個錯誤。這時這個出錯幾率已 經(jīng)通過終結(jié)評審可以接受了。那么測試就結(jié)束了。移植成功之后測試工作由開發(fā)部 門來維護。3 測試一些成熟的游戲或應(yīng)用，測試過程中很難發(fā)現(xiàn)大量的缺陷；而測試一些不成熟 的游戲或應(yīng)用，在測試前期，會出現(xiàn)大量的問題；這樣就導(dǎo)致不同的工程師發(fā)現(xiàn)不 同數(shù)量的 bug；4 軟件測試的進度首先會按照測試計劃逐步進行， 但是在測試過程中， 測試進度會隨研 發(fā)部門的進度而調(diào)整； 所以積極的與研發(fā)部門交流、 協(xié)調(diào)測試中的問題是相當(dāng)必要的。三測試工作最低成功標準及測試工程師考核內(nèi)容： 測試工作的最終目標就是發(fā)現(xiàn)客戶可能發(fā)現(xiàn)的所有錯誤。 如果移植測試在使用第一天

4、就發(fā)現(xiàn)了你沒測試出來的錯誤， 那測試是失敗的。 如果使用了很久 （如幾個月）才出 現(xiàn)錯誤，那說明測試還是成功的 。測試工程師考核內(nèi)容：1 測試工程師比開發(fā)工程師更了解產(chǎn)品； （產(chǎn)品各模塊總體把握能力）2 測試工程師能從客戶的角度來檢測軟件的功能； （用戶身份）3 測試工程師獲取資料，使得編制的測試用例更切合測試的重點、難點以及關(guān)注點；（編寫測試用例）4測試工程師比開發(fā)工程師更容易發(fā)現(xiàn)產(chǎn)品的問題；（不同的思維模式）5測試工程師總是不斷的發(fā)現(xiàn)問題，驗證問題；（提交bug數(shù)量、bug質(zhì)量）6測試工程師按照測試計劃完成各自工作；（測試計劃的執(zhí)行能力）7測試工程師以操作員的角度測試產(chǎn)品；（Free測試能

5、力）8測試工程師及時與開發(fā)工程師溝通、交流解決問題；（部門間的工作協(xié)調(diào)能力）9測試工程師及時提交測試報告；（報告的及時性、準確性）10測試工程師之間處理問題；（共同完成任務(wù)）11測試工程師協(xié)助開發(fā)工程師，了解開發(fā)流程等信息；（學(xué)習(xí)能力）四軟件測試人員工作業(yè)績評估的誤區(qū)：1不能僅從提交的問題數(shù)量、測試執(zhí)行用例數(shù)量來判斷測試人員的好壞；模塊A很不穩(wěn)定，潛在的問題數(shù)可能有100個，由測試人員甲負責(zé)測試，他一個月執(zhí)行300個用例，提交50個問題單，發(fā)現(xiàn)30個有效問題，有10個嚴重問題；模塊B比較穩(wěn)定，潛在的問題數(shù)可能有20個，由測試人員乙負責(zé)測試，他一個月執(zhí)行100個用例，提交20個問題單，發(fā)現(xiàn)18個

6、有效問題，有8個嚴重問題；從上述測試執(zhí)行結(jié)果來看，甲提交的問題單數(shù)量和執(zhí)行用例數(shù)量都要遠遠高于乙，但是從測試的質(zhì)量來看，模塊 B的遺留問題顯然少于模塊 A,甲執(zhí)行測試的充分性顯然不如 乙，從問題單質(zhì)量來看，甲提交的問題單雖然很多，但近半數(shù)是非問題，做了無用功， 還影響到開發(fā)人員對問題的定位所消耗的時間。因此，必須要走出用問題單數(shù)量、用例數(shù)量評價測試人員的誤區(qū)。2對軟件人員發(fā)現(xiàn)的問題的價值沒有進行評估；發(fā)現(xiàn)一個系統(tǒng)架構(gòu)設(shè)計方面的缺陷和隱患遠比發(fā)現(xiàn)幾個普通界面顯示問題的價值大的多；3不重視測試文檔的質(zhì)量；測試文檔的質(zhì)量往往是測試人員測試水平的反映；只有對系統(tǒng)進行了統(tǒng)分的、深入的測試人員才能寫出高質(zhì)

7、量的測試報告；4不重視測試人員的綜合能力；責(zé)任心、積極性、創(chuàng)造性以及溝通和協(xié)調(diào)能力附：軟件測試工程師業(yè)績評估模板：（滿分：100分）軟件測試工程師業(yè)績評估模板：（滿分：100分）類型評定參數(shù)參數(shù)值說明提交有效問題數(shù)量單位（個）最基本的考核指標問題(35%)提交的非問題數(shù)量單位（個）需要測試人員意識到處理非問題影響測試、開發(fā)的工作效 率；測試主管必須嚴格審核測試人員提交的bug提交問題的規(guī)范性優(yōu)秀良好普通 不合格問題描述是否清晰；相關(guān)trace文件是否齊全； 問題等級、版本等信息是否正確； 問題跟蹤是否到位；嚴重問題所占比例單位（%）（嚴重問題/問題總數(shù)）*100%提交問題的質(zhì)量非常好很好一般

8、良好 低綜合評定測試人員提交問題的質(zhì)量； 測試人員發(fā)現(xiàn)問題的深入程度；工作效率提交bug驗證bug優(yōu)秀 良好 普通 不合格對自己所提交問題的多版本跟蹤；Check他人bug的程度；不同模塊功能的理解程度；測試用例（20%）執(zhí)行用例覆蓋率開發(fā)用例難度困難 普通 容易編寫測試用例質(zhì)量用力的難度直接反映測試人員的測試能力；并影響測試效率；FREE TEST用例外，測試發(fā)現(xiàn)問題的能力新增測試用例價值新增測試用例質(zhì)量文檔（15%）測試報告質(zhì)量優(yōu)秀良好 普通 不合格測試報告的規(guī)范化程度； 及時性； 準確性；內(nèi)部測試文檔、測試 經(jīng)驗的交流及共享經(jīng)常偶爾從不測試工作的協(xié)調(diào)； 經(jīng)驗的交流； 問題的確定；等等態(tài)度

9、（30%）工作積極性優(yōu)良中差主動解決測試中遇到的問題；溝通能力根據(jù)實際情況，分析評價；學(xué)習(xí)能力不斷的提高工作效率；項目了解（主動性）對項目總體的把握；測試計劃的執(zhí)行執(zhí)行計劃；部門間團結(jié)協(xié)作各部門相互配合解決問題；上級主管綜合評定及意見綜合評定：部門經(jīng)理給岀測試人員考核評定及意見附：軟件測試工程師業(yè)績評估模板評估類型績效指標評價標準分值軟件測試績 效工作態(tài)度嚴格遵守各項工作制度和崗位要求。工作認真負責(zé)，責(zé)任心強。能夠主動進行工作溝通、交流。主動發(fā)現(xiàn)問題，并且跟蹤解決。積極參與測試組各項活動，能夠主動承擔(dān)組內(nèi)工作。16-20 分1、工作制度2、工作認真3、工作積極4、溝通、交5、主動性、遵守各項工

10、作制度和崗位要求。 工作認真負責(zé)，責(zé)任心強。能夠主動進行工作溝通、交流。主動發(fā)現(xiàn)問題，基本能做到跟蹤解決。參與測試組各項活動，能夠承擔(dān)組內(nèi)工作任務(wù)。11-15 分遵守各項工作制度和崗位要求。工作認真負責(zé)，責(zé)任心強。能夠進行工作中基本溝通、交流。發(fā)現(xiàn)問題，缺少跟蹤解決。參與測試組各項活動，能夠承擔(dān)組內(nèi)工作。6-10 分測試用例測試BUG有督導(dǎo)情況下基本能遵守各項工作制度和崗位要求。能基本按要求完成任務(wù)。進行基本工作溝通、交流。發(fā)現(xiàn)問題，缺少跟蹤解決?；灸軈⑴c測試組各項活動，不能夠承擔(dān)組內(nèi)工作嚴格按照用例模版編寫用例根據(jù)需求設(shè)計有效用例，覆蓋所有的需求點。 用例描述準確、簡潔、清晰，評審?fù)ㄟ^率高

11、。按計劃執(zhí)行用例并且能夠及時補充用例保證用例完 整性，對于無法執(zhí)行或不具備環(huán)境不能法執(zhí)行用例 及時溝通，并且測試結(jié)果中具體說明。能夠按照用例模版編寫用例根據(jù)需求設(shè)計有效用例，基本覆蓋所有的需求點。 用例描述比較準確、簡潔、清晰，評審?fù)ㄟ^率高。按計劃執(zhí)行用例并且能夠及時補充用例保證用例完 整性，對于無法執(zhí)行或不具備環(huán)境不能執(zhí)行用例及 時溝通。并且測試結(jié)果中具體說明。在有人員指導(dǎo)情況下達到以下標準或者個人獨立工 作達到以下要求能夠按照用例模版編寫用例根據(jù)需求設(shè)計有效用例，基本覆蓋主要功能的需求 點。用例描述基本準確、簡潔、清晰，通過評審可以達 到要求。基本按計劃執(zhí)行用例并且基本能及時補充用例保證

12、用例完整性。對于無法執(zhí)行或不具備環(huán)境不能執(zhí)行 用例基本做到及時溝通，并且測試結(jié)果中具體說明基本能按照用例模版編寫用例根據(jù)需求設(shè)計有效用例，沒有覆蓋所有的需求點。 用例描述基本準確、簡潔、清晰，通過評審可以達 到要求。不能按計劃執(zhí)行用例并且能夠及時補充用例保證用 例完整性。對于無法執(zhí)行或不具備環(huán)境不能執(zhí)行用 例基本做到及時溝通能夠按照規(guī)定的流程提交并跟蹤BUG的全過程BUG描述語言簡潔、準確。BUG再現(xiàn)步驟清晰、條理性強，易于再現(xiàn)。依據(jù)需求提交相應(yīng) BUG沒提交錯誤BUG 能夠分析和定位產(chǎn)生的原因，并能根據(jù)BUG的產(chǎn)生0-5分9-10 分6-8分3-5分0-2分9-10 分1、2、3、4、5、6

13、、1、2、3、4、5、測試用例 設(shè)計有效 用例描述 用例評審 用例執(zhí)行 用例及時工作能力趨勢做岀有效的質(zhì)量和風(fēng)險風(fēng)析能夠按照規(guī)定的流程提交并跟蹤BUG的全過程。BUGB述語言較簡潔、較準確。BUG再現(xiàn)步驟較清晰、條理性較強，易于再現(xiàn)。 依據(jù)需求提交相應(yīng) BUG很少提交錯誤 BUG 能夠完成基本分析和定位產(chǎn)生的原因，基本并能根 據(jù)BUG的產(chǎn)生趨勢做岀有效的質(zhì)量和風(fēng)險風(fēng)析。 在有人員指導(dǎo)情況下達到以下標準或者個人獨立工 作達到以下要求：基本能夠按照規(guī)定的流程提交并跟蹤BUG的全過程BUGB述語言基本完整。BUG再現(xiàn)步驟基本清晰、條理性不強，可以再現(xiàn)。 依據(jù)需求提交相應(yīng) BUG岀現(xiàn)提交錯誤 BUG

14、能夠協(xié)助開發(fā)再現(xiàn)，定位 bug。對bug進行基本總結(jié)。能夠按照規(guī)定的流程提交并跟蹤BUG的全過程提交的BUG有三分之一描述語言不準確BUG有三分之一出現(xiàn)步驟不清晰、條理性差，難于再現(xiàn)。依據(jù)需求基本能提交相應(yīng) BUG岀現(xiàn)錯誤BUG 能夠按時或提前完成工作計劃，并且內(nèi)容有效、準 確、合理，使人能清楚地把握工作進展和動態(tài)。能夠按時或提前完成任務(wù)，并且按要求完成各項分 配的工作，工作成果符合要求，準確率高。能夠通對過程和執(zhí)行結(jié)果的分析、評估，形成準確 的測試報告。善于溝通，能自發(fā)與人合作，積極配合，容易和他 人達成工作默契。熟練掌握測試基本技能，技巧，熟練掌握項目業(yè)務(wù)、 了解業(yè)務(wù)領(lǐng)域知識，對測試需求把

15、握到位，能夠獨 立承擔(dān)完整的測試工作。6-8分3-5分0-2分16-20 分1、計劃能力2、執(zhí)行能力3、分析、總4、溝通、交5、業(yè)務(wù)能力試技能）工作改進能夠按時完成工作計劃，并且內(nèi)容較有效、較準確、 較合理，使人能比較清楚地把握工作進展和動態(tài)。 能夠按時并且按要求完成各項分配的工作，工作成 果比較符合要求，準確率較高。能夠通對過程和執(zhí)行結(jié)果的分析、評估，形成較準 確的測試報告。具有團隊意識，樂于與人溝通協(xié)調(diào)，順利達成組織 任務(wù)。熟悉掌握測試基本技能，技巧，熟悉項目業(yè)務(wù)、了 解業(yè)務(wù)領(lǐng)域知識，對測試需求把握比較到位，能夠 獨立承擔(dān)完整的測試工作。11-15 分基本能夠按時完成工作計劃，并且內(nèi)容基本

16、有效、 基本準確、基本合理，使人能基本清楚地把握工作 進展和動態(tài)?；灸軌虬匆笸瓿筛黜椃峙涞墓ぷ鳎ぷ鞒晒?本符合要求，準確率較高。能夠通對過程和執(zhí)行結(jié)果的分析、評估，形成測試 報告。有一定的團隊意識，能夠維護團隊形像，尚能與人 合作，達成共同目標。熟悉掌握測試基本技能，技巧，熟悉項目業(yè)務(wù)、了 解業(yè)務(wù)領(lǐng)域知識，對測試需求把握比較到位，能夠 獨立承擔(dān)完整的測試工作。6-10 分很少能夠按時完成工作計劃，并且內(nèi)容有效、不準 確、不合理，使人不能清楚地把握工作進展和動態(tài)。 很少能夠按要求完成各項分配的工作，工作成果基 本符合要求。能夠通對過程和執(zhí)行結(jié)果做簡單分析、評估，形成 測試報告。團隊合作意

17、識不強，工作配合中存在較多不足，協(xié) 調(diào)不善，致使工作推進緩慢掌握一些測試基本技能，技巧，了解項目業(yè)務(wù)、了 解業(yè)務(wù)領(lǐng)域知識，基本能把握測試需求，在他人指 導(dǎo)下能夠承擔(dān)部分的測試工作。0-5分積極發(fā)現(xiàn)工作過程中存在的問題，提出改進方法， 能夠解決問題（涉及團隊）主動學(xué)習(xí)新的工具和新的知識改進測試工作，提高工作效率，改進工作產(chǎn)品質(zhì)量（涉及團隊）主動開展專項培訓(xùn)，分享學(xué)習(xí)和研究成果，幫助團 隊其它成員提高。9-10 分1、共享、培2、新知識、3、工具學(xué)習(xí)4、工作效率5、工作質(zhì)量積極發(fā)現(xiàn)工作過程中存在的問題，提出改進方法， 能夠解決問題（個人相關(guān)工作）主動學(xué)習(xí)新的工具和新的知識。改進測試工作，提高工作效

18、率，改進工作產(chǎn)品質(zhì)量。（個人相關(guān)工作）主動開展專項培訓(xùn)，分享學(xué)習(xí)和研究成果，幫助團 隊其它成員提高。6-8分作為交辦的事情愿意做如下改進：發(fā)現(xiàn)工作過程中存在的問題，提岀改進方法，能夠 解決問題。學(xué)習(xí)新的工具和新的知識。改進測試工作，提高工作效率，改進工作產(chǎn)品質(zhì)量。 開展專項培訓(xùn)，分享學(xué)習(xí)和研究成果，幫助團隊其 它成員提高。3-5分墨寸成規(guī)或沒有意識做如下改進：發(fā)現(xiàn)工作過程中存在的問題，提岀改進方法，能夠 解決問題。學(xué)習(xí)新的工具和新的知識。改進測試中存在的問題，提高工作效率，改進工作 產(chǎn)品質(zhì)量。主動開展專項培訓(xùn)，分享學(xué)習(xí)和研究成果，幫助團 隊其它成員提高。0-2分說明：共5項，每項10分，共70

19、分 備注：1. 盡量對交付物進行評估，保持相對的客觀性;2. 評估以季度為單位；3. 獎勵評估結(jié)果為 A B的員工；4. 人員在試用期不參與該評估；電氣工程師考核評分表（月度）考核期間：年月姓名崗位任 務(wù) 績 效序 號考核項目具/、體工作權(quán)重指標要求評分等級得分自 評上級結(jié)果1進度控制詳 見 工 作 分 析 表的具/、 體 工 作10%嚴格按照施工總 進度計劃中分部 分項工程的重要 節(jié)點（線管預(yù)留 預(yù)埋、室內(nèi)穿線 安裝、外網(wǎng)工程） 完成情況考核1、節(jié)點提前完工或通過 提前糾偏達到控制要求，10分2、主要節(jié)點考核每出現(xiàn) 1 次延誤，扣1分；3次0 分3、延誤后無可行的糾偏 落實方案，1次扣1分4

20、、嚴重影響工程進度造 成工程延誤0分2質(zhì)量控制10%電氣工程施工質(zhì) 量達到省優(yōu)標 準；單項驗收及 綜合驗收合格通 過1、按要求完成10分2、非一次性通過驗收， 每項每次扣2分3、達不到標準0分3安全文明施工管理10%達到市文明施工 要求標準，無重 大安全事故1、按要求完成10分2、市安全文明施工檢查 不通過，5分3、一般安全事故一次扣 1 分，重大安全事故 0分4材料、設(shè)備 檢驗10%材料進場檢驗合 格率在98%上; 設(shè)備檢驗合格100%1、達到要求10分2、主要材料進場后抽驗 一次不合格扣1分； 工作失誤未檢、漏檢 一次扣1分，不合格 材料進場并使用0分3、檢驗不合格的設(shè)備進 場并使用，0分

21、5成本控制10%嚴控現(xiàn)場簽證 單、技術(shù)核定單， 確保成本控制目 標得到優(yōu)化。1、原成本控制目標實現(xiàn)10分；2、合理建議或技術(shù)優(yōu)化 降低成本10分；3、每出現(xiàn)一次不合理的 現(xiàn)場簽證扣1分6隱蔽驗收、 技術(shù)問題 處理10%隱蔽驗收及時、 準確、資料完備； 設(shè)計變更落實； 技術(shù)、質(zhì)里方面 問題處理及時準 確；1、達到要求10分；2、每失誤1次扣1分7工程例會 落實10%會議紀要逐項落 實并反饋1、達到要求10分2、落實不了又不及時上 報，每項扣1分8開工前期 協(xié)調(diào)5%達到順利開工條件1、積極參與協(xié)調(diào)5分2、每項工作不積極主動 每扣1分9外部配合5%配合職能部門1、積極參與配合5分2、不配合職能部門0

22、分10內(nèi)業(yè)工作5%內(nèi)業(yè)完整，施工 日記工整清晰1、達到要求5分2、檢查不合格一次扣0.5復(fù)查不合格一次扣1分11集團配合5%積極參與并完成1、達到要求5分2、不積極主動參與，接 到投訴每次扣1分12內(nèi)部配合5%專業(yè)上積極主動 配合其他工程師 工作1、達到要求5分2、不積極主動配合，接 到反映每次扣1分13維修協(xié)調(diào)5%積極配合物業(yè)處 理維修投訴1、達到要求5分2、不積極主動配合，接 到反映每次扣1分加權(quán)合計行 為 考 核序 號行為指標權(quán)重指標說明考核評分自 評上 級結(jié)果1承擔(dān)責(zé)任25%1級：承認結(jié)果，而不是強調(diào)愿望 2級：承擔(dān)責(zé)任，不推卸，不指責(zé) 3級：著手解決問題，減少業(yè)務(wù)流程 4級：舉一反三

23、，改進業(yè)務(wù)流程5級：做事有預(yù)見，有防誤設(shè)計1級5分2級10分3級15分4級20分5級25分2主動性25%1級：等候指示2級：詢冋有何工作可給分配3級：提出建議，然后再作有關(guān)行動4級：行動，但例外情況下征求意見5級：單獨行動，定時匯報結(jié)果1級5分2級10分3級15分4級20分5級25分3學(xué)習(xí)力25%1級 2級3級4級5級:有學(xué)習(xí)意識但無仃動:主動學(xué)習(xí):自費學(xué)習(xí)并得到技能:學(xué)習(xí)后用于實踐:學(xué)習(xí)后實踐并得到良好效果1級5分2級10分3級15分4級20分5級25分4團隊合作25%1級意見2級團隊3級使自4級:尊重他人，耐心傾聽，接納不同，合理和包容:直言，分享他們的觀點和信息使 前進:支持團隊（領(lǐng)導(dǎo)者

24、）的決定，即 己有不同意見:愿意提供即使是不屬自己日常工1級5分2級10分3級15分4級20分5級25分作職責(zé)范圍的幫助5級：跨邊界建立關(guān)系以發(fā)展非正式及 正式工作網(wǎng)絡(luò)加權(quán)合計總 分總分=業(yè)績考核得分X %+行為考核得分X %=考核人簽字：年月日軟件測試的起源與發(fā)展軟件測試的概念與定義軟件測試是伴隨著軟件的產(chǎn)生而產(chǎn)生的。早期的軟件開發(fā)過程中，那時軟件規(guī)模都很小、復(fù)雜程度低，軟件開發(fā)的過程混亂無序、相當(dāng)隨意，測試的含義比較狹窄，開發(fā)人員將測試等同于 調(diào)試”目的是糾正軟件中已經(jīng)知道的故障，常常由開發(fā)人員自己完成這部分的工作。對測試的投入極少，測試介入也晚，常常是等到形成代碼，產(chǎn)品已經(jīng)基本完成時才進

25、行測試。直到1957年，軟件測試才開始與調(diào)試區(qū)別開來，作為一種發(fā)現(xiàn)軟件缺陷的活動。由于一直存在著為了讓我們看到產(chǎn)品在工作，就得將測試工作往后推一點”的思想，潛意識里對 測試的目的就理解為使自己確信產(chǎn)品能工作 ”測試活動始終后于開發(fā)的活動，測試通常被做為軟件生命周期中最后一項活動而進行。當(dāng)時也缺乏有效的測試方法，主要依靠錯誤推測Error Guess in g”來尋找軟件中的缺陷。因此，大量軟件交付后，仍存在很多問題，軟 件產(chǎn)品的質(zhì)量無法保證。到了 20世紀70年代，這個階段開發(fā)的軟件仍然不復(fù)雜，但人們已開始思考軟件開發(fā) 流程的問題，盡管對 軟件測試”的真正含義還缺乏共識，但這一詞條已經(jīng)頻繁出現(xiàn)

26、，一些軟件測試的探索者們建議在軟件生命周期的開始階段就根據(jù)需求制訂測試計劃，這時也涌現(xiàn)出一批軟件測試的宗師，Bill Hetzel博士就是其中的領(lǐng)導(dǎo)者。1972年，軟件測試領(lǐng)域的先 驅(qū) Bill Hetzel 博士（代表論著The Complete Guide to Software Testi ng），在美國的北卡羅來納大學(xué)組織了歷史上第一次正式的關(guān)于軟件測試的會議。在1973年，他首先給軟件測試一個這樣的定義：就是建立一種信心，認為程序能夠按預(yù)期的設(shè)想運行。Establishconfid ence that a program does what it is supposed to do.

27、后來在 1983 年他又將定義修訂為：評價一個程序和系統(tǒng)的特性或能力，并確定它是否達到預(yù)期的結(jié)果。軟件測試就是以此為目的的任何行為。Any activities aimed at evaluati ng an attribute orcapability of a program or system.在他的定義中的 設(shè)想"和 預(yù)期的結(jié)果"其實就是我們現(xiàn)在所說的用戶需求或功能設(shè)計。他還把軟件的質(zhì)量定義為符合要求”。他的思想的核心觀點是：測試方法是試圖驗證軟件是工作的”所謂 工作的”就是指軟件的功能是按照預(yù)先的設(shè)計執(zhí)行的，以正向思維，針對軟件系統(tǒng)的所有功能點，逐個驗證其正確性。

28、軟件測試業(yè) 界把這種方法看作是的軟件測試的第一類方法。Gle nfordJ.盡管如此，這一方法還是受到很多業(yè)界權(quán)威的質(zhì)疑和挑戰(zhàn)。代表人物是Myers （代表論著The Art of Software Testi ng）。他認為測試不應(yīng)該著眼于驗證軟件是工作的，相反應(yīng)該首先認定軟件是有錯誤的，然后用逆向思維去發(fā)現(xiàn)盡可能多的錯誤。他還從人的心理學(xué)的角度論證，如果將驗證軟件是工作的”作為測試的目的，非常不利于測試人員發(fā)現(xiàn)軟件的錯誤。于是他于1979年提出了他對軟件測試的定義：測試是為發(fā)現(xiàn)錯誤而執(zhí)行的一個程序或者系統(tǒng)的過程。The process of execut ing a program or

29、systemwith the intent of finding errors.這個定義，也被業(yè)界所認可，經(jīng)常被引用。除此之外,Myers還給出了與測試相關(guān)的三個重要觀點，那就是:1、測試是為了證明程序有錯，而不是證明程序無錯誤；2、一個好的測試用例是在于它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤；3、一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試；這就是軟件測試的第二類方法，簡單地說就是驗證軟件是不工作的”或者說是有錯誤的。Myers認為，一個成功的測試必須是發(fā)現(xiàn)Bug的測試，不然就沒有價值。這就如同一個病人（假定此人確有?。?，到醫(yī)院做一項醫(yī)療檢查，結(jié)果各項指標都正常，那說明該項醫(yī) 療檢查對于診斷該病人的病情是

30、沒有價值的，是失敗的。Myers提出的 測試的目的是證偽”這一概念，推翻了過去 為表明軟件正確而進行測試 ”的錯誤認識，為軟件測試的發(fā)展指出了 方向，軟件測試的理論、方法在之后得到了長足的發(fā)展。第二類軟件測試方法在業(yè)界也很流 行，受到很多學(xué)術(shù)界專家的支持。然而，對 Glenford Myers先生 測試的目的是證偽"這一概念的理解也不能太過于片 面。在很多軟件工程學(xué)、 軟件測試方面的書籍中都提到一個概念：測試的目的是尋找錯誤，并且是盡最大可能找出最多的錯誤”這很容易讓人們認為測試人員就是挑毛病”的，而由此帶來諸多問題。大家熟悉的Ron Patt on 在軟件測試（中文版由機械工業(yè)出版

31、社出版，此書是目前國內(nèi)測試新手入門的經(jīng)典教材）一書的第10頁，有一個明確而簡潔的定義：軟件測試人員的目標是找到軟件缺陷，盡可能早一些，并確保其得以修復(fù)?！边@樣的定義具有一定的片面性，帶來的結(jié)果是：1、若測試人員以發(fā)現(xiàn)缺陷為唯一目標，而很少去關(guān)注系統(tǒng)對需求的實現(xiàn)，測試活動往往會存 在一定的隨意性和盲目性；2、 若有些軟件企業(yè)接受了這樣的方法，以Bug數(shù)量來做為考核測試人員業(yè)績的唯一指標，也 不太科學(xué)。總的來說，第一類測試可以簡單抽象地描述為這樣的過程：在設(shè)計規(guī)定的環(huán)境下運行 軟件的功能，將其結(jié)果與用戶需求或設(shè)計結(jié)果相比較，如果相符則測試通過， 如果不相符則視為Bug。這一過程的終極目標是將軟件的

32、所有功能在所有設(shè)計規(guī)定的環(huán)境全部運行，并 通過。在軟件行業(yè)中一般把第一類方法奉為主流和行業(yè)標準。第一類測試方法以需求和設(shè)計為本，因此有利于界定測試工作的范疇，更便于部署測試的側(cè)重點，加強針對性。這一點對于大型軟件的測試，尤其是在有限的時間和人力資源情況下顯得格外重要。而第二類測試方法與需求和設(shè)計沒有必然的關(guān)聯(lián)，更強調(diào)測試人員發(fā)揮主觀能動性，用逆向思維方式，不斷思考開發(fā)人員理解的誤區(qū)、不良的習(xí)慣、程序代碼的邊界、無效數(shù)據(jù)的輸入以及系統(tǒng)各種的弱點，試圖破壞系統(tǒng)、摧毀系統(tǒng)，目標就是發(fā)現(xiàn)系統(tǒng)中各種各樣的問 題。這種方法往往能夠發(fā)現(xiàn)系統(tǒng)中存在的更多缺陷。到了上世紀80年代初期，軟件和IT行業(yè)進入了大發(fā)展

33、，軟件趨向大型化、高復(fù)雜度， 軟件的質(zhì)量越來越重要。這個時候，一些軟件測試的基礎(chǔ)理論和實用技術(shù)開始形成，并且人們開始為軟件開發(fā)設(shè)計了各種流程和管理方法，軟件開發(fā)的方式也逐漸由混亂無序的開發(fā)過程過渡到結(jié)構(gòu)化的開發(fā)過程，以結(jié)構(gòu)化分析與設(shè)計、結(jié)構(gòu)化評審、結(jié)構(gòu)化程序設(shè)計以及結(jié)構(gòu)化測試為特征。人們還將 質(zhì)量”的概念融入其中，軟件測試定義發(fā)生了改變，測試不單純是一個發(fā)現(xiàn)錯誤的過程，而且將測試作為軟件質(zhì)量保證（SQA ）的主要職能，包含軟件質(zhì)量評價的內(nèi)容，Bill Hetzel在軟件測試完全指南（Complete Guide ofSoftware Testi ng） 書中指出： 測試是以評價一個程序或者系統(tǒng)

34、屬性為目標的任何一種活動。測試是對軟件質(zhì)量的度量?！边@個定義至今仍被引用。軟件開發(fā)人員和測試人員開始坐在一起探討軟件工程和測試問題。軟件測試已有了行業(yè)標準(IEEE/ANSI ) , 1983 年IEEE提出的軟件工程術(shù)語中給軟件測試下的定義是：使用人工或自動的手段來運行或測定某個軟件系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實際結(jié)果之 間的差別”這個定義明確指出：軟件測試的目的是為了檢驗軟件系統(tǒng)是否滿足需求。它再 也不是一個一次性的，而且只是開發(fā)后期的活動，而是與整個開發(fā)流程融合成一體。軟件測試已成為一個專業(yè)，需要運用專門的方法和手段，需要專門人才和專家來承擔(dān)。軟件測試成

35、熟度隨著軟件產(chǎn)業(yè)界對軟件過程的不斷研究，美國工業(yè)界和政府部門開始認識到，軟件過 程能力的不斷改進才是增進軟件開發(fā)組織的開發(fā)能力和提高軟件質(zhì)量的第一要素。在這種背景下，由美國卡內(nèi)基-梅隆大學(xué)軟件工程研究所(SEI )研制并推出了軟件能力成熟度模型 SW-CMM，CMM逐漸成為了評估軟件開發(fā)過程的管理以及工程能力的標準。從80年代中期開始，軟件生產(chǎn)開始進入以個體軟件過程PSP(Personal Software Process)、過程成熟度模型CMM和群組軟件過程 TSP(Team Software Process) 為標志的、以過程為中心 的第二階段。但是令人遺憾的是，CMM沒有充分的定義軟件測

36、試，沒有提及測試成熟度的概念，沒 有對測試過程改進進行充分說明，在KPA中沒有定義測試問題，與質(zhì)量相關(guān)的測試問題如可測性，充分測試標準，測試計劃等方面也沒有滿意的闡述。僅在第三級的軟件產(chǎn)品工程(SPE)KPA中提及軟件測試職能，但對于如何有效提高機構(gòu)的測試能力和水 平?jīng)]有提供相應(yīng)指導(dǎo)，無疑是一種不足。為此，許多研究機構(gòu)和測試服務(wù)機構(gòu)從 不同角度出發(fā)提出有關(guān)軟件測試方面的能力成熟度模型，作為SEI-CMM 的有效 補充，比較有代表性的包括：美國國防部提出一個CMM軟件評估和測試KPA建 議；Gelper 博士提出一個測試支持模型(TSM)評估測試小組所處環(huán)境對于他 們的支持程度；Burgess/

37、DrabickI.T.I.公司提出的測試能力成熟度模型(TestingCapability Maturity Model )則提供了與 CMM 完全一樣的 5 級模型。Burnstein 博士提出了測試成熟度模型(TMM )，依據(jù)CMM的框架提出測試 的5個不同級別，關(guān)注于測試的成熟度模型。它描述了測試過程，是項目測試部分得到 良好計劃和控制的基礎(chǔ)。TMM測試成熟度分解為 5級別，關(guān)注于5個成熟度級別遞增：Phase 0:測試和調(diào)試沒有區(qū)別，初了支持調(diào)試外，測試沒有其他目的Phase 1:測試的目的是為了表明軟件能夠工作Phase 2:測試的目的是為了表明軟件不能夠能夠正常工作Phase 3:

38、測試的目的不是要證明什么，而是為了把軟件不能正常工作的預(yù)知風(fēng)險降低到能夠接受的程度Phase 4:測試不是行為，而是一種自覺的約束(me ntal discipli ne)，不用太多的測試投入產(chǎn)生低風(fēng)險的軟件上的。軟件測試模型的演變軟件測試模型與軟件測試標準的研究也隨著軟件工程的發(fā)展而越來越深入，在2 0世 紀8 0年代后期 Paul Rook提出了著名的軟件測試的 V模型，旨在改進軟件開發(fā)的效率和 效果。V模型反映出了測試活動與分析設(shè)計活動的關(guān)系。在圖1-1中，從左到右描述了基本的開發(fā)過程和測試行為，非常明確的標注了測試過程中存在的不同類型的測試，并且清楚的描述了這些測試階段和開發(fā)過程期間各

39、階段的對應(yīng)關(guān)系。圖1-1V模型指出，單元和集成測試應(yīng)檢測程序的執(zhí)行是否滿足軟件設(shè)計的要求；系統(tǒng)測試應(yīng)檢測系統(tǒng)功能、性能的質(zhì)量特性是否達到系統(tǒng)要求的指標；驗收測試確定軟件的實現(xiàn)是否滿足用戶需要或合同的要求。但V模型存在一定的局限性，它僅僅把測試作為在編碼之后的一個階段，是針對程序進行的尋找錯誤的活動，而忽視了測試活動對需求分析、系統(tǒng)設(shè)計等活動的驗證和確認的功能。Evolutif 公司針對V模型的缺陷，相對于 V模型，提出了 W模型的概念， W模型增 加了軟件各開發(fā)階段中應(yīng)同步進行的驗證和確認活動。如圖1-2所示，W模型由兩個 V字型模型組成，分別代表測試與開發(fā)過程，圖中明確表示出了測試與開發(fā)的并

40、行關(guān)系。W模型強調(diào)：測試伴隨著整個軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、設(shè) 計等同樣要測試，也就是說，測試與開發(fā)是同步進行的。W 模型有利于盡早地全面的發(fā)現(xiàn)問題。例如，需求分析完成后， 測試人員就應(yīng)該參與到對需求的驗證和確認活動中，以盡早 地找出缺陷所在。同時，對需求的測試也有利于及時了解項目難度和測試風(fēng)險，及早制定應(yīng)對措施，這將顯著減少總體測試時間，加快項目進度。但W模型也存在局限性。在 W模型中，需求、設(shè)計、編碼等活動被視為串行的，同時，測試和開發(fā)活動也保持著一種線性的前后關(guān)系，上一階段完全結(jié)束，才可正式開始下一個階段工作。軟件測試工具的發(fā)展進入上世紀90年代，軟件行業(yè)開始迅猛發(fā)

41、展，軟件的規(guī)模變的非常大，在一些大型軟 件開發(fā)過程中，測試活動需要花費大量的時間和成本，而當(dāng)時測試的手段幾乎完全都是手工測試，測試的效率非常低；并且隨著軟件復(fù)雜度的提高，出現(xiàn)了很多通過手工方式無法完成測試的情況，盡管在一些大型軟件的開發(fā)過程中，人們嘗試編寫了一些小程序來輔助測試， 但是這還是不能滿足大多數(shù)軟件項目的統(tǒng)一需要。于是，很多測試實踐者開始嘗試開發(fā)商業(yè)的測試工具來支持測試， 輔助測試人員完成某一類型或某一領(lǐng)域內(nèi)的測試工作，而測試工具逐漸盛行起來。人們普遍意識到，工具不僅僅是有用的， 而且要對今天的軟件系統(tǒng)進行充分 的測試，工具是必不可少的。 測試工具可以進行部分的測試設(shè)計、實現(xiàn)、執(zhí)行和

42、比較的工作。通過運用測試工具， 可以達到提高測試效率的目的。測試工具的發(fā)展，大大提高了軟件測試的自動化程度，讓測試人員從繁瑣和重復(fù)的測試活動中解脫出來，專心從事有意義的測試設(shè)計等活動。采用自動比較技術(shù)， 還可以自動完成測試用例執(zhí)行結(jié)果的判斷，從而避免人工比對存在的疏漏問題。設(shè)計良好的自動化測試，在某些情況下可以實現(xiàn)“夜間測試”和“無人測試”。在大多數(shù)情況下，軟件測試自動化可以減少開支，增加有限時間內(nèi)可執(zhí)行的測 試，在執(zhí)行相同數(shù)量測試時節(jié)約測試時間。而測試工具的選擇和推廣也越來越受到重視。在軟件測試工具平臺方面，商業(yè)化的軟件測試工具已經(jīng)很多，如捕獲/回放工 具、Web測試工具、性能測試工具、測試

43、管理工具、代碼測試工具等等，這些都 有嚴格的版權(quán)限制且價格較為昂貴，但由于價格和版權(quán)的限制無法自由使用，當(dāng) 然，一些軟件測試工具開發(fā)商對于某些測試工具提供了 Beta 測試版本以供用戶 有限次數(shù)使用。幸運的是，在開放源碼社區(qū)中也出現(xiàn)了許多軟件測試工具，已得 到廣泛應(yīng)用且相當(dāng)成熟和完善。校園招聘系統(tǒng)測試總結(jié)報告文檔標識：當(dāng)前版本：當(dāng)前狀態(tài)：草稿發(fā)布日期：發(fā)布修改歷史日期版本作者修改內(nèi)容評審號變更控制號目錄1. 測試概述 211.1 編寫目的 211.2 測試范圍 211.3 參考資料 222. 測試計劃執(zhí)行情況 222.1 測試類型 222.2 進度偏差 232.3 測試環(huán)境與配置 242.4

44、測試機構(gòu)和人員 242.5 測試問題總結(jié) 253. 測試總結(jié) 253.1 測試用例執(zhí)行結(jié)果 253.2 測試問題解決 273.3 測試結(jié)果分析 28 覆蓋分析 28 缺陷分析 284. 綜合評價 294.1 軟件能力 294.3 建議 301. 測試概述1.1 編寫目的對 MicroMOe 項目中所有的軟件測試活動中，包括測試進度、資源、問題、風(fēng)險以及測試 組和其他組間的協(xié)調(diào)等進行評估，總結(jié)測試活動的成功經(jīng)驗與不足，以便今后更好的開展測試 工作。本系統(tǒng)測試總結(jié)報告的預(yù)期讀者是：? 開發(fā)部經(jīng)理；? 項目組所有人員；? 測試組人員；? SQA人 員；? SCM人 員；以及B公司授權(quán)調(diào)閱本文檔的其他

45、人員。1.2 測試范圍MicroMOe 項目因其自身的特殊性， 測試組僅依據(jù)用戶需求說明書和軟件需求規(guī)格說明書以 及相應(yīng)的設(shè)計文檔進行系統(tǒng)測試，包括功能測試、性能測試、用戶訪問與安全控制測試、用戶 界面測試以及兼容性測試等，而單元測試和集成測試則由開發(fā)人員來執(zhí)行。主要功能包括： 前臺個人求職功能注冊新用戶登錄系統(tǒng)找回密碼更改密碼填寫簡歷信息預(yù)覽簡歷信息修改簡歷信息查詢職位瀏覽職位應(yīng)聘職位瀏覽公告信息瀏覽申請記錄招聘企業(yè)管理后臺登錄系統(tǒng)修改注冊信息修改密碼職位管理用戶管理申請查詢?yōu)g覽通知信息 申請表詳情系統(tǒng)提供商管理后臺管理員登錄系統(tǒng)查詢簡歷簡歷詳情發(fā)布公告信息1.3參考資料資料名稱版本作者是否

46、經(jīng)過評審備注校園招聘系統(tǒng) MicroMOe軟件開發(fā)計劃.doc2.0已評審校園招聘系統(tǒng) MicroMOe系統(tǒng)測試方案.doc1.1已評審校園招聘系統(tǒng) MicroMOe測試計劃.doc1.1已評審校園招聘系統(tǒng)MicroMOe測試進度表.mpp1.1已評審2. 測試計劃執(zhí)行情況2.1測試類型測試類型測試內(nèi)容測試目的所用的測試工 具和方法功能測試個人前臺：注冊新用戶、登錄系統(tǒng)、找回 密碼、更改密碼、填寫簡歷信息、預(yù)覽簡歷 信息、修改簡歷信息、查詢職位、瀏覽職位、 應(yīng)聘職位、瀏覽公告信息、瀏覽申請記錄企業(yè)后臺：登錄系統(tǒng)、修改注冊信息、修 改密碼、職位管理、用戶管理、申請查詢、 瀏覽通知信息、申請表詳情

47、核實所有功能均已正常實現(xiàn)，即可按每 個用戶的需求定制不冋的申請表及招 聘流程（篩選、筆試、面試）。1 業(yè)務(wù)流程檢驗：各個業(yè)務(wù)流程符合 常規(guī)邏輯，用戶使用時不會產(chǎn)生疑 問。2、數(shù)據(jù)精確：各數(shù)據(jù)類型的輸入輸出 時統(tǒng)計精確。采用黑盒測試， 使用邊界值測 試、等價類劃 分、數(shù)據(jù)驅(qū)動等 測試方法，進行 手工測試；管理后臺：管理員登錄系統(tǒng)、查詢簡歷、簡歷詳情、發(fā)布公告信息用戶界面1.導(dǎo)航、鏈接、Cookie、頁面結(jié)構(gòu)包括菜核實各個窗口風(fēng)格(包括顏色、字體、WEB測試通用方法(UI)測試單、背景、顏色、字體、按鈕名稱、TITLE、提示信息、圖標、TITLE等等)都與基手工測試提示信息的一致性等。準版本保持一

48、致，或符合可接受標準，2.友好性、易用性、合理性、一致性、正能夠保證用戶界面的友好性、易操作確性等，(詳性，而且符合用戶操作習(xí)慣。見:sepg-sever/TDBIN/start_a.htmProject:PRJ_MicroMOe , UserName:guest )安全性和訪1.密碼：登錄、企業(yè)用戶、個人用戶、管1應(yīng)用程序級別的安全性：核實用戶黑盒測試、測試手工問控制測試理員用戶；只能操作其所擁有權(quán)限能操作的功能。2.權(quán)限限制；2 系統(tǒng)級別的安全性：核實只有具備3.通過修改URL非法訪問；系統(tǒng)訪問權(quán)限的用戶才能訪問系統(tǒng)。4.登錄超時限制等等；兼容性測試1.用不同版本的不同瀏覽器：NetSca

49、pe、核實系統(tǒng)在不同的軟件和硬件配置中黑盒測試、測試手工MylE、 Tecent,IE5.5,IE6.0,分辨運行穩(wěn)定率：800*600、1024*768,操作系統(tǒng)：WIN2000 Server 、WIN2000Professional 、WIN XP分別進行測試。2.不同操作系統(tǒng)、瀏覽器、分辨率和各種運行軟件等各種條件的組合測試。性能測試1.最大并發(fā)數(shù)；核實系統(tǒng)在大流量的數(shù)據(jù)與多用戶操LoadRunner 8.0自動化測試2.查詢職位、簡歷時，注冊新用戶時以及作時軟件性能的穩(wěn)定性，不造成系統(tǒng)崩登錄時系統(tǒng)的響應(yīng)時間；潰或相關(guān)的異常現(xiàn)象2.2進度偏差測試活動計劃起止日期實際起止日期進度偏差備注制

50、定測試計劃待SDP評審?fù)戤厹y試計劃等待和 SCMP SQAF評審?fù)瑫r評審分解測試需求測試需求Review選定測試范圍編寫測試萬案測試方案評審待測試用例設(shè)計完畢后評審設(shè)計測試用例根據(jù)需求變更修改用例測試用例評審測試執(zhí)行測試移交延遲一天測試總結(jié)2.3測試環(huán)境與配置資源名稱/類型配置測試PC機（4臺）P4,主頻1.6G以上，硬盤 40G內(nèi)存512M本要求是最小 配置。TD7.6服務(wù)器，DB服務(wù)器（同1臺）PC Server : 512M內(nèi)存、40G SCSI 硬盤數(shù)據(jù)庫管理系統(tǒng)SQL Server2000應(yīng)用軟件MICROSOFT OFFICEVISIO、VISUAL SOURCESAFMicrosoftProject客戶端前端展示IE6.0負載性能測試工具Loadrunner8.0 ;功能性測試工具MANUAL測試管理工具TestDirector7.62.4測試機構(gòu)和人員測試階段測試機構(gòu)名稱負責(zé)人參與人員所充當(dāng)角色系統(tǒng)測試測試組測試人員2.5測試問題總結(jié)在整個系