Gradle tarafından yönetilen cihazlar, otomatik araçlı testleriniz olabilir. Bu özellik, API düzeyleri 27 ve sanal veya uzaktan fiziksel test cihazlarını yapılandırmanızı projelerinin Gradle dosyalarını tarar. Derleme sistemi, bu yapılandırmaların tam olarak ekibinizin bu cihazları yönetmesi, dağıtması ve ortadan kaldırması otomatik testlerden yararlanır.
Bu özellik, Gradle'ın yalnızca yürüttüğünüz testlerle değil, aynı zamanda cihazların da yaşam döngüsünü takip eder. Böylece, aşağıdaki şekillerde test edebilirsiniz:
- Testlerinizin yürütülmesini sağlamak için cihazla ilgili sorunları ele alır
- Sanal cihazlarda cihaz başlatma süresini iyileştirmek için emülatör anlık görüntülerinden yararlanır ve bellek kullanımını artırır ve cihazları testler arasında temiz bir duruma getirir.
- Test sonuçlarını önbelleğe alır ve yalnızca farklı sağlama olasılığı olan testleri tekrar çalıştırır sonuç
- Yerel ve harici kaynaklar arasında testlerinizi çalıştırmanız için tutarlı bir ortam sağlar uzaktan test çalıştırmaları
Gradle tarafından yönetilen sanal bir cihaz oluşturma
Gradle'ın uygulamanızı test etmek için kullanmasını istediğiniz bir sanal cihaz uygulamanız gerekir. Aşağıdaki kod örneği Pixel 2 oluşturur Gradle tarafından yönetilen bir cihaz olarak API düzeyi 30'u çalıştırma.
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"
}
}
}
}
}
Eski
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 birden fazla cihaz yapılandırmasında ölçeklendirmenize yardımcı olması için (ör. ve form faktörlerini kullanarak Gradle tarafından yönetilen birden fazla cihazları adlandırılmış bir gruba ekleyebiliriz. Böylece Gradle, testlerinizi paralel olarak, gruptaki tüm cihazlar
Aşağıdaki örnekte,
phoneAndTablet
Kotlin
testOptions {
managedDevices {
localDevices {
create("pixel2api29") { ... }
create("nexus9api30") { ... }
}
groups {
create("phoneAndTablet") {
targetDevices.add(devices["pixel2api29"])
targetDevices.add(devices["nexus9api30"])
}
}
}
}
Eski
testOptions {
managedDevices {
localDevices {
pixel2api29 { ... }
nexus9api30 { ... }
}
groups {
phoneAndTablet {
targetDevices.add(devices.pixel2api29)
targetDevices.add(devices.nexus9api30)
}
}
}
}
Testlerinizi yapın
Testlerinizi, Gradle tarafından yönetilen, yapılandırdığınız cihazları kullanarak çalıştırmak için
aşağıdaki komuttan yararlanabilirsiniz. device-name, yapılandırdığınız cihazın adıdır
Gradle derleme komut dosyanız (pixel2api30 gibi) ve BuildVariant,
uygulamanızın test etmek istediğiniz varyantını oluşturun.
Windows'da:
gradlew device-nameBuildVariantAndroidTest
Linux veya macOS'te:
./gradlew device-nameBuildVariantAndroidTest
Testlerinizi Gradle tarafından yönetilen bir grup üzerinde çalıştırmak için komutudur.
Windows'da:
gradlew group-nameGroupBuildVariantAndroidTest
Linux veya macOS'te:
./gradlew group-nameGroupBuildVariantAndroidTest
Test çıkışı, test raporunun bulunduğu HTML dosyasının yolunu içerir. Siz ayrıca, test sonuçlarını kullanarak daha ayrıntılı bir analiz için Çalıştır > IDE'deki Test Geçmişi.
Test parçalamayı etkinleştir
Gradle tarafından yönetilen cihazlar, testinizi bölmenizi sağlayan test parçalamayı destekler. kırık adı verilen bir dizi özdeş sanal cihaz örneğine uygulanır. çalışır. Test parçalama özelliğini kullanmak, genel test yürütmesinin azaltılmasına yardımcı olabilir daha az kaynak harcıyor.
Belirli bir test çalıştırmasında kullanmak istediğiniz kırık sayısını ayarlamak için
gradle.properties dosyanızda şu bilgiler yer alır:
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ında her cihaz profili için belirttiğiniz kırık sayısı. Bu nedenle
örnek olarak, testlerinizi üç cihazlık bir cihaz grubuna dağıtıp
numManagedDeviceShards ila iki, Gradle tarafından yönetilen cihazlar için toplam temel hazırlık
altı sanal cihazdan yararlanabilirsiniz.
Testleriniz tamamlandığında Gradle, test sonuçlarını bir .proto dosyasında yayınlar.
gereken her parça için ayrı bir kontrol listesi sunar.
Otomatik Test Cihazlarını Kullanma
Gradle tarafından yönetilen cihazlar, Otomatik Aşağıdaki durumlarda CPU ve bellek kaynaklarını azaltmak için optimize edilen Test Cihazı (ATD) öğrenmeniz gerekecek. ATD'ler çalışma zamanı performansını birkaç şekilde iyileştirir:
- Uygulamanızı test etmek için genellikle yararlı olmayan önceden yüklenmiş uygulamaları kaldırın
- Genellikle aşağıdakiler için yararlı olmayan belirli arka plan hizmetlerini devre dışı bırakın: uygulamanızı test etme
- Donanım oluşturmayı devre dışı bırak
Başlamadan önce şunlardan emin olun: Android Emülatör'ü en son sürüme güncelleyin kullanılabilir sürümü. Ardından, bir "-atd" Gradle tarafından yönetilen bir tanımlarken resim aşağıda gösterildiği gibi modül düzeyindeki derleme dosyanızda bulabilirsiniz:
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"
}
}
}
}
}
Eski
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 diğer Gradle tarafından yönetilen cihazlar. Performans iyileştirmelerinden daha fazla yararlanmak için toplam testi azaltmak için ATD'leri test parçalama ile de kullanabilir test paketinizin yürütme süresini kontrol eder.
ATD resimlerinden neler kaldırılır?
ATD'ler, gözetimsiz modda çalışmanın yanı sıra performansı şu şekilde optimize eder: için gerekli olmayan uygulama ve hizmetleri kaldırmanız veya uygulamanızın kodunu test etmektir. Aşağıdaki tabloda, bileşenlere genel bir bakış sunulmaktadır ATD resim ve açıklamalarında bu reklamların neden devre dışı bırakıldığını veya faydalı olur.
| ATD resimlerinde neler kaldırılır? | Otomatik testler çalıştırırken neden buna ihtiyaç duymayabileceğinizi öğrenin |
|---|---|
Google ürün uygulamaları:
|
Otomatik testleriniz, uygulamanızın mantığına odaklanarak bir yandan da
düzgün çalışmasını sağlamalısınız.
Espresso-Intents ile giden niyetlerinizi eşleştirip doğrulayabilir, hatta yerine bu bilgileri kullanın. |
Ayar uygulamaları ve hizmetleri:
|
Bu uygulamalar, son kullanıcıların platformu değiştirmesi için bir GUI sunar
ayarlarını yapabilir, cihazını kurabilir veya cihaz depolama alanını yönetebilirsiniz. Bu genelde
testin kapsamı dışında kalmalıdır.
|
| Sistem Arayüzü | Otomatik testleriniz, uygulamanızın mantığına odaklanarak bir yandan da düzgün çalışmasını sağlamalısınız. |
AOSP uygulamaları ve hizmetleri:
|
Bu uygulamalar ve hizmetler genellikle otomatik için testler yapabilirsiniz. |
Firebase Test Lab cihazlarını kullanma
Firebase Test'te otomatik araçlı testlerinizi geniş ölçekte çalıştırabilirsiniz Lab cihazları Gradle tarafından yönetilen cihazlar. Test Lab, testlerinizi tek bir cihazda aynı anda çalıştırmanızı sağlar hem fiziksel hem de sanal Android cihazları. Bu testler Google veri merkezlerine bakıyor. Gradle tarafından yönetilen cihazların desteğiyle, sistemi, kalite puanına göre bu Test Lab cihazlarına karşı çalışan testleri yardımcı olabilir.
Başlayın
Aşağıdaki adımlarda, Firebase Test Lab cihazlarını Gradle tarafından yönetilen cihazlar. Bu adımlarda, gcloud KSA'yı kullanarak kullanıcıya kimlik bilgilerinden yararlanırsınız. Bu bilgiler, tüm geliştirme ortamları için geçerli olmayabilir. Daha fazla için hangi kimlik doğrulama işlemini kullanacağınızla ilgili daha fazla bilgi için Nasıl Uygulama Varsayılan Kimlik Bilgileri çalışır.
Firebase projesi oluşturmak için Firebase konsolu. Sonraki slayta geçin Proje ekleyin ve proje oluşturmak için ekrandaki talimatları uygulayın. Proje kimliğinizi unutmayın.
Google Cloud KSA'yı yüklemek için şu sayfadaki adımları uygulayın: gcloud KSA'yı yükleyin.
Yerel ortamınızı yapılandırın.
gcloud'daki Firebase projenize bağlayın:
gcloud config set project FIREBASE_PROJECT_ID
Kullanıcı kimlik bilgilerinizin API erişimi için kullanımına yetki verin. Önerilerimiz: bir hizmet hesabı JSON dosyasını kullanarak Gradle'a Modül düzeyinde derleme komut dosyasındaki DSL:
Kotlin
firebaseTestLab { ... serviceAccountCredentials.set(file(SERVICE_ACCOUNT_JSON_FILE)) }Eski
firebaseTestLab { ... serviceAccountCredentials = file(SERVICE_ACCOUNT_JSON_FILE) }Alternatif olarak aşağıdaki terminali kullanarak manuel olarak yetkilendirebilirsiniz komut:
gcloud auth application-default login
İsteğe bağlı: Firebase projenizi kota projesi olarak ekleyin. Bu adım yalnızca Test Lab için ücretsiz kota.
gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID
.
Gerekli API'leri etkinleştirin.
Google Developers Console API Kitaplığı sayfası, Cloud Testing API'yi etkinleştirin ve Cloud Tool Results API Bu API adlarını konsolun üst kısmındaki arama kutusuna yazıp API'yi etkinleştir'i tıklayarak. sayfasını kullanı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 }Eski
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" }Eski
plugins { ... id 'com.google.firebase.testlab' }
Bir Test Lab cihazı belirtin
Gradle'ın test amacıyla kullanacağı bir Firebase Test Lab cihazı belirtebilirsiniz
inceleyebilirsiniz. Aşağıdaki kod örneği,
Gradle tarafından yönetilen Test Lab cihazı olarak API düzeyi 30'u çalıştıran Pixel 3
ftlDevice firebaseTestLab {} bloğunu şurayı uyguladığınızda kullanılabilir:
Modülünüze com.google.firebase.testlab eklentisi.
Kotlin
firebaseTestLab {
managedDevices {
create("ftlDevice") {
device = "Pixel3"
apiLevel = 30
}
}
...
}
Eski
firebaseTestLab {
managedDevices {
ftlDevice {
device = "Pixel3"
apiLevel = 30
}
}
...
}
Firebase Test Lab cihazları dahil olmak üzere, Gradle tarafından yönetilen bir cihaz grubu tanımlamak için: Cihaz gruplarını tanımlama başlıklı makaleyi inceleyin.
Testlerinizi çalıştırmak için Gradle tarafından yönetilen diğer işlemleri çalıştırırken kullanılan komutların aynısını kullanın cihazlar. Gradle'ın testleri paralel olarak çalıştırmadığını veya Test Lab cihazları için diğer Google Cloud CLI yapılandırmaları.
Akıllı parçalama ile test çalıştırmalarını optimize edin
Gradle tarafından yönetilen Test Lab cihazlarında yapılan testler, akıllı parçalamayı destekler. Akıllı parçalama, testlerinizi otomatik olarak parçalara dağıtır. Böylece, her bir kırık yaklaşık olarak aynı süre boyunca çalışır. Bu da manuel ayırma çalışmalarını azaltır ve toplam test çalıştırması süresidir. Akıllı parçalama, test geçmişinizi veya bilgilerinizi kullanır için testlerinizin ne kadar süre önce çalıştırıldığına dair yol açabilir. Gradle eklentisinin 0.0.1-alpha05 sürümüne ihtiyacınız olduğunu unutmayın Firebase Test Lab'in akıllı parçalama özelliğini kullanmasını sağlayın.
Akıllı parçalamayı etkinleştirmek için her kırıkta ne kadar süre test yapılacağını belirtin
belirler. Hedef parça süresini en az beş olarak ayarlamalısınız.
parçanın timeoutMinutes dakikadan daha kısa olması sayesinde
testler bitmeden iptal edilir.
firebaseTestLab {
...
testOptions {
targetedShardDurationMinutes = 2
}
}
Daha fazla bilgi edinmek için Firebase Test Lab cihaz DSL seçenekleri.
Test Lab cihazları için DSL güncellendi
Test çalıştırmalarınızı özelleştirmenize yardımcı olması için yapılandırabileceğiniz başka DSL seçenekleri vardır. diğer çözümlerden geçiş yapın. Bu seçeneklerden bazılarını inceleyin aşağıdaki kod snippet'inde açıklandığı gibidir.
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
}
}