测试是应用开发过程中不可或缺的一部分。您通常会在模拟器或设备上运行应用，以手动验证代码是否按预期运行。然而，手动测试既耗时又容易出错，对于在各种屏幕和尺寸设备上运行的应用来说，往往难以管理。手动测试的问题通常是由于仅使用一台设备进行开发造成的。因此，在具有不同外形规格的其他设备上，错误可能会被忽略。
为了识别不同窗口和屏幕尺寸上的回归问题，请实施自动化测试，以验证您的应用在不同外形规格上的行为和外观是否一致。自动化测试能够及早发现问题，从而降低问题影响用户体验的风险。
测试内容
在开发适用于不同屏幕和窗口尺寸的 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 行为测试可以是 仪器化测试 或 本地测试。仪器化测试在设备或模拟器上运行，而本地 UI 测试则在 JVM 上的 Robolectric 上运行。
使用 UI 行为测试来验证应用导航的实现是否正确。这些测试执行点击和滑动等操作。UI 行为测试还会检查某些元素或属性是否存在。有关更多信息，请参阅 自动化 UI 测试。
截屏测试会截取 UI 或组件的截屏，并将图像与之前批准的截屏进行比较。这是一种非常有效的防范回归的方法，因为单个截屏可以覆盖大量元素及其视觉属性。您可以在 JVM 或设备上运行截屏测试。有多种截屏测试框架可用。有关更多信息，请参阅 截屏测试。
最后，您可能需要单元测试来测试根据设备类型或窗口大小行为不同的逻辑单元的功能，但单元测试在此领域不太常见。
后续步骤
有关如何实施本文档中包含的检查的更多信息，请参阅 库和工具。