測試使用者互動有助於確保使用者不會遇到非預期結果，或與應用程式互動時體驗不佳。如需確認應用程式的 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 Resources) 的方式。此外，您也可以替換模組，用於測試可以查詢閒置性或改善同步處理作業的版本，例如適用於協同程式的 TestDispatcher，或 RxJava 適用的 RxIdler。
架構與測試設定
應用程式的架構應讓測試取代實際部分內容，以便進行測試，並使用提供公用程式的程式庫來協助進行測試。舉例來說，您可以將資料存放區模組替換成該模組的記憶體內版本，為測試提供假確定性資料。
如要啟用這項功能，建議您使用依附元件插入。您可以手動建立自己的系統，但建議使用 Hilt 等 DI 架構。
為什麼要自動測試？
Android 應用程式可以針對多種 API 級別和板型規格指定數千種不同的裝置，而 OS 為使用者提供的高度自訂功能，意味著應用程式在某些裝置上可能無法正確轉譯，甚至停止運作。
UI 測試可讓您進行相容性測試，驗證應用程式在不同情境中的行為。建議您在採用下列不同方法的裝置上執行 UI 測試：
- API 級別：21、25 和 30。
- 語言代碼：英文、阿拉伯文和中文。
- 方向：直向、橫向。
此外，應用程式應確認手機以外的行為。您應在平板電腦、折疊式裝置和其他裝置上測試。
其他資源
如要進一步瞭解如何建立 UI 測試，請參閱下列資源。