1、軟件測試風險分析【精選文檔】作為軟件測試計劃的一部分，軟件測試風險的分析與控制是其中重要的環節.如果前期風險分析與控制比較充分，那么會使軟件的測試成功性大大增加,且可將由風險異常引發的額外成本(如人力，時間等）降到最低。查閱了網上很多關于軟件測試風險控制的文章，其中不乏精品之作。本文將此類知識進行了歸納，查漏補缺，并在思維導向性上給出了簡單的實施步驟,以使得在實際應用中能得到更好的運用。第一部分：軟件測試項目級的風險分析1。從人、料、法、環、時等方面分析測試項目級的風險分布探尋測試隱藏的風險時，應招集測試全組成員舉行會議, 建議采用頭腦風暴和詢問5Why的方式進行，以集思廣益和深度挖掘.下面就

2、在魚骨圖中以TQM （全面質量管理） 的人、機、料、法、環等五個方面來全方位的分析和羅列項目級可能隱藏的風險 （注：考慮到在軟件測試中“機”這一項更多的屬于環境這一分類,故刪除此類。另外時間對于軟件測試是一個非常重要的屬性，故添加之)。下面對魚骨圖中的各個分支及子分支進行相應注解：人，即測試人員： 業務不熟：測試人員對被測系統的業務流程不熟悉,體現在對需求的理解上把握不準、理解不透側、理解錯誤等. 測試人員變動：離職，崗位調動，請假等。 定位效應：測試過的可靠的功能,特別是在多次回歸且沒有發現問題，在此后往往會認為此功能是可靠的。 疲態：某一些功能點一直由某一位測試人員測試,經過多次回歸后，測

3、試人員對該功能點的測試顯示出倦意和缺乏興趣。 同化效應：經過和開發的長時間接觸，往往會被開發的思維邏輯所同化，漸漸喪失從用戶角度出發的測試觀察點。料,即測試相關文檔（在TQM中指的是生產原材料）： Spec （詳細規格說明書)缺失:只有PRD（項目需求概要說明書),沒有spec。筆者所在的公司，早些時候的產品更多的時候只有PRD，沒有Spec。 需求變更:這是最不想，但又最經常發生的事情 測試用例/數據設計不充分：某些時候由于編寫測試人員的個人因素或時間的限制等方面因素導致。 質量標準不統一:如某些Bug的優先級方面,測試和開發的認同不一致。法,即測試方法和實施： 錯誤或缺失測試方法：對功能點

4、沒有采用正確的測試方法,或某些測試方法沒有被忽視,如邊界測試等，導致測試不充分. 場景的缺失或部分缺失:Spec非常詳細，所有的精力放在功能點的測試上，忽視了業務場景（Spec中無定義)的全（100）測試。 測試用例實施不充分：測試用例由于各種原因沒有完全測試，如在回歸測試中.環,即測試環境： 被測軟件版本不統一:沒有有效的配置管理，這種情況及易出現 測試軟件環境不一致：測試員之間或和開發之間的操作系統類型不一致、操作系統的干凈程度不一致。 測試硬件環境不一致:測試員之間或和開發的設備不一致,如CPU頻率，內存大小等。 測試硬件未及時到位時，即測試時間： 測試時間不足:里程碑之間留給測試的時間

5、無法滿足全測試要求. 測試時間延長：由于需求方突然宣布原進度表中的里程碑時間點延后，導致項目的進度表一下松弛了許多。筆者參加過的兩個項目就遇見過這種情況，我們為世界某著名品牌電腦供應商開發并提供隨機軟件。在項目進展到中后期時，客戶忽然通知我們暫時不安排我們的軟件在他們這一版本系統中進行安裝,要等到下一版本，時間延遲可能長達三個月，甚至更多。注：以上五個方面不可能將所有軟件測試中潛在的風險全部羅列，旨在給出思維方式.2。采用FMEA評估及分析風險項在采用FMEA對風險進行評估和分析前，有必要先熟悉一些FMEA的知識點。（1）FMEA (Failure Mode Effects Analysis）

6、 :潛在失效模式和結果分析。即找出產品/過程中潛在的故障模式根據相應的評價體系對找出的潛在故障模式進行風險量化評估;列出故障起因/機理,尋找預防或改進措施。(2）FMEA關鍵項: Function （功能要求)： What is design/process/service supposed to do at this stage？ Failure Mode （潛在失效模式）： A specific means by which a design （product)， process， or service may fail. Effect （潛在失效后果）： What happens whe

7、n the failure occurs? Severity （嚴重度）： How serious is the consequence of the failure? The value is 110。 Cause （潛在的失效起因）： What can occur to cause the failure? Occurrence （頻度）： How often will the cause/failure occur？ The value is 110. Current Control （現行控制）： Current method to detect/prevent transmissio

