Android 应用测试基础

此页面概述了 Android 应用测试的核心原则，包括核心最佳实践及其优势。

测试的优势

测试是应用开发过程中的一个组成部分。通过持续对您的应用运行测试，您可以在公开发布应用之前验证其正确性、功能行为和可用性。

您可以手动测试您的应用，方法是浏览应用。您可能会使用不同的设备和模拟器，更改系统语言，并尝试生成每个用户错误或遍历每个用户流程。

但是，手动测试的可扩展性很差，并且很容易忽略应用行为的回归。自动化测试涉及使用为您执行测试的工具，这更快、更可重复，并且通常会在开发过程的早期为您提供更多关于应用的可操作反馈。

Android 中的测试类型

移动应用程序很复杂，必须在许多环境中都能正常工作。因此，有许多类型的测试。

主题

例如，根据主题，测试类型会有所不同

  • 功能测试：我的应用是否按预期工作？
  • 性能测试：它是否快速有效地工作？
  • 无障碍测试：它是否能与无障碍服务良好配合？
  • 兼容性测试：它是否能在每台设备和 API 级别上都能正常工作？

范围

测试也会根据大小或隔离程度而有所不同

  • 单元测试或小测试仅验证应用的一小部分，例如方法或类。
  • 端到端测试或大测试同时验证应用的较大一部分，例如整个屏幕或用户流程。
  • 中等测试介于两者之间，并检查两个或多个单元之间的集成。
Tests can be either small, medium, or big.
图 1：典型应用程序中的测试范围。

有许多方法可以对测试进行分类。但是，对于应用开发者来说，最重要的区别是测试在何处运行。

工具测试与本地测试

您可以在 Android 设备上或其他计算机上运行测试

  • 工具测试在 Android 设备（物理设备或模拟器）上运行。应用与测试应用一起构建并安装，该测试应用注入命令并读取状态。工具测试通常是 UI 测试，启动应用，然后与其交互。
  • 本地测试在您的开发机器或服务器上执行，因此它们也称为主机端测试。它们通常很小且速度很快，将测试对象与应用的其余部分隔离开来。
Tests can run as instrumented tests on a device, or local tests on your development machine.
图 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 和业务逻辑移动到其他位置，例如 Composable、ViewModel 或域层。
  • 避免在包含业务逻辑的类中直接使用框架依赖项。例如，不要在 ViewModel 中使用 Android 上下文。
  • 使依赖项易于替换。例如，使用接口而不是具体实现。使用依赖注入，即使您不使用 DI 框架。

后续步骤

现在您已经了解了为什么要测试以及两种主要类型的测试，您可以阅读测试什么或了解测试策略

或者，如果您想创建第一个测试并通过实践学习，请查看测试代码实验室。