這裏不聊爲什麼android要進行UI測試，主要聊一下android studio集成的兩種測試包的區別以及如何搭配使用。
android studio集成了兩種的UI測試包Espresso和UIAutomator，搭配使用起來也非常方便(一個測試類中兩種測試代碼可以混搭使用）。Espresso主要是用於應用內的測試；UIAutomator是用於跨應用的測試。個人覺得：
（1）Espresso非常適合用於單頁面測試，之所以這麼說，是基於以下原因：
（a) Espresso測試有個很強大的功能是它在多個測試操作中是線程安全的。Espresso會等待當前進程的消息隊列中的UI事件，並且在任何一個測試操作中會等待其中的AsyncTask結束纔會執行下一個測試。這樣就不用處理各種UI加載快慢導致的測試用例運行奔潰問題，這點要比基於Instrumentation的測試框架要簡單的多，後者主要是通過設置適當的等待時間，來等待UI繪製完成在進行後續的測試動作，例如打開一個activity後要點擊一個按鈕，使用後者的測試代碼需要在寫完“打開activity”這個測試代碼後，測試代碼中要專門設置一個適當的等待時間，然後才能繼續寫“點擊按鈕”測試代碼，否則直接執行“點擊按鈕”操作很容易出現測試奔潰的情況。
(b) Espresso可以模擬頁面間的跳轉和數據通信。頁面間跳轉和數據傳遞，可以用模擬的方法進行測試，而不需要真正跳轉到其他頁面。比較典型的例子是，測試頁面通過startActivityForResult()跳轉到a頁面，然後關閉a頁面返回到測試的onActivityResult方法時，往往會攜帶Intent數據。這時就可以使用espress-intents包來模擬發送這個Intent數據，而不需要真正的跳轉到a頁面。因此，一個activity頁面在使用Espresso測試時，最好是一個測試類對應一個activity頁面，這樣比較清晰明朗。
(c) 基於第一點的UI事件驅動測試流程的原因，Espresso測試的運行速度很快。
（2）UIAutomator比較適合多頁面或跨應用的功能測試。
（a）所謂的功能測試通俗講就是一連串的頁面跳轉，一個app一般都有幾個主要的功能流程，例如註冊流程、登陸流程等，這些流程都包含一系列的頁面跳轉，這種跳轉可能要跳到其他app頁面或者系統的頁面。例如“藍牙搜索”功能大致流程如下：啓動頁面->彈出用戶權限對話框->彈出系統藍牙開關對話框->藍牙搜索頁面。這當中涉及到系統的彈框，這時候使用Espresso就比較麻煩了，Espresso要實現IdlingResources接口，然後將這個實現類在app代碼中（注意不是在測試代碼中）實例化，通過阻斷測試進程來等待用戶彈框的操作結果，這樣不能完全分離app代碼和測試代碼，而且阻斷了自動化測試過程（因爲要等待測試人員手動點擊系統彈框），這是我們不希望看到的。使用UIAutomator可以非常簡單的自動點擊系統彈框，而且不需要在app頁面中嵌入測試代碼。
(b) Espresso也可以進行多頁面跳轉測試，但是它只能獲取入口activity的實例，一旦跳轉到其他頁面，就不能獲取(或者說很難獲取)到當前activity的實例，這對有些測試情況是很不友好的，例如異步加載數據然後刷新UI的情況。
因此，個人的做法是：
（1）單頁面測試主要使用Espresso，這可以覆蓋絕大部分頁面的詳盡測試。
（2）整個app梳理出幾條主要的功能流程，針對這些功能流程，使用UIAutomator配合Espresso編寫測試用例。
瞭解更多資料可以加我QQ: 1914532832 驗證信息請註明：Android開發