Testlerinizi Gradle tarafından yönetilen cihazlarla ölçeklendirin

Gradle tarafından yönetilen cihazlar, otomatik araçlı testleriniz için tutarlılığı, performansı ve güvenilirliği artırır. 27 ve üzeri API düzeyleri için kullanılabilen bu özellik, projenizin Gradle dosyalarında sanal veya uzaktan fiziksel test cihazları yapılandırmanıza olanak tanır. Derleme sistemi, otomatik testlerinizi yürütürken bu cihazları tümüyle yönetmek, yani oluşturmak, dağıtmak ve ortadan kaldırmak için yapılandırmaları kullanır.

Bu özellik, Gradle'a yalnızca çalıştırdığınız testlerde değil, cihazların yaşam döngüsünde de görünürlük sağlayarak test deneyiminizin kalitesini aşağıdaki şekillerde iyileştirir:

  • Testlerinizin yürütüldüğünden emin olmak için cihazla ilgili sorunları ele alır
  • Sanal cihazlarda, cihazın başlatma süresini ve bellek kullanımını iyileştirmek ve testler arasında cihazları temiz bir duruma geri yüklemek için emülatör anlık görüntülerini kullanır
  • Test sonuçlarını önbelleğe alır ve yalnızca farklı sonuçlar sağlayabilecek testleri yeniden çalıştırır.
  • Yerel ve uzaktan test çalıştırmaları arasında testlerinizin yürütülmesi için tutarlı bir ortam sağlar

Gradle tarafından yönetilen sanal bir cihaz oluşturma

Modül düzeyindeki derleme dosyanızda, Gradle'ın uygulamanızı test etmek için kullanmasını istediğiniz sanal cihazı belirtebilirsiniz. Aşağıdaki kod örneği, Gradle tarafından yönetilen cihaz olarak API düzeyi 30'u çalıştıran Pixel 2 oluşturur.

Kotlin

android {
  testOptions {
    managedDevices {
      localDevices {
        create("pixel2api30") {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // Use only API levels 27 and higher.
          apiLevel = 30
          // To include Google services, use "google".
          systemImageSource = "aosp"
        }
      }
    }
  }
}

Modern

android {
  testOptions {
    managedDevices {
      localDevices {
        pixel2api30 {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // Use only API levels 27 and higher.
          apiLevel = 30
          // To include Google services, use "google".
          systemImageSource = "aosp"
        }
      }
    }
  }
}

Cihaz gruplarını tanımlayın

Testlerinizi farklı API seviyeleri ve form faktörleri gibi birden fazla cihaz yapılandırmasında ölçeklendirmenize yardımcı olması için, Gradle tarafından yönetilen birden fazla cihaz tanımlayabilir ve bunları adlandırılmış bir gruba ekleyebilirsiniz. Daha sonra Gradle, testlerinizi gruptaki tüm cihazlarda paralel olarak yürütebilir.

Aşağıdaki örnekte, phoneAndTablet adlı bir cihaz grubuna eklenmiş iki cihaz gösterilmektedir.

Kotlin

testOptions {
  managedDevices {
    localDevices {
      create("pixel2api29") { ... }
      create("nexus9api30") { ... }
    }
    groups {
      create("phoneAndTablet") {
        targetDevices.add(devices["pixel2api29"])
        targetDevices.add(devices["nexus9api30"])
      }
    }
  }
}

Modern

testOptions {
  managedDevices {
    localDevices {
      pixel2api29 { ... }
      nexus9api30 { ... }
    }
    groups {
      phoneAndTablet {
        targetDevices.add(devices.pixel2api29)
        targetDevices.add(devices.nexus9api30)
      }
    }
  }
}

Testlerinizi çalıştırın

Testlerinizi, yapılandırdığınız Gradle tarafından yönetilen cihazları kullanarak çalıştırmak için aşağıdaki komutu kullanın. device-name, Gradle derleme komut dosyanızda yapılandırdığınız cihazın adıdır (ör. pixel2api30) ve BuildVariant, test etmek istediğiniz uygulamanızın derleme varyantıdır.

Windows'da:

gradlew device-nameBuildVariantAndroidTest

Linux veya macOS'te:

./gradlew device-nameBuildVariantAndroidTest

