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