测试是应用开发过程中的一个组成部分。您通常在模拟器或设备上运行应用，以手动验证您的代码是否按预期工作。但是，手动测试既费时又容易出错，并且对于在各种尺寸的屏幕和设备上运行的应用来说，通常难以管理。手动测试的问题通常是由于在开发过程中使用单个设备造成的。因此，在其他具有不同外形尺寸的设备上，错误可能会被忽略。
为了识别不同窗口和屏幕尺寸上的回归，请实施自动化测试以验证应用的行为和外观在不同外形尺寸下是否一致。自动化测试可以尽早识别问题，从而降低问题影响用户体验的风险。
测试内容
在为不同屏幕和窗口尺寸开发 UI 时，请特别注意以下两个方面
- 组件和布局的视觉属性在不同尺寸的窗口上是如何不同的
- 状态如何在配置更改之间保留
视觉属性
无论您是否为不同的窗口尺寸自定义 UI，都应验证 UI 是否正确显示。请考虑紧凑、中等和扩展的宽度和高度。有关建议的断点，请参阅窗口尺寸类。
此外，当您的设计系统中某些组件的大小约束被拉伸时，您的应用可能无法按预期渲染这些组件。
如果您的应用针对不同窗口大小设计了自适应布局，则应进行自动化测试以防止出现回归问题。例如，修复手机上的边距可能会导致平板电脑上的布局不一致。创建UI 测试来验证布局和组件的行为，或构建屏幕截图测试以视觉方式验证布局。
状态恢复
在平板电脑等设备上运行的应用比手机上的应用更频繁地旋转和调整大小。此外，折叠式设备引入了新的显示功能，例如折叠和展开，这些功能可能会触发配置更改。您的应用需要能够在发生这些配置更改时恢复状态。然后，您还需要编写测试来确认您的应用正确恢复了状态。
首先，测试您的应用在发生配置更改时不会崩溃。确保应用中的每个 UI 都可以处理旋转、调整大小或折叠的任何组合。由于配置更改默认情况下会重新创建 Activity，因此某些崩溃是由于 Activity 持久性假设造成的。
有多种方法可以测试配置更改，但在大多数情况下，有两种方法可以进行测试
- 在 Compose 中，使用
StateRestorationTester以有效的方式模拟配置更改，而无需重新启动 Activity。有关更多信息，请参阅以下部分。 - 在任何 UI 测试（例如 Espresso 或 Compose）中，通过调用
Activity.recreate()来模拟配置更改。
通常，您不必使用不同的设备来测试响应配置更改的状态恢复。这是因为所有重新创建 Activity 的配置更改都会产生类似的影响。但是，某些配置更改可能会在特定设备上触发不同的状态恢复机制。
例如，当用户在展开的折叠式设备上查看列表-详情 UI并将其折叠以切换到前显示屏时，UI 通常会切换到详情页面。自动化测试应涵盖此 UI 状态的恢复，包括导航状态。
要测试设备从一个显示屏切换到另一个显示屏或进入多窗口模式时发生的配置更改，您可以选择多种方法
- 使用任何设备，在测试期间调整屏幕大小。在大多数情况下，这会触发您需要验证的所有状态恢复机制。但是，此测试不适用于检测折叠式设备中特定姿势的逻辑，因为姿势更改不会触发配置更改。
- 使用支持您要测试的功能的设备或模拟器来触发相关的配置更改。例如，可以使用 Espresso Device 控制折叠式设备或平板电脑，使其从折叠状态变为横向展开状态。有关示例，请参阅Espresso Device部分，该部分位于用于测试不同屏幕尺寸的库和工具中。
不同屏幕和窗口尺寸的测试类型
针对每个用例使用适当类型的测试，以验证测试在不同外形规格下是否正常工作
UI 行为测试启动应用 UI 的一部分，例如 Activity 的显示。测试验证某些元素是否存在或是否具有特定属性。测试可以选择性地执行模拟用户操作。对于视图，请使用Espresso。Jetpack Compose 拥有自己的测试 API。UI 行为测试可以是Instrumented或本地的。Instrumented 测试在设备或模拟器上运行，而本地 UI 测试在 JVM 上的Robolectric上运行。
使用 UI 行为测试来验证应用的导航实现是否正确。测试执行诸如点击和滑动等操作。UI 行为测试还检查某些元素或属性的存在。有关更多信息，请参阅自动化 UI 测试。
屏幕截图测试拍摄 UI 或组件的屏幕截图，并将图像与先前批准的屏幕截图进行比较。这是一种非常有效的防止回归的方法，因为单个屏幕截图可以涵盖大量元素及其视觉属性。您可以在 JVM 或设备上运行屏幕截图测试。有多个可用的屏幕截图测试框架。
最后，您可能需要单元测试来测试逻辑单元的功能，这些逻辑单元根据设备或窗口大小的类型而表现不同，但单元测试在此领域不太常见。
后续步骤
有关如何实现本文档中包含的检查的更多信息，请参阅库和工具。