Tests mit vom Build verwalteten Geräten skalieren

Build-verwaltete Geräte verbessern die Konsistenz, Leistung und Zuverlässigkeit Ihrer automatisierten instrumentierten Tests. Mit dieser Funktion, die für API-Level 27 und höher verfügbar ist, können Sie virtuelle oder physische Testgeräte in den Gradle-Dateien Ihres Projekts konfigurieren. Das Android-Gradle-Plug-in verwendet die Konfigurationen, um diese Geräte beim Ausführen Ihrer automatisierten Tests vollständig zu verwalten, d. h. zu erstellen, bereitzustellen und zu entfernen.

Diese Funktion ermöglicht dem Android-Gradle-Plug-in, nicht nur die von Ihnen ausgeführten Tests, sondern auch den Lebenszyklus der Geräte zu sehen. Dadurch wird die Qualität Ihrer Tests auf folgende Weise verbessert:

• Behebt gerätebezogene Probleme, damit Ihre Tests ausgeführt werden können
• Bei virtuellen Geräten werden Emulatorsnapshots verwendet, um die Startzeit des Geräts und die Arbeitsspeichernutzung zu verbessern und Geräte zwischen Tests in einen sauberen Zustand zurückzusetzen.
• Testergebnisse werden im Cache gespeichert und nur Tests, die wahrscheinlich andere Ergebnisse liefern, werden noch einmal ausgeführt.
• Bietet eine einheitliche Umgebung für die Ausführung Ihrer Tests zwischen lokalen und Remote-Testläufen

Virtuelles Build-verwaltetes Gerät erstellen

Sie können ein virtuelles Gerät angeben, das Sie zum Testen Ihrer App in der Build-Datei auf Modulebene verwenden möchten. Im folgenden Codebeispiel wird ein Pixel 2 mit API-Level 30 als Build-verwaltetes Gerät erstellt.

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"
        }
      }
    }
  }
}

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"
        }
      }
    }
  }
}

Gerätegruppen definieren

Damit Sie Ihre Tests auf mehrere Gerätekonfigurationen wie verschiedene API-Levels und Formfaktoren ausweiten können, können Sie mehrere Build-verwaltete Geräte definieren und sie einer benannten Gruppe hinzufügen. Das Android-Gradle-Plugin kann Ihre Tests dann parallel auf allen Geräten in der Gruppe ausführen.

Im folgenden Beispiel sind zwei Geräte zu einer Gerätegruppe namens phoneAndTablet hinzugefügt.

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

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

Tests ausführen

Verwenden Sie den folgenden Befehl, um Ihre Tests auf den von Ihnen konfigurierten Build-verwalteten Geräten auszuführen. device-name ist der Name des Geräts, das Sie in Ihrem Gradle-Build-Skript konfiguriert haben (z. B. pixel2api30), und BuildVariant ist die Build-Variante Ihrer App, die Sie testen möchten, z. B. Debug.

./gradlew device-nameBuildVariantAndroidTest

gradlew device-nameBuildVariantAndroidTest

Wenn Sie Ihre Tests auf einer Gruppe von Build-verwalteten Geräten ausführen möchten, verwenden Sie den folgenden Befehl.

./gradlew group-nameGroupBuildVariantAndroidTest

./gradlew group-nameGroupBuildVariantAndroidTest

gradlew group-nameGroupBuildVariantAndroidTest

Die Testausgabe enthält einen Pfad zu einer HTML-Datei mit dem Testbericht. Sie können Testergebnisse auch in Android Studio importieren, um sie weiter zu analysieren. Klicken Sie dazu in der IDE auf Run > Test History (Ausführen > Testverlauf).

Test-Sharding aktivieren

Auf Build-verwalteten Geräten wird Test-Sharding unterstützt. Damit können Sie Ihre Testsuite auf mehrere identische virtuelle Geräteinstanzen aufteilen, die als Shards bezeichnet werden und parallel ausgeführt werden. Durch die Verwendung von Test-Sharding kann die Gesamtausführungszeit von Tests reduziert werden, was jedoch zusätzliche Rechenressourcen erfordert.

