Derleme tarafından yönetilen cihazlar, otomatik olarak izlenen testlerinizin tutarlılığını, performansını ve güvenilirliğini artırır. API düzeyi 27 ve sonraki sürümlerde kullanılabilen bu özellik, projenizin Gradle dosyalarında sanal veya uzaktan fiziksel test cihazları yapılandırmanıza olanak tanır. Android Gradle eklentisi, otomatik testlerinizi yürütürken bu cihazları tam olarak yönetmek (yani oluşturmak, dağıtmak ve kaldırmak) için yapılandırmaları kullanır.
Bu özellik, Android Gradle eklentisinin yalnızca çalıştırdığınız testleri değil, cihazların yaşam döngüsünü de görmesini sağlar. Böylece test deneyiminizin kalitesini aşağıdaki şekillerde iyileştirir:
- Testlerinizin yürütülmesini sağlamak için cihazla ilgili sorunları ele alır.
- Sanal cihazlarda, cihazın başlatılma süresini ve bellek kullanımını iyileştirmek için emülatör anlık görüntülerini kullanır ve testler arasında cihazları temiz bir duruma geri yükler.
- Test sonuçlarını önbelleğe alır ve yalnızca farklı sonuçlar verebilecek testleri yeniden çalıştırır.
- Yerel ve uzak test çalıştırmaları arasında testlerinizi çalıştırmak için tutarlı bir ortam sağlar.
Sanal, derleme tarafından yönetilen bir cihaz oluşturma
Modül düzeyindeki derleme dosyanızda uygulamanızı test etmek için kullanmak istediğiniz bir sanal cihaz belirtebilirsiniz. Aşağıdaki kod örneği, API seviyesi 30'u çalıştıran bir Pixel 2'yi derleme tarafından yönetilen cihaz olarak 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" } } } } }
Groovy
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ımlama
Testlerinizi farklı API düzeyleri ve form faktörleri gibi birden fazla cihaz yapılandırmasında ölçeklendirmenize yardımcı olmak için derleme tarafından yönetilen birden fazla cihaz tanımlayabilir ve bunları adlandırılmış bir gruba ekleyebilirsiniz. Android Gradle eklentisi daha sonra testlerinizi gruptaki tüm cihazlarda paralel olarak çalıştırabilir.
Aşağıdaki örnekte, phoneAndTablet adlı bir cihaz grubuna eklenen iki cihaz gösterilmektedir.
Kotlin
testOptions { managedDevices { localDevices { create("pixel2api29") { ... } create("nexus9api30") { ... } } groups { create("phoneAndTablet") { targetDevices.add(devices["pixel2api29"]) targetDevices.add(devices["nexus9api30"]) } } } }
Groovy
testOptions { managedDevices { localDevices { pixel2api29 { ... } nexus9api30 { ... } } groups { phoneAndTablet { targetDevices.add(devices.pixel2api29) targetDevices.add(devices.nexus9api30) } } } }
Testlerinizi çalıştırma
Yapılandırmış olduğunuz derleme tarafından yönetilen cihazları kullanarak testlerinizi çalıştırmak için aşağıdaki komutu kullanın. device-name, Gradle derleme komut dosyanızda (ör. pixel2api30) yapılandırdığınız cihazın adıdır. BuildVariant ise test etmek istediğiniz uygulamanızın derleme varyantıdır (ör. Debug).
Linux ve macOS
./gradlew device-nameBuildVariantAndroidTest
Windows
gradlew device-nameBuildVariantAndroidTest
Testlerinizi derleme tarafından yönetilen cihazlardan oluşan bir grupta çalıştırmak için aşağıdaki komutu kullanın.
Linux ve macOS
./gradlew group-nameGroupBuildVariantAndroidTest
./gradlew group-nameGroupBuildVariantAndroidTest
Windows
gradlew group-nameGroupBuildVariantAndroidTest
Test çıktısında, test raporunun bulunduğu bir HTML dosyasının yolu yer alır. Ayrıca, IDE'de Çalıştır > Test Geçmişi'ni tıklayarak test sonuçlarını daha ayrıntılı analiz için Android Studio'ya aktarabilirsiniz.
Test parçalama özelliğini etkinleştirme
Derleme tarafından yönetilen cihazlar, test paketinizi paralel olarak çalışan parçalar adı verilen bir dizi özdeş sanal cihaz örneğine bölmenize olanak tanıyan test parçalama özelliğini destekler. Test parçalama kullanmak, ek işlem kaynakları maliyetiyle 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>
Testlerinizi bu seçeneği kullanarak çalıştırdığınızda, derleme 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 üç cihazlık bir cihaz grubuna dağıttıysanız ve numManagedDeviceShards değerini iki olarak ayarladıysanız derleme 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 parça için test sonuçlarını .proto dosyasında verir.
Otomatik test cihazlarını kullanma
Derleme tarafından yönetilen cihazlar, enstrümanlı testlerinizi çalıştırırken CPU ve bellek kaynaklarını azaltmak için optimize edilmiş, Otomatik Test Cihazı (ATD) adı verilen bir tür emülatör cihazı destekler. ATD'ler, çalışma zamanı performansını birkaç şekilde iyileştirir:
- Genellikle uygulamanızı test etmek için yararlı olmayan önceden yüklenmiş uygulamaları kaldırma
- Genellikle uygulamanızı test etmek için yararlı olmayan belirli arka plan hizmetlerini devre dışı bırakma
- Donanım oluşturmayı devre dışı bırakma
Başlamadan önce Android Emulator'ı mevcut en son sürüme güncellediğinizden emin olun. Ardından, modül düzeyindeki derleme dosyanızda derleme tarafından yönetilen bir cihazı tanımlarken aşağıdaki örnekte gösterildiği gibi bir "-atd" resmi 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" } } } } }
Groovy
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" } } } } }
Diğer derleme tarafından yönetilen cihazlarda olduğu gibi cihaz grupları da oluşturabilirsiniz. Performans iyileştirmelerinden daha fazla yararlanmak için test paketinize ait toplam test yürütme süresini azaltmak amacıyla test parçalama ile birlikte ATD'leri de kullanabilirsiniz.
ATD görüntülerinden hangi bilgiler kaldırılır?
ATD'ler, başsız modda çalışmanın yanı sıra uygulamanızın kodunu test etmek için genellikle gerekli olmayan uygulama ve hizmetleri kaldırarak veya devre dışı bırakarak performansı da optimize eder. Aşağıdaki tabloda, ATD resimlerinde kaldırdığımız veya devre dışı bıraktığımız bileşenlere genel bir bakış sunulmakta ve bunların neden yararlı olmayabileceği açıklanmaktadır.
| ATD görüntülerinden kaldırılanlar | Otomatik testler çalıştırırken bu özelliğe neden ihtiyacınız olmayabilir? |
|---|---|
Google ürün uygulamaları:
|
Otomatik testleriniz, diğer uygulamaların veya platformun doğru şekilde çalışacağını varsayarken kendi uygulamanızın mantığına odaklanmalıdır.
Espresso-Intents ile giden amaçlarınızı eşleştirebilir ve doğrulayabilir, hatta gerçek amaç yanıtları yerine sahte yanıtlar sağlayabilirsiniz. |
Ayarlar uygulamaları ve hizmetleri:
|
Bu uygulamalar, son kullanıcıların platform ayarlarını değiştirmesi, cihazlarını kurması veya cihaz depolama alanını yönetmesi için bir GUI sunar. Bu genellikle uygulama düzeyinde otomatik testin kapsamı dışındadır.
|
| SystemUI | Otomatik testleriniz, diğer uygulamaların veya platformun doğru şekilde çalışacağını varsayarken kendi uygulamanızın mantığına odaklanmalıdır. |
AOSP uygulamaları ve hizmetleri:
|
Bu uygulamalar ve hizmetler genellikle uygulamanızın koduna yönelik otomatik testlerin kapsamı dışındadır. |
Firebase Test Lab cihazlarını kullanma
Build tarafından yönetilen cihazları kullanırken Firebase Test Lab cihazlarında otomatik enstrümantasyon testlerinizi büyük ölçekte çalıştırabilirsiniz. Test Lab, hem fiziksel hem de sanal olmak üzere çok çeşitli Android cihazlarda testlerinizi aynı anda çalıştırmanıza olanak tanır. Bu testler, uzak Google veri merkezlerinde çalışır. Derleme 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 tam olarak yönetebilir.
Başlayın
Aşağıdaki adımlarda, derleme tarafından yönetilen cihazlarla Firebase Test Lab cihazlarını kullanmaya nasıl başlayacağınız açıklanmaktadır. Bu adımlarda, kullanıcı kimlik bilgilerini sağlamak için gcloud CLI kullanılır. Bu kimlik bilgileri tüm geliştirme ortamları için geçerli olmayabilir. İhtiyaçlarınız için hangi kimlik doğrulama sürecini kullanacağınız hakkında daha fazla bilgi edinmek için Uygulama Varsayılan Kimlik Bilgileri nasıl çalışır? başlıklı makaleyi inceleyin.
Firebase projesi oluşturmak için Firebase konsoluna gidin. Proje ekle'yi tıklayın ve proje oluşturmak için ekrandaki istemleri uygulayın. Proje kimliğinizi unutmayın.
Google Cloud KSA'yı yüklemek için gcloud CLI'yi yükleme başlıklı makaledeki adımları uygulayın.
Yerel ortamınızı yapılandırın.
gcloud'da Firebase projenize bağlantı oluşturun:
gcloud config set project FIREBASE_PROJECT_ID
API erişimi için kullanıcı kimlik bilgilerinizin kullanılmasına izin verin. Modül düzeyindeki derleme komut dosyasında DSL'yi kullanarak Gradle'a hizmet hesabı JSON dosyası ileterek yetkilendirme yapmanızı öneririz:
Kotlin
firebaseTestLab { ... serviceAccountCredentials.set(file(SERVICE_ACCOUNT_JSON_FILE)) }
Groovy
firebaseTestLab { ... serviceAccountCredentials = file(SERVICE_ACCOUNT_JSON_FILE) }
Alternatif olarak, aşağıdaki terminal komutunu kullanarak manuel olarak yetkilendirebilirsiniz:
gcloud auth application-default login
İsteğe bağlı: Firebase projenizi kota projesi olarak ekleyin. Bu adım yalnızca Test Laboratuvarı'nın ücretsiz kotasını aşarsanız gereklidir.
gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID
Gerekli API'leri etkinleştirin.
Google Developers Console API Kitaplığı sayfasında, Cloud Testing API ve Cloud Tool Results API'yi etkinleştirin. Bunun için bu API adlarını konsolun üst kısmındaki arama kutusuna yazın ve her API'nin genel bakış sayfasında API'yi Etkinleştir'i tıklayın.
Android projenizi yapılandırın.
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 }
Groovy
plugins { ... id 'com.google.firebase.testlab' version '0.0.1-alpha05' apply false }
gradle.propertiesdosyasında özel cihaz türlerini etkinleştirin:android.experimental.testOptions.managedDevices.customDevice=true
Modül düzeyindeki derleme komut dosyasına Firebase Test Lab eklentisini ekleyin:
Kotlin
plugins { ... id "com.google.firebase.testlab" }
Groovy
plugins { ... id 'com.google.firebase.testlab' }
Test laboratuvarı cihazı belirtme
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ğinde, ftlDevice adlı derleme tarafından yönetilen bir Test Lab cihazı olarak API düzeyi 30'u çalıştıran bir Pixel 3 oluşturuluyor. firebaseTestLab {} bloğu, modülünüze com.google.firebase.testlab eklentisini uyguladığınızda kullanılabilir.
Kotlin
firebaseTestLab { managedDevices { create("ftlDevice") { device = "Pixel3" apiLevel = 30 } } ... }
Groovy
firebaseTestLab { managedDevices { ftlDevice { device = "Pixel3" apiLevel = 30 } } ... }
Firebase Test Lab cihazları da dahil olmak üzere derleme tarafından yönetilen cihazlardan oluşan bir grubu tanımlamak için Cihaz gruplarını tanımlama başlıklı makaleyi inceleyin.
Testlerinizi çalıştırmak için diğer derleme tarafından yönetilen cihazları çalıştırmak için kullanılan komutların aynısını 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 etme
Derleme tarafından yönetilen Test Lab cihazlarında test etme, akıllı parçalama özelliğini destekler. Akıllı parçalama, testlerinizi parçalar arasında otomatik olarak dağıtır. Böylece her parça yaklaşık olarak aynı süre boyunca çalışır. Bu sayede manuel ayırma çabaları ve genel test çalıştırma süresi azalır. Akıllı parçalama, testleri en iyi şekilde dağıtmak için test geçmişinizi veya testlerinizin daha önce ne kadar sürdüğüne dair bilgileri kullanır. Akıllı parçalama özelliğini kullanmak için Firebase Test Lab'e yönelik Gradle eklentisinin 0.0.1-alpha05 sürümüne ihtiyacınız olduğunu unutmayın.
Akıllı parçalama özelliğini etkinleştirmek için her parçadaki testlerin ne kadar süreceğini belirtin. Parçaların testler tamamlanmadan önce iptal edilmesini önlemek için hedef parça süresini timeoutMinutes değerinden en az beş dakika daha kısa 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 halihazırda kullandığınız diğer çözümlerden geçiş yapmanıza yardımcı olacak daha fazla DSL seçeneği vardır. Bu seçeneklerden bazılarını aşağıdaki kod snippet'inde açıklandığı şekilde görebilirsiniz.
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. */ 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 } }