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