什么是基于風險的測試？如何做？

　　風險處理——老生長談?

　　在20世紀50年代，當數學家David van Dantzig 在防衛洪水的領域作出先鋒性工作的時候，風險分析和風險處理就已經被應用在工程上了。自那以后，風險處理的意識在不同的工程領域得到發展和傳播。在軟件測試領域，風險處理最早的應用之一是Boris Beizer在他的傳奇著作——軟件測試技術里著述到，測試時需要考慮到風險。

　　James Bach 在1995年以更時髦的方式第一次介紹了基于風險的測試(RBT)，然后在1999年在一篇叫做《啟發式基于風險的測試》(“Heuristic Risk-based Testing”，譯者注)中得到更詳細的描述：

　　1. 列出一個風險的列表

　　2. 進行考察每項風險的測試

　　3. 當風險消失而新的風險出現的時候，調整測試策略

　　自那以后，RBT得到了廣泛的關注，ISTQB在他們針對基礎級別和進階級別的測試認證中，將RBT認定為一種重要的測試方式。

　　應用RBT的實踐

　　盡管RBT作為一個重要的測試方式得到廣泛認同，但對于如何在實踐中實際地應用RBT還存在不少混淆。大多數我研究的組織都非正式的在測試中考慮到了風險，但很少有組織具有正式描述的、系統化的方式把風險納入到他們的測試中。

　　當然，一些采用RBT的障礙源自于通常的擁抱變化的困難。在這方面采用RBT與采用任何其他的變化沒有分別。另一方面，更進一步澄清如何在一個實際的環境中應用RBT的工作也是需要的。許多關于RBT的報告描述了RBT的理論框架而沒有告訴讀者實際的實現細節。具體的說，這關系到以下一些問題：

　　1. 如何識別風險

　　2. 如何評估識別出的風險

　　3. 如何確定合理的減輕風險的活動

　　在一個試驗性的研究中(此研究在一個大型的工業化的軟件生產商那里進行)，一個目標之一是引入RBT，完成一個易于使用的指導方針。以下的段落總結了這個試驗性研究一些關鍵經驗，集中在上面提到的幾點問題上。

　　風險識別

　　RBT第一個步驟的目標，是發現盡可能多的風險，以力求使得所有重要的風險都在已識別的風險當中。具體的說，風險識別的建議包括頭腦風暴會議，和專家的討論，以及檢查表等。所有這些指導方針都很有用很重要。然而，在一個組織中第一次引入基于風險的測試的時候，過去的識別風險的經驗通常很少，因此會存在問題，因為所有提及的技術或多或少的依賴于經驗。

　　為了克服缺乏經驗的問題，我們基于現有的一組High Level需求創建了一個起始點。每一個需求通過以下面的方式轉述從而轉化成一個風險項：如果這個需求的實現存在一個缺陷那會怎樣?

　　結果起始點包含了一組相當多的風險項。然后我們讓參與RBT的成員們在想起一個新風險項的時候就把它加進來。我們在后面的段落會更詳細的介紹，這些被識別出的風險通過會議的方式得到指導。這個會議在另一方面也促使新風險更快的被識別。如上所述的使用起始點的方法是獨立于其它風險識別的方法的，所以當團隊的經驗增長了之后，可以加入任何其他的方法。

　　風險評估

　　通常，風險是以二維的可能性-結果的形式表述的，這需要對每一個風險項進行度量和評估。然后，或者通過倍乘這兩個維度的值從而得出一個單一指標來得出每一個風險項的重要性，或者通過使用一個二維坐標系統來表征每一個風險項的重要性，這個坐標系統里的面積對應了不同水平的重要性。

　　對于參與RBT的不太有經驗的成員來說，評估可能性-結果的過程可能很抽象和困難。為了使這個任務更加具體，我們把每個維度劃分為一組單獨的屬性。與可能性相關的屬性的例子有：

　　使用頻度

　　使用復雜度

　　實現復雜度

　　相對應的，與風險的結果相關的屬性的例子有：

　　用戶結果

　　業務結果

　　測試組織的結果

　　在我們的例子中，為了達到對于一組風險的普遍認識，我們把所有的項目干系人召集在一個會議里來一起評定風險的維度。在這個會議里，要求每個RBT的參與者對每個風險項的每個屬性進行打分，用1~4來標示。通過這樣的使用屬性，描述一個特定值實際是什么意思就容易了。例如，在我們的例子里，使用頻度“1”對應了少于每周一次的使用，“2”對應了每周一次，“3”是每天一次而“4”是一天若干次。這樣清晰的描述使得評級更為有效。

　　然后風險的得分被賦予權重，從而得出這兩個抽象維度——可能性和結果的指標，基于這些值，也計算尺每個風險項的單一風險指標。

　　單一風險指標方式的一個缺點是，在某一個維度上比較低的風險可能不能引起足夠的注意。一個明顯的例子是核熔解相關的風險。盡管風險的結果是異常巨大的，但是非常低的可能性使得最終的風險指標相對很低。為了克服這個障礙，我們采用的方式是通過最終的風險指標以及兩個單一維度值來判斷重要性。最終的風險等級是這三個值中的最大值。

　　減輕風險

　　RBT的最后一個步驟是基于風險的等級，用一組適合的測試用例來覆蓋每一個風險項。為了幫助不太有經驗的測試人員，我們給出了一組指導性方針。例如，每一個高風險必須被正向測試用例及負向測試用例所覆蓋。另外，至少50%與高風險相關的測試用例應該具有最高等級的測試用例優先級。中間等級的風險主要由正向測試用例覆蓋，并且可以分布于最高的三個測試用例優先級中，等等。

　　結論

　　針對我們這個試驗性的項目的一個關鍵要點是，一組關于如何在實踐中使用RBT的指導方針可以大大地減少采用一個更為結構化的方式來在測試中使用風險的障礙。這一點會在我的Eurostar的演講中得到進一步的闡述。斯德哥爾摩見!

原文轉自：http://www.kjueaiud.com