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

　　概要：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測試自動化工具將擁有許多和一個好的開發環境相同的功能。

　　“噢，當然”你可能會想。“我將在我的大量的空閑時間里開始編寫我的測試。”你或許剛剛好有足夠的時間完成你現在的任務。自動化被假設為可以使你的生活更加輕松，而不是增加一個全新的編程任務。不幸的是，如果你不將測試自動化看待為一個編程任務，你將無止盡的重做，重做，重做。更糟的是，如果在項目的末尾時，最后一分鐘的變更破壞了測試，那么已自動化的測試將不能夠運行-剛好在你最需要它們的時候。即使你認為你沒有時間在多數的測試中遵循優秀的開發實踐，也應該購買一個支持它們的工具。把它看成是一個保險措施。

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