一.RBT的概念
很有意思的是從字面上講，RBT可以被翻譯成Requirement Base Testing,也可以被翻譯成Risk Base Testing。而正好在ISTQB的測試體系裏，測試從大的方向可以分爲“基於規格說明”的測試技術及“基於缺陷與經驗”的測試技術。“基於規格說明"的測試技術，主要講求的是基於需求說明、規格說明進行結構化的測試計劃、測試分析、測試設計、測試執行等工作。本文講的RBT是Risk Base Testing，它更多的是一種面向缺陷發現的測試技術。
個人理解，RBT不是一種具體的測試工具，也不是具體的某種測試類型（類似功能、性能、可靠性），它更多的是一種宏觀上測試策略，對於整個測試活動的組織方式。
二.什麼是風險，爲什麼需要RBT
2.1什麼是風險
風險是一種負面的或者不想要的結果，或者事件發生的可能性。任何影響利益相關者對產品質量及成功信心的因素都可以稱之爲風險。而風險又可以分爲產品風險和項目風險：
- 產品風險：與被測試對象有直接關係的風險。
- 項目風險：與整個軟件項目的管理與控制相關的風險。
2.2爲什麼需要RBT
總所周知，由於測試的不可窮盡性。我們總只能在有限的時間、資源和質量之間找平衡。採用RBT又能讓測試更具針對性，幫助決策者做測試資源的精確配置–人力、測試優先級等等。
如上圖所示，由於缺陷的羣集效應，相比基於規格說明的測試，RBT試圖通過精準的風險識別來達到更高效的測試。
基於風險的測試不再是強迫所有人依靠例如缺陷數和測試數等不充足的策略性度量來做發佈決定，而是和利益相關者一起來做決定剩餘風險的可接受級別，從而做出合理的發佈決定。
三.如何進行RBT
我們這裏說的RBT，是一個廣義上的測試，並不僅僅是軟件項目測試執行階段。軟件項目測試人員所介入的諸如需求澄清、方案討論、測試分析等等一切活動都是屬於測試活動，也都是進行RBT的時機。
- 通常來說RBT分如下爲三步驟：
GB_T_20918-2007中定義了一套很嚴格的風險管理規範，在時機軟件上可能並不需要達到如此的規範程度，但基本的：風險識別、風險分析、風險控制 過程還是需要有的
3.1風險識別
3.1.1風險識別的手段
風險識別可以採取如下正式或非正式的手段：
1>專家諮詢。2>獨立評估。3>使用風險模板。4>項目回顧。5>風險研討會及頭腦風暴。6>檢查清單。7>問卷調查 8>以往的經驗。
本文不是軟件測試教材，此處不詳細展開
3.1.2風險識別中應該考慮的關注點：
技術因素：
- 技術和團隊的複雜度。
- 個人和培訓問題。
- 團隊內部與團隊間的溝通衝突。
- 供應商和客戶的合同問題。
- 開發組織的地理分佈以及外包。
- 管理上或技術上較差的領導力。
- 時間、資源和管理壓力。
- 軟件生命週期早期未引入測試和質量保證活動。
- 項目中需求、設計和代碼的頻繁變更。
也就是從研發項目交付的整體上考慮技術和管理上考慮方方面面的問題。
商業因素:
- 受影響部分的使用頻率和重要性。
- 潛在的形象損害。
- 客戶和商業損失。
- 潛在的金融、生態或社會方面的損失或法律責任。
- 民事或刑事制裁。
站在用戶的角度，從行業、從盈利模式、合規等方面考慮方方面面的問題。
3.1.3風險識別的兩個方向：
風險識別可以分爲如下兩個方向：INSIDE-OUT、OUTSIDE-IN:
INSIDE-OUT:
INSIDE-OUT的基本思路是從具體分析測試對象的詳細信息和背景信息入手，識別與之相關的風險。採用該方法，測試人員在學習測試對象時需要不斷地提出這樣的問題“這裏可能會存在什麼樣的風險”。更加正確地說，針對測試對象的每個部分，測試人員需要回答下面3個問題。
- 弱點Vulnerabilities：測試對象有何種弱點或者可能的失效？
- 原由Treats：測試對象在何種輸入或者情況下會導致出現缺陷和弱點，並且觸發測試對象出現失效？
- 影響者Victims：弱點或者失效的影響對象是誰？其影響程度有多大？
INSIDE-OUT分析方法需要測試人員深入瞭解測試對象。其常用過程可以是在帶有黑板/白板的會議室中測試人員詢問開發人員相關的問題（如這個功能是如何實現的？）；開發人員在黑板/白板上畫出相應的原理圖，並講解測試對象的內部工作過程；同時測試人員在開發人員畫原理圖時，快速地思考一些問題。測試人員和開發人員之間可以很快的在測試對象工作原理方面有相當的認同。在測試人員存在疑慮或者不清楚時可以立即詢問開發人員。在瞭解測試對象的工作原理之後，測試人員即可開始查找其中的弱點或者可能的失效。
OUSIDE-IN:
OUSIDE-IN，目前的理解更多是更多的是通過一些預先制定的 Check-list、啓發、規範對於被測系統進行Check，從而發現被測系統存在的一些風險。例如:
- ISO9126中定義的常見風險列表
- 質量特性列表
- 通用風險列表
- 領域風險列表
3.1.4全流程的風險識別：
從研發全流程的角度考慮風險，我們可以有如下啓發：
需求：
- 產品的業務需求、用戶需求、功能需求和系統需求是否完整、清晰？
- 僅僅是用戶提出的不成熟的解決方案當需求？還是能解決用戶深層次痛點的需求？甚至是滿足用戶人性層面的訴求？
- 開發人員在進行產品設計之前是否充分理解了需求。
設計：
- 是否爲規模龐大、複雜以及難以理解的對象？
- 是否使用了新技術？是否爲新的團隊？沒有任何經驗可以借鑑？
- 功能與非功能性的設計是否都有充分考慮？性能？可靠性？精度？
- 開發人員在設計中是否存在一些比較擔憂的地方？是否有一些設計瓶頸？
- 開發人員是否能夠自己講的清楚設計？
- 項目對依賴和約束是否有充分考慮？（合規、不同團隊的進度）
流程：
- 項目是否使用了新的流程、開發方法等？
- 開發人員是否會自測？是如何自測的？測試的深度和發現的問題如何？
- 開發人員如何進行代碼修改，是如何保證修改正確性的？
- 開發人員如何進行版本管理？
變更：
- 新版本在舊功能方面做了哪些修改？修改後的主要影響是什麼？
- 在項目過程中需求是否總在變化？
組織和人：
- 異地開發帶來的溝通協作、進度問題、不同的開發流程、能力?
- 人力，團隊穩定性。
- 環境和資源是否具備和充足。
歷史：
- 基於缺陷羣集效應和殺蟲劑效應。分析歷史缺陷，從而得到更多的Idea。
3.2風險分析
3.2.1風險分級
風險主要從可能性和嚴重程度兩個維度考慮它的分級:
風險的級別 = 風險的可能性 * 風險的影響（嚴重程度）
- 風險的可能性：測試對象中存在潛在問題的可能性。
- 風險的影響（嚴重程度）：風險發生後，對用戶、客戶或其他利益相關者影響的嚴重性。
風險級別的判定：
3.2.2基於風險分級的測試安排
不難看出，其實基本思路就是根據風險級別的高低給予不同測試資源和人力的分配。高風險的問題將獲得更多資源和人力的關注。
風險覆蓋策略：
- 廣度覆蓋： 按一定權值同時對高風險和低風險的問題安排測試。
- 深度覆蓋： 嚴格按照優先級進行測試工作安排。
3.3風險控制
在風險管理中，風險應對主要分爲如下四種：
- 風險迴避：指主動避開損失發生的可能性。
- 轉移風險：通過某種安排，將自己面臨的風險全部或部分轉給其他一方。
- 減輕風險：指採取措施，降低風險發生的可能性或影響。
- 接受風險：指自己理性或非理性的承擔風險。
不同的風險控制策略正體現了RBT的價值，項目的資源總是有限的很難奢望真正0缺陷的產品。風險迴避、風險接受也是常常需要面對的一種策略。
3.3.1風險記錄與跟蹤
前面總結了風險的兩個維度；風險的分級；基於風險分級的測試安排。那麼當我們發現和識別風險後，還需要對風險進行記錄和跟蹤，這樣才能保證風險控制能夠落地。那麼風險的記錄可以採用如下的表格進行記錄：
風險類別：
可以是 產品風險、項目風險。如果是產品風險，可以進一步說明是 功能、可用性、性能、可靠性等。
可能性、影響、風險級別
與上文 風險分析 中介紹的概念相同。
測試安排：
可以使用 風險分析中 基於風險級別的測試安排。也可以針對風險制定探索性測試章程，將章程的描述或編號維護在這個之中。
追蹤：
描述風險當前的狀態。“新建”、“已轉移”、“已接受”、“已爆發”（已在商用中爆發問題）、“已減輕”、“減輕中”。
個人覺得重點在於風險的跟蹤。我們在記錄風險後需要定期的與項目干係人討論風險的控制策略，併力求得到項目干係人的支持。安排落實計劃（測試探索計劃、開發計劃等）。風險跟蹤的活動中要求測試人員能夠轉型，主動承擔起更重要的職責，而不僅僅是作爲研發最後一個環境的 Checker。
3.3.2風險減輕
四種風險控制策略，在這裏我們重點風險減輕的方法。
作爲測試人員，最直接的風險減輕的方法就是通過測試 反饋缺陷，並跟蹤缺陷。但在RBT理念裏面，系統測試人員能夠做的更多，以下是從全流程的角度，總結的部分風險減輕的方法：
3.3.2.1需求類風險
1>需求描述不清，不能有效指導開發和測試的工作：
加強需求場景的評審，在需求澄清中加強對於場景疑問的溝通，確保對於需求理解的一致性。
2>開發人員在設計時沒有充分理解需求,特別是易用性和性能方面：
a.測試人員提早開展性能相關的測試探索。（很多性能問題由於早期就已經定型的架構問題）
b.在需求澄清中要明確性能規格。
c.編寫實例化驗收測試用例，並確保能夠被正確實現。評審驗收測試用例。
3.3.2.2設計類風險
使用了新的技術平臺
a.新舊平臺對比尋找差異性、變化點。
b.針對變化點、差異點可能引入的問題進行針對性的探索。
設計過於複雜，難以理解
a.與需求工程師進行確認，確認是否存在過度設計。
b.要求開發人員進行方案的講解和梳理。
3.3.2.3流程類風險
1>開發自測不充分：
a.通過測試分層的方式與開發約定好測試分工。（重複覆蓋，重複視角引起的效率浪費）
c.與開發溝通開發已測試部分，有針對性的進行補位。
d.爲開發的自測活動提供測試環境框架 或測試設計技術指導 。
3.3.2.4變更類風險
在項目過程中，需求總是在增加
a.和開發人員、需求工程師進行溝通，進行需求控制。
b.裁剪部分低優先級需求。
3.3.2.5組織和人風險
團隊大部分人員沒有測試設計經驗
a.好的測試設計案例學習。
b.帶領團隊做好測試分析、加強評審。
測試工具不滿足：
a.測試工具採購及進度跟蹤。
b.積極尋找替代工具。
3.3.2.6歷史類風險
特性在基線版本中就存在很多bug
對基線版本該特性進行缺陷分析、分析哪些測試手段容易發現該特性的問題，據此進行探索性測試。
基線版本中開發人員修改引入缺陷導致缺陷趨勢無法收斂，對測試進度和產品發佈造成了影響
在繼承版本中，很可能會存在同樣的風險。對基線版本中開發人員修改引入的缺陷問題進行根因分析，針對根因來制定措施。
四. 基於風險測試的挑戰：
4.1測試策略的動態變化：
“基於規格說明”、“基於風險的測試”都有其存在的價值，不是誰替代誰的關係。“倒浴盆曲線”，給我們的啓示是，測試策略一定是隨着項目處於不同階段和不斷調整的。一定要在關鍵的項目里程碑的時候重新調整風險分析、測試和項目。
4.2風險級別認識的一致性：
項目中不同人、不同視角、不同知識背景甚至利益關係導致會對同一個風險的認知程度不一樣，但一個RBT的跟蹤和落地很多時候需要項目干係人的意見達成一致。這就是非常大的挑戰，通常可以：
- 影響力、行政權力。（不可頻繁使用）
- 在其他風險級別上做出調整，讓所有風險的級別在整體上符合雙方的要求。（妥協和退讓、相互理解）
- 把不一致的問題上報到一些資深的項目利益相關者那裏。
4.3如何讓人們對於風險做出理智的決定（風險評價的客觀性）。
—風險帶來的恐懼感覺會提升風險感的知級別。
4.4所有風險都是高優先級？
相對於第一點，有時候大家很容易達成風險認識的一致性，即所有風險都是高優先級。那麼此時風險優先級評估將沒有意義。可能從整個項目的成本、進度、預算的層面進行取捨。
五.業界專家對於實施RBT的忠告：
以下內容來源於 “海盜派Tester” 微信羣中關於RBT的討論:
羣中有包含 邰曉梅、劉琛梅、高翔、Michael Bolton等衆多國內外測試專家…
5.1 RBT應該是持續性的，而不是一次性的。
項目持續在演進，那麼風險是持續存在的。RBT不能僅僅做成一種Show，一種臨時性的活動。應該持續的去做。
5.2 RBT應該更注重內容，而不是形式。
1> RBT過程中，應該重視的風險識別、分析和跟蹤的過程。雖然有些CheckList、風險記錄表、質量特性列表…等文檔化的東西，但應該已實用便捷爲主。
2> RBT應該是持續化的工作，那麼頻繁化正式化的會議、評審可能會成爲項目不能承受之痛。應該多轉化爲非正式的，頻繁的的溝通和交流。
5.3 RBT也應該快速迭代和反饋。
注意RBT的粒度，不要奢求一次性做大而全的風險識別，風險分析等活動。應該秉承敏捷思想，縮小RBT的範圍，並頻繁反饋，頻繁的去更新對於當前項目風險的認識。