本页概述了测试 Android 应用的核心要点，包括核心最佳实践及其优势。
测试的好处
测试是应用开发流程中不可或缺的一环。通过持续对应用运行测试，您可以在公开发布应用之前验证其正确性、功能行为和易用性。
您可以通过浏览应用来手动测试应用。您可以使用不同的设备和模拟器，更改系统语言，尝试生成每个用户错误或遍历每个用户流。
不过，手动测试的扩展性较差，并且很容易忽略应用行为的回归问题。自动化测试是指使用工具为您执行测试，这种方式更快速、更可重复，并且通常会在开发流程的早期为您提供有关应用的更实用反馈。
Android 中的测试类型
移动应用非常复杂，必须能够在多种环境中正常运行。因此，测试有很多种类型。
主题
例如，根据主题的不同，有不同类型的测试：
- 功能测试：我的应用是否能按预期运行？
- 性能测试：是否快速高效地完成测试？
- 无障碍功能测试：应用是否能与无障碍服务正常协作？
- 兼容性测试：它是否在所有设备和 API 级别上都能正常运行？
范围
测试还会因大小或隔离程度而异：
- 单元测试或小型测试仅验证应用的一小部分，例如方法或类。
- 端到端测试或大型测试可同时验证应用的较大部分，例如整个屏幕或用户体验流程。
- 中型测试介于两者之间，用于检查两个或更多单元之间的集成。
测试的分类方式有很多。不过，对于应用开发者来说，最重要的区别在于测试的运行位置。
插桩测试与本地测试
您可以在 Android 设备或其他计算机上运行测试：
- 插桩测试在 Android 设备（实体设备或模拟设备）上运行。该应用会与用于注入命令并读取状态的测试应用一起构建和安装。插桩测试通常是界面测试，指的是启动应用，然后与之交互。
- 本地测试在开发机器或服务器上执行，因此也称为主机端测试。它们通常小巧且运行速度快，可将被测对象与应用的其余部分隔离。
并非所有单元测试都是本地测试，也并非所有端到端测试都在设备上运行。例如：
- 大型本地测试：您可以使用在本地运行的 Android 模拟器，例如 Robolectric。
- 小型插桩测试：您可以验证自己的代码是否能与框架功能（例如 SQLite 数据库）正常协作。您可以在多部设备上运行此测试，以检查与多个版本的 SQLite 的集成情况。
示例
以下代码段演示了如何在插桩界面测试中与界面互动，点击某个元素并验证是否显示了另一个元素。
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)
可测试的架构
采用可测试的应用架构后，代码会遵循一种结构，让您可以轻松单独测试其不同部分。可测试架构还具有其他优势，例如更好的可读性、可维护性、可伸缩性和可重用性。
不可测试的架构会生成以下内容：
- 更大、更慢、更不稳定的测试。无法进行单元测试的类可能需要通过更大的集成测试或界面测试进行覆盖。
- 测试不同场景的机会较少。测试规模越大，速度就越慢，因此测试应用的所有可能状态可能并不现实。
如需详细了解架构准则，请参阅应用架构指南。
分离方法
如果您可以从函数、类或模块中提取部分内容，那么测试起来会更容易、更有效。这种做法称为解耦，是可测试架构最重要的概念。
常见的分离技术包括：
- 将应用拆分为层，例如呈现层、网域层和数据层。您还可以将应用拆分为模块，每个功能对应一个模块。
- 避免向具有大量依赖项的实体（例如 activity 和 fragment）添加逻辑。将这些类用作框架的入口点，并将界面和业务逻辑移至其他位置，例如可组合项、ViewModel 或网域层。
- 避免在包含业务逻辑的类中使用直接的框架依赖项。例如，请勿在 ViewModel 中使用 Android 上下文。
- 使依赖项易于替换。例如，使用接口，而不是具体实现。使用依赖项注入，即使您不使用 DI 框架也是如此。
后续步骤
现在，您已经了解了为何应进行测试以及两种主要测试类型，接下来可以阅读要测试的内容或了解测试策略
或者，如果您想创建自己的第一个测试并通过实践学习，请查看测试 Codelab。