本页概述了 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 Context。
- 使依赖项易于替换。例如，使用接口而不是具体实现。即使您不使用 DI 框架，也要使用依赖项注入。
后续步骤
现在，您已经了解了为什么要进行测试以及两种主要的测试类型，接下来可以阅读测试内容或了解测试策略
或者，如果您想创建第一个测试并边做边学，请查看测试 Codelab。