android界面測試

⑴ android自動化測試工具有哪些

1、 Robotium 安卓測試工具

Robotium是一款經常使用的自動化測試工具軟體，支持Android。
Robotium是一個免費的Android UI測試工具。它適用於為不同的安卓版本和子版本測試自動化。軟體開發人員經常把它描述為Android Selenium。Robotium測試是用java寫的。事實上，Robotium是一個單元測試庫。
但通過Robotium創建測試需要花費很多時間和努力，因為為了自動化測試還需要修改程序源代碼。該工具也不適合與系統軟體的交互，它不能鎖定和解鎖智能手機或平板電腦。Robotium也沒有錄制回放功能，也不提供截圖。
2、MonkeyRunner 安卓應用測試

Monkeyrunner是一款流行的Android測試工具，用於自動化功能測試。
這個工具比Robotium更低一層次。這個不必處理源代碼來做自動化測試。這個測試可以用Python寫，並且可以使用錄制工具來創建測試。
Monkeyrunner可以連接到電腦或模擬真實設備運行測試。該工具有一個介面，用它來控制智能手機，平板電腦或外部模擬器的Android代碼。
這個測試工具的缺點是，它必須為每個設備編寫腳本。另一個問題是，每次測試程序的用戶界面變化都需要調整測試腳本。
3、Ronaorex 安卓測試應用工具
Ranrex 是一款不僅可以支持最新Android版本，也支持從Android2.2開始的早期版本和分支版本。
Ranorex的優勢是它有詳細的截屏報告。它能通過Wifi連接智能手機和平板電腦。
一個自動化測試工程師通過這個Android工具可以不用XML數據格式來詳細編寫數據驅動的測試。Ranorex工作室使自動化測試工程師只要點擊滑鼠就可容易地創建測試。它允許詳細聲明額外的程序模塊，來用於在後期開發周期中測試更復雜的場景。
它是一個商業的移動應用工具，其許可價格為1990歐元。不過Ranorex搜索功能相當慢；它需要30秒來完成這樣的操作。我們必須為Ranorex配備apk文件設備，否則無法通過這個工具實現自動化測試，因為它只能在APK文件設備上工作。

⑵ 如何設計Android App測試用例

一般安卓開發者在其日常工作中面臨的最大挑戰之一是：終端設備和[url=]操作系統[/url]版本的范圍太廣。OpenSignal進行的一項研究表明，2013年7月市場上有超過11，828的不同安卓終端設備，所有設備在類型/大小/屏幕解析度以及特定配置方面有所不同。考慮到前一年的調查僅記錄有3，997款不同設備，這實在是一個越來越大的挑戰障礙。

從一個移動APP開發角度出發，定義終端設備有四個基本特徵：
1．操作系統：由「API指標」（ 1 ～18 ）專業定義的安卓操作系統版本（ 1.1～ 4.3 ），。
2．顯示器：屏幕主要是由屏幕解析度（以像素為單位），屏幕像素密度（ 以DPI為單位），和/或屏幕尺寸（以英寸為單位）定義的。
3．CPU：該「應用程序二進制介面」 （ABI ）定義CPU的指令集。這里的主要區別是ARM和基於Intel的CPU。
4．內存：一個設備包括內存儲器（ RAM）和Dalvik 虛擬存儲器（ VM堆）的預定義的堆內存。
這是前兩個特點，操作系統和顯示器，都需要特別注意，因為他們是直接由最終用戶明顯感受，且應該不斷嚴格地被測試覆蓋。至於安卓的版本， 2013年7月市場上有八個同時運行導致不可避免的碎片的不同版本。七月，近90％這些設備中的34.1 ％正在運行Gingerbread版本（ 2.3.3-2.3.7 ），32.3 ％正在運行Jelly Bean（ 4.1.x版），23.3 ％正在運行Ice Cream Sandwich（ 4.0.3 - 4.0.4 ）。

