Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Aşağıda CI sisteminizde kullanmak isteyebileceğiniz bazı tipik otomasyon biçimleri verilmiştir.
Temel işler
Derleme: Sıfırdan bir proje derleyerek yeni değişikliklerin doğru şekilde derlenmesini ve tüm kitaplıklar ile araçların birbiriyle uyumlu olmasını sağlarsınız.
Lint veya stil kontrolleri: Bu, isteğe bağlı ancak önerilen bir adımdır. Stil kurallarını zorunlu kıldığınızda ve statik analiz gerçekleştirdiğinizde kod incelemeleri daha kısa ve öz olabilir.
Yerel testler veya ana makine tarafı testler: Derlemeyi gerçekleştiren yerel makinede çalıştırılır. Android'de bu genellikle JVM olduğundan hızlı ve
güvenilirdir. Robofactric testleri de gerçekleştirilir.
CI'da aracılı testler çalıştırmak için birden fazla seçenek vardır:
Gradle Tarafından Yönetilen Cihazlar, kullanılacak cihazları tanımlamak için kullanılabilir (örneğin, "API 27'deki Pixel 2 emülatörü") ve cihaz temel hazırlığını gerçekleştirir.
Çoğu CI sistemi, Android emülatörlerini işlemek için üçüncü taraf bir eklenti ("eylem", "entegrasyon" veya "adım" olarak da adlandırılır) ile birlikte gelir.
Araçlı testler için Firebase Test Lab gibi bir cihaz çiftliğine yetki verin.
Cihaz çiftlikleri yüksek güvenilirlik özelliklerinden dolayı kullanılır ve emülatörlerde veya fiziksel cihazlarda çalışabilir.
Performans regresyon testleri
Uygulama performansını izlemek için karşılaştırma kitaplıklarını kullanmanızı öneririz.
Geliştirme sırasında performans testlerinin otomatikleştirilmesi, tutarlı ve gerçekçi test sonuçları elde etmek için fiziksel cihazlar gerektirir.
Karşılaştırmaları çalıştırmak, özellikle de karşılaştırma yaptığınız kod ve kullanıcı yolculukları kapsamının geniş olduğu durumlarda uzun sürebilir. Birleştirilen her özellik veya kaydetme için tüm karşılaştırmaları çalıştırmak yerine, bunları düzenli olarak planlanmış bakım derlemesi (ör. gecelik derleme) kapsamında yürütmeyi deneyin.
Performansı izleme
Adım sığdırmayı kullanarak performans regresyonlarını izleyebilirsiniz. Adım sığdırma, önceki derleme sonuçlarının geçerli derlemeyle karşılaştırıldığı bir kayan zaman aralığını tanımlar. Bu yaklaşımda çeşitli karşılaştırma sonuçları, regresyona özel tek bir metrikte birleştirilir. Regresyon testi sırasında gürültüyü azaltmak için adım sığdırma uygulayabilirsiniz.
Bu, tek bir derleme için karşılaştırma süreleri yavaş olduğunda oluşabilecek yanlış pozitifleri azaltır ve ardından tekrar normalleştirir.
Kapsam regresyon kontrollerini test et
Test kapsamı, sizin ve ekibinizin testlerin bir değişikliği yeterince kapsayıp kapsamadığına karar vermenize yardımcı olabilecek bir metriktir. Ancak, tek gösterge bu olmamalıdır. Yaygın bir uygulama olarak, kapsam temel dala göre düşüş gösterdiğinde başarısız olan veya bir uyarı gösteren bir regresyon kontrolü ayarlanır.
Bu sayfadaki içerik ve kod örnekleri, İçerik Lisansı sayfasında açıklanan lisanslara tabidir. Java ve OpenJDK, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-27 UTC.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 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."]]
