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