使用傳統的制表格式介紹決策過程。 決策表提供了一個簡單的，可視化的幫助，它可以在知識庫系統中被使用，來高效的執行驗證過程。在軟件開發過程中，決策表能夠幫助測試小組在軟件應用程序中管理復雜的邏輯性。

這篇文章介紹了一種基于決策表的測試技術，描述了一種使用 IBM Rational Functional Tester 和 IBM Rational Software Modeler 的實現方法。這項技術常常通過運行一系列復用測試腳本來詳細描述非回歸測試套件。每一個測試腳本都是使用 Functional Tester 的 GUI 記錄/回放技術產生的。

這里，我的目標是"概念證明"。為此，我花費了5天的時間開發了一個Java類庫，用來使用 IBM Rational 工具實現決策表技術。雖然這項技術還沒有被部署到實際項目中，但是我會通過使用基于Eclipse框架的IBM Rational工具來論證這個方法的潛力。我計劃的實現方法是完全基于標準的，文檔化的接口，任何讀者都可以很容易的理解。

問題

非回歸測試是基于數據驅動的測試技術，一個簡單的測試腳本會根據輸入數據的不同而反復的被使用，這在測試自動化方面是很常見的。 這項技術可以使用Functional Tester中的數據池來實現，這些數據池是在一個測試腳本建立期間或者建立之后關聯在測試腳本上的。不幸的是，當測試應用程序陷入復雜的邏輯中時，數據驅動的測試在沒有硬編碼的情況下變得難以實現。一般來說，應用程序的行為是受組成測試套件的測試腳本的不同輸入數據影響的。我們需要使用等值劃分來區別輸入的數據，它可以提供一個AUT(被測試的應用程序)的等價行為。在每一個測試套件中都要使用硬編碼環境，它能幫助我們向著正確的測試路徑前進，并且可以處理數據的變化。這個方法不僅適用于測試人員，同樣對于開發人員來說也很"有趣"，特別是在使用自動化測試工具時，因為在硬編碼的測試腳本環境中，使得維護以及測試腳本的擴變得非常難以管理。此外，如果在頭腦中沒有一個清晰的策略，是很難優化測試腳本分解的。

建議方法

當一個測試人員手動實現一個測試程序時，他會根據測試目的選擇輸入的數據，并根據AUT的行為作決策。問題是，我們怎樣在不使用硬編碼而使用自動化測試工具的決策制定過程中幫助測試人員?

這個簡單的問題使我們去考慮決策表技術，并開發一個Java類庫來驗證這個概念。決策表通過Functional Tester數據池實現。通過決策表提供的用于解釋測試邏輯的決策腳本，被整合到測試套件的體系架構中，如圖1所示。其他組成測試套件的可重用測試腳本是通過使用Functional Tester的GUI記錄/回放技術產生的。一個測試片斷被定義成一個測試腳本的序列，它可能是兩個決策腳本之間的序列，或者是開始腳本和決策腳本的序列，再或者是決策腳本和結束腳本的序列。一個數據驅動表和測試套件連接在一起，它可以根據不同的輸入數據重復運行測試套件，并把結果輸入給不同的測試腳本。

圖1：由測試腳本和決策腳本組成的測試套件。

這項技術提供了以下好處：
　　一種詳細描述測試套件和測試腳本的形式化方法
　　在決策腳本中封裝測試套件邏輯
　　以決策點為中心的測試套件體系架構
　　測試邏輯可以很容易地使用決策表進行追蹤與變更，這樣可以被非程序員閱讀和填寫一個更加靈活的數據驅動的實現方法。

基于決策表的測試技術

在測試過程中當達到一個決策點時，測試人員會檢查AUT的狀態并決定測試活動。每一個決策點都可以用一個決策表來指定。一個決策表由兩部分組成：條件和活動。決策表列出了一個測試活動執行所需的條件。每一個條件表達了各種變量之間的關系是正確的還是錯誤的。所有可能的條件組合定義了一系列的選擇。對于每一個選擇，測試活動都要考慮到。選擇的數量使得條件種類呈指數級增加，可能會顯示為2NumberOfConditions。當決策表變得復雜時，一個新的決策表層級就會被創建。

由于一些選擇的情況是不存在的，所以一個測試策略應該是：1) 驗證所有可能實現的選擇。2) 描述AUT是如何在所有選擇環境下運轉的。有了決策表，我們就可以根據測試策略輕松的添加和刪除條件。我們可以根據測試策率的需要，通過反復的添加新的測試條件來增加測試的覆蓋率。

如圖2所示，決策表在指定，分析和測試復雜邏輯性時起到很重要的作用。它們可以很有效的描述不同條件產生不同的測試活動。它們還可以有效的查找到執行與規范中的錯誤。

圖2：一個決策表的例子

