Android自動化框架介紹

隨着Android應用得愈來愈廣，愈來愈多的公司推出了本身移動應用測試平臺。例如，百度的MTC、東軟易測雲、Testin雲測試平臺……。因爲本身所在項目組就是作終端測試工具的，故抽空了解了下幾種常見的基於UI層面的自動化測試工具。趁晚上有空總結下，好記心不如爛筆頭呀！

一 常見Android自動化測試框架及其應用

         目前，Android基於UI層面的自動化測試工具，均可以理解爲是基於Android控件層面的，涉及Widgets和WebView兩大類。其主流的測試方法主要有如下幾種。一種是經過Android提供的各類服務，來獲取當前窗口的視圖信息。而後，在當前視圖內查找目標控件，並根據該控件屬性信息計算出該控件中心點的座標，進而構造出一個Android Input事件來實現對應用的自動化測試。其主要特色是：測試代碼和被測應用各自運行在各自的進程內，相互獨立。其表明有Uiautomator。另外一種則是基於Instrumentation，經過把測試代碼和應用代碼，確切地說是測試APK和被測APK，運行在同一個進程中，經過Java反射機制，來獲取當前窗口全部視圖，並根據該視圖查找到目標控件的屬性信息，並計算出目標控件中心點座標。而後，利用Instrument內部接口，實現點擊操做。其表明有Robotium。

咱們先來看下第一種。這類方法一般須要知足兩個功能，一是能獲取屏幕視圖；二是能產生輸入事件。這樣，用戶就能夠經過屏幕視圖查找到目標控件，進而計算出其中心點座標，並由此產生一個輸入事件來模擬用戶操做。一般，這類框架還會提供一個截屏功能，方便用戶對照。例如，分析定位問題等等。

目前，這類測試方法常見應用模式有如下幾種：（1）、Hierachyview+monkey；（2）、uiautomator；（3）、accessibilityservice。（4）其餘。先來講下第一種，Hierachyview+monkey的組合方式。

咱們先來講下第一種，Hierachyview+monkey。其實現原理以下：

 

首先，hierahcyview經過socket與設備側ViewServer創建鏈接，端口爲4939。其次，經過命令「dump -1」獲取控件屬性信息。信息存入ViewNode中。第三，根據ViewNode信息，遍歷控件樹，查找到目標控件，並根據其bounds信息，計算出其中心點座標。第四，根據計算出的座標信息，發送一個點擊該點的monkey命令給設備側的monkey服務。除點擊操做外，咱們還能夠經過Monkey服務進行輸入、硬按鍵類操做。至此，對設備的一個自動化操做就完成了。這裏須要說明的是，絕大部分商用手機ViewServer服務的開啓都須要系統權限。故採用這種模式，手機通常須要root權限。另外，關於Hierachyview，CSDN上有一篇很好地介紹Hierachyview實現原理的文章，其鏈接地址以下：

http://www.cnblogs.com/vowei/archive/2012/08/08/2627614.html。現摘錄其部份內容，關於從設備側ViewServer獲取控件層次結構圖的過程，以便你們更好地理解該模式。

 

HierachyViewerDirector.java（即Controller）經過DeviceBridge.java來和Android設備通訊，而DeviceBridge.java具體是經過AndroidDebugBridage.java和DeviceConnection.java來和設備通訊。備註：Hierachyview自己採用MVC模式。

AndroidDebugBridge.java : AndroidDebugBridge.java是ADB API，位於ddmlib項目中。它實現了命令行版adb同樣的功能，在HierarchyViewer中主要用到其鏈接設備，forward端口，啓動ViewServer等操做。

DeviceConnection.java: 負責和ViewServer通訊，向ViewServer發送命令並接受其返回的信息。從而獲取Activity列表、控件層次結構圖、截圖等。

 

第二種應用模式Uiautomator。UiAutomator是Google仿照微軟Uiautomation提供的一套自動化框架，基於Android AccessilibilityService提供（注：Android AccessilibilityService，是一個可訪問服務，是一個爲加強用戶界面並幫助殘疾用戶的應用程序，或者用戶可能沒法徹底與設備的交互。例如，用戶在開車。那麼用戶就有可能須要添加額外的或者替代的用戶反饋方式）。其應用方式有如下幾種，一種是UiAutomatorView+monkey，另外一種是直接調用UiAutomator API。其中，第一種方法同hierachyview+monkey差很少。其區別是：UiAutomatorView經過ADB向設備側發送一個dump命令，而不是創建一個socket，下載一個包含當前界面控件佈局信息的xml文件。相比較hierachyview下載的內容而言，該文件小不少。所以，從效率上講，這種方法比第一種應用模式快不少。第二種方法，則是直接調用UiAutomator框架對外提供的API，主要有UiDevice、UiSelector、UiObject等。其原理與第一種方式，即HierachyView+Monkey，差很少。其過程大體是：首先，UiAutomator測試框架經過Accessibilityservice，獲取當前窗口的控件層次關係及屬性信息，並查找到目標控件。如果點擊事件，則計算出該控件的中心點座標。其次，UiAutomator經過測試框架，注入用戶事件（點擊、輸入類操做），從而實現模擬人的操做。UiAutomator對外提供UiAutomatorTestCase、UiDevice、UiSelector、UiObject、UiCollection、UiScrollable等類，其做用以下：

l  UiAutomatorTestCase ：繼承自Junit TestCase （Junit），對外提供setup、teardown等，以便初始化用例、清除環境等。

l  UiDevice：此類主要包含了獲取設備狀態信息，和模擬用戶至於設備的操做兩類API。UiSelector，主要是經過必定查詢方式，定位到所要操做的UI元素。