考慮設備顯示器，一項TechCrunch從2013年4月進行的研究顯示，絕大多數（79.9％）有效設備正在使用尺寸為3和4.5英寸的「正常」屏幕。這些設備的屏幕密度在「MDPI」（～160 DPI），「hdpi」（～240 DPI）和「xhdpi」（～320 DPI）之間變化。也有例外， 一種只佔9.5％的設備屏幕密度低「hdpi」（～120 DPI）且屏幕小。

如果這種多樣性在質量保證過程中被忽略了，那麼絕對可以預見：bugs會潛入應用程序，然後是bug報告的風暴，最後Google Play Store中出現負面用戶評論。因此，目前的問題是：你怎麼使用合理水平的測試工作切實解決這一挑戰？定義測試用例及一個伴隨測試過程是一個應付這一挑戰的有效武器。

用例—「在哪測試」、「測試什麼」、「怎麼測試」、「何時測試」？
「在哪測試」
為了節省你測試工作上所花的昂貴時間，我們建議首先要減少之前所提到的32個安卓版本組合及代表市場上在用的領先設備屏的5-10個版本的顯示屏。選擇參考設備時，你應該確保覆蓋了足夠廣范圍的版本和屏幕類型。作為參考，您可以使用OpenSignal的調查或使用手機檢測的信息圖[3]，來幫助選擇使用最廣的設備。
為了滿足好奇心，可以從安卓文件[5]將屏幕的尺寸和解析度映射到上面數據的密度（「ldpi」，「mdpi」等）及解析度（「小的」，「標準的」，等等）上。

有了2013手機檢測研究的幫助，很容易就找到了代表性的一系列設備。有一件有趣的瑣事：30％印度安卓用戶的設備解析度很低只有240×320像素，如上面列表中看到的，三星Galaxy Y S5360也在其中。另外，480×800解析度像素現在最常用（上表中三星Galaxy S II中可見）。

「測試什麼」
移動APP必須提供最佳用戶體驗，以及在不同尺寸和解析度（關鍵字「響應式設計」）的各種智能手機和平板電腦上被正確顯示（UI測試）。與此同時，apps必須是功能性的和兼容的（兼容性測試），有盡可能多的設備規格（內存，CPU，感測器等）。加上先前獲得的「直接」碎片化問題（關於安卓的版本和屏幕的特性）， 「環境相關的」碎片化有著舉足輕重的作用。這種作用涉及到多種不同的情況或環境，其中用戶正在自己的環境中使用的終端設備。作為一個例子，如果網路連接不穩定，來電中斷，屏幕鎖定等情況出現，你應該慎重考慮壓力測試[4]和探索性測試以確保完美無錯。

有必要提前准備覆蓋app最常用功能的所有可能的測試場景。早期bug檢測和源代碼中的簡單修改，只能通過不斷的測試才能實現。

「怎麼測試」
將這種廣泛的多樣性考慮在內的一種務實方法是， 安卓模擬器 - 提供了一個可調節的工具，該工具幾乎可以模仿標准PC上安卓的終端用戶設備。簡而言之，安卓模擬器是QA流程中用各種設備配置（兼容性測試）進行連續回歸測試（用戶界面，單元和集成測試）的理想工具。探索性測試中，模擬器可以被配置到一個范圍廣泛的不同場景中。例如，模擬器可以用一種能模擬連接速度或質量中變化的方式來設定。然而，真實設備上的QA是不可缺少的。實踐中，用作參考的虛擬設備依然可以在一些小的（但對於某些應用程序來說非常重要）方面有所不同，比如安卓操作系統中沒有提供程序特定的調整或不支持耳機和藍牙。真實硬體上的性能在評價過程中發揮了自身的顯著作用，它還應該在考慮了觸摸硬體支持和設備物理形式等方面的所有可能終端設備上進行測試（可用性測試）。

