轉自：http://bbs2.c114.net/home.php?mod=space&uid=1025779&do=blog&id=5322
幾種常見的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來進行消息交互，從而達到測試效果。當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。