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