對於測試工程師而言，隨著在這個行業的深耕，逐漸會接觸到一些專案層次的理念和方法論。

風險分析以及風險管理就是其中重要的一項。

風險管理與質量控制實際存在著非常大的關聯關係，也是管理測試的有效理念。

1. 什麼是風險

在專案管理的領域內，風險被定義為：某一事件發生給專案目標帶來不利影響的可能性。

在開發新的軟體系統過程中，由於存在許多不確定因素，軟體開發失敗的風險是客觀存在的。因此，風險分析對於軟體專案管理是決定性的。風險管理是專案管理團隊的重要職責，也是促使專案成功的有效辦法，測試管理人員以及整個測試團隊在這個過程當中要起到非常重要的作用。

風險分析實際上就是貫穿在軟體工程過程中的一系列風險管理步驟，其中包括：風險識別、風險評估、風險策略、風險解決和風險監督等。

對大多數軟體研發組織和專案而言，當談及風險的時候，一般分為兩個方面：

• 專案風險（過程風險）
• 產品風險（質量風險）

我們首先要將這兩個概念區分開來，因為測試團隊在這兩項風險管理過程中的任務可能是截然不同的。

1.1 專案風險

專案風險或者叫“過程風險”是圍繞專案按目標交付的能力的一系列風險，比如來自組織方面，人員管理方面，流程方面和其他方面的風險。

我們只對測試工程中常見的風險做一個大致羅列，如：

• 技能、培訓和人員不足；
• 專案團隊成員出現的個人問題，人員流失；
• 組織內部協作不調，缺乏有效的溝通渠道；
• 管理流程缺乏組織，測試工作的支撐和依賴無法得到滿足；
• 專案成員尤其是管理人員可能對測試團隊抱有錯誤的態度和認知；
• 有效的測試方法（比如靜態測試）不受重視；
• 技術支援的缺乏導致的測試技術問題；
• 測試時間受到壓縮；
• 交付的程式碼質量低下，加重測試以及返工任務量；
• 產品的缺失配置管理，變更流程等控制手段；
• 離岸團隊的合作效率問題；
• 第三方支援的問題；

以上都是可能影響到測試任務完成的常見專案風險，管理人員需要在計劃階段對風險進行預估，並給出規避方案和應急措施。

1.2. 產品風險

產品風險又稱為“質量風險”，用通俗的話講即為：“產品交付之後可能帶有的質量問題”。

為什麼我們研發的軟體產品會有風險存在呢？問這個問題實際就等同於問“為什麼軟體產品可能會有缺陷呢”？

其實其本質在於“人都是會犯錯誤的”這樣一個論斷的成立。

基於這個論斷我們又可以推論出：“因為人都會犯錯誤，所以人開發出來的軟體也就可能帶有錯誤”。

這些在研發過程中我們犯的錯誤，遺留在產品中，就是缺陷；缺陷存在的可能性，就是產品風險。

產品風險產生的原因，可能有以下這些：

1. 產品大小/程式碼量：工作量越大，那麼我們就越有可能犯錯。
2. 技術因素：未曾使用過的新技術都存在風險。包括未使用過的新型硬體、支援軟體，缺乏標準與規範的非傳統的開發方法等。技術過時也是風險。
3. 開發環境：適用的開發工具不足、不可靠、使用不方便等因素，都會降低開發效率。
4. 組織規模和人員經驗：比如人手不足，人員經驗不豐富，都有可能帶來產品風險。
5. 客戶因素：表現在客戶需求經常矛盾，不瞭解客戶的特殊需要，客戶不瞭解專案中採用的新技術，且雙方又難於溝通等。

在軟體研發領域，通過測試過程發現並且解決問題，實際就是產品風險的最重要和直接的規避手段。

換言之，軟體測試就是產品風險管理的重要手段，也即產品風險控制的有效辦法，甚至有些組織會將軟體測試從組織架構上納入風險管控部門。

常見的軟體產品風險有如下型別：

• 軟體的故障頻發；
• 軟體/硬體對個人或公司造成損害；
• 軟體特性低劣，比如效能低下；
• 資料完整性不足；
• 既定的功能未被完全滿足；

等等。可以看到，以上的軟體產品風險，我們軟體測試的活動和任務都有可能對他們進行評估，並且通過資訊收集和事件報告等手段實現規避和控制的目的。

2. 專案風險管理

風險管理一般通過下面四個階段來完成：

1. 風險識別
2. 風險評估
3. 風險緩解
4. 風險監控

 在進行風險管理的過程中，要把握好四個原則：

