基于風險的測試

風險是指負面或不希望發生的后果或事件發生的可能性。當引起客戶、用戶、參與者或干系人對產品質量或項目成功的信心減弱的問題可能發生時，風險就存在。當潛在問題主要影響的是產品質量時，它們被稱為質量風險、產品風險或產品質量風險。而當潛在問題主要影響的是項目成功時，它們則被稱為項目風險或計劃風險。

在基于風險的測試中，在干系人參與的產品質量風險分析的過程中對質量風險進行識別和評估。測試團隊設計、實施和執行測試來緩解質量風險。質量包括影響客戶、用戶和干系人滿意度的全部功能、行為、特征和屬性。因此，質量風險是產品可能存在質量問題的情況。系統質量風險的例子包括報告中的錯誤計算（與準確度相關的功能風險），用戶輸入響應慢（與效率和響應時間相關的非功能風險），界面和字段難以理解（與易用性和易理解性相關的非功能風險）。當測試找出了缺陷時，通過讓他人意識到這些缺陷，并在發布前有機會處理這些缺陷，測試緩解了質量風險。當測試不再發現缺陷時，通過確保在測試條件下，系統可以正常運作，測試也緩解了質量風險。

基于風險的測試使用產品質量風險來選擇測試條件，為這些條件分配測試工作，并為生成的測試用例設定優先級。基于風險的測試有各種各樣的技術，這些技術在采集的文檔的類型和級別，以及運用的形式方面大相徑庭。基于風險的測試明確指出的或隱含的目的就是用測試來降低整體的質量風險水平，具體而言是把風險水平降低到可接受的范圍。

基于風險的測試包含四個主要活動：

1、風險識別

2、風險評估

3、風險緩解

4、風險管理

要想取得最佳的效果，風險識別和評估小組應包括所有項目和產品干系人的代表，不過有時項目的實際情況導致某些干系人代理其它干系人。例如，在大眾市場的軟件開發中，可能抽樣一小部分潛在客戶，要求他們幫助識別潛在的嚴重影響他們使用軟件的缺陷；在這個例子中，抽樣的小部分潛在客戶就是作為所有最終客戶群的代理人。由于測試人員在產品質量風險和失效方面的專長，他們應該積極參與風險識別和評估過程

一、風險識別

干系人可通過下列的一項或多項技術來識別風險：

1、專家咨

2、獨立評估

3、使用風險模版

4、項目回顧

5、風險研討會

6、頭腦風暴

7、檢查表

8、參考過去的經驗

對參與風險識別的干系人的抽樣越廣泛，風險識別過程就越有可能識別出越多的嚴重產品質量風險。

風險識別通常會產生一些副產品，例如，識別出并非產品質量風險的問題。例子包括有關產品或項目的一般疑問或問題，或參考的文檔，如需求和設計說明中的問題。質量風險識別的另一副產品是識別出項目風險，不過項目風險并不是基于風險的測試關注的焦點。然而，項目風險管理對于包括基于風險測試在內的所有測試方法都是很重要的

二、風險評估

識別了風險后，就開始風險評估，即研究識別出的這些風險。具體而言，風險評估包括對每個風險進行分類，確定風險發生的概率和影響。風險評估還可能涉及評價或分配每個風險的其它屬性，如風險責任人。

風險的分類就是將每個風險劃分到適當的類型中，例如性能、可靠性、功能性等等。有些組織使用 ISO9126（ISO 9126 標準正在被 ISO 25000 標準所取代）的質量特征進行分類，但大多數組織采用的都是其它的分類方案。風險分類時使用的檢查表通常與風險識別使用的相同。有通用的質量風險檢查表，許多企業都根據自己的需要定制這些檢查表。如果使用檢查表作為風險識別的基礎，在風險識別時通常就進行了風險的分類。

確定風險的級別通常包括評估每條風險發生的可能性，以及發生之后的影響。發生的可能性是指被測系統存在潛在問題的概率。換句話說，可能性是對技術風險的級別的評估。

影響產品和項目風險發生的可能性的因素包括：

1、技術和團隊的復雜性

2、業務分析師、設計師和程序員的人員和培訓問題

3、團隊內部的沖突

4、與供應商的合同問題

5、異地工作的團隊隊員

6、舊方法與新方法對立

7、工具和技術

8、管理或技術領導不力

9、時間、資源、預算和管理壓力

10、缺乏前期的質量保證活動

11、高變更率? 早期的高缺陷率

12、 接口和集成問題

風險發生的影響是指風險發生對用戶、客戶或其它干系人的影響的嚴重程度。換句話說，影響來自于業務風險。影響項目和產品風險的影響程度的因素包括：

1、使用受影響的特性的頻率

2、該特性對于實現業務目標的關鍵程度

3、聲譽的損害? 商業損失

4、潛在的財務、生態、社會損失或法律責任

5、民事或刑事法律制裁

6、吊銷執照

7、缺乏合理的變通

8、明顯的失效導致負面聲譽

9、安全性

風險的級別既可定性也可定量地評估。如果確定了可能性和影響的量化數據，可以將這兩個值相乘，計算出定量的風險優先級數值。不過通常風險的級別只能通過定性的方式確認。也就是說，我們可以將可能性形容成很高、高、中、低或很低，但無法用精確的百分比表達出來；同樣地，我們可以將影響形容成很高、高、中、低或很低，但也不能完整或精確地表達財務上的影響。不應該認為定性的方法比定量的方法差；實際上，如果風險級別的定量評估使用不當的話，會誤導干系人對風險程度的理解和管理。風險級別的定性評估通常通過乘法或加法相結合，得到一個風險總分。這個風險總分可能被稱為風險優先數，但確切來說，它應是定性的、有序的相對評級。

