測試使用者互動，有助於確保使用者在與應用程式互動時不會遇到非預期結果，或不佳的使用體驗。如果需要驗證應用程式的 UI 是否正常運作，應嘗試建立使用者介面 (UI) 測試的習慣。
UI 測試的其中一種方法，就是請真人測試人員對目標應用程式執行一組使用者作業，並確認應用程式可正常運作。不過，手動方法可能很耗時且容易出錯。更有效的做法是編寫 UI 測試，以自動方式執行使用者動作。這個自動化方法可讓您以可重複的方式快速可靠地執行測試。
UI 測試會啟動應用程式 (或其中一部分)，然後模擬使用者互動，最後再檢查應用程式是否已正確回應。這些測試屬於整合測試，範圍從驗證小型元件的行為，到遍及整個使用者流程的大型導覽測試都可以。這有助於檢查迴歸，以及驗證與不同 API 級別和實體裝置的相容性。
Android Studio 中的檢測設備 UI 測試
如要使用 Android Studio 執行檢測 UI 測試，請在獨立的 Android 測試資料夾 (src/androidTest/java) 中實作測試程式碼。Gradle 適用的 Android 外掛程式會根據測試程式碼建構測試應用程式，然後在與目標應用程式相同的裝置上載入測試應用程式。在測試程式碼中，您可以使用 UI 測試架構在目標應用程式中模擬使用者互動，以便執行涵蓋特定使用情境的測試工作。
Jetpack 架構
Jetpack 包含多種提供用於編寫 UI 測試的 API：
- Espresso 測試架構 (Android 4.0.1，API 級別 14 或以上版本) 提供的 API 可讓您編寫 UI 測試，藉此在單一目標應用程式中模擬使用者與 View 的互動。使用 Espresso 的優點是能夠自動同步處理測試動作與要測試的應用程式 UI。Espresso 會偵測主要執行緒是否處於閒置狀態，因此能夠在適當時機執行測試指令，提升測試的可靠性。
- Jetpack Compose (Android 5.0，API 級別 21 以上) 提供一組測試 API，用於啟動及與 Compose 畫面和元件互動。與 Compose 元素的互動會與測試保持同步，並能完全控制時間、動畫和重組。
- UI Automator (Android 4.3，API 級別 18 或以上) 是 UI 測試架構，適用於跨系統和已安裝應用程式的跨應用程式功能 UI 測試。UI Automator API 可讓您執行作業，例如在測試裝置上開啟「設定」選單或應用程式啟動器。
- Robolectric (Android 4.1，API 級別 16 或以上) 可讓您建立在工作站或持續整合環境中 (一般 JVM) 上執行的「本機」測試，而非透過模擬器或裝置執行。可使用 Espresso 或 Compose 測試 API 與 UI 元件互動。
柔和與同步
行動應用程式和架構的非同步特性，往往很難編寫可靠且可重複的測試。插入使用者事件時，測試架構必須等待應用程式完成回應，從變更畫面上的部分文字，到完整重新建立活動的過程。如果測試沒有確定性行為，就屬於「不穩定」。
Compose 或 Espresso 等現代化架構在設計時特別注重測試，因此可確保 UI 在下一次測試動作或斷言之前，會處於閒置狀態。這就是同步處理作業。
測試同步處理
執行非同步或背景作業無法辨識時 (例如從資料庫載入資料或顯示無限動畫) 時，仍可能會發生問題。
如要提高測試套件的可靠性，您可以安裝追蹤背景作業的方式，例如 Espresso Idling 資源。此外，您也可以替換模組，用於查詢閒置狀態，或改善同步處理作業，例如適用於協同程式的 TestDispatcher 或 RxJava 的 RxIdler。
架構與測試設定
應用程式的架構應允許測試取代應用程式的部分內容，以便測試雙重驗證，而且建議您使用提供公用程式的程式庫來協助進行測試。舉例來說，您可以將資料存放區模組替換為該模組的記憶體內版本，以便向測試提供假的確定性資料。
如要啟用這項功能，建議您使用依附元件插入。您可以手動建立自己的系統，但我們建議使用 Hilt 等 DI 架構來解決這個問題。
為什麼要自動測試？
Android 應用程式可指定多種 API 級別和板型規格的數千種不同裝置；如果作業系統提供高階自訂功能，就意味著應用程式可能無法在部分裝置上轉譯，甚至異常終止。
UI 測試可讓您進行相容性測試，驗證不同情境的應用程式行為。您可能須針對不同裝置執行 UI 測試，方法如下：
- API 級別：21、25 和 30。
- 語言代碼：英文、阿拉伯文和中文。
- 相片方向：直向、橫向。
此外，應用程式也應檢查手機以外的行為。建議您在平板電腦、折疊式裝置和其他裝置上測試。
其他資源
如要進一步瞭解如何建立 UI 測試，請參閱下列資源。