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