Skip to main content

Android 截图测试

为什么我们要进行截图测试？​

截图测试用于验证当前的用户界面是否与存储在仓库中的参考用户界面相匹配。通过这样做，我们可以确保对用户界面的任何更改都是有意的并经过验证。这些测试的范围仅限于用户界面。

我们应该在各种设备形状和尺寸上进行测试，从小屏幕（例如，Wear OS 设备）到大屏幕（例如，55" 电视）。

截图测试的好处​

  • 用户界面一致性：确保在更新中用户界面保持一致。
  • 库更新：验证对用户界面库的更新不会引入意外的更改。
  • 广泛的设备覆盖：跨多个屏幕尺寸和形状进行测试，以确保兼容性。

真实案例​

在使用库的测试版时，截图测试已证明其有效性，例如 Wear Compose 库，其中库的变化可能影响用户界面。

Compose 截图测试​

我们使用 Compose 预览截图测试 框架来断言用户界面不会意外变化。

Compose 截图测试的优势​

  • 无需模拟器：这些测试不需要模拟器，使其占用资源更少，并且相比于 集成测试 快得多。
  • 快速反馈：开发人员可以快速验证用户界面更改，而无需等待模拟器启动时间。

参考截图​

参考截图存储在每个 Gradle 模块的 src/debug/screenshotTest/reference 下。要更新参考截图，请运行以下命令：

./gradlew updateDebugScreenshotTest

CI 集成​

我们的 CI 流水线 验证测试报告以查找任何错误。如果发现差异，CI 会阻止拉取请求，直到问题解决。

避免在 Compose 预览中重复​

为了避免在测试中重复 Compose 预览，请确保尽可能重用现有的可组合项和预览注释。这减少了冗余，并确保预览和测试之间的一致性。

配置测试的注释​

编写截图测试时，使用适当的配置注释来定义设备大小、主题和其他参数。这确保测试准确反映预期的用户界面。

处理阈值更新​

截图测试在不同操作系统上运行时可能会失败，原因是渲染中的细微差异，例如抗锯齿。该问题在此 Google 问题跟踪器 中进行了详细讨论。

当前方法​

  • 我们的目标是将阈值保持尽可能低，以避免掩盖真实问题。
  • 如果由于轻微的渲染差异导致测试失败，您可能需要调整阈值。

要调整阈值，请在测试文件中更新配置，以允许轻微的变化，同时仍然捕获重大的更改。

截图测试的最佳实践​

  • 跨设备测试：确保您的测试覆盖一系列屏幕尺寸和形状。
  • 保持参考截图更新：定期更新参考截图以反映有意的用户界面更改，并在您的 PR 中解释更改。
  • 最小化阈值：使用尽可能小的阈值，以避免隐藏真实问题。
  • 重用预览：通过重用现有的可组合项和注释，避免重复 Compose 预览。

通过遵循这些实践，您可以确保您的用户界面在更新和设备配置之间保持一致和可靠。