測試基礎
用戶與 App 有很多不同水平的交互，從點擊一個提交按鈕到向設備上下載信息。因此，你應該在你迭代開發你的App 時測試各種各樣的使用場景和交互。
使用迭代開發工作流程
隨着你的App的拓展，你應該會發現從服務器獲取數據，與設備的傳感器交互，訪問本地存儲，或者渲染複雜的界面都是必要的。因此你的多功能的 App 需要一種全面的測試策略。
當你迭代開發一個功能時，你可以通過編寫一個新的測試，或者添加 case 和斷言到一個已經存在的測試。首次測試是失敗的，因爲功能還沒開發完成。
當你設計一個新功能時考慮出現的責任單元是很重要的。對於每一個單元，你應該寫一個相關的單元測試。你的單元測試應該幾乎包括相關單元中幾乎所有可能的交互場景，包含標準的交互，無效的輸入，和一些資源無效的場景。
圖1迭代，測試驅動開發相關聯的兩個循環
完整的工作流程，向圖1中所顯示的那樣，包含一系列的嵌套迭代循環，其中一個長時間、慢速的UI驅動循環測試代碼單元的集成。你可以用更短，更快的開發循環來測試它本身。這些循環將持續到您的應用程序滿足每一個用例。
瞭解測試金字塔
圖2. 測試金字塔，展示了三種你應該包含在你的App 測試中的測試種類
圖二中所顯示的測試金字塔，說明了您的 App 應該包含三種測試：小的，中等的和大的：
小型測試是一種可以和你的生產系統所隔離的測試。他們通常會模擬每個主要的組件並且快速的在你的機器上運行。
中型測試是位於小型測試和大型測試中間的集成測試。他們集成了一些組件，運行在模擬器或者真實的設備上。
大型測試是通過完成一個 UI 工作流程來運行的集成和UI測試。他們確保關鍵的最終的用戶任務在模擬器或實際設備上按預期工作。
儘管小型測試速度很快，並且重點突出，可以讓你快速的定位錯誤，但是他們也是低保真和獨立的，讓你很難有信心僅僅通過這些測試就允許您的App工作。當編寫大型測試時會遇到一些相反的折衷。
由於不同測試種類特徵的不同，你應該包含測試金字塔中的每一層級測試。雖然每個類別的測試比例可能會因爲您的 App 用例而變化，但是我們通常建議這樣拆分這些種類：70%小型測試，20%中型測試，10%大型測試。
要了解更多關於 Android 測試金字塔的信息，請參考來自 Google I/O 2017大會上的 Android測試驅動開發 系列視頻。
編寫小型測試
當你添加或者修改應用程序的功能時，請確保這些功能按照預期的方式運行，並針對他們創建和運行單元測試。雖然可以在設備或者模擬器上運行測試，但是在你的開發環境上測試這些單元是更快更容易的。根據需要來添加stubbed 或者 mocked 方法來與 Android 系統交互。
Robolectric
如果您的應用測試環境需要單元測試更廣泛的與 Android 框架來交互，你可以用robolectric。這個工具可以很友好的執行。基於 Java 邏輯的 Stubs 模擬 Android 框架。Android團隊在維護這個 stubs。
Robolectric 測試效果幾乎與在 Android 設備上測試一樣，同時比在 Android 設備上測試更快。它也支持 Android 平臺的以下幾個方面：
Android 4.1（API 16）以上
Android Gradle 2.4版本以上
組件生命週期
事件循環
所有的資源
備註: Robolectric 有屬於它自己的一些 API 並且介紹了一些新概念。有關將 Robolectric 的 API 與應用測試集成的更多信息，請看 Robolectric使用指南
Mock對象
你可以通過對 android.jar 的修改版本運行單元測試來監視與您的應用程式進行交互的 Android 框架的元素。這個 JAR 文件不包含任何代碼，因此你的 App 對Android 框架調用時默認會拋出異常。爲了測試你代碼中與 Android 系統交互的每一個元素，你應該使用一個像 Mockito 的框架來配置mock對象。
如果你的代碼包含對資源文件的引用或者與 Android 結構有着複雜的交互，你應該使用一種不同的單元測試的方式，例如 Robolectric.
Instrumented單元測試
你也可以在物理設備或者模擬器上運行 Instrumented 單元測試，他不涉及框架的任何模擬或者 stubbing 。然而，因爲這種測試方法執行的時間比本地單元測試的執行時間要慢的多，因此你最好只有在評估應用程序對實際設備硬件的行爲至關重要時才依賴此方法。
編寫中等測試
當你已經在開發環境中測試了應用的每一個單元后，你應該驗證這些組件是否在模擬器或設備上也運行良好。中等測試可以允許你完成這部分的開發過程。如果你的 App 的某些組件依賴於物理硬件，那麼這些測試尤其重要。
中等測試評估您的 App 如何協調衆多的單元，但是他們不測試整個 App 。中等測試的例子包含 Service 測試，集成測試，和模擬外部依賴行爲的密封UI測試。
一般來說，在模擬器或者基於雲服務 (例如Firebase測試實驗室) 上測試你的 App 要比在物理設備上測試好，因爲你可以更快更容易的測試很多不同大小的屏幕尺寸和不同的硬件配置的設備。
編寫大型測試
儘管獨立的測試應用程序中的每個層和功能很重要，但是測試常見的工作流程和包含完整堆棧的使用場景也同等重要，從UI到業務邏輯到數據層。
如果你的 App 足夠小，你可能僅僅需要一套大型測試來評估你的 App 的整體功能。否則，你應該根據團隊所有權，功能垂直或者用戶目標來分割大型測試。
備註: 對於每個你編寫的基於工作流程的大型測試，你同時也應該寫中型測試來檢查工作流程中所包含的每一個 UI 組件的功能。這樣的話，你的測試套件可以繼續識別關鍵用戶流程中每個步驟中的潛在問題，即使相關的大型測試在前幾個步驟中發生錯誤。
AndroidJUnitRunner 類定義了一個基於 instrumentation 的 JUnit 測試運行器，可以讓你在 Android 設備上運行 JUnit3 或者 JUnit4-style 測試類。測試運行器有助於將測試包和被測試的應用程序加載到設備或者仿真器上，運行測試並報告結果.
AndroidJUnitRunner 同時還支持 Android 測試支持庫(ATSL)中的以下工具和框架：
JUnit4 Rules
ATSL(Android測試支持庫) 包含管理測試中所涉及的關鍵應用程序組件生命週期的代碼，例如 Services 和Activities。要了解如何定義這些規則，請查看 JUnit4 Rules 指南。
Espresso
Espresso 可以執行下列的App內的操作：
對 View 對象執行操作
完成跨越應用程序的工作流程，僅僅在 Android 8.0(API 26) 及以上可用
評估需要訪問您的 App 的用戶如何使用您的應用
定位並執行 RecyclerView 和 AdapterView 中的 item
驗證 intent 的狀態
驗證 WebView 對象中的 DOM 結構
跟蹤 App 內長時間運行的後臺操作
想要了解更多關於這些操作和如何在 App 測試中使用它們，請看 Espresso指南
UI Automator
注意: 我們建議僅當您的App必須要和系統進行交互才能完成關鍵的用例時才使用 UI Automator,由於 UI Automator 與系統因應用和UI進行交互，所以當系統更新時你需要重新運行和修復你的 UI Automator 測試。這些更新包括 Android 平臺版本更新和一些 Google Play 服務版本的更新。
作爲使用 UI Automator 的替代方案，我們建議添加密封測試或者將你的大型測試分割成一套中小型測試。特別是當測試一個跨進程通信，例如給別的 App 發送信息並且相應 intent 結果。Espresso-Intents 可以幫你編寫這些小型測試。
UI Automator框架運行於你的 App 在和系統的 App 進行交互的場景，例如檢查當前顯示的 UI 的層次結構，截取屏幕截圖和分析設備的當前狀態。關於 UI Automator 如何觀察被測試應用程序的更多詳細信息請看 UI Automator指南
Android Test Orchestrator
Android Test Orchestrator 在其自己的Instrumentation 沙箱中運行每一個UI測試，通過減少測試之間的共享狀態並且在每個測試基礎上隔離應用程序崩潰來提高測試的穩定定。
想要了解更多關於Android Test Orchestrator 在測試您的App時提供的優勢，請看 Android Test Orchestrator指南