• 可避免的風險，採取好的過程管理和流程控制來應對；
• 不可避免的風險，採取降低和轉移的措施；
• 做好風險管理計劃；
• 做好應急方案；

我們列舉一下測試過程中可能存在的風險和對應的可行舉措：

對於測試過程風險：

• 需求的計劃外變更
  • 做好變更控制和配置管理
  • 為可能的變更預留時間和人員的調整空間
• 測試用例執行率不足
  • 日常跟蹤所有工作過程，及時發現阻礙測試執行的因素並協調解決
• 測試分析產生偏差
  • 更完善的測試分析流程，對於經驗不足的人員安排指導
  • 用評審的手段予以檢查
• 測試用例設計不足
  • 更完善的測試分析流程
  • 充足的人員技能培訓和指導
  • 用例評審的把關
測試與生產環境差異
• 儘量縮小測試環境與生產環境的差異，比如使用更大的資料量
• 更強的客戶響應以確定使用者生產環境的特性
• 偶現類問題
  • 倡議充分的問題記錄和分析流程
• 程式碼質量過低
  • 更好的單元測試實行
  • 倡議和建立規範的提測控制流程
• 迴歸測試覆蓋率不足
  • 適合的迴歸測試策略
  • 自動化的迴歸測試覆蓋

對於人員風險：

• 人員流失
  • 積極響應人員訴求
  • 創造更積極的工作流程及環境
  • 做好人員技能儲備
• 人員不可用狀態（休假等）
  • 建立良好的文件歸檔流程
  • 建立完善的工作後備機制（不可讓某項工作只有某一個人能完成）
  • 協調完備的人員抽調機制
• 新人工作準備
  • 建立良好的人員培訓機制
  • 建立幫助新人融入的導師機制
• 外包人員管理
  • 控制專案團隊中外包或兼職人員的比例
  • 與外包人員保持足夠的溝通和把控
  • 與外包公司保持足夠的管理聯絡

可以看到這部分專案風險預估和應對的內容，更多的出現在測試計劃以及一些專案籌劃會議上，應劃歸為專案管理範疇。

3. 基於風險的測試

上文提到，專案風險需要通過管理手段和策略來緩解規避。

那麼產品風險呢？長話短說：測試（質量控制）就是降低產品風險的行之有效的手段。

正因為如此，所以以風險為基準來制定的策略是測試領域內非常重要也非常普及的一種方法。

這就是所謂的基於風險的測試（Risk Based Test - RBT）。

常見的測試策略可能有：

• 分析型策略
• 基於模型的策略（如：基於執行概況分析的測試） ·
• 符合過程或標準的策略（如符合OWASP標準的web安全測試）
• 應對型策略（如：探索性測試）
• 諮詢式策略（如：外部機構測試）
• 面向迴歸測試策略（如：自動化迴歸測試）

而基於風險的測試就是典型的分析性策略。

正如我們前文中提到的專案風險和產品風險的區別，基於風險的測試是基於“產品”風險而非專案風險。通過對於產品不同區域和特性可能遺留缺陷，以及其影響程度的分析，確定測試的資源分配等問題。

基於風險的測試策略之所以有很大的應用價值，是基於以下幾個基本論斷：

1. 事有輕重緩急，對於測試工程而言，並非所有被測物件和模組都具有同等的重要程度。
2. 測試不可窮盡，測試成本和錯誤成本處在天平兩端，用更少的資源和成本覆蓋更多更重要的測試目標是測試管理的重要訴求。
3. 缺陷具有叢集性，經驗而論，對於缺陷集中的模組投入更多的測試關注度和資源可以最有效的發現最多的缺陷，從而帶來質量的快速提升。

下面我們通過一個簡化版的RBT例項來論述其組織實施過程。

某稅務處理系統

• 該專案為一個COTS產品的定製性二次開發專案
• 專案週期計劃為4個月
• 採用持續整合，高速迭代的研發方式

①風險識別：識別出軟體研發過程中，可能產生缺陷的區域，包括功能模組和專項問題，羅列如下：

這個風險識別的過程，可以依靠專家的分析，比如測試經理和開發組長、專案經理等的討論，但是更多的情況下應該依靠集體智慧，條件允許的話專案所有利益相關方，都應該參與到風險分析的過程中來。在風險識別這個動作上，頭腦風暴是一種可行的方法（即與會各方各抒己見，提出自己認為產品可能有的風險項）。

