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