Rational nal TestRFT是一款基于Java的自動化功能測試工具。作為RationalSoftwareDevelopmentPlatformRSDP軟件家族中的一員，它為java/eclipse/html/.net等各種被測試程序提供了一個自動化測試平臺。其中對基于eclipse的程序的支持更是RFT的特色之一，這使得它在eclipse得到廣泛應用的背景下前景廣闊。
在功能測試中，用RFT完成一個校驗點的測試是非常容易的，只需要很少的代碼。下面我們首先給出一個靜態校驗點測試的例子。本文中被測試程序是RationalDataArchitect 6.1。RFT的版本是6.1.1.1。
問題 1給定了當前如圖 1 所示的PropertiesView,請校驗Name字段的值是否是預期的“DB_LARGE1”。
圖 1： 被測試的面板
 |
圖 2： 抓取測試對象testDb
 |
String expect=TESTDB;
booleanresult=expect.equalstestDb.getPropertytext.toString;//判斷字符串是否等于預期值
String context=The value of textfield =+expect;
RationalTestt.logTestResultcontext,result;//輸出測試的結果
批量控件校驗的挑戰
問題2請校驗圖1的面板中的連續8個文本控件的值是否都等于預期值，它們的預期值依次為DB_LARGE1,,LARGE,DATABASE_MANAGED,32,32,12.67，0.18。
毫無疑問，問題2也完全可以使用靜態的方法予以實現。但是,要注意到在上面的靜態校驗點測試中，預期值、被測試對象、和校驗過程都同時出現在代碼中。如果繼續用傳統的方法來處理問題2，那么很有可能面臨至少兩方面的問題。首先，傳統方法無法管理較多的預期值，預期值只能硬編碼在文件中，而且只能編譯前進行修改;其次，所有的被測試控件都必須提前被抓取到tExplorer中，維護的成本是比較高的,一旦被測試對象有所改變,tExplorer就需要重新維護。
這兩點的局限性實際上就是代碼的耦合太強的表現，當不同功能的代碼都混在一個類中，類的功能界限會趨于模糊。這樣的編寫思路不管是從功能還是邏輯上來講，都不能稱之為好的設計和實現。所以我們嘗試用一個全新的動態的方法來解答問題2。
動態實現校驗點測試的基本思路
為了實現一個比較好的動態的校驗點測試，首先測試人員可以將被測試控件和預期結果分別配置在兩個文件中。因為幾乎每個被測試的控件通常都和某些特征標簽文本相鄰，我們只需要在文件中清楚地配置出這種相對位置關系即可。在運行的時候，主程序會讀取這兩個配置文件，并在測試對象樹上面搜索被測試控件。一旦搜索到該控件，則從該控件的屬性集合中取出對應的屬性值，和配置文件中的預期結果進行比對，最終得以判斷該校驗點是否通過。這個思路的流程圖如圖3所示。
圖 3： 動態校驗點測試流程圖
 |
根據以上的思路,被測試的控件不再通過texplorer一一維護,而是只需要維護一個總體的容器。這樣就是在犧牲一定性能的情況下提高了系統的靈活性和可維護性。主程序從配置文件讀取控件列表,一次就可以全部校驗完成,也同時進一步減少了維護的成本。表1全面地對比了兩種不同的校驗方法的差異。
表 1：靜態方法和動態方法對比 靜態測試方法 動態測試方法 預期值 硬編碼于源程序中 配置在一個單獨的文件中被測試控件需要一個個的抓取到t explorer中 配置在一個單獨的文件中 校驗代碼非常冗長，代碼行和校驗點數量成正比非常簡短,而且隨著校驗點增加而不變 維護性 需要在編譯前修改源程序,而且經常需要維護texplorer只需要修改兩個配置文件，不需要重新編譯,幾乎不需要維護t explorer重用性幾乎沒有重用性，對于新增加的校驗點，需要添加新的程序段 重用性非常高，不需要對新增的校驗點不需要編寫任何新的代碼 性能性能非常好性能中等,因為遍歷需要消耗時間
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