Testlerinizi Gradle tarafından yönetilen bir cihaz grubunda çalıştırmak için aşağıdaki komutları kullanın.

Windows'da:

gradlew group-nameGroupBuildVariantAndroidTest

Linux veya macOS'te:

./gradlew group-nameGroupBuildVariantAndroidTest

Test çıkışı, test raporunu içeren bir HTML dosyasının yolunu içerir. Ayrıca, daha ayrıntılı analiz için IDE'de Çalıştır > Test Geçmişi'ni tıklayarak test sonuçlarını Android Studio'ya aktarabilirsiniz.

Test parçalamayı etkinleştir

Gradle tarafından yönetilen cihazlar test parçalamayı destekler. Bu özellik, test paketinizi paralel olarak çalışan kırıklar adı verilen bir dizi özdeş sanal cihaz örneği arasında bölmenize olanak tanır. Test parçalamayı kullanmak, ek hesaplama kaynakları pahasına genel test yürütme süresini azaltmaya yardımcı olabilir.

Belirli bir test çalıştırmasında kullanmak istediğiniz parça sayısını ayarlamak için gradle.properties dosyanızda aşağıdakileri ayarlayın:

android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>

Bu seçeneği kullanarak testlerinizi çalıştırırken, Gradle tarafından yönetilen cihazlar test çalıştırmasındaki her cihaz profili için belirttiğiniz parça sayısını sağlar. Örneğin, testlerinizi üç cihazdan oluşan bir cihaz grubuna dağıttıysanız ve numManagedDeviceShards değerini iki olarak ayarlarsanız Gradle tarafından yönetilen cihazlar test çalıştırmanız için toplam altı sanal cihaz sağlar.

Testleriniz tamamlandığında Gradle, test çalıştırmasında kullanılan her kırık için test sonuçlarını .proto dosyası şeklinde üretir.

Otomatik Test Cihazları Kullanın

Gradle tarafından yönetilen cihazlar, otomatik test cihazı (ATD) adı verilen bir tür emülatör cihazını destekler. Bu cihaz, izlemeli testlerinizi çalıştırırken CPU ve bellek kaynaklarını azaltmak için optimize edilmiştir. ATD'ler, çalışma zamanı performansını birkaç şekilde artırır:

  • Uygulamanızı test etmek için genellikle yararlı olmayan, önceden yüklenmiş uygulamaları kaldırın
  • Uygulamanızı test etmek için genellikle faydalı olmayan belirli arka plan hizmetlerini devre dışı bırakın
  • Donanım oluşturmayı devre dışı bırak

Başlamadan önce Android Emülatör'ü mevcut en son sürüme güncellediğinizden emin olun. Ardından, aşağıda gösterildiği gibi, modül düzeyindeki derleme dosyanızda Gradle tarafından yönetilen bir cihaz tanımlarken bir "-atd" görüntüsü belirtin:

Kotlin

android {
  testOptions {
    managedDevices {
      localDevices {
        create("pixel2api30") {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // ATDs currently support only API level 30.
          apiLevel = 30
          // You can also specify "google-atd" if you require Google Play Services.
          systemImageSource = "aosp-atd"
        }
      }
    }
  }
}

Modern

android {
  testOptions {
    managedDevices {
      localDevices {
        pixel2api30 {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // ATDs currently support only API level 30.
          apiLevel = 30
          // You can also specify "google-atd" if you require Google Play Services.
          systemImageSource = "aosp-atd"
        }
      }
    }
  }
}

Ayrıca, Gradle tarafından yönetilen diğer cihazlarda olduğu gibi cihaz grupları da oluşturabilirsiniz. Performans iyileştirmelerinden daha fazla yararlanmak için test paketinizin toplam test yürütme süresini azaltmak amacıyla ATD'leri test parçalama ile de kullanabilirsiniz.

ATD görüntülerinden neler kaldırılır?

ATD'ler, gözetimsiz modda çalışmaya ek olarak uygulamanızın kodunu test etmek için gerekli olmayan uygulama ve hizmetleri kaldırarak veya devre dışı bırakarak da performansı optimize eder. Aşağıdaki tabloda, ATD görüntülerinden kaldırdığımız veya devre dışı bıraktığımız bileşenlere genel bir bakış ve bunların neden yararlı olmayabileceğine dair açıklamalar yer almaktadır.

