以下是您可能想要在 CI 系統中使用的一些常見自動化形式。
基本工作
建構：從頭建構專案，即表示您確保新變更能夠正確編譯，且所有程式庫和工具彼此相容。
Lint 或樣式檢查：這是選用步驟，但建議您執行。強制執行樣式規則並執行靜態分析時，程式碼審查就能更簡明扼要。
本機或主機端測試：會在執行版本的本機電腦上執行。在 Android 上通常是 JVM，因此速度飛快且穩定。以及 Robolectric 測試。
檢測設備測試
在模擬器或實體裝置上執行的測試需要進行一些佈建作業，等待裝置啟動或連線，以及其他會增加複雜度的作業。
您可以透過多種方式在 CI 中執行檢測設備測試：
- Gradle 管理的裝置可用來定義要使用的裝置 (例如「API 27 中的 Pixel 2 模擬器」)，並會處理裝置佈建作業。
- 大部分的持續整合系統都隨附第三方外掛程式 (也稱為「動作」、「整合」或「步驟」)，可處理 Android 模擬器。
- 將檢測設備測試委派給 Firebase Test Lab 等裝置設備。裝置設備採用高可靠性，可在模擬器或實體裝置上執行。
效能迴歸測試
如要監控應用程式效能，建議您使用基準程式庫。如要在開發期間自動化效能測試，實體裝置才能確保測試結果一致且實際可行。
執行基準測試可能需要較長時間，尤其是在進行基準測試的程式碼和使用者歷程時，更是如此。與其為每個合併的功能或修訂版本執行所有基準測試，請考慮將其做為定期維護版本 (例如夜間建構) 的一部分執行。
監控效能
您可以使用步數符合功能監控效能迴歸。步驟調整定義了先前建構結果的滾動式視窗，供您與目前版本進行比較。這種做法可將多個基準結果合併成一個迴歸專屬指標。您可以在迴歸測試期間套用步適調整功能來減少雜訊。
這樣可減少單一建構作業的基準時間緩慢情形發生，並再次正規化時，可能會出現偽陽性的情形。
測試涵蓋範圍迴歸檢查
「測試涵蓋範圍」指標可協助您和團隊判斷測試能否涵蓋變更。但不應是唯一的指標。常見的做法是設定迴歸檢查失敗，或在範圍低於基本分支版本時顯示警告。