【一兩年前收集整理的資料，感覺不錯，放到部落格上來】
作為軟體測試計劃的一部分，軟體測試風險的分析與控制是其中重要的環節。如果前期風險分析與控制比較充分，那麼會使軟體的測試成功性大大增加，且可將由風險異常引發的額外成本(如人力，時間等)降到最低。查閱了網上很多關於軟體測試風險控制的文章，其中不乏精品之作。本文將此類知識進行了歸納，查漏補缺，並在思維導向性上給出了簡單的實施步驟，以使得在實際應用中能得到更好的運用。
第一部分：軟體測試專案級的風險分析
1. 從人、料、法、環、時等方面分析測試專案級的風險分佈
探尋測試隱藏的風險時，應招集測試全組成員舉行會議， 建議採用頭腦風暴和詢問5Why的方式進行，以集思廣益和深度挖掘。下面就在魚骨圖中以TQM (全面質量管理) 的人、機、料、法、環等五個方面來全方位的分析和羅列專案級可能隱藏的風險 (注：考慮到在軟體測試中“機”這一項更多的屬於環境這一分類，故刪除此類。另外時間對於軟體測試是一個非常重要的屬性，故新增之)。
下面對魚骨圖中的各個分支及子分支進行相應註解：
人，即測試人員：
l 業務不熟：測試人員對被測系統的業務流程不熟悉，體現在對需求的理解上把握不準、理解不透側、理解錯誤等。
l 測試人員變動：離職，崗位調動，請假等。
l 定位效應：測試過的可靠的功能，特別是在多次迴歸且沒有發現問題，在此後往往會認為此功能是可靠的。
l 疲態：某一些功能點一直由某一位測試人員測試，經過多次迴歸後，測試人員對該功能點的測試顯示出倦意和缺乏興趣。
l 同化效應：經過和開發的長時間接觸，往往會被開發的思維邏輯所同化，漸漸喪失從使用者角度出發的測試觀察點。
料，即測試相關文件(在TQM中指的是生產原材料)：
l Spec (詳細規格說明書)缺失：只有PRD(專案需求概要說明書)，沒有spec。筆者所在的公司，早些時候的產品更多的時候只有PRD，沒有Spec。
l 需求變更：這是最不想，但又最經常發生的事情
l 測試用例/資料設計不充分：某些時候由於編寫測試人員的個人因素或時間的限制等方面因素導致。
l 質量標準不統一：如某些Bug的優先順序方面，測試和開發的認同不一致。
法，即測試方法和實施：
l 錯誤或缺失測試方法：對功能點沒有采用正確的測試方法，或某些測試方法沒有被忽視，如邊界測試等，導致測試不充分。
l 場景的缺失或部分缺失：Spec非常詳細，所有的精力放在功能點的測試上，忽視了業務場景(Spec中無定義)的全(100%)測試。
l 測試用例實施不充分：測試用例由於各種原因沒有完全測試，如在迴歸測試中。
環，即測試環境：
l 被測軟體版本不統一：沒有有效的配置管理，這種情況及易出現
l 測試軟體環境不一致：測試員之間或和開發之間的作業系統型別不一致、作業系統的乾淨程度不一致。
l 測試硬體環境不一致：測試員之間或和開發的裝置不一致，如CPU頻率，記憶體大小等。
l 測試硬體未及時到位
時，即測試時間：
l 測試時間不足：里程碑之間留給測試的時間無法滿足全測試要求。
l 測試時間延長：由於需求方突然宣佈原進度表中的里程碑時間點延後，導致專案的進度表一下鬆弛了許多。筆者參加過的兩個專案就遇見過這種情況，我們為世界某著名品牌電腦供應商開發並提供隨機軟體。在專案進展到中後期時，客戶忽然通知我們暫時不安排我們的軟體在他們這一版本系統中進行安裝，要等到下一版本，時間延遲可能長達三個月，甚至更多。
注：以上五個方面不可能將所有軟體測試中潛在的風險全部羅列，旨在給出思維方式。
2. 採用FMEA評估及分析風險項
在採用FMEA對風險進行評估和分析前，有必要先熟悉一些FMEA的知識點。
l FMEA (Failure Mode Effects Analysis) ：潛在失效模式和結果分析。即找出產品/過程中潛在的故障模式根據相應的評價體系對找出的潛在故障模式進行風險量化評估；列出故障起因/機理，尋找預防或改進措施。
l 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 when the failure occurs?
ü Severity (嚴重度): How serious is the consequence of the failure? The value is 1~10.
ü Cause (潛在的失效起因): What can occur to cause the failure?
ü Occurrence (頻度): How often will the cause/failure occur? The value is 1~10.
ü Current Control (現行控制): Current method to detect/prevent transmission of failures to subsequent “customers”.
ü Detection (探測度): Can the cause/failure be detected if it occurs? The value is 1~10.
ü RPN (風險順序數): Review Risk Priority Numbers, RPN = (Severity) x (Occurrence) x (Detection)
ü Recommended Actions (建議措施): What can we do?
ü Responsibility & Target Completion Date (責任及目標完成日期): When it can be fixed?
ü Actions Taken Result (措施結果): The actually result after action have been taken.
l FMEA流程：
本文只給出了簡單流程示意圖，更詳細的流程做法，請參看《FAILURE MODES AND EFFECTS ANALYSIS》Kenneth Crow 中的FMEA Procedure章節。
下面給出一個FMEA的簡單模板，可以參照下圖的表格填寫上面人、料、法、環、時五大因素中所提及的各個風險子項填寫在Function一列，並按公司的切實情況填寫後續各列。
第二部分：軟體測試用例級的風險分析
1. 測試用例風險分析的目的
在進行迴歸測試等情況下，從所有測試用例集（含功能點和場景測試兩部分）中如何選擇最小測試用例集，是一個值得思考的問題，本文僅想從測試用例風險係數等級劃分來對這一問題進行部分探討。對所有測試用例進行風險係數等級劃分，並按等級數進行排序。在選擇迴歸測試用例集時，從中挑選風險係數等級級別的高的測試用例進行優先測試，最後根據專案進度條件從風險等級高到等級低的合理選擇迴歸測試用例集。
2. 採用風險矩陣評估及分析測試用例優先順序
|
測試用例 |
風險 |
出現概率(1~10) |
後果與影響(1~10) |
風險係數(=出現概率x影響) |
規避措施 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
第三部分：總結與說明
1. 本文沒有對專案管理方面的隱藏風險進行探尋，如專案經費成本風險分析等。僅從測試本身考慮了風險分佈，角色定位於測試專案Leader，而前者則是PM。
2. 本文的標題定為測試風險分析，所以對於發生風險後所應該採用的規避措施，沒有在文中給出，可採用根據公司內容的實際情況採用頭腦風暴進行解決方案的探討和篩選，也可參考網上一些文章所建議的解決方案。
3. 風險分析的方法有很多種，如Boehm的六步風險管理法、Rex Black在《軟體測試核心過程》一書中提到的風險分析過程等都是比較優秀的方法，但其精髓和FMEA、風險分析矩陣是如出一轍，個人覺得以表格的形式展示更加形象化。