另外，除非風險分析基于廣泛的、有效統計的風險數據，風險分析應該更多基于干系人對于可能性和影響的主觀感知。通常，項目經理、編程人員、用戶、業務分析師、架構師和測試人員的感知各不相同，因此針對各項風險的風險級別可能有不同的意見。風險分析過程應包括達成共識，或者即使在最糟的情況下，也要有確立都同意的風險級別的方式（如通過管理層下達命令或通過取該風險級別的平均值，中間值或眾數值）。此外，還應檢查風險級別的分布情況，確保風險的評分對于測試排序、優先級設定和分工能起到實際的指導作用。否則，將無法使用風險級別來指導風險緩解活動。

三、風險緩解

基于風險的測試從質量風險分析（識別和評估產品質量風險）開始。質量風險分析是主測試計劃和其它測試計劃的基礎。正如計劃中所述，測試的設計、實施和執行是為了覆蓋風險。開發和執行測試的工作量與風險的級別成一定比例，也就是說風險的級別越高，使用的測試技術就越細致（如結對測試），風險的級別越低，使用的測試技術就越不細致（如等價類劃分或有時限的探索性測試）。此外，開發和執行測試的優先級也是依據風險級別而設定。有些安全規范（如 FAA DO-178B/ED 12B,IEC 61508）規定了基于風險級別的測試技術和覆蓋率。另外，風險的級別還應影響到一些決策，例如使用項目工作產品（包括測試）的評審、獨立的級別、測試人員的經驗水平、確認測試（再測試）和回歸測試的程度。

在項目開展期間，測試團隊仍應對改變質量風險集和／或已知質量風險的風險級別的補充信息保持了 解。應該定期調整質量風險分析，至少在項目的主要里程碑到來時（進行這種調整），以此來指導對測試的調整。調整包括識別新風險，重新評估現有風險的級別和評價風險緩解活動的有效性。例如，如果在需求階段，基于需求規格說明進行了一次風險識別和評估，那么當設計規格說明定案后，就應對已有的需求規格風險重新進行評價。再如，如果在測試中發現某個組件包含的缺陷要遠比預期的缺陷數多，則可得出在此區域缺陷的可能性比預期的要高的結論，并將風險的可能性和整體風險級別上調，根據調整結果就應增加該組件測試的工作量。

在測試執行開始之前也可以緩解產品質量風險。例如，如果在風險識別時發現了需求的問題，項目組就可以通過實施全面的需求規格說明評審來緩解這一風險。這樣做可以降低風險的級別，可能意味著緩解殘余質量風險所需的測試數目減少。

四、生命周期中的風險管理

理想情況下，在整個生命周期期間都在進行風險管理。如果組織有測試方針文檔和／或測試策略文檔，這些文檔中應當描述測試中管理產品風險和項目風險的一般過程，以及風險管理怎樣集成到測試的各個階段中，并使其發揮作用。

一個成熟的組織，風險意識應遍及整個項目組，在這樣的組織中，風險管理并非僅僅發生在測試中，而是發生在各個方面。重要的風險不僅在特定測試級別的前期就得到處理，而且在早期的測試級別中也得到了處理。例如，如果性能被識別為一個關鍵質量風險區域，性能測試在系統測試的前期就會開始進行，而且在單元測試和集成測試時也會運行性能測試。成熟的組織不僅識別風險，還識別風險的來源和風險一旦發生將帶來的后果。對于那些確實發生的風險，使用根本原因分析來深入理解風險的來源和實施過程改進，防范于未然。風險緩解貫穿于整個軟件開發生命周期。風險分析獲得了充足的信息，考慮到了相關的工作活動、系統行為分析、基于成本的風險評估、產品風險分析、最終用戶風險分析和責任風險分析。當測試團隊參與并對整個程序范圍的風險分析產生影響的情況下，風險分析超越了測試的范疇。

大多數基于風險的測試方法還包括用風險級別來對測試進行排序和優先級設定的技術，以此確保測試執行時盡早覆蓋最多的重要區域，發現最多的重要缺陷。某些情況下，所有的高級別風險的測試都是在較低級別風險測試之前進行的，且測試的運行嚴格按照風險排序（通常稱為“深度優先” ）；其它情況下，測試優先級根據抽樣方法來制定。抽樣方法就是選擇一個測試樣本，該測試樣本可以覆蓋到所有已識別的風險。用風險覆蓋率評估選出的測試樣本，確保每條風險至少被覆蓋到一次（通常稱為“廣度優先” ）。

無論基于風險的測試是深度優先還是廣度優先，分配給測試的時間都有可能不足。基于風險的測試使得測試人員能以剩余風險級別的方式向管理層報告當前測試狀態，讓管理層決定是否要增加測試時間或將剩余的風險轉移給用戶／客戶、服務／技術支持人員和／或運營人員。

在測試執行期間，最先進的基于風險的測試技術（并不一定是最正式或重量級的技術）讓項目參與人、項目和產品經理、高層行政管理人員和項目干系人根據剩余風險級別監督和控制軟件開發生命周期，包括做出是否發布的決策。這就要求測試經理在匯報有關風險的測試結果時，要確保所有干系人都能理解。

總結

以上是生活随笔為你收集整理的测试管理 | 基于风险的测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。