「何時測試」
既然我們已經定義了在哪裡（參考設備）測試 ，測試什麼（測試場景），以及如何（ 安卓模擬器和真實設備）測試，簡述一個過程並確定何時執行哪一個測試場景就至關重要了。因此，我們建議下面的兩級流程：
1 ．用虛擬設備進行的回歸測試。
這包括虛擬參考設備上用來在早期識別出基本錯誤的連續自動化回歸測試。這里的理念是快速地、成本高效地識別bugs。
2 ．用真實設備進行的驗收測試。
這涉及到：「策劃推廣」期間將之發布到Google Play Store前在真實設備上的密集測試（主要是手動測試），（例如，Google Play[ 5 ]中的 alpha和beta測試組） 。
在第一階段，測試自動化極大地有助於以經濟實惠的方式實現這一策略。在這一階段，只有能輕易被自動化（即可以每日執行）的測試用例才能包含在內。
在一個app的持續開發過程中，這種自動化測試為開發人員和測試人員提供了一個安全網。日常測試運行確保了核心功能正常工作，app的整體穩定性和質量由測試數據透明地反映出來，認證回歸可以輕易地與最近的變化關聯。這種測試可以很輕易地被設計並使用SaaS解決方案（如雲中的TestObject的UI移動app測試）從測試人員電腦上被記錄下來。
當且僅當這個階段已被成功執行了，這個過程才會在第二階段繼續勞動密集測試。這里的想法是：如果核心功能通過自動測試就只投入測試資源，使測試人員能夠專注於先進場景。這個階段可能包括測試用例，例如性能測試，可用性測試，或兼容性測試。這兩種方法相結合產生了一個強大的移動apps質量保證策略[ 7 ] 。

結論 - 做對測試
用正確的方式使用，測試可以在對抗零散的安卓的斗爭中成為一個有力的工具。一個有效的測試策略的關鍵之處在於定義手頭app的定製測試用例，並定義一個簡化測試的工作流程或過程。測試一個移動app是一個重大的挑戰，但它可以用一個結構化的方法和正確的工具集合以及專業知識被有效解決掉。

⑶ android 哪些函數會引起界面重新測量

橫屏和豎屏
、新建一個Activity，並把各個生命周期列印出來

2、運行Activity，得到如下信息

onCreate-->
onStart-->
onResume-->

3、按crtl+f12切換成橫屏時

onSaveInstanceState-->
onPause-->
onStop-->
onDestroy-->
onCreate-->
onStart-->
onRestoreInstanceState-->
onResume-->

4、再按crtl+f12切換成豎屏時，發現列印了兩次相同的log

onSaveInstanceState-->
onPause-->
onStop-->
onDestroy-->
onCreate-->
onStart-->
onRestoreInstanceState-->
onResume-->
onSaveInstanceState-->
onPause-->
onStop-->
onDestroy-->
onCreate-->
onStart-->
onRestoreInstanceState-->
onResume-->

5、修改AndroidManifest.xml，把該Activity添加 android:configChanges="orientation"，執行步驟3

onSaveInstanceState-->
onPause-->
onStop-->
onDestroy-->
onCreate-->
onStart-->
onRestoreInstanceState-->
onResume-->

6、再執行步驟4，發現不會再列印相同信息，但多列印了一行onConfigChanged

onSaveInstanceState-->
onPause-->
onStop-->
onDestroy-->
onCreate-->
onStart-->
onRestoreInstanceState-->
onResume-->
onConfigurationChanged-->

7、把步驟5的android:configChanges="orientation" 改成 android:configChanges="orientation|keyboardHidden"，執行步驟3，就只列印onConfigChanged

onConfigurationChanged-->

8、執行步驟4

onConfigurationChanged-->
onConfigurationChanged-->

總結：

1、不設置Activity的android:configChanges時，切屏會重新調用各個生命周期，切橫屏時會執行一次，切豎屏時會執行兩次

2、設置Activity的android:configChanges="orientation"時，切屏還是會重新調用各個生命周期，切橫、豎屏時只會執行一次

