測試 Android 應用程式的基礎知識

本頁概述測試 Android 應用程式的核心原則，包括主要最佳做法及其優點。

測試的好處

測試是應用程式開發流程中不可或缺的一環。藉由持續測試，您可以在公開發布前，確認應用程式運作無誤、功能正常，且易於使用。

您可以手動測試應用程式，方法是瀏覽應用程式。您可能會使用不同的裝置和模擬器、變更系統語言，並嘗試產生所有使用者錯誤，或遍歷所有使用者流程。

不過，手動測試的擴充性不佳，而且很容易忽略應用程式行為中的迴歸問題。自動化測試涉及使用工具為您執行測試，這種測試速度更快、可重複性更高，而且通常能在開發程序初期提供更多可做為行動依據的應用程式意見回饋。

Android 測試類型

行動應用程式相當複雜，必須在多種環境中正常運作。因此，測試類型有很多種。

主旨

舉例來說，根據測試對象，測試類型會有所不同：

  • 功能測試：應用程式是否能正常運作？
  • 效能測試：是否能快速有效率地執行？
  • 無障礙功能測試：是否能與無障礙服務搭配運作？
  • 相容性測試：在所有裝置和 API 級別上是否都能正常運作？

範圍

測試也會因大小或隔離程度而異：

  • 單元測試或小型測試只會驗證應用程式的一小部分，例如方法或類別。
  • 端對端測試或大型測試會同時驗證應用程式的大部分內容，例如整個畫面或使用者流程。
  • 中型測試介於兩者之間，用於檢查兩個或多個單元之間的整合。
測試可分為小型、中型或大型。
圖 1：一般應用程式中的測試範圍。

測試有多種分類方式。不過，對應用程式開發人員來說，最重要的區別在於測試執行的位置。

檢測設備測試與本機測試

您可以在 Android 裝置或其他電腦上執行測試：

  • 檢測設備測試會在 Android 裝置上執行，無論是實體或模擬裝置皆可。建構及安裝應用程式時，會一併安裝測試應用程式，用於插入指令及讀取狀態。檢測設備測試通常是 UI 測試，會啟動應用程式，然後與其互動。
  • 本機測試會在開發機器或伺服器上執行，因此也稱為「主機端測試」。這類測試通常規模較小且速度較快，可將測試對象與應用程式的其他部分隔離。
測試可以做為檢測設備測試在裝置上執行，或做為本機測試在開發機器上執行。
圖 2：不同類型的測試，取決於測試執行的位置。

並非所有單元測試都是本機測試，也並非所有端對端測試都在裝置上執行。例如：

  • 大型本機測試：您可以使用在本機執行的 Android 模擬器，例如 Robolectric。
  • 小型檢測設備測試：您可以驗證程式碼是否能與架構功能 (例如 SQLite 資料庫) 搭配運作。您可以在多部裝置上執行這項測試，檢查與多個 SQLite 版本的整合情形。

範例

下列程式碼片段示範如何在檢測設備 UI 測試中與 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)

可測試的架構

如果應用程式架構可供測試，程式碼就會遵循特定結構，讓您輕鬆測試不同部分的程式碼。可測試的架構還有其他優點，例如更易於閱讀、維護、擴充及重複使用。

無法測試的架構會產生以下結果：

  • 測試規模更大、速度更慢、更不穩定。無法進行單元測試的類別，可能需要透過較大型的整合測試或 UI 測試來涵蓋。
  • 測試不同情境的機會較少。大型測試的速度較慢，因此測試應用程式的所有可能狀態可能不切實際。

如要進一步瞭解架構指南，請參閱應用程式架構指南。

分離方法

如果能從函式、類別或模組中擷取部分內容，測試就會更輕鬆有效。這種做法稱為「去耦」，是可測試架構最重要的概念。

常見的去耦技術包括：

  • 將應用程式分割成多個層，例如 UI、網域和資料。您也可以將應用程式拆分為模組，每個功能一個模組。
  • 避免在具有大量依附元件的實體 (例如活動和片段) 中加入邏輯。請將這些類別做為架構的進入點，並將 UI 和商業邏輯移至其他位置，例如可組合項、ViewModel 或網域層。
  • 避免在包含商業邏輯的類別中直接依附架構。例如，請勿在 ViewModel 中使用 Android Context。
  • 讓依附元件易於替換。例如，使用介面，而非具體實作。即使不使用 DI 架構，也請使用依附元件插入。

後續步驟

現在您已瞭解測試的原因和兩種主要測試類型，可以參閱「測試項目」或瞭解「測試策略」。

或者，如果您想建立第一個測試，並透過實作學習，請參閱測試程式碼研究室。