選擇正確的GUI測試自動化工具(2)

　　因此你可以怎樣確信你已經識別了一個將使你能夠構建一個系統并利用優秀的編程實踐實現它的工具呢?讓我們來看看在任何優秀的工具中都很重要的12個功能。

　　功能檢查表

　　1). 腳本語言

　　本文中描述的其他所有功能的一個先決條件是工具必須有一種包含了常見編程構想的腳本語言。至少，它應該：

　　·使你能夠編輯已錄制的腳本

　　·支持變量和數據類型

　　·支持矩陣，列表，結構，或其他復合的數據類型

　　·支持條件式的邏輯(IF和CASE語句)

　　·支持循環 (FOR, WHILE)

　　·使你可以創建和調用函數

　　如果工具使用的是象VB或C一樣的常用語言，你會獲得一個附加的好處：很容易找到這些語言的書籍或培訓課程，并且在你組織中的大多人可能已經知道它們。

　　語言越強大，你潛在擁有的控制就越多。成熟的腳本語言使你能夠創建更加成熟的腳本。當然，擁有一個復雜語言也使創建比所測軟件更復雜的自動化測試變為可能。因此尋找一門可以帶給你所需的力量和靈活性的語言，并且為使用這一先進的功能明智地設計你的測試。

　　2). UI元素識別器 element identifiers

　　為了編寫真正的可以測試一些東西的測試腳本，你應該確信測試工具能夠把UI上的元素識別為對象，而不是試圖通過坐標指向它們。

　　如果你正在測試一個Windows的應用程序，并且開發人員正在使用MFC (Microsoft Foundation Class library) 控件的話，那么大多數可用的測試工具就都沒有什么問題。然而，如果你的應用程序是使用Java Swing控件(a.k.a. JFC，或 Java Foundation Class library)編寫的話，有些工具會比其它的工具工作地更好。在評估期間，確信工具可以識別多種典型窗口中的UI元素。

　　有些UI元素根本不是真正的控件，這是真的，它們只是一些當你點擊它們時可以作些事情的位圖。使用位圖UI元素比使用那些不能和任何自動化測試工具一起運行的真正的控件更好。如果你的軟件是這種情況的話，在工具評估時把開發人員一起叫來以便他們可以第一時間看到為什么使用標準的控件對于提高軟件的可測試性是很重要的。

　　3). 可重用的庫文件Reusable libraries

　　設想你正在測試一個允許你查詢數據庫中記錄的應用程序。許多產品的功能只可以在有一組可用的查詢結果的情況下工作，因此大部分的測試都要包含執行一個查詢所需的步驟?，F在試想一下輕微地改變一下步驟的順序：你需要更新每個腳本。

　　可供選擇的方法是創建一個執行查詢的函數或子程序。這個函數變成了一個可重用庫文件的一部分。每個腳本調用這個函數比重新定義那些步驟更好。如果你在一個地方(函數庫中)定義了事件的進展，你將使你所有的腳本更加好維護，這樣勝于在需要執行這些操作的每個腳本中定義它們。

　　為了尋找一個支持可重用庫的工具，有兩件重要的事情需要做。首先，要確保你用工具創建的腳本能夠輕松地調用你放在庫文件中的函數。如果工具只允許你調用在當前腳本中創建的子程序那是不足夠的。第二，確信函數可以帶參數。例如，如果你創建了一個登陸的函數，你想要在每次調用函數的時候指定用戶名和密碼(而不是在函數中嵌入這些信息)。

　　4). 外部的庫文件Outside libraries

　　除了創建你自己的庫文件之外，你通常會發現訪問外部的庫文件是非常有用的。在Windows里，這意味著你應該能夠調用.dll文件。舉個例子，思考一下一個已構建的與關系數據庫一起運行的C/S系統。所測試的軟件使用了數據庫私有的API(Application Program Interface)。如果自動化測試可以使用相同的API，它們可以變得更加強大。他們可以檢查不允許訪問的用戶界面。例如，它們可以檢查一個已更改的值是否已經被寫到數據庫中，而不僅僅只是在屏幕上更改了。即便UI沒有給權限給它們記錄，它們都可以檢查交易是否成功并且完全被記錄了。一般說來，這些測試可以比通過驗證UI上的值更加準確地判斷“成功”或是“失敗”。

　　如果你正在一個Windows系統上測試，你也應該有訪問Windows API的權限。Windows API 使你能夠獲得系統信息，這是非常困難的或者其他方法不可能獲得的。例如，在你的自動化腳本中獲取或設置注冊表的鍵值的時候是非常有用的。

原文轉自：http://www.uml.org.cn/Test/200608111.htm