3、設置Activity的android:configChanges="orientation|keyboardHidden"時，切屏不會重新調用各個生命周期，只會執行onConfigurationChanged方法

總結一下整個Activity的生命周期

補充一點，當前Activity產生事件彈出Toast和AlertDialog的時候Activity的生命周期不會有改變

Activity運行時按下HOME鍵(跟被完全覆蓋是一樣的)：onSaveInstanceState --> onPause --> onStop onRestart -->onStart--->onResume

Activity未被完全覆蓋只是失去焦點：onPause--->onResume

⑷ Android 手機自動化測試工具有哪幾種

1、Monkey
Android SDK自帶的測試工具，在測試過程中會向系統發送偽隨機的用戶事件流，如按鍵輸入、觸摸屏輸入、手勢輸入等)，實現對正在開發的應用程序進行壓力測試，也有日誌輸出。

2、MonkeyRunner
也是Android SDK提供的測試工具。嚴格意義上來說MonkeyRunner其實是一個Api工具包，比Monkey強大，可以編寫測試腳本來自定義數據、事件。

3、Instrumentation
早期Google提供的Android自動化測試工具類，雖然在那時候JUnit也可以對Android進行測試，但是Instrumentation允許你對應用程序做更為復雜的測試，甚至是框架層面的。通過Instrumentation你可以模擬按鍵按下、抬起、屏幕點擊、滾動等事件。Instrumentation是通過將主程序和測試程序運行在同一個進程來實現這些功能，你可以把Instrumentation看成一個類似Activity或者Service並且不帶界面的組件，在程序運行期間監控你的主程序。

5、Espresso
Google的開源自動化測試框架。相對於Robotium和UIAutomator，它的特點是規模更小、更簡潔，API更加精確，編寫測試代碼簡單，容易快速上手。

6、Robotium也是基於Instrumentation的測試框架，目前國內外用的比較多，資料比較多，社區也比較活躍。缺點是對測試人員來說要有一定的Java基礎，了解Android基本組件，不能跨App。

⑸ 怎樣使用Appium進行Android自動化測試

