● 目的：保證需求質量
● 手段：針對需求開展測試設計
● 測試設計面臨的挑戰：
1、測試準則不確定（測試是比較預期結果與實際結果的過程，預期結果最了解的人群是開發、需求人員還是客戶？答案未知，但是如果需求的質量更高些的話，會更利于更準確的知道預期結果）
2、測試無窮盡：要用少的用例覆蓋盡可能多的需求，如何挑選合適的用例顯得尤其重要
3、用例執行pass是否真正代表對應場景或功能就pass =>缺陷隱藏效應證明不一定，那么在挑選用例時如何做到，RBT會有所考慮
RBT是如何實現上面所提挑戰的？
● 為什么要基于需求來開展測試？
1、導致軟件失敗的原因如下：
a）需求不完整
b）需求多變
c）需求缺少來自用戶的實際輸入
從而導致僅有60%~70%的需求交付量，且此其中50%左右的需求未被使用過，而開發團隊針對這些未使用過的需求，投入了大量精力，存在一定程度的浪費。
2、BUG分析缺陷來自哪個階段？=>60%來源于需求階段（怎么有效區分BUG是哪個階段？）
● RBT解決的是偏重型的測試問題（考慮項目的可適用性），是針對每條需求進行分析設計
● RBT倡導的思維是先測試，再構建
● RBT過程兩大步：需求模糊度分析、因果圖方法進行測試設計
1、需求模糊度分析
實際是分析需求是可測試的、可觀察可觸發的、結果是確定的（結果是確定的指：給定輸入后，能準確得出其唯一的結果，對于輸入A，結果為C，再次輸入A，結果為B的情況則是不符合“結果是確定的”原則。當出現這種情況，則需求是肯定有問題的）
2、因果圖方法進行測試設計，以下是幾類設計方法的對比分析
a）根據用戶實際使用場景、環境參數來設計用例的情況：30%左右的覆蓋不樂觀，且異常考慮不充分，依賴時間的場景無法覆蓋
b）依據直覺進行設計的情況：依賴測試者經驗，覆蓋不確定，只能代表執行過的是OK，不能證明其完整覆蓋度
c）組合測試設計的情況：所有場景組合全部覆蓋，量太大
d）因果圖方法設計的情況：借鑒了硬件領域的一些工程算法，覆蓋率高
● RBT方法選擇用例的標準：
1、體現變量間的各種邏輯關系
2、體現每個變量各種狀態間的約束
3、考慮各節點的可觀察性，如下面的例子
例子：
A、B、D、E全為T，C、F、G均為True，假定當A恒為False的缺陷存在時，直接通過對G的觀察是無法發現此缺陷的，因為C、F是不可觀察的
4、需測試哪些功能塊
● RBT過程12步驟（12步記錄不全）
1、分析為什么要做這個需求？（如同敏捷測試中要求一樣，即：需求來自于哪里？用戶是什么樣的群體？基于什么原因提出這樣的需求？要解決什么樣的問題？有無其它可替代方案來解決？是否一定要做這樣的需求？
2、用場景分析方法來分析需求的應用情況
3、進行模糊度分析，即：識別不清晰、不完整、疑惑點的地方（此點更期望是不了解需求的人來做，而非專家）
4、領域專家進行更深層次的審視
5、針對需求建模，理出所有業務邏輯，采用因果圖方法
6、用工具檢查邏輯不一致問題，可能是需求本身的問題，也可能是建模的問題
7、工具自動生成用例（此處的用例可以理解為是測試驗證點，而非具體的測試數據）
8、確認生成的用例是否正確（此處有一個個人問題：既然自動生成的用例已經是很精簡了，再進行評審怎么保證評審出的問題是否需要補充到用例的？=>答案：評審的目的一是確認是否正確理解了規則與需求，二是通過評審問題反向識別出需求遺漏的場景（如果可能，要求客戶對需求進行review是最合適的）
9、設計編碼階段，用生成的用例進行驗證
● RBT工具用途（記錄了一些，不全）
1、自動生成測試用例
2、自動生成兩張表單：因與果清單、規則VS用例覆蓋率的對照表（“X”表示多個用例覆蓋此規則，“#”表示1個用例覆蓋此規則）
3、生成測試統計數據
4、自動反向生成較規范的需求文檔，適用場景：a、review需求時發現的問題確認后，不會更新需求，通過自動生成更新得到全集；b、敏捷項目中適用，項目結束后形成需求與用例的匹配
5、生成用例過程中自動進行功能邏輯一致性校驗，并給出提示，如同開發程序編譯時的錯誤提示
6、維護過程會考慮對原有用例的最大程度復用
7、告訴你可優先執行哪些用例
8、支持快速設計（推薦在配置測試中使用，如移動領域測試環境支持驗證，可生成基礎用例）
9、可定義節點間的狀態、約束，以便生成的用例是可執行或真實的組合，對于不可執行的用例前面會有“I”標識，點擊后會顯示原因