除了頭腦風暴法以外，更為嚴格的風險研討會議，經驗總結會議，第三方獨立評估，問卷調查法都是可以使用的風險識別方法。不同的人員處在不同角度和專業背景下，對於風險的識別和分析等可以提供更全面專業的思路。

②風險評估：在風險評估過程中，我們要對上個階段列出的風險專案做出評估，得出風險高低大小的一個排序。

風險評估中需要考慮的兩個維度：風險發生的可能性大小，以及風險如果發生，帶來的影響範圍和嚴重程度。兩個維度結合起來，才最終定義一個風險專案的級別高低。

因此，首先需要確定我們對於這兩個維度以及風險級別之間的判別關係，採用風險定義矩陣是一個比較好的做法，比如採用如下風險分析矩陣：

將識別階段得出的風險專案列表進行兩個維度的風險判斷，得出如下結果：每一個風險項都從兩個維度給他’高、中、低‘的判斷，得出下表：

按照風險分析矩陣，進一步整理：

到此為止我們已經得到了風險評估結果列表，可以使用風險追蹤表格管理起來。

在這個評估過程中，只是使用簡單的高中低三個級別的劃分對於風險進行評估。如果需要更為精細的評估，也可以採用更為細緻的評分方式，並且對於風險的發生概率和影響度可以分開進行更為嚴格的評估，比如使用下表進行的發生概率分析：

 同理對於另外的影響範圍和嚴重程度，也可以做出類似的分析評估。

最後使用（可能性X影響）的公式得出風險專案的最終級別。

③風險緩解

基於產品風險分析，測試管理人員可以在測試活動的安排上，實施緩解措施：

確定測試優先順序

根據測試風險的分析和評估得到的風險分佈，確定測試的優先順序。如上例中，將風險級別最高的三個專案定位最高優先順序，優先進行測試分析、設計和執行。其他項以此類推。

確定測試完備性

前面提到的一個假設條件：並不是所有的測試對專案而言是同等重要的。同樣的道理，並不需要對測試物件的不同內容進行同等重要的測試，最重要或者風險最大的模組或者物件需要測試得更加徹底，更加完備。而對於風險比較小、優先順序低的模組或物件，可以簡單測試。對於優先順序最低的物件，在時間和成本等不允許的時候，甚至不進行測試。

為達到更高的完備度，可以採用更為嚴格的測試分析、設計，更為全面的執行和測試覆蓋。

測試資源優化分配

根據測試風險的分析和測試優先順序的評估，將經驗豐富和技術能力豐富的測試人員（不管是設計人員、實現人員，還是執行人員）放在最重要的模組或測試物件中，可以達到如下效果：

• 設計更加完善、完備和準確的測試用例。
• 實現高質量的測試用例指令碼和程式碼。
• 更加高效地發現測試物件中的缺陷。

這種基於風險的測試策略可以非常有效的幫助測試團隊快速實現重要模組的測試覆蓋，並且可以有效的快速提升產品質量，進而帶來利益相關方的信心提升。同時，對於測試監控而言也是非常有幫助的。

④風險追蹤

風險分析不是一個一次性的工作，需要持續追蹤。通過在專案實際研發過程中得到的資訊和反饋，對風險等級進行調整，比如調高和調低風險等級。

一個實際的例子是：當專案開始時，將某一個風險專案定為了高階，因此這個風險項很有可能引起了團隊的重視。而正因為團隊對這個風險專案很重視，以至於在後續工作開展過程中，團隊投入了更多的資源和力量，導致最終測試階段可能反而在這個模組裡面沒有發現太多問題，也即他真正展示出來的風險等級並沒有預計的那麼高。當發現這樣的現象時，應該對風險跟蹤表做出及時更新。

風險級別的更新可以是即時的，即發現現象則對應更改；也可以是階段性的，比如每週一次，對於風險專案進行更新和調整。

風險級別一旦發生調整，測試活動的安排也應隨之相應調整。

4. 總結

風險的控制，在企業生產和管理中是被廣為接受和採納的理念。

對於軟體產業而言，產品質量風險的緩解很大程度依賴於測試工作所提供的質量控制（QC）。

也許並不是所有測試人員都會採用如本文所述的精益化的風險管理過程，但不管是對於測試管理人員還是測試技術人員而言，風險的觀念都是不可或缺的。

不論採用怎樣的測試過程，都應採用風險管控理解來編排工作，抓住重心，這樣才能將有限的（有時非常有限！）測試時間合理投入到無限的任務中