資料結構
網路
關係資料庫管理系統 (RDBMS)
作業系統
Java
Microsoft Excel
iOS
HTML
CSS
Android
Python
C語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
服裝設計
法學基於風險的測試——方法、矩陣、流程和示例
基於風險的測試 (RBT)
這是基於風險機率的軟體測試的一個子類別。在這個測試中，會對軟體進行評估以識別風險。它包括評估業務的 критичность、使用頻率、可能出現問題的區域等。這種型別的測試強調對易受缺陷影響的軟體特性和功能進行測試。
風險是指任何可能對專案結果產生影響（正面或負面）的意外事件的發生。風險可以是先前發生的事件，也可以是當前事件，甚至是未來可能發生的事件。這些事件會影響專案的成本、業務、技術和質量標準。
風險分為兩種：
積極風險——這些被稱為機會，能夠促進業務的可持續性。例如，投資新專案、改變業務流程等。
消極風險——這些被稱為威脅，應該執行減少或消除它們的建議以確保專案成功。
何時執行基於風險的測試
可以在以下情況下進行：
擁有適當的時間、資源、預算等的專案。
可以進行風險分析以查詢冗餘和SQL注入攻擊漏洞的專案。
雲計算中的安全測試。
具有高風險因素的專案，例如，缺乏專案中涉及的技術專業知識或缺乏領域知識。
迭代和逐步模型。
風險管理流程
以下是風險管理流程的步驟：
風險識別——這可以透過風險研討會、檢查表、頭腦風暴、訪談、德爾菲技術、因果圖、以往專案的觀察、根本原因分析、領域專家和主題專家來實現。
風險登記冊——這是一個電子表格，其中包含已識別的風險、可能的響應和根本原因的列表。它在整個專案中跟蹤和監控風險。風險應對策略用於處理積極和消極風險。風險分解結構對於風險規劃至關重要。它有助於識別易受風險影響的區域，並有助於有效評估和監控整個專案的風險。它有助於為風險管理留出足夠的時間和資源。它還有助於對專案可能產生的風險來源進行分類。
風險分析——列出潛在風險後，將根據其重要性對它們進行分析和篩選。這包括定量和定性風險分析。定性風險分析的一種技術是風險矩陣，用於估計風險的機率和影響。
風險應對計劃——根據此分析，可以確定風險是否需要響應。某些風險本質上需要在專案規劃中做出響應，而某些風險可能需要在專案監控中做出響應，而某些風險甚至根本不需要做出響應。風險所有者確定選項以最大限度地減少已分配任務的機率和有效性。
風險緩解——這是一種最大限度地減少風險或潛在威脅的影響的方法。它是透過消除風險或將其最小化到指定的可接受水平來執行的。
風險應急——這是無法預測的事件的可能性，其影響既未知也無法估計。應急計劃也稱為行動計劃或針對最壞情況的備用計劃。它有助於決定在意外事件發生時應採取的步驟。
風險監控和控制——這是一個跟蹤已識別風險、監控殘餘風險、發現新風險、更新現有風險、分析變化、執行響應計劃和監控風險觸發器的過程。這可以透過風險評估、風險審計、差異和趨勢分析、測量技術性能、更新狀態會議和追溯會議來實現。
請注意，隨著技術的變化、專案規模、專案長度或持續時間、贊助機構的數量、工作量和缺乏適當技能，風險會增加。
基於風險的測試方法
分析需求。
審查文件，例如 SRS、FRS、用例等，以檢測和消除錯誤和歧義。
為了避免在專案中引入任何後期更改，採用了稱為“需求籤核”的風險降低技術。在對文件進行基線化之後，如果必須進行任何更改，則需要更改控制流程和後續批准。
透過確定每個需求對專案的影響和可能性來評估風險，同時考慮已定義的標準，例如成本、進度、資源、範圍、技術性能安全、可靠性等。
確定故障機率和易受風險影響的區域。這是使用風險評估矩陣完成的。
維護風險登記冊以記錄已識別的風險。定期更新、跟蹤和監控風險。
在此階段執行風險分析以確定風險的能力和容忍度水平。
根據其等級對需求進行優先排序。
定義基於風險的測試流程。
高度關鍵和中等風險將被納入緩解規劃、實施和進度監控，而低風險則列入觀察清單。
透過風險資料質量評估來評估資料質量。
根據等級規劃測試。
採用適當的方法和測試設計技術來設計測試用例，以便首先測試最高風險的專案。可以使用具有專家領域知識的資源來測試此類專案。
可以採用不同的測試設計技術，例如對於高風險測試專案使用決策表技術，而對於低風險專案使用等價劃分。
測試用例還涵蓋多個功能和端到端業務場景。
開發測試資料、條件和測試平臺。
審查測試計劃、測試策略、測試報告以及測試人員建立的其他文件。這對於識別和減少缺陷至關重要。
進行試執行並檢查結果質量。
確保風險、涵蓋它們的測試、其結果以及在測試中發現的缺陷之間的可追溯性。
在系統級別，重點關注軟體中最重要的內容。這可以透過檢視功能的可見性、使用頻率和估計的故障成本來實現。
評估退出標準。到目前為止，所有高風險區域都已測試完畢，只有少量風險未得到處理。
報告基於風險的測試結果。
根據關鍵風險指標 (Key Risk Indicators) 重新評估之前的和新的風險事件。
更新風險登記冊。
分析和防止缺陷以消除它們。
執行迴歸測試，以根據估計的風險分析驗證修復程式。必須全面覆蓋高風險區域。
如果可行，執行基於風險的自動化測試。
計算殘餘風險。
對不同風險級別使用退出或完成標準。
評估風險分析和客戶反饋。
基於風險的測試方法
技術系統測試——也稱為環境測試和整合測試，包括在開發、測試和生產環境中進行測試。
功能系統測試——這測試所有功能、特性、程式和模組。其目標是評估系統是否滿足指定的要件。
非功能系統測試——這測試非功能方面、效能、負載測試、壓力測試、配置、安全、備份和恢復程式以及文件。
優先順序和風險評估矩陣
風險評估矩陣，也稱為機率影響矩陣，使測試人員能夠快速瞭解風險以及解決風險的優先順序。
機率是衡量意外事件發生可能性的指標。時間、接近程度和重複次數的暴露程度以百分比表示。
它們是：
頻繁 (A)——預期在大多數情況下會發生多次。(91-100%)
可能 (B)——很可能在大多數情況下發生多次 (61-90%)
偶爾 (C)——有時可能會發生 (41-60%)
罕見 (D)——不太可能發生/有時可能會發生 (11-40%)
不可能 (E)——在罕見情況下可能會發生 (0-10%)
已消除 (F)——不可能 (0%)
嚴重性是衡量意外事件造成的損失程度的指標。其評分為1-4級，具體分類如下：
災難性 = 1 − 嚴重影響，導致生產力降至零。也可能導致專案終止。在風險管理中具有最高優先順序。
嚴重 = 2 − 重大影響，可能造成巨大損失，嚴重威脅專案。
輕微 = 3 − 短期影響，但可逆。
可忽略 = 4 − 損失很小，可以透過常規程式進行管理。
優先順序分為4個類別：嚴重、高、中、低。
嚴重 − 必須終止專案，並立即採取有效措施隔離風險。除非風險降低到低或中等水平，否則專案不予恢復。
高 − 立即採取措施隔離、消除和替代風險，採取有效的風險控制措施。如果不能立即解決，則定義嚴格的時間表來解決。
中 − 採取合理可行的措施將風險降至最低。
低 − 通常不會構成任何威脅，可以忽略。但是，應定期審查以確保控制措施有效。
結果報告和指標
測試報告準備 − 測試狀態報告包括有效地與利益相關者溝通結果。它提供了對測試結果和目標的清晰理解和比較。
計劃和執行的測試用例數量。
透過和失敗的測試用例數量。
已識別缺陷的數量、嚴重性和狀態。
現有嚴重缺陷的數量。
環境故障。
指標準備 − 指標是多個度量的組合，用於比較軟體流程、專案和產品。
進度和工作量變化。
測試用例編制效率。
測試設計覆蓋率。
風險識別效率
風險緩解效率
測試有效性。
測試執行覆蓋率。
測試執行效率。
缺陷遺漏。
缺陷識別效率。
需求穩定性指數。
質量成本
根據缺陷狀態以及測試透過和失敗狀態的數量，分析功能和非功能方面所涉及的風險及其與風險的關係。
確定關鍵的領先指標和滯後指標，制定預警指標。
透過分析資料模式、趨勢和依賴關係來跟蹤和報告領先指標和滯後指標。
基於風險的測試的優勢
基於風險的測試測試軟體的所有重要功能。它提供了對專案中涉及風險的即時清晰理解。
強烈強調業務專案的風險，而不是資訊系統的功能。
測試可以用所有利益相關者都能理解的語言進行。
它專注於最佳測試交付、生產力和成本降低。
3000+ 次瀏覽
