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

　　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

　　沒有比“該死，它應該是可以工作的” 的感覺更令人沮喪的事情了，你完成了你的測試并且成功的使它運行在你的機器上了?，F在你試圖運行測試在其他人的機器上，而它卻不能運行。擁有一個好的調試器可以比試驗-錯誤方法使你更快的發現問題。

　　調試器是嵌入在測試腳本開發環境中的，通常調試器使你能夠一步步的按行執行腳本，設置“斷點”(調試器可以停下執行腳本并且等待下一個指令的地方)，并且檢查當前定義的變量和它們的值。如果調試器能夠讓你在任何可執行行上設置斷點那將更好，不管它是在所測試的腳本里還是在支持的代碼中(例如，在可重用的庫文件)。

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