例項！用軟體風險分析來實施測試
在開發新的軟體系統過程中，由於存在許多不確定因素，軟體開發失敗的風險是客觀存在的。因此，風險分析對於軟體專案管理是決定性的。風險分析實際上就是貫穿在軟體工程過程中的一系列風險管理步驟，其中包括：風險識別、風險估計、風險管理策略、風險解決和風險監督等。
要理解風險分析，我們首先要理解‘風險’這個名詞。用漢語的邏輯去對這個詞做一個通俗性解釋，可以這麼展開： 風險=“一個不好的事情可能會發生” 。這裡要注意這句話裡的兩個要素：一是“可能”，即這是一種可能性的預測，他不是真實已經發生的或者100%一定發生了的事；二是“不好的事”，站在軟體產品質量的角度而言，就是質量的一個瑕疵、問題。
那麼總結一下，對於軟體產品而言，產品的風險就是軟體產品可能會有質量問題的情況（更直白一點就是，產品可能會有缺陷）。
我們引用ISTQB對於產品風險定義：
在軟體或系統中的潛在失效部分（即將來可能發生不利事件或危險）稱之為產品風險，因為它們對產品質量而言是一個風險，包括：
- 故障頻發的軟體交付使用；
- 軟體/硬體對個人或公司造成潛在損害的可能性；
- 劣質的軟體特性（比如功能性、可靠性、易用性和效能等） ；
- 低劣的資料完整性和質量（例如：資料遷移問題、資料轉換問題、資料傳輸問題、違反數 據標準問題）；
- 軟體沒有實現既定的功能。
那麼為什麼我們研發的軟體產品會有風險存在呢？其實問這個問題就等同於問’為什麼軟體產品可能會有缺陷呢‘？其實這個問題的本質就在於’ 人都是會犯錯誤的 ‘這樣一個論斷的成立。基於這個論斷我們又可以推論出：’ 因為人都會犯錯誤，所以人開發出來的軟體也就可能帶有錯誤 ‘。這些在研發過程中我們犯的錯誤，遺留在產品中，就是缺陷；缺陷存在的可能性，就是產品風險。
我們還可以更具體的去討論，哪些因素，可能導致我們研發軟體時更容易在產品中遺留錯誤：
① 產品大小/程式碼量：工作量越大，那麼我們就越有可能犯錯。
② 技術因素：未曾使用過的新技術都存在風險。包括未使用過的新型硬體、支援軟體，缺乏標準與規範的非傳統的開發方法等。技術過時也是風險。技術風險一般難於改正。
③ 開發環境：適用的開發工具不足、不可靠、使用不方便等因素，都會降低開發效率。
④ 組織規模和人員經驗：比如人手不足，人員經驗不豐富，都有可能帶來產品風險。
⑤ 客戶因素：表現在客戶需求經常矛盾，不瞭解客戶的特殊需要，客戶不瞭解專案中採用的新技術，且雙方又難於溝通等。
所以，既然軟體產品的風險是客觀存在的，我們就要採取必要手段對風險進行處理，於是就引出了我們今天的課題，’ 風險分析 ‘。
首先描述一下風險分析的步驟，一般而言我們可以認為風險分析包括以下部分內容：
- 風險識別想要控制風險，我們首先要知道有哪些風險，不然談何控制？
- 風險評估知道了有哪些風險，其次我們要判斷風險有多大，有多嚴重
- 風險緩解知道了風險有哪些和他的嚴重程度，我們就要想辦法去緩解和規避風險
- 風險管理最後我們要對風險進行管理，達到風控的目標
理論說了這麼多，下面用一個簡單的實際例子來詮釋風險分析的過程。
我還是拿上一篇《 ofollow,noindex"> 例項！軟體缺陷資料度量和分析 》中的COTS專案為例，這個專案情況是這樣的：
- 該專案為一個COTS產品的定製性二次開發專案
- 專案週期計劃為4個月，實際完成時間為6個月
- 專案是一個總體人員不到10人的小型專案
- 採用持續整合，高速迭代的研發方式
第一步：列出軟體的所有功能和特性
根據專案相關人員對本專案的調研，我們列出了以下的軟體功能模組和特性：
所有主功能：訂單支付模組、使用者管理模組、後臺管理模組、瀏覽展示模組、使用者評價子系統、活動模組、促銷管理模組
質量專項問題：功能性問題、效能問題、介面問題、易用性問題、安全性問題、計算錯誤、描述錯誤
用表格來展示就是這樣的：
所有我們列出來的這些條目，就是所謂的“風險專案”。
那麼風險識別這件事，在專案裡應該由誰來做呢？一般情況下，風險分析的過程除了有專家的參與，更是一種集體智慧的體現，也就是說專案所有利益相關方，都應該參與到風險分析的過程中。在風險識別這個動作上，頭腦風暴是一種可行的方法（即與會各方各抒己見，提出自己認為產品可能有的風險項）。
第二步：對每個風險專案做出風險等級評估
在風險評估過程中，我們要對上個階段列出的風險專案做出評估，得出風險高低大小的一個排序。
這裡我們要考慮風險的兩個維度：風險發生的可能性大小，以及風險如果發生，帶來的影響範圍和嚴重程度有多大。
我們首先用定性的方法對風險進行評估，採用風險評估矩陣來指導我們的評估過程：
我們將前一階段得出的風險專案列表進行兩個維度的風險判斷，得出如下結果：每一個風險項我們都從兩個維度給他’高、中、低‘的判斷：
那麼這個填表過程是由誰來執行呢？答案仍然是集體智慧。風險評估會議要求各專案利益相關方參與，專案團隊的成員，包括客戶（如果可能的話）每個個體都可能在評估過程中表達自己在某一方面最權威的意見。打個比方說，上面表單裡的’訂單支付模組‘的影響範圍，最適合對他進行評估的可能就是：客戶、需求人員和測試工程師；而對於’後臺管理系統‘的風險概率，最適合對他進行評估的可能是：開發組長或者對應的開發人員，以此類推。
得到這個評估表，我們使用先前的風險評估矩陣對他進行排序和整理，就得出以下結果：
進一步：
到此為止我們就完成了定性風險評估的過程。
不過這種定性分析還沒有能夠很細緻的展示各風險項之間更細節的風險等級，比如上圖標註紅色，風險等級為高的三個專案，他們之間的排序我們並不能確定。
所以我們可以改為採用更為細緻的一種定量分析，比如我們把’高、中、低‘這樣的指標轉換為’3，2，1‘這樣的得分系統，可以得出如下結果：
可以看到，通過得分相加（採用發生概率和影響範圍兩個指標相乘是一種更合理的做法）這樣的形式，我們得出了更為細緻的風險等級劃分。
實際上我們還可以更進一步細化，比如對於所有風險項的發生概率，我們可以結合其產生原因進行去量化分析：
對於風險的影響範圍，我們從相關風險的使用頻率和問題的嚴重程度去進行量化：
這樣再從兩個維度去對這個表格做一個運算，不管是用相加還是相乘的策略，我們就能得出更準確的一個風險排序。
當然風險評估除了矩陣法，還有一些其他的方法我們就不一一闡述了。
第三步：定義風險緩解措施
既然我們已經得到風險由高到底的一個風險結果，那麼我們就要實施一些措施，對這些風險進行規避和緩解。
這裡我們可以有很多種思路：比如將更有經驗的開發人員投入到風險高的領域裡面去，或者向風險高的領域投入更多的人手，等等。
還有就是：進行 基於風險的測試。
實際上， 軟體測試活動，本身就可以被認為是一種風險控制措施 。試想一下，我們測試團隊，對於一個軟體進行測試，發現了缺陷進行彙報，並督促開發團隊去修復和解決問題。這是不是已經直觀的降低了產品的風險？這個論斷顯然是成立的。而測試活動通過其反饋作用，去達到過程改進的效果，也可以更進一步的幫助專案去規避風險。
那麼基於風險的測試應該怎麼去組織呢？我們就是用風險分析的結果報告，去指導我們測試的開展，具體而言可以有如下措施：
- 基於風險確定測試優先順序
- 基於風險確定測試完備性
- 基於風險確定測試資源分配
這樣的一些措施要基於我們測試的幾個基本原則：
1.“測試是不可能窮盡的” - 既然測試不可能窮盡，那麼我們就應該優先去測試風險高的部分，把低的部分放到後續去做，如果時間不允許甚至有部分低風險的部分不測。
2.“缺陷具有叢集性” - 即所謂的20%的模組有80%的bug，那麼我們通過將風險可能性高的部分去準備更完備的測試（比如更多的測試用例覆蓋，更多的執行輪次，更多的執行時間）和更有經驗的人員，就可以實現軟體質量的快速上升。
最後要注意： 風險分析不是一個一次性的工作 ，我們要通過在專案實際研發過程中得到的資訊和反饋，對風險等級進行調整，比如調高和調低風險等級。一個實際的例子是：我們在專案開始時，將某一個風險專案定為了高階，因此這個風險項引起了團隊的重視。從而在後續工作開展過程中，團隊投入了更多的資源和力量，導致最終測試階段可能反而在這個模組裡面沒有發現太多問題。
所以我們測試活動的產出和收集到的資訊要用來對風險評估結果進行持續的反饋和調整更新，並根據調整後的風險等級繼續指導測試。