Wenn Sie die Anzahl der Shards für einen bestimmten Testlauf festlegen möchten, geben Sie Folgendes in Ihrer gradle.properties-Datei an:

android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>

Wenn Sie Ihre Tests mit dieser Option ausführen, wird auf den vom Build verwalteten Geräten die Anzahl der Shards bereitgestellt, die Sie für jedes Geräteprofil im Testlauf angeben. Wenn Sie Ihre Tests beispielsweise auf einer Gerätegruppe mit drei Geräten bereitgestellt und numManagedDeviceShards auf „2“ festgelegt haben, werden insgesamt sechs virtuelle Geräte für Ihren Testlauf bereitgestellt.

Wenn Ihre Tests abgeschlossen sind, gibt Gradle für jeden Shard, der im Testlauf verwendet wird, Testergebnisse in einer .proto-Datei aus.

Automatisierte Testgeräte verwenden

Build-verwaltete Geräte unterstützen einen Emulatortyp namens Automated Test Device (ATD), der für die Ausführung instrumentierter Tests optimiert ist, um CPU- und Arbeitsspeicherressourcen zu reduzieren. ATDs verbessern die Laufzeitleistung auf verschiedene Arten:

• Vorinstallierte Apps entfernen, die in der Regel nicht zum Testen Ihrer App nützlich sind
• Bestimmte Hintergrunddienste deaktivieren, die in der Regel nicht für das Testen Ihrer App nützlich sind
• Hardware-Rendering deaktivieren

Bevor Sie beginnen, sollten Sie den Android-Emulator auf die neueste verfügbare Version aktualisieren. Geben Sie dann beim Definieren eines vom Build verwalteten Geräts in der Build-Datei auf Modulebene ein „-atd“-Image an, wie unten gezeigt:

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"
        }
      }
    }
  }
}

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"
        }
      }
    }
  }
}

Sie können auch Gerätegruppen erstellen, wie bei anderen Build-verwalteten Geräten. Um die Leistungsverbesserungen noch besser zu nutzen, können Sie ATDs auch mit Test-Sharding verwenden, um die Gesamttestausführungszeit Ihrer Testsuite zu verkürzen.

Was wird aus ATD-Bildern entfernt?

ATDs werden nicht nur im Headless-Modus ausgeführt, sondern optimieren auch die Leistung, indem sie Apps und Dienste entfernen oder deaktivieren, die normalerweise nicht zum Testen des App-Codes erforderlich sind. In der folgenden Tabelle finden Sie eine Übersicht der Komponenten, die wir aus ATD-Bildern entfernt oder deaktiviert haben, sowie eine Beschreibung, warum sie möglicherweise nicht nützlich sind.

Firebase Test Lab-Geräte verwenden

Wenn Sie von Build verwaltete Geräte verwenden, können Sie Ihre automatisierten instrumentierten Tests im großen Maßstab auf Firebase Test Lab-Geräten ausführen. Mit Test Lab können Sie Ihre Tests gleichzeitig auf einer Vielzahl von physischen und virtuellen Android-Geräten ausführen. Diese Tests werden in Remote-Rechenzentren von Google ausgeführt. Da Build-verwaltete Geräte unterstützt werden, kann das Build-System Tests auf diesen Test Lab-Geräten basierend auf Ihren Konfigurationen vollständig verwalten.

Erste Schritte

In den folgenden Schritten wird beschrieben, wie Sie Firebase Test Lab-Geräte mit Build-verwalteten Geräten verwenden. In diesen Schritten wird die gcloud CLI verwendet, um Nutzeranmeldedaten bereitzustellen. Das ist möglicherweise nicht für alle Entwicklungsumgebungen geeignet. Weitere Informationen dazu, welches Authentifizierungsverfahren Sie für Ihre Anforderungen verwenden sollten, finden Sie unter Funktionsweise von Standardanmeldedaten für Anwendungen.

1. Wenn Sie ein Firebase-Projekt erstellen möchten, rufen Sie die Firebase Console auf. 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.

2. Folgen Sie der Anleitung unter gcloud CLI installieren, um die Google Cloud CLI zu installieren.