1、Robotium——安卓測試工具 Robotium是安卓系統最常用的自動化測試工具，並且是一款免費的安卓UI測試工具。它適合於各種不同的安卓版本及其下行版本。軟體開發者經常把它稱作安卓。Robotium創建的測試使用Java寫的。事實上，Robotium是一個個體測試資料庫。 但是Robotium需要花費很長時間努力去創建測試，就像為了自動化程序創建的源代碼。它不適合互動的軟體系統，不能鎖住和解鎖智能手機。Robotium沒有記錄和播放功能，它不支持截屏。 2、MonkeyRunner——安卓App測試工具 MonkeyRunner是最流行的有自動化功能的安卓軟體測試工具。MonkeyRunner比起Robotium要低端一些。它並不處理源代碼。測試創建是用Python寫的，其中可能使用記錄工具，為了創建測試。MonkeyRunner可以在連接狀態的PC或者模擬器上運行測試。它有一個應用程序介面可以控制智能手機或者模擬器。但手機APP測試工具的最大缺陷是每個設備都要編寫腳本。另一個缺陷就是，每次測試程序發生改變時都要調整。 3、Ranorex——安卓App測試工具 Ranorex是一個不錯的自動化測試工具，不僅最新版本，Android 2.2.以上版本都是可以的。Ranorex的好處在於它有詳細的截屏報告。他可以通過WiFi上網連接智能手機或者平板電腦。通過這個 Android 工具，自動化的測試工程師可以詳細描述數據驅動測試，但不包括 XML 數據格式。Ranorex可以很輕松地創建測試，自動化測試工程師只需點擊滑鼠。Ranorex允許附加的程序模塊。這個模塊可以被用於開發更為復雜的測試場景中。Ranorex是一個商業化的移動應用程序的工具;其許可價格是 1990歐元/年。Ranorex搜索相當慢;它需要 30 秒的時間來執行操作。其中一個必須為Ranorex文書的 APK 文件。否則它不能通過這個工具進行自動化測試，它只能在APK 文件下工作。 4、Appium——安卓自動化測試工具 Appium是為iOS和安卓系統創建的自動化測試框架，是一個免費工具。它支持 2.3 及更高版本的 Android 系統。Appium利用WebDriver界面運行測試。它支持許多編程語言，如 Java、 C#、Ruby和其他的WebDriver資料庫。它可以在移動設備上控制 Safari 和Chrome。但是，一些自動化的測試工程師抱怨它提供的報告不足。它的缺點也減少了對於XPath在移動設備上的支持。 5、UI Automator——安卓自動化測試 谷歌最近推出了這一工具。它支持從4.1開始的安卓版本。我們應該選擇另一個更早期的安卓應用程序進行自動化測試。UI Automator能夠與各類安卓系統兼容，包括系統的應用程序。這使得UI Automator可以鎖定和解鎖智能手機或平板電腦。通過該工具創建的腳本可以在許多不同的安卓平台上執行。它允許復制用戶的操作復雜的序列。UI Automator也可以利用外部按鈕的裝置調節，打開和關閉設備的按鈕。 UI Automator可以與測試框架TestNG集成。在這種情況下，用戶界面自動可以生成內容豐富和詳細的報告，類似於由Ranorex生成的報告。此工具搜索速度還非常快。在許多安卓平台上測試後，軟體測試專家認為UI Automator是質量最好的移動應用程序。它是安卓做好的應用程序之一，它由谷歌推出。 通常大約 80%的新軟體的 bug 都會重現支持的平台。其餘 20%出現在其他平台上。這意味著，在大多數情況下，事先測試軟體產品比盲目使用更好。 目前， Android 4.1 版本安裝了約 66%操作系統的設備。這就是為什麼許多自動化的測試工程師經常決定UI Automator是最合適的解決方案。

⑹ android studio instrumentation 做UI測試

一個項目代表一個完整的Android應用程序。Android Studio項目包含一個或多個mol... 測試或調試。mole包含您的應

⑺ 如何測試安卓（Android）系統的流暢度

測試方法一：系統自帶-開發者模式

實際上，為了方便開發者測試，安卓本身就內置了流暢度檢測的功能。不過，這需要我們開啟隱藏的開發者選項。如果你在用原生系統，那麼開啟開發者選項的方法很簡單，進入到設置菜單「關於手機」頁面，點擊數次「版本號」，即可開啟開發者選項。如果用的是其他ROM，方法也許有所不同，比如說魅族的Flyme開啟開發者選項的方法是在撥號界面輸入「*#*#6961#*#*」，其他機器方法也各有不同，大家可以參照廠商的說明。

進入到開發者選項，可以看到有「GPU呈現模式分析」的選項，開啟後即可以條形圖和線形圖的方法顯示系統的界面響應速度，可以用以觀察系統流暢度。那麼要如何根據曲線判斷系統是否流暢呢？實際上這個曲線表達的是GPU繪制每一幀界面的時間，只要不超過頂部綠線，都可以視為足夠流暢。

開啟GPU呈現模式分析

FPS Meter可以顯示最大最小幀數以及平均幀數

FPS Meter可以測試界面幀數，不過某些手機如果界面靜止，幀數會為0。FPS Meter除了測量系統界面幀數外，還可以用來測量游戲的幀數，所以用FPS Meter來測試某部安卓機游戲性能多強也是個很好的選擇。

當然，FPS Meter也並非十全十美。由於屬於第三方App，所以可能會有一些兼容性問題。某些安卓機或者ROM使用FPS Meter可能會不兼容，即使成功開啟了幀數顯示也沒法測量到准確數值，而某些設備使用FPS Meter甚至會死機。不過在大多數情況下，這款App還是相當值得信任的。

