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