以下是您可能希望在 CI 系统中使用的某些典型自动化形式。
基本作业
构建：通过从头开始构建项目，您可以确保新的更改可以正确编译，并且所有库和工具彼此兼容。
Lint 或样式检查：这是一个可选但推荐的步骤。当您强制执行样式规则并执行静态分析时，代码审查可以更简洁和更有针对性。
本地或主机端测试：它们在执行构建的本地机器上运行。在 Android 上，这通常是 JVM，因此它们快速且可靠。它们也包括 Robolectric 测试。
工具测试
在模拟器或物理设备上运行的测试需要一些预配，等待设备启动或连接以及其他增加复杂性的操作。
有多种选项可在 CI 上运行工具测试
- Gradle 托管设备可用于定义要使用的设备（例如“API 27 上的 Pixel 2 模拟器”），它处理设备预配。
- 大多数 CI 系统都带有第三方插件（也称为“操作”、“集成”或“步骤”）来处理 Android 模拟器。
- 将工具测试委托给设备农场，例如Firebase Test Lab。设备农场因其高可靠性而被使用，并且可以在模拟器或物理设备上运行。
性能回归测试
为了监控应用性能，我们建议使用基准测试库。开发过程中性能测试的自动化需要物理设备以确保一致且真实的测试结果。
运行基准测试可能需要很长时间，尤其是在您对代码和正在进行基准测试的用户旅程具有高覆盖率的情况下。与其为每个合并的功能或提交运行所有基准测试，不如考虑将其作为定期计划的维护构建（例如夜间构建）的一部分执行。
性能监控
您可以使用步进拟合监控性能回归。步进拟合定义了一个滚动窗口的先前构建结果，您可以将其与当前构建进行比较。这种方法将多个基准测试结果组合成一个特定于回归的指标。您可以应用步进拟合以减少回归测试期间的噪声。
这减少了误报的发生，误报可能发生在单个构建的基准测试时间较慢然后再次标准化时。
测试覆盖率回归检查
测试覆盖率是一个指标，可以帮助您和您的团队确定测试是否充分涵盖了更改。但是，它不应该成为唯一的指标。通常的做法是设置一个回归检查，当覆盖率相对于基准分支下降时，该检查会失败或显示警告。