基于需求的測試用例設計工具 BenderRBT
BenderRBT是基于需求的功能測試用例設計工具，可以驗證應用程序的需求，為最大的功能覆蓋設計最少數量的測試用例。BenderRBT全面評估應用程序需求的錯誤和邏輯的不一致，使得項目團隊在開發過程的早期完成對需求的調節和驗證，然后以需求為基礎設計最小數量的測試用例滿足功能的全部覆蓋。BenderRBT允許項目團隊以各種格式查看需求和測試用例，包括邏輯圖和結構化規范說明，以確保需求正確、完整、得到了充分理解和可測試性。
基于因果圖的設計引擎
因果圖提供了基于圖形的測試引擎，用于業務關鍵、任務關鍵和/或安全關鍵的功能，它確保你不僅得到了正確的答案，而且正確的答案是來自于正確的原因。它指出了這樣一個事實，即多個缺陷有時可以相互抵消。因果圖確保缺陷被傳播到測試人員可以看到問題的可觀測點。具有完整的約束規則支持（One、Only One、Exclusive、Inclusive、Requires和Masks），以確保所創建的測試在物理上是可能的，同時支持完整的逆向測試。
● 更好的需求
RBT協助項目團隊分析和評審需求，消除邏輯矛盾和錯誤。利用因果圖這種創新的方法，以圖形方式顯示應用中的節點（輸入和輸出）之間的關系和約束。項目團隊可以在RBT中分析功能需求的各個方面，然后RBT計算它記錄的信息，找出關系的優先級問題和邏輯錯誤。RBT以各種易于閱讀的格式提供詳細的分析信息，分析師和項目利益相關者共同審查RBT生成的以自然語言寫就的測試用例，在開發周期的早期識別和糾正任何需求錯誤。
● 因果圖
作為有效的需求驗證和測試用例設計的一種行之有效的技術，因果圖將功能規范轉換為圖形化表示。這個圖形表示描繪了需求中呈現的功能關系和條件，描述每個輸入如何與其他輸入以及每個輸出相關的。在此過程中還建立了節點的約束和可觀測性，允許項目團隊識別潛在的問題區域。在開發因果圖時，測試團隊評估需求的完整性、一致性、充分的細節和是否有二義性，經常能發現若不用此方法則在集成測試之前找不到的缺陷。
● 本地化支持
所有用戶輸入的信息——圖標題、備注、節點名稱、節點說明——可以是任何語言。然后，RBT將使用這些信息生成其所有輸出。
● 最小化測試
在許多測試環境中，測試是使用“直覺”或基于組合的方法開發的。直覺測試依賴于單獨的測試人員來開發要使用的測試，而基于組合的測試則使用所有可能的輸入組合。雖然這些測試開發方法被廣泛使用，但它們不能確保全功能覆蓋，更不用說保證所需測試的最小數量。 BenderRBT使用數學上嚴格的算法來確定全功能測試覆蓋率所需的最少測試用例數量。
● 最大化覆蓋
RBT的成熟的自動化測試用例的設計方法保證了功能測試的覆蓋率將達到100%，同時使用最少的測試。RBT仔細評估它獲取的所有因和果，將測試用例減少到足以實現完整功能覆蓋的數量。RBT也交叉引用功能與測試用例。當評估執行的測試狀態時，此信息允許項目團隊計算正確運行的功能的百分比，然后管理層可以對應用程序是否準備好生產做出明智的決定。
● 保護在測試用例上的投入
因果圖是一個迭代的過程。一般來說，你要繪制圖、檢查結果、調整圖，直到你確信需求是可靠的，并且圖反映了這些需求。然后實現測試用例。當你提交建立可執行的測試時，你想要確保RBT知道這套測試是你正在實施的測試。這將使你能夠保護在這些測試中的投入。
如果RBT知道了現有的測試集，那么當需求和圖形變化時可以評估這些測試。舊的測試實現了多少覆蓋？你需要什么新的測試？必須對舊的測試進行哪些修改？RBT可以為你回答這些問題。
● 矩陣視圖
RBT提供兩個矩陣視圖顯示這類詳細信息。覆蓋矩陣顯示每個測試所覆蓋的功能變化，它也描述每一個測試執行至少一個沒有被其他測試覆蓋的功能變化。使用這個矩陣，測試團隊可以確信他們正在測試應用程序功能的100%。定義矩陣總結RBT生成的每一個測試用例的輸入和輸出條件。這兩個矩陣都可以導出到Excel，供測試人員進一步說明。
BenderRBT的功能覆蓋矩陣識別哪些功能變化在哪些測試用例中。 “X”表示功能變化是在兩個或更多測試中?！埃！北硎咀兓瘍H在一次測試中出現。
BenderRBT的覆蓋分析矩陣允許項目團隊量化地確定測試狀態。當選擇一個或多個測試用例時，覆蓋率分析功能將計算所選測試用例的弱和強功能覆蓋率的百分比。
Fewer Tests Dialog
此功能允許你輸入一個小于或等于測試總數的數字，RBT會決定哪些是測試的最優子集——哪些測試會帶來最大的覆蓋
BenderRBT定義矩陣用表格顯示在每個測試用例中每個節點的狀態，一目了然的了解每一個測試案例。
● 對敏捷的強大支持
敏捷項目在版本內部和跨版本中都是高度迭代的，常見的問題是測試往往落后于項目，規范從來沒有完整的文檔化。RBT除了保護在先前版本的圖上實現的測試的能力，還可以從模型生成的功能規格說明，這確保了代碼、測試和規格在發布時都是同步的。
基于組合對的設計引擎
快速設計（QD）提供了基于組合對的測試引擎，包括正交對和優化對。QD用于測試用戶界面（例如Web頁面、客戶機服務器應用程序中的屏幕），它也適用于設計配置測試，以及關鍵功能的快速測試。具有完整的約束規則支持（One、Only One、Exclusive、Inclusive、Requires和Masks），以確保所創建的測試在物理上是可能的，同時支持完整的逆向測試。
發動機控制軟件測試
為保證控制系統軟件的質量，在進行航空發動機控制系統控制軟件測試的時候，不僅要覆蓋到全部的軟件功能點，還需要考慮各種輸入情況的組合。在輸入情況較多時，各種輸入情況的完全組合數目將變得非常大。譬如在10個輸入條件下，全部組合將達到210（1024）種情況之多。所以在測試中窮舉全部輸入情況的組合往往是不可能的，并且，從發現軟件缺陷、提高軟件質量的角度來看，窮舉全部輸入情況的組合的意義也并不大，如何選取合適的用例成為了測試過程中一項具有挑戰性的工作。
發動機控制狀態監視中的需求示例：
燃油系統元件狀態檢查：在Ng>60％情況下，檢查燃油壓力Pt，超限時報警；
防冰系統接通檢查：在PAL>=115°1秒后，判斷防冰接通檢查指令和防冰電磁閥吸合的終端開關的反饋信息是否一致，若不一致，則防冰系統失效；
發動機過熱保護：如果Ng<66%且T45－T45max>50℃且保持時間>=5秒，則發動機過熱；如果Ng>=66% 且T45－T45max>40℃且保持時間>=3秒，則發動機過熱。
使用BenderRBT繪制需求的因果關系，在確認因果圖和軟件需求一致后，繼續運行工具軟件，形成最小的測試用例集。
某大型系統的單元測試
某大型系統的單元測試項目，測試人員每天面對龐大復雜的系統、繁雜的功能場景以及邏輯分支，要做到完全的覆蓋率需要做很多的分析工作。其中某個11行代碼的函數，需要28個初始節點，這些節點之間還有一些復雜的邏輯依賴關系。單靠人工花費一下午時間畫完真值表，再針對表格又花了幾個小時設計了將近四十個用例，才做好了完整的MC/DC覆蓋。而且這些節點之間的邏輯關系是否合理還未知。
借助于BenderRBT圖形化地表示需求中的功能及邏輯關系，節省了大量的時間。特別針對某些邏輯中，節點之間有多重的依賴關系，這個工具就顯得快捷方便，大大提高了工作效率。并且，工具算法可靠，用例最優化，形成測試用例的同時，檢測軟件需求中的缺陷，這些缺陷的分析，有利于我們更加深入的分析需求。
