.z.-風險異常引發的額外本錢〔如人力，時間等〕降到析析測試工程級的風險分布?業務不熟：測試人員對被測系統的業務流程不熟悉，表達在對需求的理解上把握不準、理解不透現問題，在此后往往會認為此功能輯所同化，漸漸喪失從用戶角度出?質量標準不統一：如*些Bug的優先級方面，測試和開發的認同不一致。?錯誤或缺失測試方法：對功能點沒有采用正確的測試方法，或*些測試方法沒有被無視，如邊界測.z.-統類型不一致、操作系統的干凈程度不求。里程碑時間點延后，導致工程的進度表一下松。在工程進展到中后期時，客戶突然通知我們暫時不安排我們的軟件在他們這一版本2.采用FMEA評估及分析風險項MEAFMEAailureModeAspecificmeansbywhichadesignproductprocessorservicemayfail.?Severity〔嚴重度〕：Howseriousistheconsequenceofthefailure?Thevalueis1~10.Occurrence〔頻度〕：Howoftenwillthecause/failureoccur?Thevalueis1~10.ansmissionoffailurestosub?Detection〔探測度〕：Canthecause/failurebedetectedifitoccurs?Thevalueis1~10.?Responsibility&TargetpletionDate(責任及目標完成日期):Whenitcanbefi*ed?tafteractionhavebeentaken本文只給出了簡單流程示意圖，更詳細的流程做法，請參看?FAILUREMODESANDEFFECTSANennethCrowFMEAProcedureFMEA、時五大因素中所.z.-析從所有測試用例集〔含功能點和場景測試兩局部〕中如何選擇最小測試用想從測試用例風險系數等級劃分來對這一問題進展局部探討。對所按等級數進展排序。在選擇回歸測試用例集時，從中挑選風險系數，最后根據工程進度條件從風險等級高到等級低的合理選擇回歸測2.采用風險矩陣評估及分析測試用例優先級如工程經費本錢風險分析等。僅從測試本身考慮了derPM測試風險分析，所以對于發生風險后所應該采用的躲避措施，沒有在文中給出，可，也可參考網上一些文章所建議的解優秀的方法，但其精華和FMEA、風險分析矩陣是如出一轍，個人覺得以表道-微軟測試測試技術心得?梁博，許珊等電子工業理?.51testing./html/90/n-9990.htmlnoonepmbbs1testing./thread-7105-1-1.html常見問題及其答復?songfunbbs.51testing./thread-39181-1-1.html二軟件測試風險是不可防止的、總是存在的，所以對測試風險的管理非常重要，必須盡一、質量需求或產品的特性理解不準確，造成測試圍分析的誤差，結果*些地方始終測試不到或驗證的標準不對；.z.-二、測試用例沒有得到百分之百的執行，如有些測試用例被有意或無意的遺漏；三、需求的臨時/突然變化，導致設計的修改和代碼的重寫，測試時間不夠；四、質量標準不都是很清晰的，如適用性的測試，仁者見仁、智者見智；五、測試用例設計不到位，無視了一些邊界條件、深層次的邏輯、用戶場景等；六、測試環境，一般不可能和實際運行環境完全一致，造成測試結果的誤差；七、有些缺陷出現頻率不是百分之百，不容易被發現；如果代碼質量差，軟件缺陷很多，被漏檢的缺陷可能性就大；八、回歸測試一般不運行全部測試用例，是有選擇性的執行，必然帶來風險。最后一種回歸測試風險是可以防止，但出于時間或本錢的考慮，一般也是存在的。針對上述軟件測試的風險，有一些有效的測試風險控制方法，如：·測試環境不對可以通過事先列出要檢查的所有條目，在測試環境設置好后，由其他人員按已列出條目逐條檢查；·有些測試風險可能帶來的后果非常嚴重，能否將它轉化為其他一些不會引起嚴重后果的低風險。如產品發布前夕，在*個不是很重要的新功能上發現一個嚴重的缺陷，如果修正這個缺陷，很有可能引起*個原有功能上的缺陷。這時處理這個缺陷所帶來的風險就很大，對策是去掉(Diasble)那個新功能，轉移這種風險；·有些風險不可防止，就設法降低風險，如“程序中未發現的缺陷〞這種風險總是存在，我們就要通過提高測試用例的覆蓋率〔如到達99.9%〕來降低這種風險；為了防止、轉移或降低風險，事先要做好風險管理方案和控制風險的策略，并對風險的處理還要制定一些應急的、有效的處理方案，如：·在工程開場前，把一些環節或邊界上的可能會有變化、難以控制的因素列入風·對每個關鍵性技術人員培養后備人員，作好人員流動的準備，采取一些措施確·對所有工作多進展互相審查，及時發現問題，包括對不同的測試