ATD görüntülerinden kaldırılanlar Otomatik testler çalıştırırken buna neden ihtiyacınız olmayabilir?
Google ürün uygulamaları:
  • Posta
  • Haritalar
  • Chrome
  • Mesajlar
  • Play Store ve diğerleri
Otomatik testleriniz diğer uygulamaların veya platformun düzgün çalışacağını varsayarak kendi uygulamanızın mantığına odaklanmalıdır.

Espresso-Intents ile giden amaçlarınızı eşleştirip doğrulayabilir ve hatta gerçek amaç yanıtları yerine saplama yanıtları sağlayabilirsiniz.

Uygulamalar ve hizmetleri ayarlama:
  • CarrierConfig
  • Acil Durum Bilgisi
  • OneTimeInitializer
  • PhotoTable (ekran koruyucular)
  • Provizyon
  • Ayarlar uygulaması
  • Depolama Yöneticisi
  • Telefon APN Yapılandırması
  • Duvar Kağıdı Kırpma Aracı
  • Duvar Kağıdı Seçici
Bu uygulamalar, son kullanıcılara platform ayarlarını değiştirmeleri, cihazlarını kurmaları veya cihaz depolama alanlarını yönetmeleri için bir GUI sunar. Bu işlem, genellikle uygulama düzeyinde otomatik test kapsamının dışındadır.


Not: Ayar sağlayıcısı, ATD resminde hâlâ mevcuttur.

Sistem Arayüzü Otomatik testleriniz diğer uygulamaların veya platformun düzgün çalışacağını varsayarak kendi uygulamanızın mantığına odaklanmalıdır.
AOSP uygulamaları ve hizmetleri:
  • Tarayıcı2
  • Takvim
  • Camera2
  • Kişiler
  • Dialer
  • Masa Saati
  • Galeri2
  • Latince
  • Launcher3HızlıAdım
  • Müzik
  • Hızlı Arama Kutusu
  • Ayar Zekası
Bu uygulamalar ve hizmetler genellikle uygulamanızın koduna yönelik otomatik testlerin kapsamı dışındadır.

Firebase Test Lab cihazlarını kullanma

Gradle tarafından yönetilen cihazları kullanırken otomatik araçlı testlerinizi Firebase Test Lab cihazlarında geniş ölçekte çalıştırabilirsiniz. Test Lab, testlerinizi hem fiziksel hem de sanal pek çok farklı Android cihazda eş zamanlı olarak çalıştırmanıza olanak tanır. Bu testler Google'ın uzak veri merkezlerinde yürütülür. Gradle tarafından yönetilen cihazların desteğiyle derleme sistemi, yapılandırmalarınıza göre bu Test Lab cihazlarında çalışan testleri tamamen yönetebilir.

Başlayın

