概要：GUI (圖形用戶界面graphical user interface)工具自詡其擁有許多的功能。把GUI測試自動化作為一個編程的項目處理，你將需要一個和你項目大小相當的工具。這是一篇對你購買的GUI測試自動化產品中你所需的關鍵功能的梗概。
· 在選擇一個GUI測試工具需要考慮的因素
· 把GUI測試自動化象一個編程項目一樣對待
· 必要功能的清單
購買一個GUI測試自動化工具是一個令人畏縮的任務。如果你是第一次評估工具的話，很難知道要在工具里查找些什么。即使你以前曾經評估過GUI測試工具，那些可用的工具和你上次察看時的情況可能也已經發生了巨大的變化。你會選擇哪一個工具呢？你真的需要每個供應商的市場宣傳冊中吹捧的所有功能嗎？你知道你不應該聽從那些圓滑的宣傳標語。你不確信從現在開始的6個月里你會需要哪些功能。因此你在購買一個可能遠遠超出你目的的高端工具和購買一個僅僅可以開始作些事情的低端工具之間痛苦的徘徊。
你要做的第一件事情是建立你將在評估工具中使用的決策標準。有一些標準可能是很明顯的：你想從一個有信譽的供應商手中購買，你選擇的工具需要支持你測試的操作系統，并且容易使用，不管這對你的組織重不重要。這篇文章并不是要告訴你那些你已知的所需功能，而是要說一說在你第一次采購后的幾個月里你將發現需要的GUI測試自動化工具中的功能。把它看成是一個對即要發生事情的“預警”（heads up）。
在開始時，思考一下自動化測試系統的概要圖形。如果你把測試開發看成是創建一些運行于基于GUI的軟件應用程序的測試那樣一件簡單的事情的話，那么你的測試自動化的模型看上去就像圖1。
當你只使用錄制和回放時，你的測試將類似于此圖。但是這個模型是有局限的。因為測試直接和用戶界面一起工作，幾乎在UI上的任何變更都意味著每個使用了這部分UI的測試都需要變更。另外，如果有一些大多數測試都必須執行的通用操作（例如，登陸），那么每個測試都必須包括這些步驟。最后，由于在測試中嵌入了所有的測試數據，為了迎合變更，甚至象在登陸表格中的名稱這樣小的事情，你都不得不編輯測試代碼。
結果，做日常維護是非常的困難，并且為本地化或UI檢查而做的重大變更更是一個惡夢。象這樣的測試系統在一個單獨的版本里徹底崩潰可不是罕見的。換句話說，在1.0版本中可以運行的測試，但在2.0中你可能就需要再創建它們了。
為了說明每個缺點，讓我們增加一些更多的元素。在后面將會詳細的解釋每個元素。首先，在所測試的軟件和測試腳本中增加一個抽象層。抽象層把UI元素映射為測試將使用的邏輯名稱。接下來，增加一個可重用的函數庫以封裝常用的操作。最后，增加測試數據文件以保存否則可能被硬編碼在腳本中的數據。現在這個模型看起來象圖2。
即使你沒有計劃使用在這個圖中的所有元素，你都要尋找一個可以支持所有這些元素的工具。你會在比你想象中更早的時間里需要這些功能。
為什么呢？當你創建一些快速的，低劣的并且為任意使用而設計的測試時，你的自動化測試工作量是不太可能得到回報的，除非你的測試大部分是：
·可維護的：從一個版本到另一個版本都是可用的，只是為了新的功能或新的UI而做少量的更新
·可靠的：提供準確的結果，它對于識別所測試軟件中問題是直接了當的
·健壯的：能夠處理異常的錯誤條件，使測試可以在沒有人工干涉的情況下運行。
只有當你將測試自動化象軟件開發一樣認真的對待，你才能達到那個目標。測試自動化實際上就是編程。因此一個好的GUI測試自動化工具將擁有許多和一個好的開發環境相同的功能。
“噢，當然”你可能會想。“我將在我的大量的空閑時間里開始編寫我的測試。”你或許剛剛好有足夠的時間完成你現在的任務。自動化被假設為可以使你的生活更加輕松，而不是增加一個全新的編程任務。不幸的是，如果你不將測試自動化看待為一個編程任務，你將無止盡的重做，重做，重做。更糟的是，如果在項目的末尾時，最后一分鐘的變更破壞了測試，那么已自動化的測試將不能夠運行－剛好在你最需要它們的時候。即使你認為你沒有時間在多數的測試中遵循優秀的開發實踐，也應該購買一個支持它們的工具。把它看成是一個保險措施。
因此你可以怎樣確信你已經識別了一個將使你能夠構建一個系統并利用優秀的編程實踐實現它的工具呢？讓我們來看看在任何優秀的工具中都很重要的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
設想你正在測試一個允許你查詢數據庫中記錄的應用程序。許多產品的功能只可以在有一組可用的查詢結果的情況下工作，因此大部分的測試都要包含執行一個查詢所需的步驟。現在試想一下輕微地改變一下步驟的順序：你需要更新每個腳本。
可供選擇的方法是創建一個執行查詢的函數或子程序。這個函數變成了一個可重用庫文件的一部分。每個腳本調用這個函數比重新定義那些步驟更好。如果你在一個地方（函數庫中）定義了事件的進展，你將使你所有的腳本更加好維護，這樣勝于在需要執行這些操作的每個腳本中定義它們。
為了尋找一個支持可重用庫的工具，有兩件重要的事情需要做。首先，要確保你用工具創建的腳本能夠輕松地調用你放在庫文件中的函數。如果工具只允許你調用在當前腳本中創建的子程序那是不足夠的。第二，確信函數可以帶參數。例如，如果你創建了一個登陸的函數，你想要在每次調用函數的時候指定用戶名和密碼（而不是在函數中嵌入這些信息）。
4). 外部的庫文件Outside libraries
除了創建你自己的庫文件之外，你通常會發現訪問外部的庫文件是非常有用的。在Windows里，這意味著你應該能夠調用.dll文件。舉個例子，思考一下一個已構建的與關系數據庫一起運行的C/S系統。所測試的軟件使用了數據庫私有的API(Application Program Interface)。如果自動化測試可以使用相同的API，它們可以變得更加強大。他們可以檢查不允許訪問的用戶界面。例如，它們可以檢查一個已更改的值是否已經被寫到數據庫中，而不僅僅只是在屏幕上更改了。即便UI沒有給權限給它們記錄，它們都可以檢查交易是否成功并且完全被記錄了。一般說來，這些測試可以比通過驗證UI上的值更加準確地判斷“成功”或是“失敗”。
如果你正在一個Windows系統上測試，你也應該有訪問Windows API的權限。Windows API 使你能夠獲得系統信息，這是非常困難的或者其他方法不可能獲得的。例如，在你的自動化腳本中獲取或設置注冊表的鍵值的時候是非常有用的。
5). 抽象層Abstract layers
一個“抽象層”使你能夠為物理的用戶界面元素定義邏輯名稱。一些工具稱它為“test map” 或“GUI map”，也有些稱其為“test frame”。不管它叫什么名稱，抽象層的目的就是使維護測試變得更輕松。
舉個例子，想象一下帶有用戶名和密碼字段的登陸對話框。在程序里，編程人員命名這些字段為“Name”和“Password”。你創建一個抽象層，它也將那些字段識別為“Name”和“Password”，并且在你所有的500個測試中都使用這些標志符 。但是隨著所測試軟件下一個版本的出現，名稱和密碼字段的潛在標志符變成了“username”和“pword”。你只要在一個地方－抽象層中更改UI標志符，而不是在你所有的500個腳本中做變更。
幾個測試工具都提供了這樣的功能，例如窗口錄制器，它是特別設計的以支持一個抽象層的創建。這些功能是非常有用的，但是如果你愿意手工的編寫抽象層，這也不是絕對需要的。
6). 分布式的測試Distributed tests
如果你正在測試多用戶的軟件，你需要能夠創建包含多個模擬用戶的測試。 例如，你可能想創建一個某臺機器上的用戶鎖住一個文件而另一臺機器上的用戶又在試圖打開同一個文件的測試。你如何自動化這種類型的測試呢？如果你選擇的測試工具沒有分布式測試的能力的話，那么這將是很困難的。
在一個分布式的測試里，自動化測試工具使你能指定執行一個既定指令的機器。這和在一臺遠程的機器上完成一個測試的能力（這也是一個很好的功能）有些不同。在一臺遠程機器上開始測試，遠程機器從頭到尾完整地運行那個測試。但是如果你需要在兩個不同的機器上協調這一活動，那么你應該做比只是開始一個測試且讓它運行更多的事情。你需要能夠創建一個等待一個動作的測試（例如鎖住一個文件），以便在第二臺機器開始一個動作之前（例如試圖打開文件）在第一臺機器上完成操作。
7). 文件I/O
文件的I/O (輸入/輸出input/output)意味著工具提供了讓你通過編程打開硬盤中的文件，讀取文件，寫文件和關閉文件（通常是一個ASCII文件）的函數 。
文件I/O函數是“數據驅動測試自動化”的核心。在一個數據驅動的自動化測試里，腳本使用文件中的測試數據來驅動測試活動（注意在圖2中“測試數據”在測試自動化架構中的角色）。數據驅動測試使自動化大量的測試，卻只有少量的測試自動化代碼變為可能。
如果你正在測試一個Windows的系統，如果工具提供了處理.ini文件的函數，那是特別有用的。例如，如果所測試軟件需要知道正在使用哪個服務器，那么在.ini文件中指定服務器的名稱是一個很好的方法。于是你只需要在文件中更改測試服務器，而不需要更改自動化腳本。
8). 錯誤處理Error handling
在你昨天晚上離開之前，你開始了一個很長的，需要運行250個測試的自動化測試。你來到的第二天早晨，你發現那些測試只運行5分鐘，因為在運行第二個測試之前出現了一個意外的對話框。這是個令人沮喪的場景，而且從來不少見。
擁有一個優異的錯誤處理系統的工具使得其他的腳本可以繼續運行，甚至于一個腳本失敗之后。工具可以停止失敗的腳本，然后在開始下一個腳本之前重新設置軟件到它初始的狀態。
如果工具的錯誤處理能力可以定制的話，那是非常有用的。例如，或許你的產品有已知的的錯誤條件，它需要一定數量的清除以修復。如果你能夠擴展錯誤處理系統以便它可以識別那些錯誤并且執行所需的清除，你的自動化測試甚至可以更加得健壯。
9). 調試器The debugger
沒有比“該死，它應該是可以工作的” 的感覺更令人沮喪的事情了，你完成了你的測試并且成功的使它運行在你的機器上了。現在你試圖運行測試在其他人的機器上，而它卻不能運行。擁有一個好的調試器可以比試驗－錯誤方法使你更快的發現問題。
調試器是嵌入在測試腳本開發環境中的，通常調試器使你能夠一步步的按行執行腳本，設置“斷點”（調試器可以停下執行腳本并且等待下一個指令的地方），并且檢查當前定義的變量和它們的值。如果調試器能夠讓你在任何可執行行上設置斷點那將更好，不管它是在所測試的腳本里還是在支持的代碼中（例如，在可重用的庫文件）。
10). 源代碼控制Source control
源代碼控制是一個任何類型軟件開發的基礎性工具，因此測試自動化也不例外。一般來說，源代碼控制系統允許你從一個主庫中check in或check out文件，回滾到先前的版本，找出版本之間的差異，并且同時追蹤幾個項目。這些功能使得多個人工作在源碼文件的多個版本上變為可能。
與其尋找一個包括了源代碼控制功能的測試工具，不如使用和軟件開發人員所使用的一樣的源代碼控制系統，實際上這樣也會更好些。使用相同的源代碼控制系統的實用性好處是你可以利用已經有一個建立了的工作方式的事實。使用相同的系統還有心理上的好處：在你組織的其他人了解到測試自動化是“真正的編程”。
即使你是你團隊中唯一的正在做自動化測試的人，你仍然要確信你所構建的測試系統中的所有部分－從測試數據文件和測試腳本到抽象層－可以在源碼控制下進行。幸運地是，和源代碼控制系統集成是比較簡單的：如果測試自動化文件用ASCII存儲，你可以使用你源碼控制系統中的所有功能。用二進制格式存儲自動化測試任何部分的測試工具會妨礙你和你的測試一起使用源碼控制的能力。你仍然可以把二進制文件放到源碼控制中，但是你將不能把文件的一個版本和另一個版本對比以判斷文件做何變更。（如果你不確定的話，你可以通過用好像Windows中的Notpad文字處理器來打開文件以斷定它是否是ASCII。如果你只看到文字字符并且有些意思，那么文件就是ASCII的。如果取而代之的是看到笑臉，心形，方塊或其他的奇怪的字符，那么文件可能就是二進制的了。）
另外，如果測試工具需要你將所有的文件放在一個集中的地方并且規定文件的結構，你需要試驗一下以確定和集中的文件位置一起使用源碼控制的最好方法（最好是在評估期間）。
11). 命令行腳本執行Command line script execution
從命令行運行腳本的能力使得設置腳本更加地容易，在機器comes back up之后自動地重啟機器和重新開始測試。這也使在每個版本后自動地開始自動化測試成為可能。
12). 用戶社區The user community
最后一個要查找的功能在軟件盒中是找不到：尋找一個擁有已建立用戶社區的工具。討論組，用戶的網站和當地用戶團體是所有可以學習你新工具細節的好地方。用戶社區的成員常常會共享通用函數的庫文件或其他一些有用的源代碼－這樣為開發你自己的內部可重用的庫文件有很大的幫助。
在你購買大量license之前先購買一些
就大多數組織而言，轉換工具的成本是非常昂貴的。那不僅僅是購買新軟件的事情。它也是關乎是要用新的工具重新創建現有的測試還是繼續為現有的工具支付維護費用的事情。購買一個受限的試用版的一個或兩個license，可能是在沒有太大風險的情況下試驗工具的最好辦法。如果試用版運行的很好，那么就購買更多的license并且全力的投入。如果試用版運行的不好，至少你沒有購買太多的license，潛在地浪費了很多的錢。
這也意味著如果你現在有一個工作的相當好的工具，但是沒有本文提及的所有功能，不要馬上跑出去買一個新的工具。切換工具可能比你相象中更加地昂貴。
結論
評估自動化測試工具是特別困難的，因為大部分的測試工具供應商在試圖做成買賣時，強調易用功能多過編程功能。你不會發現工具不能和你的源代碼控制系統一起工作，或是腳本很難維護，直到上路的6個月后。尋找與你現在所需功能，將來需要功能相平衡，以及迎合你預算底線成本的工具，這的確是一個挑戰。