安卓在多個版本中都通過新技術提升了流暢度，比如說安卓2.3引入Dalvik、安卓4.0引入GPU界面繪制、安卓4.1引入黃油計劃、安卓4.3引入Trim以及安卓4.4引入ART等等。

H5頁面載入速度：window.performance.timing

Android以上測試方法不適用h5頁面

如何分析頁面整體載入速度：

主要是查看指標值PAGET_頁面載入時間,此指標指的是頁面整體載入時間但不含(onload事件和redirect), 此指標值可直接反應用戶體驗, 從此項指標可以知道指定某時間段的頁面載入速度值,以及和天,周,月的對比狀況.也可以查詢指標ALLT_頁面完全載入時間, 可以查詢到從瀏覽器開始導航(用戶點擊鏈接或在地址欄輸入url或點刷新,後退按鈕)到頁面onload 事件js完全跑完的所有時間.如果發現頁面載入速度有增加或減少,則可以分項查詢前面表格中的每個指標值,總的來說他們的關系如下:

dom開始載入前所有花費時間=重定向時間+域名解析時間+建立連接花費時間+請求花費時間+接收數據花費時間

pageLoadTime頁面載入時間=域名解析時間+建立連接花費時間+請求花費時間+接收數據花費時間+解析dom花費時間+載入dom花費時間

allLoadTime頁面完全載入時間=重定向時間+域名解析時間+建立連接花費時間+請求花費時間+接收數據花費時間+解析dom花費時間+載入dom花費時間+執行onload事件花費時間

resourcesLoadedTime資源載入時間=解析dom花費時間+載入dom花費時間

流暢度暫時沒有發現好用的測試衡量工具，開發層面了解，主要是根據log分析

⑻ 如何 測試 android app

使用eclipse新建android app並測試運行結果
一、新建android app
在文件菜單中打開新建，選擇new android application。然後會出現一個對話框。

在上面一步的各輸入框中填寫相應信息。注意包的名字一般是域名的倒寫。如果書寫不規范，它會提示一個紅色的叉。然後單擊下一步。

配置啟動圖標，可以選擇自己本地有的圖標。這個圖標就是app在手機應用上快捷方式所產生的圖標。

如果選擇clipart,它會提供許多圖標進行選擇。

下一步建立一個"activity"。有7個可供選擇。選擇第一個blank activity。表示空白活動。

下一步一般沒有修改的必要，點擊finish。

完成之後，它會創建一個項目，包含了幾個文件夾，有裝源代碼的，還有裝需要用到的資料的。

二、運行與測試
右擊工程名，下面這個就是Firstprj，然後選擇run as android application。它會啟動模擬器。提示調試信息。

上一步選擇yes，它會提示log信息。

最終的運行結果如下。

注意事項：
在開發之前，確保電腦已經配置好開發環境。

⑼ 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。其次，通過命令「mp -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向設備側發送一個mp命令，而不是建立一個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。在該測試框架下，主程序和測試程序需要運行在同一個進程中
需要說明的是，在Android系統中，測試程序也是應用程序，我們可以將其看成一個沒有UI的應用。
其實現過程大致如下：如圖，InstrumentationTestRunner通過調用Instrumentation殺除應用程序的進程，再用Instrumentation重啟該應用。這時，測試應用和被測應用就運行在同一進程下。測試應用怎麼知道該測試哪個應用呢？嗯，這是通過在測試工程的mainfest文件中添加元素來實現的。當測試應用和被測應用運行在同一個進程里，它們之間就可以通過Instrumentation來進行消息交互，從而達到測試效果。當Instrumentation與某個程序交互時，其大致採用如下步驟：
首先，啟動時，初始化測試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則繼承自。從這個繼承關系，我們也能理解為什麼採用Robotium的方式，應用需要簽名。而採用UiAutomator則不需要。其原因是：採用Robotium的方式，其測試代碼本質上是一個APK。根據Android的安全機制，應用是需要簽名的。