Tests mit von Gradle verwalteten Geräten skalieren

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.

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

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

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

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:

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

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.

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.

1. 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.

2. So installieren Sie die Google Cloud CLI: Installieren Sie die gcloud CLI.

3. Lokale Umgebung konfigurieren

   1. Stellen Sie in gcloud eine Verknüpfung zu Ihrem Firebase-Projekt her:

      gcloud config set project FIREBASE_PROJECT_ID
      

   2. 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
      

   3. 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
      

4. 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.

5. Konfigurieren Sie Ihr Android-Projekt.

   1. 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
      }
      

   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 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.

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

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