l  UiObject：UiObject可表明頁面的任意元素，它的各類屬性定位一般經過UiSelector來完成。

l  UiCollection：UiCollection通常與UiSelector連用，如它的構造函數也要求提供Uiselector: UiCollection(UiSelector selector)。它的API較少，主要用以從Uiselector篩選出的元素集中挑出所要的元素:getChildByDescription(), getChildByInstance(), getChildByText() ,以及統計元素集的個數getChildCount()。

l  UiScrollable：UiScrollable 用來表示能夠滑動的界面元素,其繼承關係爲UiObject -> UiCollection ->UiScrollable。

但UiAutomator的實現方式與HierachyView+Monkey有很大不同。以控件點擊操做爲例，其實現流程大體以下：

 

定義一個點擊對象Object，該對象則經過UiSelector對象定位到具體的控件。而UiSelector則經過UiAutomatorBridge（它可看作是UiSelector與AccesibilityService之間的鏈接器），將查詢內容（AccessibilityNodeInfo）和輸入事件（AccessibilityEvent）傳給AccessibilityService。實際業務過程比這複雜的多。這樣，就實現了對某個控件的查找或點擊操做。備註：AccessibilityEvent，全部可操縱的UI元素都定義爲一個AccessibilityEeventt；AccessibilityNodeInfo指視窗中的組件樹節點。    

第三種則是accessibilityservice。先來介紹下Accessibilityserveice服務。前面已經講過，它是一個Android的一個服務。如果用Accessibilityservice進行自動化，咱們須要繼承Accessibilityservice開發一個服務。這樣，咱們就能夠依據這個服務獲取當前界面的控件屬性信息。其獲取內容跟Uiautomator同樣，都是AccessibilityNodeInfo。控件信息獲取到後，如果要進行點擊等操做，則可經過Monkey或其餘方式，如Input等，來模擬點擊操做。

上述幾種Android測試方法中，UiAutomator比較正統，是Google正式推出的，也是應用範圍最廣的。另外幾種方法，則見得很少，其中Hierachyview+monkey的方式，公司內部Ares就採用了。這類測試工具的一個好處就是能夠跨應用。但不足之處也不少，速度慢、不支持WebView等（這種模式下，對WebView控制有限，沒法注入Java Script）。

接下來講下第二種框架，即Instrumentation，它是Android對外提供的一系列的測試方法的核心。Instumentation可當作一系列控制函數的集合，做用於系統和應用之間，相似於Windows中的Hook。在該測試框架下，主程序和測試程序須要運行在同一個進程中，見下圖（圖片來源CSDN，連接地址：http://blog.csdn.net/jayfei0308/article/details/7950052）。

  

 

須要說明的是，在Android系統中，測試程序也是應用程序，咱們能夠將其當作一個沒有UI的應用。

其實現過程大體以下：如圖，InstrumentationTestRunner經過調用Instrumentation殺除應用程序的進程，再用Instrumentation重啓該應用。這時，測試應用和被測應用就運行在同一進程下。測試應用怎麼知道該測試哪一個應用呢？嗯，這是經過在測試工程的mainfest文件中添加元素來實現的。當測試應用和被測應用運行在同一個進程裏，它們之間就能夠經過Instrumentation來進行消息交互，從而達到測試效果。當Instrumentation與某個程序交互時，其大體採用以下步驟：（資料來源：

http://blog.csdn.net/fireworkburn/article/details/20144153）。

首先，啓動時，初始化測試APK的配置文件AndroidManifest.xml文件中。該配置文件中標明瞭所使用的測試運行類、被測目標應用、包名等。而後，啓動被測應用的Activity。同時，將測試ActivityThread作爲一個引用進行初始化。此時，若是找不到目標應用則會報錯。其次，執行測試腳本。測試時，測試工程中任何對目標應用進行的操做，都會用異步的方式，將消息體放在目標程序的MessageQueue中。這樣，目標程序在查看到本身的MessageQueue中有內容時就會執行。      

         基於Android Instrumentiaon開發的測試工具備不少，其中最有名的恐怕要數Robotium了。目前，網絡上不少移動應用測試平臺，如百度移動應用測試平臺MTC，都支持Robotium。

二 各種Android測試工具的TestCase繼承關係

         Android提供了不少測試工具，如Monkey、Instrumentation、UiAutomator。其中，基於Android測試工具進行二次開發的測試工具也不少，如Robotium、Espresso。它們的繼承關係下圖：

 

UiAutomator Testcase類繼承自JUnit的TestCase類。而Robotium、Espresso則繼承自activityInstrumentationTestCase2。從這個繼承關係，咱們也能理解爲何採用Robotium的方式，應用須要簽名。而採用UiAutomator則不須要。其緣由是：採用Robotium的方式，其測試代碼本質上是一個APK。根據Android的安全機制，應用是須要簽名的。

  

三 常見Android自動化框架優缺點關係

這裏主要介紹下前面講的幾種測試工具的優缺點，包括HierachyView+Monkey、UiAutomator、Robotium。

	Hierachyview+Monkey	UiAutomator + Monkey	Robotium
權限	root	普通	普通
是否須要簽名	是	否	否
響應速度	10s（網友測試數據）	4s（網友測試數據）	1-2s
是否支持WebView	否	否	是
是否支持跨應用測試	是	是	否
支持該特性的Android API	?	API 16	API 7
是否支持控件ID	是	否	是

從上述數據來看，Android提供的測試工具各有優缺點，有的支持WebView測試，有的不支持。有的支持跨應用，有的不支持。所以，一個好的Android測試工具，更多地是兼容了上述幾種測試方法。例如，Appium。

 

轉自：http://bbs.c114.net/blog-1025779-5322.html