本頁將概述測試 Android 應用程式的核心原則，包括 中央最佳做法與優點
測試的好處
測試是應用程式開發流程中不可或缺的一環。透過執行測試 您可以持續驗證應用程式的正確性和功能 行為和可用性
您可以逐一瀏覽每個應用程式，手動進行測試。您可以使用 變更系統語言，再試著生成不同的裝置和模擬器 每個使用者錯誤，或週遊每個使用者流程。
不過，手動測試的規模效果不佳，而且可能很容易忽略 避免出現迴歸問題自動化測試牽涉到使用工具 且執行速度更快、可重複執行 讓你在開發初期就取得更多實用的應用程式意見回饋 上傳資料集之後，您可以運用 AutoML 自動完成部分資料準備工作
Android 中的測試類型
行動應用程式相當複雜，且在許多環境中都能順利運作。阿斯 因此測試有許多種。
主旨
例如，視主旨而定，會有不同的測試類型：
- 功能測試：應用程式的用途為何？
- 效能測試：測試是快速又有效率嗎？
- 無障礙功能測試：搭配無障礙服務運作是否正常？
- 相容性測試：在所有裝置和 API 級別上都適用嗎？
範圍
測試方式也會因大小或隔離程度而有所不同：
- 單元測試或小型測試只會驗證應用程式的一小部分。 例如方法或類別
- 端對端測試或大型測試，可驗證應用程式中的較大部分 例如整個螢幕或使用者流程
- 媒介測試介於兩個測試之間，並檢查二或兩個或之間的整合
分類測試的方法有很多種，不過 是應用程式開發人員執行測試
檢測設備測試與本機測試
您可以在 Android 裝置或其他電腦上執行測試：
- 檢測設備測試是在 Android 裝置 (實體或模擬) 上執行。 應用程式建立及安裝的測試應用程式會插入指令， 讀取狀態檢測設備測試通常是 UI 測試、啟動應用程式 然後與其互動
- 本機測試會在開發機器或伺服器上執行，因此 又稱「主機端測試」通常很小且快速， 來自應用程式的其餘部分。
並非所有單元測試都是本機測試，也並非所有裝置都會執行端對端測試。例如：
- 大型本機測試：您可以使用在本機執行的 Android 模擬工具，例如 Robolectric 中的一個。
- 小型檢測設備測試：您可以使用 像是 SQLite 資料庫您可能會在 檢查整合的多個 SQLite 版本。
範例
以下程式碼片段示範如何在 檢測設備 UI 測試，可點選元素並驗證另一個元素
Espresso
// When the Continue button is clicked
onView(withText("Continue"))
.perform(click())
// Then the Welcome screen is displayed
onView(withText("Welcome"))
.check(matches(isDisplayed()))
Compose UI
// When the Continue button is clicked
composeTestRule.onNodeWithText("Continue").performClick()
// Then the Welcome screen is displayed
composeTestRule.onNodeWithText("Welcome").assertIsDisplayed()
這段程式碼是 ViewModel (本機、主機端) 單元測試的一部分 測試)：
// Given an instance of MyViewModel
val viewModel = MyViewModel(myFakeDataRepository)
// When data is loaded
viewModel.loadData()
// Then it should be exposing data
assertTrue(viewModel.data != null)
定義測試策略
在理想的世界中，您可能會在每個裝置上測試應用程式中的每一行程式碼 必須與應用程式相容可惜的是，這個做法太慢 執行實際操作所耗費的成本
理想的測試策略會在 測試、速度和穩定性測試環境與 測試的保真度取決於實際裝置。執行更精準的測試 模擬裝置或實體裝置本身。則可執行較低的擬真度測試 執行指令碼高保真度測試通常較慢， 需要更多資源，所以不是每次測試都應進行高精確度測試。
不穩定的測試
即使在設計正確且執行測試的情況下，發生錯誤仍會發生錯誤。例如： 在實體裝置上執行測試時，系統可能會在 而這會導致測試失敗程式碼中的細微競爭狀況可能會 只有極少比例出現的情況未通過 100% 的測試 時間不穩定。
可測試的架構
以可測試應用程式的架構來說，程式碼的結構可讓您 ，輕鬆地單獨測試產品的不同部分可測試的架構 其他優點包括較佳的可讀性、可維護性、擴充性 可重複使用
「無法測試」的架構會產生以下內容：
- 測試範圍更大、速度較慢，測試期間較不穩定。無法進行單元測試的類別可能含有 以便進行更大規模的整合測試或 UI 測試
- 測試不同情境的機會較少。測試規模越大，速度越慢 因此，測試應用程式的所有可能狀態可能並不切實際。
如要進一步瞭解架構指南，請參閱應用程式指南 架構
分離的方法
如果可從其餘部分擷取函式、類別或模組的一部分，請測試 變得輕鬆又有效這種做法稱為「分離」 是可測試架構最重要的概念。
常見的分離技術包括：
- 將應用程式分割為圖層，例如簡報、網域和資料。你可以 可以將應用程式分割為「模組」，每個模組一個。
- 避免為具有大型依附元件的實體新增邏輯，例如 活動和片段使用這些類別做為架構的進入點， 將 UI 和商業邏輯移至他處，例如可組合函式、ViewModel 網域層
- 避免在含有商業邏輯的類別中直接使用架構依附元件。 例如，請勿在 ViewModel 中使用 Android 情境。
- 簡化依附元件的取代。舉例來說，請使用 介面，而非具體實作。使用 插入依附元件 (即使您未使用 DI 架構)。
後續步驟
現在您已瞭解測試原因與兩種主要測試 請參閱「測試項目」。
或者，如果您想要建立第一項測試並從中學習，請前往 請參閱測試程式碼研究室。