Aşağıdaki adımlarda, Firebase Test Lab cihazlarını Gradle tarafından yönetilen cihazlarla nasıl kullanmaya başlayacağınız açıklanmaktadır. Bu adımlar, tüm geliştirme ortamları için geçerli olmayabilecek kullanıcı kimlik bilgilerini sağlamak için gcloud KSA'yı kullanır. İhtiyaçlarınız için hangi kimlik doğrulama işleminin kullanılacağı hakkında daha fazla bilgi edinmek istiyorsanız Uygulama Varsayılan Kimlik Bilgileri nasıl çalışır? bölümüne bakın.

  1. Firebase projesi oluşturmak için Firebase konsoluna gidin. Proje oluşturmak için Proje ekle'yi tıklayın ve ekrandaki talimatları uygulayın. Proje kimliğinizi unutmayın.

  2. Google Cloud KSA'yı yüklemek için gcloud CLI'ı yükleme sayfasındaki adımları uygulayın.

  3. Yerel ortamınızı yapılandırın.

    1. gcloud'daki Firebase projenize bağlayın:

      gcloud config set project FIREBASE_PROJECT_ID
      
    2. API erişimi için kullanıcı kimlik bilgilerinizin kullanımına yetki verin. Modül düzeyindeki derleme komut dosyasında DSL'yi kullanarak Gradle'a bir hizmet hesabı JSON dosyası ileterek yetkilendirme yapmanızı öneririz:

      Kotlin

      firebaseTestLab {
        ...
        serviceAccountCredentials.set(file(SERVICE_ACCOUNT_JSON_FILE))
      }
      

      Modern

      firebaseTestLab {
        ...
        serviceAccountCredentials = file(SERVICE_ACCOUNT_JSON_FILE)
      }
      

      Alternatif olarak aşağıdaki terminal komutunu kullanarak manuel olarak yetkilendirebilirsiniz:

      gcloud auth application-default login
      
    3. İsteğe bağlı: Firebase projenizi kota projesi olarak ekleyin. Bu adım, yalnızca Test Lab için ücretsiz kotayı aşarsanız gereklidir.

      gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID
      
  4. Gerekli API'leri etkinleştirin.

    Google Developers Console API Kitaplığı sayfasında, bu API adlarını konsolun üst kısmındaki arama kutusuna yazıp her API'nin genel bakış sayfasındaki API'yi Etkinleştir seçeneğini tıklayarak Cloud Testing API ve Cloud Tool Results API'yi etkinleştirin.

  5. Android projenizi yapılandırın.

    1. Firebase Test Lab eklentisini üst düzey derleme komut dosyasına ekleyin:

      Kotlin

      plugins {
        ...
        id("com.google.firebase.testlab") version "0.0.1-alpha05" apply false
      }
      

      Modern

      plugins {
        ...
        id 'com.google.firebase.testlab' version '0.0.1-alpha05' apply false
      }
      
    2. gradle.properties dosyasında özel cihaz türlerini etkinleştir:

      android.experimental.testOptions.managedDevices.customDevice=true
      
    3. Firebase Test Lab eklentisini modül düzeyindeki derleme komut dosyasına ekleyin:

      Kotlin

      plugins {
       ...
       id "com.google.firebase.testlab"
      }
      

      Modern

      plugins {
       ...
       id 'com.google.firebase.testlab'
      }
      

Test Lab cihazı belirtin

Gradle'ın modül düzeyindeki derleme komut dosyasında uygulamanızı test etmek için kullanacağı bir Firebase Test Lab cihazı belirtebilirsiniz. Aşağıdaki kod örneği, ftlDevice adlı Gradle tarafından yönetilen Test Lab cihazı olarak API düzeyi 30'u çalıştıran bir Pixel 3 oluşturur. firebaseTestLab {} blokunu, com.google.firebase.testlab eklentisini modülünüze uyguladığınızda kullanılabilir.

Kotlin

firebaseTestLab {
  managedDevices {
    create("ftlDevice") {
      device = "Pixel3"
      apiLevel = 30
    }
  }
  ...
}

Modern

firebaseTestLab {
  managedDevices {
    ftlDevice {
      device = "Pixel3"
      apiLevel = 30
    }
  }
  ...
}

Firebase Test Lab cihazları dahil, Gradle tarafından yönetilen bir cihaz grubu tanımlamak için Cihaz gruplarını tanımlama konusuna bakın.

Testlerinizi çalıştırmak için Gradle tarafından yönetilen diğer cihazları çalıştırmak için kullanılan komutları kullanın. Gradle'ın testleri paralel olarak çalıştırmadığını veya Test Lab cihazları için diğer Google Cloud CLI yapılandırmalarını desteklemediğini unutmayın.

Akıllı parçalama ile test çalıştırmalarını optimize edin

Gradle tarafından yönetilen Test Lab cihazlarında testler, akıllı parçalamayı destekler. Akıllı parçalama, testlerinizi parçalara otomatik olarak dağıtır. Böylece her parça yaklaşık olarak aynı süre boyunca çalışır. Böylece, manuel ayırma çabası ve genel test çalıştırma süresi azalır. Akıllı parçalama, testleri optimum şekilde dağıtmak için test geçmişinizi veya testlerinizin daha önce çalıştırılmasının ne kadar sürdüğüyle ilgili bilgileri kullanır. Akıllı parçalamayı kullanmak için Firebase Test Lab için Gradle eklentisinin 0.0.1-alpha05 sürümüne ihtiyacınız olduğunu unutmayın.

Akıllı parçalamayı etkinleştirmek için her bir parçadaki testlerin süresini belirtin. Testler tamamlanmadan önce parçaların iptal edilmesini önlemek için, hedef parça süresini en az beş dakika timeoutMinutes olacak şekilde ayarlamanız gerekir.