使用決策和數據驅動表

在每一個決策點，一個決策表要列出AUT(根據條件)需要校驗哪些內容，以及下一個活動是什么。由于決策表中已經定義了邏輯，所以測試人員不需要硬編碼任何測試邏輯。決策腳本只需在運行期間執行確認工作，比較決策表提供的驗證結果，并且如果找到了解決方案，返回并運行下一個測試腳本。

一個測試套件腳本包含很多決策腳本和測試腳本。一個測試套件的所有元素都在一個驅動表中被定義，在這個驅動表中列出了一系列無序的測試片斷。每一個測試片斷由在兩個決策腳本之間順序執行的測試腳本組成。對于每一個測試片斷來說，驅動表列出了一個源測試腳本和一個目標測試腳本之間的轉換。

隨著決策在執行期間被決策腳本動態的計算出來，需要為測試套件腳本實現一種通知機制，用來通過測試腳本通知下一個需要運行的測試腳本。當決策腳本通知測試套件腳本下一個應該運行的測試腳本時，測試套件腳本請求驅動表，查詢下一個應該運行的測試片斷。這個過程如圖3所示：

圖3：一個測試套件的元素

一般情況下，一個測試套件中的任何測試腳本都需要為數據輸入連接到一個數據池。當一個數據驅動表連接到測試套件時，我們就可以將輸入的各種組合的數據記錄列入到測試腳本和動態變化的AUT行為中。當AUT的行為發生變化時，每一個決策腳本提供的結果都會變化，因此通過AUT的測試路徑就會變化。通過一個簡單的測試套件腳本，我們可以驗證很多測試路徑。這樣可以輕松的合并輸入的數據和擴大測試套件的范圍，并在決策表中添加新條件。

這種方法清晰的將決策腳本中的測試邏輯封裝與測試腳本中執行的測試動作和驗證分離開來。AUT中決策點的識別，能夠幫助我們形式化并且精化從測試套件到測試腳本的分解。

這種方法清晰的將決策腳本中的測試邏輯封裝與測試腳本中執行的測試動作和驗證分離開來。AUT中決策點的識別，能夠幫助我們形式化并且精化從測試套件到測試腳本的分解。

使用 Functional Tester 實現此項技術

作為這個概念證明的一部分，我開發了一個Java庫，用來使用Functional Tester實現基于決策表的技術。請按照下列步驟建立一個測試套件腳本：
　　重用測試套件代碼模版并填寫測試套件驅動表
　　使用一個代碼模版建立決策腳本，并填寫決策表
　　填寫數據驅動表
　　基于決策表的測試庫
　　基于決策表的測試庫由Java類組成，它提供了下列服務：
　　初始化并重復的穿過在驅動表中定義的測試套件結構
　　瀏覽決策表并比較AUT中執行的驗證選擇

決策腳本和測試套件腳本之間的事件偵聽機制對于測試人員來說是透明的。它是通過庫中的DecisionBuilder和 TestSuiteDriver類來實現的，如圖4所示。為了使用庫中的服務，測試人員建立的每一個測試套件腳本以及決策腳本都必須繼承 TestSuiteHelper 4 類，因為它提供了一個連接到庫的接口。為此，測試人員每次建立新測試套件或者決策腳本時都需要選擇這個父幫助類。

圖4：基于決策表測試庫的主類

建立一個新的測試測試套件

測試套件可以在業務層面或者系統用例層面被用來實現自動化測試策略。在系統用例層面，一個測試套件實現用例場景。在頁面層面，一個測試套件跨越幾個用例追蹤業務流程。對于一個給定的測試級別，測試套件可以根據回歸測試計劃中定義的測試目標來組織。例如，測試套件可以集中在業務規則驗證或者服務傳遞或者數據完整性檢查(創建，更改，刪除)上。雖然理論上可以只使用一個測試套件，但是在實踐中這種情況難以管理。因此，測試人員必須根據測試選擇設計測試套件，并且擁有一個運行測試套件的測試套件是有意義的。

為了建立一個新的測試套件，測試人員需要做以下工作：
　　使用Functional Tester建立一個空的測試腳本
　　在測試套件腳本中插入代碼模版(測試套件的代碼模版如圖5所示。)
　　列出驅動表和數據驅動表的名

圖5：測試套件腳本的代碼模版

如圖6所示，每一個測試套件的結構都在測試套件驅動表中描述了，一個數據池定義了測試腳本(例如從源腳本到目標腳本的轉換)。次序并不重要，因為TestSuiteDriver類可以解析驅動數據池并且在存儲器中加載測試套間的結構。然而，你必須定義開始和結束腳本。測試人員可以填寫這個表格，來指定測試套件或者從測試套件的UML定義產生這個數據池(可以在稍后的章節查看"使用IBM Rational Software Modeler模塊化設計測試套件")。

