Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Berikut adalah beberapa bentuk otomatisasi umum yang mungkin ingin Anda gunakan dalam
sistem CI.
Tugas dasar
Build:Dengan mem-build project dari awal, Anda memastikan bahwa perubahan
baru dikompilasi dengan benar dan semua library serta alat saling
kompatibel.
Pemeriksaan lint atau gaya: Ini adalah langkah opsional tetapi direkomendasikan. Saat Anda menerapkan aturan gaya dan melakukan analisis statis, peninjauan kode dapat menjadi lebih ringkas dan terfokus.
Pengujian lokal atau sisi host: Pengujian ini berjalan di mesin lokal yang
menjalankan build. Di Android, biasanya ini adalah JVM, sehingga cepat dan
andal. Pengujian ini juga mencakup uji Robolectric.
Ada beberapa opsi untuk menjalankan uji instrumentasi pada CI:
Perangkat yang Dikelola Gradle dapat digunakan untuk menentukan perangkat yang akan digunakan (misalnya "emulator Pixel 2 di API 27") dan menangani penyediaan perangkat.
Sebagian besar sistem CI dilengkapi dengan plugin pihak ketiga (juga disebut "tindakan", "integrasi", atau "langkah") untuk menangani emulator Android.
Delegasikan pengujian berinstrumen ke farm perangkat seperti Firebase Test Lab.
Farmasi perangkat digunakan karena keandalannya yang tinggi dan dapat berjalan di emulator
atau perangkat fisik.
Pengujian regresi performa
Untuk memantau performa aplikasi, sebaiknya gunakan library benchmark.
Otomatisasi uji performa selama pengembangan memerlukan perangkat fisik untuk
memastikan hasil pengujian yang konsisten dan realistis.
Menjalankan benchmark dapat memerlukan waktu lama, terutama jika Anda memiliki cakupan
kode dan perjalanan pengguna yang tinggi yang Anda tolok ukurnya. Daripada menjalankan semua
benchmark untuk setiap fitur atau commit gabungan, pertimbangkan untuk menjalankannya sebagai bagian
dari build pemeliharaan terjadwal secara rutin, seperti build setiap malam.
Memantau performa
Anda dapat memantau regresi performa menggunakan pengaturan langkah. Pengepasan
langkah menentukan jendela berkelanjutan dari hasil build sebelumnya yang Anda bandingkan
dengan build saat ini. Pendekatan ini menggabungkan beberapa hasil benchmark menjadi
satu metrik khusus regresi. Anda dapat menerapkan penyesuaian langkah untuk mengurangi derau
selama pengujian regresi.
Tindakan ini akan mengurangi terjadinya positif palsu (PP) yang dapat terjadi saat waktu
benchmark lambat untuk satu build, lalu melakukan normalisasi lagi.
Menguji pemeriksaan regresi cakupan
Cakupan pengujian adalah metrik yang dapat membantu Anda dan tim memutuskan apakah pengujian sudah cukup mencakup perubahan. Namun, seharusnya ini bukan satu-satunya indikator. Salah satu praktik yang umum dilakukan adalah menyiapkan pemeriksaan regresi yang gagal atau menampilkan peringatan saat cakupan turun relatif terhadap cabang dasar.
Konten dan contoh kode di halaman ini tunduk kepada lisensi yang dijelaskan dalam Lisensi Konten. Java dan OpenJDK adalah merek dagang atau merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-07-27 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-07-27 UTC."],[],[],null,["# Types of CI automation\n\nThe following are some typical forms of automation that you might like to use in\nyour CI system.\n\nBasic jobs\n----------\n\n- **Build:** By building a project from scratch, you make sure that the new\n changes compile correctly and that all libraries and tools are compatible with\n each other.\n\n- **Lint or style checks:** This is an optional but recommended step. When you\n enforce style rules and perform [static analysis](/studio/write/lint), code reviews can be more\n concise and focused.\n\n- **[Local, or host-side tests](/training/testing/local-tests):** They run on the local machine that\n performs the build. On Android this is usually the JVM, so they're fast and\n reliable. They include Robolectric tests as well.\n\nInstrumented tests\n------------------\n\n[Tests that run on emulators or physical devices](/training/testing/instrumented-tests) require some provisioning,\nwaiting for devices to boot or be connected and other operations that add\ncomplexity.\n\nThere are multiple options to run instrumented tests on CI:\n\n- [Gradle Managed Devices](/studio/test/gradle-managed-devices) can be used to define the devices to use (for example \"Pixel 2 emulator on API 27\") and it handles device provisioning.\n- Most CI systems come with a third-party plugin (also called \"action\", \"integration\" or \"step\") to handle Android emulators.\n- Delegate instrumented tests to a device farm such as [Firebase Test Lab](https://firebase.google.com/docs/test-lab). Device farms are used for their high reliability and they can run on emulators or physical devices.\n\nPerformance regression tests\n----------------------------\n\nTo monitor app performance we recommend using the [benchmark libraries](/topic/performance/benchmarking/benchmarking-overview).\nAutomation of performance tests during development requires physical devices to\nensure consistent and realistic test results.\n\nRunning benchmarks can take a long time, especially when you have high coverage\nof code and user journeys that you are benchmarking. Instead of running all\nbenchmarks for every merged feature or commit, consider executing them as part\nof a regularly scheduled maintenance build, such as a nightly build.\n\n### Monitoring performance\n\nYou can monitor performance regressions using [step fitting](https://medium.com/androiddevelopers/fighting-regressions-with-benchmarks-in-ci-6ea9a14b5c71). Step\nfitting defines a rolling window of previous build results which you compare\nagainst the current build. This approach combines several benchmark results into\none regression-specific metric. You can apply step fitting to reduce noise\nduring regression testing.\n\nThis reduces the occurrence of false positives which can occur when benchmark\ntimes are slow for a single build and then normalize again.\n\nTest coverage regression checks\n-------------------------------\n\n[Test coverage](/studio/test/test-in-android-studio#view_test_coverage) is a metric that can help you and your team decide if tests\nsufficiently cover a change. However, it shouldn't be the only indicator. It is\ncommon practice to set up a regression check that fails or shows a warning when\nthe coverage goes down relative to the base branch.\n| **Note:** The coverage generated by an instrumentation test is different from that of a unit test as bigger tests typically make fewer assertions per line of tested code and their goal is different. Consider keeping two separate coverage metrics."]]
