Von Gradle verwaltete Geräte verbessern die Konsistenz, Leistung und Zuverlässigkeit mit Ihren automatisierten instrumentierten Tests. Diese Funktion ist für API-Levels 27 und können Sie virtuelle oder Remote-Testgeräte in Ihrem Gradle-Dateien des Projekts. Das Build-System nutzt die Konfigurationen, um um diese Geräte zu verwalten, d. h. zu erstellen, bereitzustellen und zu entfernen, wenn Sie Ihre automatisierte Tests durchführen.
Diese Funktion gewährt Gradle nicht nur Einblick in die ausgeführten Tests, sondern auch über den Lebenszyklus der Geräte. Dies verbessert die Qualität testen können:
- Behandelt gerätebezogene Probleme, um sicherzustellen, dass die Tests ausgeführt werden
- Verwendet für virtuelle Geräte Emulator-Snapshots, um die Gerätestartzeit zu verkürzen sowie die Speichernutzung und stellen Sie die Geräte zwischen den Tests in einem bereinigten Zustand wieder her.
- Cachet Testergebnisse im Cache und führt nur Tests noch einmal aus, die wahrscheinlich andere Ergebnisse liefern Ergebnisse
- Bietet eine einheitliche Umgebung für die Ausführung Ihrer Tests zwischen lokalen und Remote-Testläufe
Virtuelles, von Gradle verwaltetes Gerät erstellen
Du kannst ein virtuelles Gerät angeben, das Gradle zum Testen deines app in Ihrer Build-Datei auf Modulebene an. Mit dem folgenden Codebeispiel wird ein Pixel 2- API-Level 30 als von Gradle verwaltetes Gerät aus.
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"
}
}
}
}
}
Cool
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"
}
}
}
}
}
Gruppen von Geräten definieren
Damit Sie Ihre Tests über mehrere Gerätekonfigurationen hinweg skalieren können, z. B. verschiedene API-Ebenen und Formfaktoren haben, können Sie mehrere von Gradle verwaltete Geräte und fügen sie einer benannten Gruppe hinzu. Gradle kann Ihre Tests dann alle Geräte in der Gruppe gleichzeitig zu aktualisieren.
Im Beispiel unten siehst du zwei Geräte, die einer Gerätegruppe namens
phoneAndTablet
Kotlin
testOptions {
managedDevices {
localDevices {
create("pixel2api29") { ... }
create("nexus9api30") { ... }
}
groups {
create("phoneAndTablet") {
targetDevices.add(devices["pixel2api29"])
targetDevices.add(devices["nexus9api30"])
}
}
}
}
Cool
testOptions {
managedDevices {
localDevices {
pixel2api29 { ... }
nexus9api30 { ... }
}
groups {
phoneAndTablet {
targetDevices.add(devices.pixel2api29)
targetDevices.add(devices.nexus9api30)
}
}
}
}
Tests ausführen
Um Ihre Tests mit den von Ihnen konfigurierten Gradle-verwalteten Geräten auszuführen, verwenden Sie die
folgenden Befehl. device-name ist der Name des Geräts, in dem Sie das Gerät konfiguriert haben.
Ihr Gradle-Build-Skript (z. B. pixel2api30) und BuildVariant ist der
die zu testende Variante Ihrer App erstellen.
Unter Windows:
gradlew device-nameBuildVariantAndroidTest
Unter Linux oder macOS:
./gradlew device-nameBuildVariantAndroidTest
Um Ihre Tests für eine Gruppe von Gradle-verwalteten Geräten auszuführen, verwenden Sie die folgenden Befehle.
Unter Windows:
gradlew group-nameGroupBuildVariantAndroidTest
Unter Linux oder macOS:
./gradlew group-nameGroupBuildVariantAndroidTest
Die Testausgabe enthält einen Pfad zu einer HTML-Datei, die den Testbericht enthält. Ich können Testergebnisse auch zur weiteren Analyse in Android Studio importieren, auf Ausführen > Testverlauf in der IDE.
Test-Fragmentierung aktivieren
Von Gradle verwaltete Geräte unterstützen Test-Sharding, sodass Sie Ihren Test aufteilen können. auf einer Reihe identischer VM-Geräteinstanzen, die Shards genannt werden, die parallel laufen. Die Testfragmentierung kann dazu beitragen, die Gesamttestausführung zu reduzieren auf Kosten zusätzlicher Rechenressourcen.
Um die Anzahl der Shards festzulegen, die in einem bestimmten Testlauf verwendet werden sollen,
Folgendes in Ihrer gradle.properties-Datei:
android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>
Wenn Sie Ihre Tests mit dieser Option ausführen, stellen von Gradle verwaltete Geräte die
Anzahl der Shards, die Sie für jedes Geräteprofil im Testlauf angeben. Für
Wenn Sie Ihre Tests für eine Gerätegruppe mit drei Geräten bereitgestellt haben und
numManagedDeviceShards auf zwei, von Gradle verwaltete Geräte stellen insgesamt
mit sechs virtuellen Geräten
für den Testlauf testen.
Wenn die Tests abgeschlossen sind, gibt Gradle die Testergebnisse in einer .proto-Datei aus.
für jedes im Testlauf verwendete Shard.
Automatisierte Testgeräte verwenden
Von Gradle-verwalteten Geräten wird ein Emulatorgerät namens Test Device (ATD), das so optimiert ist, dass die CPU- und Speicherressourcen bei der Verwendung instrumentierten Tests durchführen. ATDs verbessern die Laufzeitleistung auf verschiedene Weise:
- Vorinstallierte Apps entfernen, die normalerweise nicht zum Testen der App nützlich sind
- Bestimmte Hintergrunddienste deaktivieren, die normalerweise nicht nützlich sind Ihre App testen
- Hardwarerendering deaktivieren
Stellen Sie zunächst sicher, Aktualisieren Sie den Android-Emulator auf die neueste Version. verfügbare Version. Geben Sie dann „-atd“ an. wenn Sie eine von Gradle verwaltete Gerät in der Build-Datei auf Modulebene an, wie unten gezeigt:
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"
}
}
}
}
}
Cool
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"
}
}
}
}
}
Wie bei anderen Apps können Sie auch Gerätegruppen erstellen. Von Gradle verwaltete Geräte. Um die Leistungsverbesserungen weiter zu nutzen, können ATDs auch mit Testfragmentierung verwenden, um den Gesamttest zu reduzieren. Ausführungszeit Ihrer Testsuite.
Was wird aus ATD-Images entfernt?
ATDs arbeiten nicht nur im monitorlosen Modus, sondern optimieren auch die Leistung, zum Entfernen oder Deaktivieren von Apps und Diensten, um den Code Ihrer App zu testen. In der folgenden Tabelle erhalten Sie einen Überblick über die Komponenten. in ATD-Images entfernt oder deaktiviert haben, sowie Beschreibungen, warum sie möglicherweise nützlich sein.
| Was aus ATD-Images entfernt wird | Warum Sie diese bei der Ausführung automatisierter Tests möglicherweise nicht benötigen |
|---|---|
Google-Produkt-Apps:
|
Ihre automatisierten Tests sollten sich auf die Logik Ihrer App konzentrieren und
dass andere Apps
oder die Plattform ordnungsgemäß funktionieren.
Bei Espresso-Intents können Sie ausgehende Intents abgleichen und validieren oder sogar Stubs bereitstellen, anstelle von tatsächlichen Intent-Antworten. |
Einstellungen für Apps und Dienste:
|
Diese Apps bieten eine GUI, mit der Endnutzer die Plattform wechseln können
ihr Gerät einrichten oder den Gerätespeicher verwalten. Das ist normalerweise
automatischen Tests auf App-Ebene.
|
| SystemUI | Ihre automatisierten Tests sollten sich auf die Logik Ihrer App konzentrieren und dass andere Apps oder die Plattform ordnungsgemäß funktionieren. |
AOSP-Apps und -Dienste:
|
Diese Apps und Dienste fallen in der Regel nicht automatisch an. Tests für den Code Ihrer App. |
Firebase Test Lab-Geräte verwenden
Sie können Ihre automatisierten instrumentierten Tests in großem Umfang in Firebase Test ausführen Lab-Geräten bei Verwendung Von Gradle verwaltete Geräte. Mit Test Lab können Sie Ihre Tests gleichzeitig auf einem eine große Auswahl an physischen und virtuellen Android-Geräten. Diese Tests werden in Remote-Rechenzentren von Google. Dank der Unterstützung von Gradle-verwalteten Geräten mit diesen Test Lab-Geräten durchgeführte Tests Ihre Konfigurationen.
Erste Schritte
In den folgenden Schritten wird beschrieben, wie Sie Firebase Test Lab-Geräte mit Von Gradle verwaltete Geräte. In diesen Schritten wird die gcloud CLI verwendet, um Anmeldedaten, die möglicherweise nicht für alle Entwicklungsumgebungen gelten. Weitere Informationen Informationen darüber, welches Authentifizierungsverfahren Sie für Ihre Anforderungen verwenden können, finden Sie unter Wie Standardanmeldedaten für Anwendungen funktioniert.
Rufen Sie zum Erstellen eines Firebase-Projekts die Firebase Console. Klicken Sie auf Projekt hinzufügen und folgen Sie der Anleitung auf dem Bildschirm, um ein Projekt zu erstellen. Merken Sie sich Ihre Projekt-ID.
So installieren Sie die Google Cloud CLI: Installieren Sie die gcloud CLI.
Lokale Umgebung konfigurieren
Stellen Sie in gcloud eine Verknüpfung zu Ihrem Firebase-Projekt her:
gcloud config set project FIREBASE_PROJECT_ID
Autorisieren Sie die Verwendung Ihrer Nutzeranmeldedaten für den API-Zugriff. Wir empfehlen, durch Übergeben einer JSON-Datei des Dienstkontos mithilfe der DSL im Build-Skript auf Modulebene:
Kotlin
firebaseTestLab { ... serviceAccountCredentials.set(file(SERVICE_ACCOUNT_JSON_FILE)) }Cool
firebaseTestLab { ... serviceAccountCredentials = file(SERVICE_ACCOUNT_JSON_FILE) }Alternativ können Sie die Autorisierung über das folgende Terminal manuell vornehmen Befehl:
gcloud auth application-default login
Optional: Fügen Sie Ihr Firebase-Projekt als Kontingentprojekt hinzu. Dieser Schritt ist nur erforderlich, wenn Sie die kostenloses Kontingent für Test Lab.
gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID
Erforderliche APIs aktivieren
Im Seite "API-Bibliothek" der Google Developers Console, Aktivieren Sie die Cloud Testing API. und Cloud Tool Results API indem Sie diese API-Namen in das Suchfeld oben in der Konsole eingeben und dann auf API aktivieren klicken. auf der Übersichtsseite der einzelnen APIs.
Konfigurieren Sie Ihr Android-Projekt.
Fügen Sie das Firebase Test Lab-Plug-in in das Build-Skript der obersten Ebene ein:
Kotlin
plugins { ... id("com.google.firebase.testlab") version "0.0.1-alpha05" apply false }Cool
plugins { ... id 'com.google.firebase.testlab' version '0.0.1-alpha05' apply false }Aktivieren Sie benutzerdefinierte Gerätetypen in der Datei
gradle.properties:android.experimental.testOptions.managedDevices.customDevice=true
Fügen Sie das Firebase Test Lab-Plug-in in das Build-Skript auf Modulebene ein:
Kotlin
plugins { ... id "com.google.firebase.testlab" }Cool
plugins { ... id 'com.google.firebase.testlab' }
Test Lab-Gerät angeben
Sie können ein Firebase Test Lab-Gerät angeben, das Gradle zum Testen Ihrer
app im Build-Skript auf Modulebene. Im folgenden Codebeispiel wird ein
Pixel 3 mit API-Level 30 als von Gradle verwaltetes Test Lab-Gerät
ftlDevice Der Block firebaseTestLab {} ist verfügbar, wenn Sie die
com.google.firebase.testlab-Plug-in zu Ihrem Modul hinzu.
Kotlin
firebaseTestLab {
managedDevices {
create("ftlDevice") {
device = "Pixel3"
apiLevel = 30
}
}
...
}
Cool
firebaseTestLab {
managedDevices {
ftlDevice {
device = "Pixel3"
apiLevel = 30
}
}
...
}
So definieren Sie eine Gruppe von über Gradle verwalteten Geräten, einschließlich Firebase Test Lab-Geräten: Weitere Informationen finden Sie unter Gerätegruppen definieren.
Verwenden Sie zum Ausführen Ihrer Tests dieselben Befehle wie bei anderen von Gradle verwalteten Geräte. Beachten Sie, dass Gradle Tests nicht parallel ausführt und keine andere Google Cloud CLI-Konfigurationen für Test Lab-Geräte.
Testläufe mit intelligenter Fragmentierung optimieren
Beim Testen auf von Gradle verwalteten Test Lab-Geräten wird die intelligente Fragmentierung unterstützt. Smart Bei der Fragmentierung werden die Tests automatisch so auf die Shards verteilt, dass jeder Shard läuft ungefähr gleich lang, wodurch der manuelle Zuweisungsaufwand Gesamtdauer des Testlaufs. Bei der intelligenten Fragmentierung werden dein Testverlauf oder deine Informationen verwendet wie lange es früher gedauert hat, Tests durchzuführen. den optimalen Weg finden. Sie benötigen die Version 0.0.1-alpha05 des Gradle-Plug-ins. für Firebase Test Lab die intelligente Fragmentierung verwendet.
Geben Sie zum Aktivieren der intelligenten Fragmentierung die Dauer der Tests in jedem Shard an
die Sie benötigen. Du solltest die Dauer des Ziel-Shards auf mindestens fünf festlegen
Minuten unter timeoutMinutes, um die Situation zu vermeiden, dass Shards
vor Abschluss der Tests abgebrochen werden.
firebaseTestLab {
...
testOptions {
targetedShardDurationMinutes = 2
}
}
Weitere Informationen finden Sie in den DSL-Optionen für Geräte in Firebase Test Lab
Aktualisierte DSL für Test Lab-Geräte
Es gibt weitere DSL-Optionen, die Sie konfigurieren können, um Ihre Testläufe anzupassen, oder Lösungen zu migrieren, die Sie möglicherweise bereits nutzen. Sehen Sie sich einige dieser Optionen an. enthalten, wie im folgenden Code-Snippet beschrieben.
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
}
}