firebaseTestLab {
  ...
  testOptions {
    targetedShardDurationMinutes = 2
  }
}

Daha fazla bilgi edinmek için Firebase Test Lab cihaz DSL seçenekleri hakkında bilgi edinin.

Test Lab cihazları için DSL güncellendi

Test çalıştırmalarınızı özelleştirmenize veya hâlihazırda kullanıyor olabileceğiniz diğer çözümlerden geçişe yardımcı olmak için yapılandırabileceğiniz daha fazla DSL seçeneği vardır. Bu seçeneklerden bazılarını aşağıdaki kod snippet'inde açıklandığı şekilde inceleyin.

firebaseTestLab {
  ...

  /**
   * A path to a JSON file that contains service account credentials to access to
   * a Firebase Test Lab project.
   */
  serviceAccountCredentials.set(file("your_service_account_credentials.json"))


  testOptions {
    fixture {
      /**
       * Whether to grant permissions on the device before tests begin.
       * Available options are "all" or "none".
       *
       * Default value is "all".
       */
      grantedPermissions = "all"

      /**
       * Map of files to push to the device before starting the test.
       *
       * The key is the location on the device.
       * The value is the location of the file, either local or in Google Cloud.
       */
      extraDeviceFiles["/sdcard/dir1/file1.txt"] = "local/file.txt"
      extraDeviceFiles["/sdcard/dir2/file2.txt"] = "gs://bucket/file.jpg"

      /**
       * The name of the network traffic profile.
       *
       * Specifies network conditions to emulate when running tests.
       *
       * Default value is empty.
       */
      networkProfile = "LTE"
    }

    execution {
      /**
       * The maximum time to run the test execution before cancellation,
       * measured in minutes. Does not include the setup or teardown of device,
       * and is handled server-side.
       *
       * The maximum possible testing time is 45 minutes on physical devices
       * and 60 minutes on virtual devices.
       *
       * Defaults to 15 minutes.
       */
       timeoutMinutes = 30

      /**
       * Number of times the test should be rerun if tests fail.
       * The number of times a test execution should be retried if one
       * or more of its test cases fail.
       *
       * The max number of times is 10.
       *
       * The default number of times is 0.
       */
      maxTestReruns = 2

      /**
       * Ensures only a single attempt is made for each execution if
       * an infrastructure issue occurs. This doesn't affect `maxTestReruns`.
       * Normally, two or more attempts are made by Firebase Test Lab if a
       * potential infrastructure issue is detected. This is best enabled for
       * latency sensitive workloads. The number of execution failures might be
       * significantly greater with `failFast` enabled.
       *
       * Defaults to false.
       */
      failFast = false

      /**
       * The number of shards to split the tests across.
       *
       * Default to 0 for no sharding.
       */
      numUniformShards = 20
    }

    /**
     * For smart sharding, the target length of time each shard should takes in
     * minutes. Maxes out at 50 shards for physical devices and 100 shards for
     * virtual devices.
     *
     * Only one of numUniformShards or targetedShardDurationMinutes can be set.
     *
     * Defaults to 0 for no smart sharding.
     */
     targetedShardDurationMinutes = 15
    }

    results {
      /**
       * The name of the Google storage bucket to store the test results in.
       *
       * If left unspecified, the default bucket is used.
       *
       * Please refer to Firebase Test Lab permissions for required permissions
       * for using the bucket.
       */
      cloudStorageBucket = "bucketLocationName"

      /**
       * Name of test results for the Firebase console history list.
       * All tests results with the same history name are grouped
       * together in the Firebase console in a time-ordered test history list.
       *
       * Defaults to the application label in the APK manifest in Flank/Fladle.
       */
      resultsHistoryName = "application-history"

      /**
       * List of paths to copy from the test device's storage to the test
       * results folder. These must be absolute paths under /sdcard or
       * /data/local/tmp.
       */
      directoriesToPull.addAll(
        "/sdcard/path/to/something"
      )

      /**
       * Whether to enable video recording during the test.
       *
       * Disabled by default.
       */
      recordVideo = false

      /**
       * Whether to enable performance metrics. If enabled, monitors and records
       * performance metrics such as CPU, memory, and network usage.
       *
       * Defaults to false.
       */
      performanceMetrics = true
  }
}