测试用户互动有助于确保用户在与应用互动时不会遇到意外结果或糟糕体验。如果您需要验证应用的界面是否正常运行，应养成创建界面 (UI) 测试的习惯。
界面测试的一种方法是直接让测试人员对目标应用执行一系列用户操作，然后验证应用是否正常运行。不过，这种人工方法可能非常耗时且容易出错。更高效的方法是编写界面测试，以便以自动化方式执行用户操作。自动化方法可让您以可重复的方式快速可靠地运行测试。
界面测试会启动应用（或应用的某一部分），然后模拟用户互动，最后检查应用是否做出适当的响应。它们属于集成测试，涉及的范围很广，从验证小型组件的行为，到遍历整个用户流的大型导航测试，不一而足。它们对于检查回归问题以及验证与不同 API 级别和实体设备的兼容性非常有用。
Android Studio 中的插桩界面测试
如需使用 Android Studio 运行插桩界面测试，您需要在单独的 Android 测试文件夹 src/androidTest/java 中实现测试代码。Android Plugin for Gradle 会根据测试代码构建测试应用，然后在目标应用所在的同一设备上加载测试应用。在测试代码中，您可以使用界面测试框架来模拟目标应用中的用户互动，以便执行涵盖特定使用场景的测试任务。
Jetpack 框架
Jetpack 包含各种框架，这些框架提供用于编写界面测试的 API：
- Espresso 测试框架（Android 4.0.1，API 级别 14 或更高级别）提供了用于编写界面测试的 API，以模拟用户在单个目标应用中与 View 的互动。使用 Espresso 的主要优势是，它可以自动同步测试操作与您测试的应用界面。Espresso 会检测主线程何时处于空闲状态，以便能够在适当的时间运行测试命令，从而提高测试的可靠性。
- Jetpack Compose（Android 5.0，API 级别 21 或更高级别）提供了一组测试 API，用于启动 Compose 屏幕和组件并与之交互。与 Compose 元素的交互会与测试同步，并且可以完全控制时间、动画和重组。
- UI Automator（Android 4.3，API 级别 18 或更高级别）是一个界面测试框架，适用于跨系统和已安装的应用进行跨应用功能界面测试。借助 UI Automator API，您可以执行在测试设备上打开“设置”菜单或应用启动器等操作。
- 借助 Robolectric（Android 4.1，API 级别 16 或更高级别），您可以创建在工作站或持续集成环境中运行常规 JVM 的本地测试，而不是在模拟器或设备上运行。它可以使用 Espresso 或 Compose 测试 API 与界面组件进行交互。
不稳定和同步
移动应用和框架的异步特性常常使得编写可靠且可重复的测试变得非常困难。注入用户事件时，测试框架必须等待应用完成对该事件的响应，从更改屏幕上的某些文本到完全重新创建 activity，不一而足。如果测试没有确定性的行为，则不稳定。
Compose 或 Espresso 等现代框架在设计时考虑到了测试，因此可以保证在下一个测试操作或断言之前界面将处于空闲状态。这就是同步。
测试同步
当您运行测试不知道的异步或后台操作（例如从数据库加载数据或显示无限动画）时，仍可能会出现问题。
为了提高测试套件的可靠性，您可以安装一种方法来跟踪后台操作，如 Espresso Idling Resources。此外，您也可以替换模块，以测试可查询空闲性或改进同步的版本，例如用于协程的 TestDispatcher 或用于 RxJava 的 RxIdler。
架构和测试设置
应用的架构应允许测试替换应用的一部分来测试替身，您还应使用提供实用程序来帮助进行测试的库。例如，您可以将数据存储模块替换为为测试提供虚假的确定性数据的内存版本。
建议使用依赖项注入来启用此功能。您可以手动创建自己的系统，但我们建议您使用 Hilt 等 DI 框架。
为什么要进行自动测试？
Android 应用可以以多种 API 级别和外形规格针对数千种不同的设备，操作系统为用户提供的定制化程度很高，意味着您的应用在某些设备上可能无法正确呈现，甚至崩溃。
通过界面测试，您可以执行兼容性测试，从而验证应用在不同上下文中的行为。您可能希望在具有以下差异的设备上运行界面测试：
- API 级别：21、25 和 30。
- 语言区域：英语、阿拉伯语和中文。
- 方向：纵向、横向。
此外，应用还应检查手机以外的行为。您应在平板电脑、可折叠设备和其他设备上进行测试。
其他资源
如需详细了解如何创建界面测试，请参阅以下资源。