GUI自動化測試原理剖析
序言：接觸過自動化測試工具的測試人員，例如，Rational fuction teste，QTP等，一定對“錄制—回放”這種機制不陌生吧，但是又有多少人能夠了解其內部大概的運行機制呢？更又有多少人能從代碼級別及其框架去分析其運作原理呢？
我一直覺得，你不理解它，你就無法用好它，更別說去拓展它成一個框架或者平臺了。
它，在錄制時，是怎么獲取對象的？可以不通過錄制的方式獲得對象嗎？
它，在回放時，是采用調用什么方式進行回放的？可以通過API或者自己編寫代碼使其錄制的腳本進行回放嗎？
自己如何去編寫一個簡單的“錄制—回放”工具呢？
那么，今天就大概根據自己的簡單介紹一下這種機制，希望能夠幫助大家一起真正走入一個自動化測試的“大門”。
一、工具如何實現錄制和回放
首先大概介紹一下自動化測試工具實現錄制和回放的兩種方法，其重點是對象的識別。
1、靜態映射：當錄制時，通過ObjectMap，將需要識別的JAVA應用程序的組件對象映射進對象庫，然后，回放時，RFT首先根據正在運行的JAVA程序到對象庫去查找相應的對象，若匹配到對應屬性閾值適合的對象，則調用其腳本中的方法對對象執行操作。
一般的工具在工具與AUT之間都有一個代理，這個代理就是包裹著實際要測試的界面的控件，而ObjectMap是腳本層面的東西，它們之間存在一個映射關系。RFT通過代理與AUT進行交互。
需要明白的是，由于swing組件的樹形結構關系，因此，ObjectMap中的映射出來的對象也是采用這種形式，雖然RFT中可以通過自己設置識別閾值的方式，但是對界面更改的適應能力還是不高。
2、動態搜索：應用動態搜索就可以不需要采用錄制的方式了，而且也不需要對象庫的方式，它是直接通過調用工作庫中的API來定制相應的組件屬性進行查找即可；回放時，自動化測試工具會獲取正在運行的JAVA程序的各個組件屬性，然后進行屬性匹配，若是能夠匹配到相應符合的屬性，則會進行腳本規定的方法操作；
所以，應用動態搜索的方式，雖然在識別效率上降低了，但是其識別能力大大提高，界面如何變化，只要屬性值不變，就沒有太大問題，這也是為什么需要開發在開發JAVA程序的時候，盡量在屬性值里添加一個唯一的識別屬性ID了，這樣做的目的可以使自動化測試更好的開展，這也可以作為以后各位的一個DFT需求了。
二、錄制和回放的原理
經過了第一環節的介紹，大家對自動化測試工作實現錄制和回放的兩種方式大概有所了解，但是深層次是怎么樣的呢？
借用關于JAVA的事件生命周期的一幅圖片來說明：
測試人員通過對界面的操作會生成一系列的事件，這些事件在工具的代碼中會由事件生成后放在系統事件隊列內部。現在事件處于事件分發線程的控制下。事件在隊列中等待處理，然后事件從事件隊列中選出，送到dispatchEvent()方法，dispatchEvent()方法調用processEvent()方法并將事件的一個引用傳遞給processEvent()方法。此刻，系統會查看是否有送出事件的位置，如果沒有這種事件類型相應的已經注冊的監聽器，或者如果沒有任何組件受到激活來接收事件類型，事件就被拋棄。
錄制時，采用了監聽器模式，和平常swing編程不同的是，這里的監聽器不是針對某個組件的，而是針對某種事件的。也就是說，任何組件發出的同一類型的事件，比如鼠標或者鍵盤事件，都會被其相應的監聽器捕獲到，然后進行處理。然后將捕獲到的JAVA事件，可以以某種格式保存在腳本文件中，這里就需要一個轉換機制了。
回放時，則從腳本文件讀取并還原事件，這里會用到java.awt.Robot類（JDK1.3之后引入的一個類，能模擬鼠標和鍵盤操作），這個類通常用來在自動化測試或程序演示中模擬系統事件，這個類主要的目的就是為方便的實現java的GUI自動化測試平臺。在事件回放時，我們同樣需要該類來模擬生成系統的事件，完成記錄的操作的回放
三、Gui自動化測試的簡單框架架構
1、類加載器或者應用程序加載器，則是去加載相應的應用程序或者主類，這樣可以指定需要測試的應用程序。
2、事件監聽器，則是對應用程序所產生的各種事件的一個監聽機制，可以通過拓展不同的事件監聽來獲得不同的事件。
3、腳本解析器，包括腳本記錄器與腳本讀取器兩個模塊，一個可以從監聽器中獲得事件的有效信息并記錄，可以指定記錄到生成相應腳本。一個可以從本地腳本文件或文本域中讀取腳本信息，并解釋成相應事件。
4、Robot類再封裝，即是一個模擬回放器，將從腳本解析器解析過來的代碼通過調用Rboot類進行模擬鼠標和鍵盤的一系列操作。
一個GUI自動化測試框架的基本架構大概就是這樣，如果有興趣的朋友可以深入研究，因為商業化的自動化測試工作實現的架構比這個要復雜一些，但原理基本還是一樣的。
WEB與WIN32等界面自動化測試的原理架構大致也是如此，不過實現方式還是很不一樣的，關鍵是調用的庫方式不一樣，具體在以后可以一起討論。
四、選擇一種合適的自動化測試方案
所以根據以上架構和原理，在自動化測試項目開展過程中
1、有資源和人力的情況下，可以考慮自己去開發一個簡單的自動化測試工具，這樣的好處是靈活，能夠很好的與自身的產品結合起來，缺點就是耗費資源太大，而且開發自動化測試工具不一定能好用。
2、可以結合相應的開源自動化測試工具（例如：測試swing的可以用abbot），這種方式優點就是免費而且實現也有一定的基礎，缺點就是其功能不一定滿足其需求。
3、采用商業性的自動化測試工作（例如：RFT），這種方式的優點是成熟度高，而且能很快的應用到項目中，但是注意的是需要自己去搭建一個框架，個人建議，應用RFT的話最好直接應用其API去拓展一個自己的庫，通過自己的庫去搭建一個適應自己需求的框架，這個在后期會介紹。
總之：各種方案的實行方式還是得具體根據項目的需求來，需求才是導向，而且個人根據經驗：不要為了做自動化而自動化，不要去為了做自動化而迷戀入技術而不可自拔，一定要在適當的時候采用適當的方式，步步為進。真心希望大家都能做好自動化測試。
版權聲明：本文出自 散步的SUN 的51Testing軟件測試博客：http://www.51testing.com/?382641
【編輯推薦】