8、n of failures to subsequent “customers”。 Detection (探測度)： Can the cause/failure be detected if it occurs？ The value is 110。 RPN (風險順序數）： Review Risk Priority Numbers,RPN = (Severity） x （Occurrence） x （Detection) Recommended Actions （建議措施）: What can we do? Responsibility Target Completion Date （責任及目標

9、完成日期)： When it can be fixed？ Actions Taken Result (措施結果）： The actually result after action have been taken。（3)FMEA流程：本文只給出了簡單流程示意圖,更詳細的流程做法，請參看FAILURE MODES AND EFFECTS ANALYSISKenneth Crow 中的FMEA Procedure章節。下面給出一個FMEA的簡單模板，可以參照下圖的表格填寫上面人、料、法、環、時五大因素中所提及的各個風險子項填寫在Function一列，并按公司的切實情況填寫后續各列.第二部分：軟件測

10、試用例級的風險分析1。測試用例風險分析的目的在進行回歸測試等情況下，從所有測試用例集（含功能點和場景測試兩部分）中如何選擇最小測試用例集,是一個值得思考的問題，本文僅想從測試用例風險系數等級劃分來對這一問題進行部分探討。對所有測試用例進行風險系數等級劃分，并按等級數進行排序。在選擇回歸測試用例集時，從中挑選風險系數等級級別的高的測試用例進行優先測試，最后根據項目進度條件從風險等級高到等級低的合理選擇回歸測試用例集。2。采用風險矩陣評估及分析測試用例優先級測試用例風險出現概率(110）后果與影響(110)風險系數(=出現概率x影響)規避措施第三部分:總結與說明1。本文沒有對項目管理方面的隱藏風險

11、進行探尋,如項目經費成本風險分析等。僅從測試本身考慮了風險分布,角色定位于測試項目Leader，而前者則是PM。2。本文的標題定為測試風險分析，所以對于發生風險后所應該采用的規避措施，沒有在文中給出，可采用根據公司內容的實際情況采用頭腦風暴進行解決方案的探討和篩選，也可參考網上一些文章所建議的解決方案。3.風險分析的方法有很多種，如Boehm的六步風險管理法、Rex Black在軟件測試核心過程一書中提到的風險分析過程等都是比較優秀的方法，但其精髓和FMEA、風險分析矩陣是如出一轍，個人覺得以表格的形式展示更加形象化。參考：1、測試有道 微軟測試測試技術心得 梁博，許珊等 電子工業出版社2、測

12、試風險的管理/html/90/n-9990.html3、風險列表 noone_pmhttp：//thread-710511。html4、軟件測試管理常見問題及其回答songfunhttp：//thread-3918111。html二軟件測試風險是不可避免的、總是存在的，所以對測試風險的管理非常重要，必須盡力降低測試中所存在的風險,最大程度地保證質量和滿足客戶的需求。在測試工作中，主要的風險有：一、質量需求或產品的特性理解不準確，造成測試范圍分析的誤差，結果某些地方始終測試不到或驗證

13、的標準不對;二、測試用例沒有得到百分之百的執行，如有些測試用例被有意或無意的遺漏;三、需求的臨時/突然變化，導致設計的修改和代碼的重寫，測試時間不夠；四、質量標準不都是很清晰的，如適用性的測試，仁者見仁、智者見智;五、測試用例設計不到位，忽視了一些邊界條件、深層次的邏輯、用戶場景等；六、測試環境，一般不可能和實際運行環境完全一致，造成測試結果的誤差；七、有些缺陷出現頻率不是百分之百，不容易被發現;如果代碼質量差，軟件缺陷很多，被漏檢的缺陷可能性就大；八、回歸測試一般不運行全部測試用例，是有選擇性的執行,必然帶來風險.前面三種風險是可以避免的，而四至七的四種風險是不能避免的，可以降到最低.最后一

14、種回歸測試風險是可以避免，但出于時間或成本的考慮，一般也是存在的。針對上述軟件測試的風險，有一些有效的測試風險控制方法，如：測試環境不對可以通過事先列出要檢查的所有條目，在測試環境設置好后，由其他人員按已列出條目逐條檢查；有些測試風險可能帶來的后果非常嚴重，能否將它轉化為其他一些不會引起嚴重后果的低風險。如產品發布前夕,在某個不是很重要的新功能上發現一個嚴重的缺陷，如果修正這個缺陷，很有可能引起某個原有功能上的缺陷。這時處理這個缺陷所帶來的風險就很大，對策是去掉（Diasble）那個新功能，轉移這種風險;有些風險不可避免，就設法降低風險，如“程序中未發現的缺陷”這種風險總是存在，我們就要通過提高測試用例的覆蓋率(如達到99。9%）來降低這種風險；為了避免、轉移或降低風險，事先要做好風險管理計劃和控制風險的策略，并對風險的處理還要制定一些應急的、有效的處理方案,如：在做資源、時間、成本等估算時,要留有余地，不要用到100；在項目開始前，把一些環節或邊界上的可能會有變化、難以控制的因素列入風險管理計劃中；對每個關鍵性技術人員培養后備人員,作好人員流動的準備，采取一些措施確保人員一旦離開公司, 項目不會受到嚴重影響，仍能可以繼續下去；制定文檔標準，并建立一種機制，保證