圖6：測試套件驅動表的實例

建立一個數據驅動測試套件

一個數據驅動表可以被連接到測試套件腳本，用來1) 控制數據輸入到不同測試腳本以及2) 建立通過AUT的不同路徑。數據驅動表的標題包含測試套件的測試腳本所使用的數據池的名稱。數據驅動表的每一行表示一種不同的輸入數據記錄的整合，這個輸入數據記錄用在每一個測試腳本數據池中。如圖7所示，數據驅動表的第一列是一個測試套件的true/false標志位，這個標志位用來表示一行是否依靠于測試對象。

圖7：測試套件數據驅動表的實例

每一個測試腳本數據池通常包含一個標志，它用來顯示測試腳本在數據池的完整回歸過程中是否必須選擇一項記錄。當測試套件開始新的回歸時， TestSuiteDriver類會讀取測試套件驅動表，并設置測試腳本數據池選擇標志位，所有測試腳本都會重復這項工作。因而，當一個測試腳本數據池記錄發生回歸時，只有驅動表中列出的記錄會被考慮。這個機制被庫文件管理，并且對于測試人員來說是完全透明的。唯一的約束就是所有數據池的 SelectRecord標志位。

建立一個決策測試腳本

測試人員識別測試套件流中的決策點，并為每一個決策點建立一個決策測試腳本。當測試套件流通過UML實體圖設計時，每一種條件(請查看"使用IBM Rational Software Modeler 建模測試套件"章節)都會建立一個決策測試腳本。

為了執行一個決策點，測試人員需要完成以下工作：
　　建立并填寫決策數據池
　　建立一個空決策測試腳本并插入代碼模版
　　為每一個決策條件注冊驗證點

首先，測試人員使用Functional Tester數據池建立一個決策表。決策表的實例如圖8所示，它也可以通過測試套件的UML定義產生請查看"使用IBM Rational Software Modeler 建模測試套件"章節)。決策腳本把AUT執行的驗證結果與條件入口相比較，以便識別執行的測試活動(例如下一個需要運行的測試腳本)。當一個合并不可能或者還沒有被實現時，數據池中的行將會被排斥，并且測試活動是未定義的。

第二步，測試人員建立一個空的測試腳本，在測試腳本中插入代碼模版(如圖9所示)，并列出決策數據池的名稱。測試人員使用Functional Tester插入確認點來捕獲決策表所需信息。

圖9：決策腳本的代碼模版

使用IBM Rational Software Modeler 建模測試套件

測試套件使用一個UML活動圖來設計，圖中每一個活動都和一個測試活動(測試腳本)通信，并且每一個決策都會和一個決策腳本通信，如圖10所示。決策點列出的條件用來產生通訊的決策表?；顒訄D很容易被非開發人員使用和理解。

一個"datastore"類型的目標節點可以被連接到一個測試活動，來指定這個測試活動需要的一個數據池。通過類指定數據池結構也是可行的方案。數據池的每一列都會和一個類的屬性通信。一個UML解析器可以產生所有Functional Tester運行測試套件所需的數據池，包括驅動表，決策表和數據驅動表和測試腳本數據池的結構?；顒訄D表和類圖都可以在一個協作元素下組織起來，如圖 11所示?？勺匪莸倪B接可以在測試套件定義和用例模塊之間建立，如圖12所示。一個更加成熟的方法可以使用IBM Rational Software Modeler提供的轉換工具進行開發。

圖11：測試套件的定義被封裝在一個協作之下。

圖12：測試套件和其他模塊元素之間的追蹤連接

我開發了一個UML解析器，它能夠以XML格式產生測試套件驅動表，決策表以及數據池(例如數據驅動表和測試腳本輸入數據表的結構)。當選擇協作時，一個擁有上下文菜單的Eclipse插件程序將會被用來產生測試套件表，如圖13所示。

圖13：類庫用來從UML定義產生測試套件表

所有可能的選擇都自動的產生在決策表數據池中，如圖14所示。只產生了活動圖中列出的測試活動。新的測試活動沒有被列在活動圖表中，但是可以在導入到Functional Tester測試項目之前添加到決策表中。

圖14：決策表中產生的所有可能組合。

結論

我相信這種基于決策表的測試技術能夠極大得改進測試人員在自動化測試期間管理決策的能力。使用IBM Rational Functional Tester和IBM Rational Software Modeler，這項技術可以通過實現一個可復用的測試腳本來促進非回歸測試套件。

正如我在介紹中提到的，雖然這項技術還沒有應用到實際項目中，但是使用出于此目的而建立的Java類庫顯示這項技術是可行的。

進一步的工作現在正在進展中，它可以擴展測試建模方法的引入。IBM Rational Software Architect提供的模型轉換服務將會用于測試自動化的輔助設計。