基于風險的測試：方法，矩陣，過程&示例 · Guru99 中文系列教程

# 基于風險的測試：方法，矩陣，過程&示例 > 原文： [https://www.guru99.com/risk-based-testing.html](https://www.guru99.com/risk-based-testing.html) ## 什么是基于風險的測試？ **基于風險的測試（RBT）**是基于風險概率完成的測試類型。它涉及根據復雜性，業務關鍵性，使用頻率，可見區域，[缺陷](/defect-management-process.html)易發區域等來評估風險。它涉及根據測試的應用程序的功能，模塊和功能的測試優先級。影響和失敗的可能性。風險是不確定事件的發生，對項目的可衡量成功標準有正面或負面的影響。可能是過去發生的事件，也可能是當前發生的事件，或者將來可能發生的事情。這些不確定的事件可能會影響項目的成本，業務，技術和質量目標。風險可以是正的或負的。 * **積極風險**被稱為機遇和對業務可持續性的幫助。例如，投資新項目，更改業務流程，開發新產品。 * **負面風險**被稱為威脅，為了使項目成功，必須實施最小化或消除它們的建議。在本教程中，您將學習- * [何時實施基于風險的測試](#2) * [風險管理流程](#3) * [基于風險的測試方法](#4) * [基于風險的系統測試方法](#5) * [如何進行基于風險的測試：完整流程](#6) * [優先級劃分和風險評估矩陣](#7) * [基于風險的測試的通用檢查表](#8) * [基于風險的測試結果報告和指標](#9) * [固有風險與殘留風險評估](#10) * [基于風險的測試的優勢](#11) ## 何時實施基于風險的測試基于風險的測試可以在 * 有時間，資源，預算限制等的項目 * 可以使用基于風險的分析來檢測 SQL 注入攻擊的漏洞的項目。 * 云計算環境中的安全性測試。 * 具有高風險因素的新項目，例如缺乏所使用技術的經驗，缺乏業務領域知識。 * 增量模型和迭代模型等 ## 風險管理流程現在讓我們了解風險管理流程中涉及的步驟 ### 風險識別可以通過風險研討會，清單，集思廣益，訪談，Delphi 技術，因果圖，從先前項目中吸取的教訓，根本原因分析，聯系領域專家和主題專家來進行風險識別。 **風險記錄**是一個電子表格，其中包含已標識的風險，潛在響應和根本原因的列表。它用于監視和跟蹤項目整個生命周期中的風險（威脅和機會）。風險應對策略可用于管理正面和負面風險。風險分解結構在風險計劃中起著重要作用。風險分解結構將有助于識別容易發生風險的區域，并有助于在項目過程中進行有效的評估和風險監控。它有助于為風險管理活動提供足夠的時間和資源。它還有助于對可能導致項目風險的許多來源進行分類。 **風險分解結構樣本** [![](https://img.kancloud.cn/8b/9b/8b9b7e28a56fb4281f690b195a418762_600x770.png) ](/images/3-2016/032316_1114_RiskBasedTe3.png) ### 風險分析（包括定量和定性分析）一旦確定了潛在風險列表，下一步就是對其進行分析，并根據重要性過濾風險。定性風險分析技術之一是使用“風險矩陣”（在下一節中介紹）。此技術用于確定風險的可能性和影響。 ### 風險應對計劃根據分析，我們可以決定是否需要應對風險。例如，某些風險將需要項目計劃中的響應，而有些風險則需要項目監視中的響應，而有些則根本不需要任何響應。風險所有者負責確定選項，以降低分配的風險的可能性和影響。 **緩解風險**是一種風險應對方法，用于減少可能威脅的不利影響。這可以通過消除風險或將風險降低到可接受的水平來實現。 ![](https://img.kancloud.cn/86/d1/86d188792207f5d460eb60965806447e_579x417.png) **風險應急措施** 不可預見性可以描述為不確定事件的可能性，但是影響是未知的或不可預測的。應急計劃也稱為最壞情況下的行動計劃/備份計劃。換句話說，它確定了發生不可預測的事件時可以采取的步驟。 ### 風險監控風險控制和監視過程用于跟蹤已識別的風險，監視殘留風險，識別新風險，更新風險登記冊，分析更改的原因，執行風險響應計劃并監視風險觸發因素等。評估其降低風險的有效性。這可以通過風險重新評估，風險審計，方差和趨勢分析，技術性能度量，狀態更新會議和回顧會議來實現。下表提供了有關 | **用于風險監視和控制的輸入** | **用于風險監控的工具和技術** | **風險監視和控制**的輸出 | | 風險管理計劃 | 項目風險應對審計 | 解決方案 | | 風險應對計劃 | 定期項目風險審查 | 糾正措施 | | 項目溝通計劃 | 掙值分析 | 項目變更要求 | | 額外的風險識別和分析 | 技術績效評估 | 更新 RiskResponse 計劃和 Risk Identification 清單 | | 范圍變更 | 其他風險應對計劃 | 風險數據庫 | 我們需要記住，風險隨著技術，項目規模，項目時間（更長的項目時限），贊助機構的數量，項目估算，工作以及缺乏適當技能的變化而增加。 ## 基于風險的測試方法 1. 分析需求。 2. 審查文檔（SRS，FRS，用例）。完成此活動是為了發現并消除錯誤&的歧義。 3. 需求簽署是減少風險的一種技術，可以避免在項目中引入最新的變更。在將文檔基準化之后，對需求的任何更改都將涉及更改控制流程和后續批準。 4. 通過計算每個需求可能對項目產生的影響以及可能產生的影響來評估風險，同時考慮定義的標準，例如成本，進度，資源，范圍，技術性能安全性，可靠性，復雜性等。 5. 確定故障和高風險區域的可能性。這可以使用風險評估矩陣來完成。 6. 使用風險記錄器列出已識別的風險集。定期更新，監視和跟蹤風險。 7. 在此階段需要進行風險分析，以了解風險能力和風險承受能力水平。 8. 根據等級對需求進行優先排序。 9. 定義了基于風險的測試流程 10. 對于緩解計劃，實施，進度??監控，可以考慮使用高度關鍵和中等風險。可以在監視列表中考慮低風險。 11. 進行風險數據質量評估以分析數據質量。 12. 根據評級計劃和定義測試 13. 應用適當的測試方法和測試設計技術來設計測試用例，以首先測試最高風險的項目。具有較高領域知識經驗的資源可以測試高風險項目。 14. 可以將不同的測試設計技術用于例如對高風險測試項目使用決策表技術，對低風險測試項目使用“僅”等效劃分。 15. 測試用例還旨在涵蓋多種功能以及端到端業務場景。 16. 準備測試數據，測試條件和測試臺。 17. 查看測試計劃，測試策略，測試用例，測試報告或測試團隊創建的任何其他文檔。 18. 同行評審是識別缺陷和降低風險的重要步驟。 19. 對結果進行空運行和質量檢查 20. 根據風險項目的優先級執行測試用例。 21. 保持風險項目之間的可追溯性，涵蓋風險項目的測試，這些測試的結果以及測試期間發現的缺陷。正確執行所有測試策略將降低質量風險。 22. 基于風險的測試可用于每個級別的測試，例如組件，集成，系統和驗收測試 23. 在系統級別，我們需要專注于應用程序中最重要的部分。這可以通過查看功能的可見性，使用頻率和可能的故障成本來確定。 24. 評估退出標準。所有高風險區域均經過全面測試，只有少量殘留風險未解決。 25. 基于風險的測試結果報告和指標分析。 26. 根據關鍵風險指標重新評估現有風險事件和新風險事件。 27. 風險登記冊更新。 28. 應急計劃-這是針對高暴露風險的后備計劃/應急計劃。 29. 缺陷分析和缺陷預防，以消除缺陷。 30. Retesting and Regression testing to validate the defect fixes based on pre-calculated risk analysis and 高風險區域應得到最密集的覆蓋。 31. 基于風險的自動化測試（如果可行） 32. 剩余風險計算 33. 風險監控 34. 退出標準或完成標準可用于不同的風險級別。所有關鍵風險均已通過適當的措施或應急計劃解決。風險敞口等于或低于項目可接受的水平。 35. 風險分析重新評估和客戶反饋。 ## 基于風險的系統測試方法 1. **技術系統測試** –這稱為環境測試和集成測試。環境測試包括開發，測試和生產環境中的測試。 2. **功能系統測試**-測試所有功能，功能，程序，模塊。該測試的目的是評估系統是否滿足其指定要求。 3. **非功能系統測試**-測試非功能需求性能，負載測試，壓力測試，配置測試，安全性測試，備份和恢復過程以及文檔（系統，操作和安裝文檔）。下圖清楚地概述了上述過程 ![](https://img.kancloud.cn/36/af/36af9761154ea6ece4ec0fbbbcdd56bc_657x393.png) 系統測試包括功能測試和非功能測試。功能測試可確保產品/應用程序滿足客戶和業務需求。另一方面，進行非功能測試以驗證產品在質量，可靠性可用性，性能，兼容性等方面是否符合客戶的期望。 ## 如何進行基于風險的測試：完整過程本節介紹基于風險的測試流程 1. 風險識別 2. 風險分析 3. 風險應對 4. 測試范圍 5. 測試過程定義 ![](https://img.kancloud.cn/0d/1c/0d1c5603f9b7f77533f24a7d6ce5aa15_653x458.png) 1. 在此過程中，對風險進行識別和分類，準備風險登記冊草案，對風險進行分類以識別重大風險。 2. 風險應對包括根據風險制定測試目標，并選擇適當的技術來證明測試活動/測試技術滿足測試目標。 3. 考慮文件的依存關系，要求，成本，軟件測試所需的時間等來計算測試有效性得分。 4. 測試范圍界定是一項審查活動，需要所有利益相關者和技術人員的參與。遵守商定的風險范圍很重要。這些風險需要通過測試來解決，所有成員都同意分配給他們的責任和分配給這些活動的預算。 5. 在確定了測試范圍之后，必須以標準格式編譯每個測試階段的測試目標，假設和依存關系。 ![](https://img.kancloud.cn/21/cd/21cdc6e968affcc0541ebad08016c28e_640x683.png) 讓我們考慮功能需求 F1，F2，F3 和非功能需求 N1 & N2 * **F1 功能要求，與 F1 相關的 R1-風險** * 測試目標 1-使用測試證明系統的預期特性和功能可以正常運行，并且可以通過功能測試解決風險 R1 * **測試**-瀏覽器頁面測試已完成，以執行重要的用戶任務，并驗證可以在多種情況下解決 R1（與 F1 相關的風險）。 * **F2-功能要求，與 F2 相關的 R2-風險** * 測試目標 2 –使用**測試**證明系統的預期功能正常運行，并且可以通過功能測試解決 R2 風險 * **測試**-瀏覽器頁面測試已完成，以執行重要的用戶任務并驗證可以在多種情況下解決 R2 問題 * **F3 功能要求，與 F3 相關的 R3-風險** * 測試目標 3 –使用**測試**演示系統的預期特性和功能運行良好，并且可以通過功能測試解決 R3 風險 * **測試**-瀏覽器頁面測試已完成，以執行重要的用戶任務并驗證可以在多種情況下解決 R3 問題 * **N1-非功能要求，與 N1 相關的 NR1-風險** * 測試目標 N1-使用**測試**演示系統的運行特性正常，并且可以通過非功能測試解決 NR1 風險 * **測試**-可用性測試是一種用于評估使用用戶界面的簡易程度并驗證可用性測試是否可以解決 NR1 的技術 * **N2-非功能性要求，與 N2 相關的 NR2-風險** * 測試目標 N.2-使用測試證明系統的運行特性運行良好，并且可以通過非功能測試解決 NR2 風險 * 測試安全性測試是一種用于檢查應用程序是否安全或是否容易受到攻擊，是否存在任何信息泄漏并驗證是否可以通過安全性測試解決 NR2 的技術。 **特定測試目標**：列出的風險和測試目標特定于測試類型。 ![](https://img.kancloud.cn/43/7e/437efefbe18161a12602d399e5b7968e_645x298.png) **設計基于風險的測試過程的程序** * 準備風險登記冊，記錄從通用風險清單，現有檢查清單，集思廣益會議得出的風險。 * 包括與系統功能和非功能需求（可用性，安全性，性能）相關的風險 * 為每個風險分配一個唯一的標識符 | **編號** | **列標題** | **說明** | | 3 | 可能性 | 系統的可能性很容易出現這種故障模式 | | 4 | 后果 | 這種故障模式的影響 | | 5 | 接觸 | 概率與后果的乘積（第 3 列& 4） | | 6 | 測試效果 | 測試人員對他們可以解決此風險的信心如何？ | | 7 | 測試優先級編號 | 概率，后果和測試有效性的乘積（第 3,4 6 列） | | 8 | 測試目標 | 什么測試目標將用于解決此風險 | | 9 | 技術測試 | 使用什么方法或技術 | | 10 | 依存關系 | 測試人員假定并依賴什么 | | 11 | 努力 | 此測試需要多少精力 | | 12 | 時間尺度 | 進行此測試需要多少時間 | | 13 | 測試階段 A 單元測試測試階段 B 集成測試測試階段 C 系統測試 | 從事此活動的個人或團體的名稱 | 評估每種風險的概率（1 低-5 高）和后果（1 低-5 高） ![](https://img.kancloud.cn/86/2c/862cd2f5ae1168083a74b588d2a6945f_585x270.png) ](/images/3-2016/032316_1114_RiskBasedTe10.png) [ ![](https://img.kancloud.cn/22/11/2211106f21995c4180d32ca5d1e30362_557x284.png) * 計算測試曝光 * 測試人員分析每種風險并評估該風險是否可測試 * 為可測試的風險定義了測試目標 * 測試人員指定應以計劃的方式進行以達到測試目標的測試活動（靜態檢查，檢查，系統測試，集成測試，驗收測試，html 驗證，本地化測試等） * 這些測試活動可以分為幾個階段（組件測試/單元測試，集成測試，系統測試，驗收測試） * 有時，一個或多個測試階段可能會解決風險 * 確定依賴關系和假設（技能，工具，測試環境，資源的可用性） * 計算測試有效性。測試有效性與測試人員對通過測試確定地解決風險的置信度有關。測試有效性得分是一個介于 1 到 5 之間的數字。（5-高置信度，1-低置信度） * 估算工作量，所需時間，準備和執行這些測試的成本。 ![](https://img.kancloud.cn/c7/71/c77166c97eb81e2bf902f7440fa6a57e_442x719.png) ![](https://img.kancloud.cn/fd/f1/fdf158a8864aaba13c34cb2ab97ae40b_517x253.png) * 計算測試優先級數。它是概率，結果和測試有效性分數的乘積。 * 125-最大風險可以通過測試檢測到非常嚴重的風險 * 1-最低àA 極低的風險，測試無法檢測到 * 根據測試優先級編號，測試重要性可以分為高（紅色），中（黃色）&低（綠色）。風險最高的項目將首先進行測試。 * 將測試活動分配到測試階段。指定將在不同測試階段（單元測試，集成測試，系統測試，驗收測試）中針對每個目標執行測試的小組 * 在測試范圍界定階段決定要進行測試的范圍和范圍之外的內容 * 對于每個階段的測試目標，定義了被測組件，職責，環境，進入標準，退出標準，工具，技術，可交付成果。 ![](https://img.kancloud.cn/e8/c1/e8c19515d6dbdfd019fd983071fe7be6_609x411.png) 通用測試目標-這些通用目標適用于多個項目和應用程序 * 組件符合要求，可以在更大的子系統中使用 * 解決了與特定測試類型相關的風險，并實現了測試目標。 * 集成組件已正確組裝。確保組件之間的接口兼容性。 * 該系統符合指定的功能和非功能要求。 * 產品組件可在其預期的操作環境中滿足最終用戶的需求 * 風險管理策略用于識別，分析和緩解風險。 * 系統符合行業法規要求 * 系統履行合同義務 * 制度化和實現其他特定目標，如成本，進度和質量目標。 * 系統，流程和人員符合業務需求 ![](https://img.kancloud.cn/fe/9c/fe9c7c048efda37d2e8b3fccaf137604_622x469.png) 可以為不同的測試階段定義通用的測試目標 * 組件測試 * 整合測試 * 系統測試 * 驗收測試讓我們考慮系統測試階段 1. G4 & G5 演示的系統滿足功能性（F1，F2，F3）和非功能性要求（N1，N2）。 2. 使用測試證明系統的預期特性和功能可以正常工作，并且可以通過功能測試解決與 F1，F2，F3 相關的風險 3. 使用測試證明系統的運行特性可以正常工作，并且可以通過非功能測試來解決與 N1，N2 相關的風險 4. 根據測試優先級編號，測試重要性可以分為高（紅色），中（黃色）&低（綠色）。 ## 優先級和風險評估矩陣風險評估矩陣是概率影響矩陣。它使項目團隊可以快速了解風險以及應對每種風險的優先級。 ``` Risk rating = Probability x Severity ``` 概率是不確定事件發生可能性的度量。根據時間，接近度和重復性進行接觸。用百分比表示。可以分為頻繁（A），可能（B），偶爾（C），遠程（D），不可能（E），消除（F） * 頻繁-預計在大多數情況下會發生幾次（91-100％） * 可能：在大多數情況下可能會發生幾次（61-90％） * 偶發：可能會在某個時間發生（41-60％） * 遠程–不太可能發生/可能在某個時間發生（11-40％） * 不太可能-可能在罕見和特殊情況下發生（0 -10％） * 消除-不可能發生（0％）嚴重程度是由于不確定事件導致的損壞或損失的影響程度。得分 1 到 4，可以分類為災難性= 1，嚴重= 2，邊際= 3，可忽略= 4 * **災難性** –嚴峻的后果，使項目完全無能為力，甚至可能導致項目停工。在風險管理期間，這必須是頭等大事。 * **嚴重**-重大后果，可能導致大量損失。項目受到嚴重威脅。 * **邊際** –短期損害仍可通過恢復活動來逆轉。 * **可以忽略不計**-損壞或損失很小或很小。這可以通過常規程序進行監視和管理。優先級分為四個類別，如下圖所示，它們與風險的嚴重性和可能性相對應。 * 嚴重 * 高 * 中 * Low ![](https://img.kancloud.cn/75/3e/753e62c9b7bff1ff6c51619815638394_566x369.png) **嚴重：**屬于此類的風險以琥珀色標記。必須停止活動，并且必須立即采取措施以隔離風險。必須確定并實施有效的控制措施。此外，除非將風險降低到中低水平，否則不得進行該活動。 **高：**屬于紅色風險操作或風險管理策略的標記為此類風險。必須立即采取行動以隔離，消除，替代風險并實施有效的風險控制。如果不能立即解決這些問題，則必須定義嚴格的時間表來解決這些問題。 **中：**屬于此類別的風險以黃色標記。必須采取合理和實際的步驟以最大程度地降低風險。 **低：**屬于此類的風險以綠色標記），可以忽略不計，因為它們通常不會帶來任何重大問題。必須定期檢查以確保控制措施有效 ## 基于風險的測試的通用檢查表基于風險的測試中要考慮的重要點的完整列表 * 項目中的重要功能。 * 項目中用戶可見的功能 * 具有最大安全影響的功能 * 對用戶產生最大財務影響的功能 * 源代碼和容易出錯的代碼的高度復雜的區域 * 可以在開發周期的早期進行測試的特性或功能。 * 在最后一分鐘將功能部件添加到產品設計中。 * 導致問題/問題的先前類似/相關項目的關鍵因素。 * 對運營和維護費用產生巨大影響的類似/相關項目的主要因素或問題。 * 不良的需求導致不良的設計和測試，可能會影響項目目標和可交付成果。 * 在最壞的情況下，產品的缺陷可能非常嚴重，以至于無法進行返工并且必須完全報廢，這將嚴重損害公司的聲譽。確定什么樣的問題對產品目標至關重要。 * 可能引起持續的客戶服務投訴的情況或問題。 * 端到端測試可以輕松地關注系統的多種功能。 * 最佳測試集可以最大程度地覆蓋風險 * 哪些測試具有最高的高風險覆蓋率與時間要求的比率？ ## 基于風險的測試結果報告和指標 1. **Test report preparation** 報告測試狀態是關于將測試結果有效地傳達給項目涉眾。并給出清晰的理解并顯示測試結果與測試目標的比較。 * 計劃的測試用例數與已執行的測試用例數 * 通過/失敗的測試用例數 * 識別出的缺陷數量及其狀態&嚴重性 * 缺陷數量及其狀態 * 嚴重缺陷數量-仍未解決 * 環境停機時間-如果有的話 * Showstoppers – if any 測試摘要報告，測試覆蓋率報告 2. **Metrics Preparation** 指標是用于比較軟件過程，項目和產品的兩個或多個度量的組合。 * 工作量和進度變化 * 測試用例準備生產力 * 測試設計范圍 * 測試用例執行效率 * **風險識別效率％** * **風險緩解效率％** * 測試效果％ * 測試執行范圍 * 測試執行效率 * 缺陷漏率％ * 缺陷檢測效率 * 需求穩定性指數 * 質量成本 3. 根據缺陷狀態和許多測試通過/失敗狀態（基于它們與風險的關系），分析非功能類別（性能，可靠性和可用性）中的風險。 4. 根據功能類別的測試風險，缺陷狀態和測試通過/失敗狀態，根據它們與風險之間的關系來分析風險。 5. 確定關鍵的超前和滯后指標并創建預警指標 6. 通過分析數據模式，趨勢和相互依存性，監視和報告提前和滯后風險指標（關鍵風險指標）。 ## 固有風險與殘留風險評估風險識別和分析還應包括固有風險，殘留風險，次要風險和經常性風險 * **固有風險**：在實施控制和響應之前已在系統中識別/已經存在的風險。固有風險也稱為總風險 * **殘留風險**：實施控制和響應后剩下的風險。殘留風險稱為凈風險 * **次要風險：**實施風險響應計劃導致的新風險 * **經常性風險：**發生初始風險的可能性。基于風險的測試結果度量有助于組織了解測試執行過程中質量風險的剩余水平，并做出明智的發布決策。 **風險分析和客戶反饋** 風險剖析是一種在考慮所需風險，風險承受能力和風險承受能力的情況下，為客戶找到最佳投資風險水平的過程。 1. 所需風險是客戶為了獲得滿意回報所需要承擔的風險等級 2. 風險承受能力是客戶可以承受的財務風險水平 3. 風險承受能力是客戶希望承擔的風險等級 **客戶反饋** 收集客戶反饋和評論，以改善業務，產品，服務和體驗。 ## 基于風險的測試的好處風險測試的好處如下 * 提高生產率并降低成本 * 改善了市場機會（上市時間）和準時交貨。 * 改善服務績效 * 測試了應用程序的所有關鍵功能，從而提高了質量。 * 提供有關測試覆蓋率的明確信息。使用這種方法，我們知道什么已經/尚未測試。 * 基于風險評估的測試工作量分配是最小化發布時殘留風險的最有效方法。 * 基于風險分析的測試結果度量使組織能夠確定測試執行過程中質量風險的剩余水平，并做出明智的發布決策。 * 使用高度定義的風險評估方法優化測試。 * 提高客戶滿意度–由于客戶的參與以及良好的報告和進度跟蹤。 * 盡早發現潛在問題區域。可以采取有效的預防措施來克服這些問題 * 在項目的整個生命周期中進行連續的風險監視和評估，有助于識別和解決風險，并解決可能危害實現總體項目目標的問題。 ### 摘要：在軟件工程中，基于風險的測試是基于風險指導項目的最有效方法。有效地組織了測試工作，并評估了每個風險項目的優先級。然后，將每種風險與適當的測試活動相關聯，其中單個測試具有多個風險項目，則該測試被指定為最高風險。根據風險優先順序執行測試。風險監控過程有助于跟蹤已識別的風險，并減少殘留風險的影響。