MILY: 宋體; mso-ascii-font-family: Arial; mso-hansi-font-family: Arial; mso-bidi-font-family: Arial; mso-bidi-font-size: 22.0pt">概要：GUI (圖形用戶界面graphical user interface)工具自詡其擁有許多的功能。把GUI測試自動化作為一個編程的項目處理，你將需要一個和你項目大小相當的工具。這是一篇對你購買的GUI測試自動化產品中你所需的關鍵功能的梗概。
· 在選擇一個GUI測試工具需要考慮的因素
· 把GUI測試自動化象一個編程項目一樣對待
· 必要功能的清單
購買一個GUI測試自動化工具是一個令人畏縮的任務。如果你是第一次評估工具的話，很難知道要在工具里查找些什么。即使你以前曾經評估過GUI測試工具，那些可用的工具和你上次察看時的情況可能也已經發生了巨大的變化。你會選擇哪一個工具呢？你真的需要每個供應商的市場宣傳冊中吹捧的所有功能嗎？你知道你不應該聽從那些圓滑的宣傳標語。你不確信從現在開始的6個月里你會需要哪些功能。因此你在購買一個可能遠遠超出你目的的高端工具和購買一個僅僅可以開始作些事情的低端工具之間痛苦的徘徊。
你要做的第一件事情是建立你將在評估工具中使用的決策標準。有一些標準可能是很明顯的：你想從一個有信譽的供應商手中購買，你選擇的工具需要支持你測試的操作系統，并且容易使用，不管這對你的組織重不重要。這篇文章并不是要告訴你那些你已知的所需功能，而是要說一說在你第一次采購后的幾個月里你將發現需要的GUI測試自動化工具中的功能。把它看成是一個對即要發生事情的“預警”（heads up）。
在開始時，思考一下自動化測試系統的概要圖形。如果你把測試開發看成是創建一些運行于基于GUI的軟件應用程序的測試那樣一件簡單的事情的話，那么你的測試自動化的模型看上去就像圖1。
當你只使用錄制和回放時，你的測試將類似于此圖。但是這個模型是有局限的。因為測試直接和用戶界面一起工作，幾乎在UI上的任何變更都意味著每個使用了這部分UI的測試都需要變更。另外，如果有一些大多數測試都必須執行的通用操作（例如，登陸），那么每個測試都必須包括這些步驟。最后，由于在測試中嵌入了所有的測試數據，為了迎合變更，甚至象在登陸表格中的名稱這樣小的事情，你都不得不編輯測試代碼。
結果，做日常維護是非常的困難，并且為本地化或UI檢查而做的重大變更更是一個惡夢。象這樣的測試系統在一個單獨的版本里徹底崩潰可不是罕見的。換句話說，在1.0版本中可以運行的測試，但在2.0中你可能就需要再創建它們了。
為了說明每個缺點，讓我們增加一些更多的元素。在后面將會詳細的解釋每個元素。首先，在所測試的軟件和測試腳本中增加一個抽象層。抽象層把UI元素映射為測試將使用的邏輯名稱。接下來，增加一個可重用的函數庫以封裝常用的操作。最后，增加測試數據文件以保存否則可能被硬編碼在腳本中的數據�，F在這個模型看起來象圖2。
即使你沒有計劃使用在這個圖中的所有元素，你都要尋找一個可以支持所有這些元素的工具。你會在比你想象中更早的時間里需要這些功能。
為什么呢？當你創建一些快速的，低劣的并且為任意使用而設計的測試時，你的自動化測試工作量是不太可能得到回報的，除非你的測試大部分是：
·可維護的：從一個版本到另一個版本都是可用的，只是為了新的功能或新的UI而做少量的更新
·可靠的：提供準確的結果，它對于識別所測試軟件中問題是直接了當的
·健壯的：能夠處理異常的錯誤條件，使測試可以在沒有人工干涉的情況下運行。
只有當你將測試自動化象軟件開發一樣認真的對待，你才能達到那個目標。測試自動化實際上就是編程。因此一個好的GUI測試自動化工具將擁有許多和一個好的開發環境相同的功能。
“噢，當然”你可能會想�！拔覍⒃谖业拇罅康目臻e時間里開始編寫我的測試�！蹦慊蛟S剛剛好有足夠的時間完成你現在的任務。自動化被假設為可以使你的生活更加輕松，而不是增加一個全新的編程任務。不幸的是，如果你不將測試自動化看待為一個編程任務，你將無止盡的重做，重做，重做。更糟的是，如果在項目的末尾時，最后一分鐘的變更破壞了測試，那么已自動化的測試將不能夠運行－剛好在你最需要它們的時候。即使你認為你沒有時間在多數的測試中遵循優秀的開發實踐，也應該購買一個支持它們的工具。把它看成是一個保險措施。
因此你可以怎樣確信你已經識別了一個將使你能夠構建一個系統并利用優秀的編程實踐實現它的工具呢？讓我們來看看在任何優秀的工具中都很重要的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在試想一下輕微地改變一下步驟的順序：你需要更新每個腳本。
可供選擇的方法是創建一個執行查詢的函數或子程序。這個函數變成了一個可重用庫文件的一部分。每個腳本調用這個函數比重新定義那些步驟更好。如果你在一個地方（函數庫中）定義了事件的進展，你將使你所有的腳本更加好維護，這樣勝于在需要執行這些操作的每個腳本中定義它們。
為了尋找一個支持可重用庫的工具，有兩件重要的事情需要做。首先，要確保你用工具創建的腳本能夠輕松地調用你放在庫文件中的函數。如果工具只允許你調用在當前腳本中創建的子程序那是不足夠的。第二，確信函數可以帶參數。例如，如果你創建了一個登陸的函數，你想要在每次調用函數的時候指定用戶名和密碼（而不是在函數中嵌入這些信息）。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
