使用Functional Tester的一項測試技術[1]

　　使用Functional Tester的一項測試技術[1]   軟件測試　

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

　　這篇文章介紹了一種基于決策表的測試技術，描述了一種使用 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：由測試腳本和決策腳本組成的測試套件。

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