3. Konfigurieren Sie Ihre lokale Umgebung.

   1. So verknüpfen Sie Ihr Firebase-Projekt in gcloud:

      gcloud config set project FIREBASE_PROJECT_ID
      

   2. Autorisieren Sie die Verwendung Ihrer Nutzeranmeldedaten für den API-Zugriff. Wir empfehlen, die Autorisierung durchzuführen, indem Sie eine JSON-Datei für das Dienstkonto über das DSL im Build-Skript auf Modulebene an Gradle übergeben:

      Kotlin

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

      Groovy

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

      Alternativ können Sie die Autorisierung manuell mit dem folgenden Terminalbefehl vornehmen:

      gcloud auth application-default login
      

   3. Optional: Fügen Sie Ihr Firebase-Projekt als Kontingentprojekt hinzu. Dieser Schritt ist nur erforderlich, wenn Sie das kostenlose Kontingent für Test Lab überschreiten.

      gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID
      

4. Erforderliche APIs aktivieren.

   Aktivieren Sie auf der Seite der Google Developers Console API-Bibliothek die Cloud Testing API und die Cloud Tool Results API. Geben Sie dazu die Namen der APIs in das Suchfeld oben in der Console ein und klicken Sie dann auf der Übersichtsseite für jede API auf API aktivieren.

5. Android-Projekt konfigurieren

   1. Fügen Sie das Firebase Test Lab-Plug-in im Build-Skript der obersten Ebene hinzu:

      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
      }

   2. Aktivieren Sie benutzerdefinierte Gerätetypen in der Datei gradle.properties:

      android.experimental.testOptions.managedDevices.customDevice=true

   3. Fügen Sie das Firebase Test Lab-Plug-in im Build-Skript auf Modulebene hinzu:

      Kotlin

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

      Groovy

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

Test Lab-Gerät angeben

Sie können ein Firebase Test Lab-Gerät für Gradle angeben, das zum Testen Ihrer App im Build-Skript auf Modulebene verwendet werden soll. Im folgenden Codebeispiel wird ein von Build verwaltetes Test Lab-Gerät namens ftlDevice erstellt, auf dem ein Pixel 3 mit API-Level 30 ausgeführt wird. Der Block firebaseTestLab {} ist verfügbar, wenn Sie das com.google.firebase.testlab-Plug-in auf Ihr Modul anwenden.

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

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

Informationen zum Definieren einer Gruppe von Build-verwalteten Geräten, einschließlich Firebase Test Lab-Geräten, finden Sie hier.

Verwenden Sie zum Ausführen der Tests dieselben Befehle wie für andere vom Build verwaltete Geräte. Beachten Sie, dass Gradle keine Tests parallel ausführt und keine anderen Google Cloud CLI-Konfigurationen für Test Lab-Geräte unterstützt.

Testläufe mit Smart Sharding optimieren

Beim Testen auf von Build verwalteten Test Lab-Geräten wird Smart Sharding unterstützt. Beim Smart Sharding werden Ihre Tests automatisch auf Shards verteilt, sodass jeder Shard ungefähr gleich lange ausgeführt wird. So werden der manuelle Zuweisungsaufwand und die Gesamtdauer des Testlaufs reduziert. Beim intelligenten Sharding wird der Testverlauf oder die Informationen dazu verwendet, wie lange die Ausführung Ihrer Tests in der Vergangenheit gedauert hat, um Tests optimal zu verteilen. Für die Verwendung von Smart Sharding benötigen Sie Version 0.0.1-alpha05 des Gradle-Plug-ins für Firebase Test Lab.

Wenn Sie Smart Sharding aktivieren möchten, geben Sie an, wie viel Zeit Tests in jedem Shard in Anspruch nehmen sollen. Die Dauer des Ziel-Shards sollte mindestens fünf Minuten kürzer als timeoutMinutes sein, damit Shards nicht abgebrochen werden, bevor die Tests abgeschlossen werden können.

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

Weitere Informationen zu den DSL-Optionen für Geräte in Firebase Test Lab

Aktualisierte DSL für Test Lab-Geräte

Es gibt weitere DSL-Optionen, mit denen Sie Ihre Testläufe anpassen oder von anderen Lösungen migrieren können, die Sie möglicherweise bereits verwenden. Einige dieser Optionen werden 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.
       */
      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
  }
}