Derleme tarafından yönetilen cihazlar, otomatik enstrümanlı testlerinizin tutarlılığını, performansını ve güvenilirliğini artırır. API düzeyi 27 ve üzeri için 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şlatma 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 olarak oluşturulan ve 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, derleme tarafından yönetilen bir cihaz olarak API seviyesi 30'u çalıştıran bir 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ı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"]) } } } }
Modern
testOptions { managedDevices { localDevices { pixel2api29 { ... } nexus9api30 { ... } } groups { phoneAndTablet { targetDevices.add(devices.pixel2api29) targetDevices.add(devices.nexus9api30) } } } }
Testlerinizi çalıştırma
Testlerinizi yapılandırdığınız derleme tarafından yönetilen cihazları kullanarak ç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 değişkenidir (ö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 işlemi 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ümantasyonlu 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" } } } } }
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" } } } } }
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 paketi toplam test yürütme süresini azaltmak amacıyla test parçalama ile ATD'leri de kullanabilirsiniz.
ATD görüntülerinden neler 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ış ve bunların neden yararlı olmayabileceğine dair açıklamalar yer almaktadır.
| ATD görüntülerinde 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ı varsayarak 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ı varsayarak 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
Derleme tarafından yönetilen cihazları kullanırken Firebase Test Lab cihazlarında otomatik enstrümanlı 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)) }
Modern
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 Lab'in ü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. Bunu yapmak için bu API adlarını konsolun üst kısmındaki arama kutusuna yazın ve ardından 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 }
Modern
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
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 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ği, ftlDevice adlı derleme tarafından yönetilen bir Test Lab cihazı olarak API düzeyi 30'u çalıştıran bir Pixel 3 oluşturur. 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 } } ... }
Modern
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 derleme 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 KSA 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'in 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ı 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 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 } }