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