Von Firebase Test Lab zur Developer Device Platform migrieren

Wir freuen uns, die Vorschau der gcloud beta device-run-Befehlszeile in der Developer Device Platform (DDP) anzukündigen. Sie ist eine Erweiterung der gcloud firebase test-Befehlszeile.

Die gcloud beta device-run-CLI vereinfacht und modernisiert das Ausführen von Automatisierungs- und Instrumentierungstests auf Geräten, sowohl physischen als auch virtuellen. In der Vorabversion werden Android Instrumentation und iOS XCTest unterstützt. Eine Anleitung finden Sie unter Geräteausführung – Übersicht.

Übersicht und Vorteile

Der Wechsel von Firebase Test Lab zur Developer Device Platform (DDP) bietet mehrere wichtige Vorteile, insbesondere in Bezug auf Kosteneinsparungen, Geschwindigkeit der Testausführung, erweitertes Debugging und integrierte Unterstützung für KI-basierte Workflows.

Entwickler, die mobile Tests in der Cloud ausführen, müssen zwischen verschiedenen Konfigurationsmodellen (Firebase Test Lab) wechseln oder zusätzliche Pipelines und Tooling-Wrapper-Ebenen (Flank) verwalten.

Die gcloud beta device-run-Befehlszeile in der Developer Device Platform führt diese Funktionen direkt in der Google Cloud CLI zusammen. Sie bietet eine robuste, deklarative und skalierbare Backend-Schnittstelle, mit der Tests auf physischen und virtuellen Geräten vorhersehbar und effizient ausgeführt werden können.

Die wichtigsten Funktionen und Möglichkeiten, die DDP im Vergleich zu Firebase Test Lab zu einer überlegenen Plattform machen, sind:

Erweitertes Smart Sharding

Firebase Test Lab verwendet Timing-Daten aus einzelnen Läufen, um Tests aufzuteilen. Das Smart Sharding von DDP ist jedoch wesentlich intelligenter:

  • Verlaufsdaten für 30 Tage: DDP analysiert bis zu 30 Tage Ausführungsverlauf, um Tests in stabile, optimierte Shards zu verteilen.
  • Gerätespezifische Dauererfassung: DDP erfasst die Laufzeiten der Testausführung für jedes spezifische Gerätemodell und verwendet nicht generalisierte Plattformdurchschnitte für alle Geräte.
  • Orchestrator-Overhead-Modellierung: DDP berücksichtigt den Start-Overhead des Android Test Orchestrator für jede Testinstanz, damit die Shards ihre Zieldauer nicht überschreiten.

Detaillierte und kostengünstige Wiederholungsversuche

Wenn in Test Lab ein einzelner Testlauf innerhalb eines Shards fehlschlägt, muss der gesamte Shard (möglicherweise Dutzende von Tests) wiederholt werden. Dadurch verlängern sich sowohl die Ausführungszeiten als auch die Abrechnungskosten. DDP bietet hocheffiziente Wiederholungsmechanismen:

  • Wiederholungen auf Testfallebene: Es werden nur die spezifischen fehlgeschlagenen Testfälle innerhalb eines Shards isoliert und wiederholt.
  • Sequenzielle Wiederholungen von instabilen Tests: Wiederholungen von instabilen Tests werden standardmäßig sequenziell ausgeführt (nicht gleichzeitig wie in Test Lab). In Kombination mit Wiederholungsversuchen auf Testlauf-Ebene wird die Gesamtzahl der Testläufe drastisch reduziert, was zu erheblichen Einsparungen bei den Geräteabrechnungskosten führt.

Erweiterte Unterstützung für Android-Tests

DDP behebt langjährige Einschränkungen der Test Lab-Test-API:

  • Nur Test-APK (keine Dummy-Apps): Bisher war für selbstinstrumentierende Tests in Test Lab eine Dummy-App erforderlich. DDP unterstützt die Ausführung von Instrumentierungstests mit nur einem Test-APK.
  • Längere Zeitüberschreitung für Shards: Mit DDP wird das maximale Ausführungslimit für einen einzelnen Instrumentierungstest-Shard von 45 Minuten in Test Lab auf 3 Stunden erhöht.
  • Mehrere Orchestrators: DDP unterstützt mehrere Android Test Orchestrator-Versionen.
  • Integrierte Unterstützung für C++-Binärdateien: DDP unterstützt die Ausführung von Android-C++-Binärdateien.

Erweiterte Geräteinteraktionen und erweitertes Debugging

DDP bietet umfassendere Interaktionen auf dem Gerät und viel umfangreichere Debugging-Artefakte als Test Lab:

  • Scheinstandorte: DDP unterstützt das Simulieren von GPS-Koordinaten des Geräts.
  • Unterstützung von ApkSets: Entwickler können ApkSets (.apks-Dateien) direkt auf den Remote-Geräten installieren.
  • Erweiterte Fehlerbehebung: DDP stellt wichtige Systemprotokolle und Informationen zur Fehlerbehebung, einschließlich dumpsys und bugreport, direkt für den Entwickler bereit.

Hochskalierbarer Gerätekatalog

DDP ersetzt den starren und umfangreichen Umgebungskatalog von Test Lab durch eine komplett neu gestaltete Device Catalog API:

  • Serverseitige Filterung: Beschleunigt Abfragen und verringert die Nutzlastlatenz, da Entwickler Geräte serverseitig filtern können.
  • Echtzeitdaten zur Verfügbarkeit: DDP stellt Device Run Echtzeitinformationen zur Geräteverfügbarkeit direkt zur Verfügung. So können Sie Geräte mit hoher Verfügbarkeit auswählen und lange Wartezeiten vermeiden. Diese Funktion ist in Test Lab nicht verfügbar.

Migrationspfad auswählen

Migration mit KI automatisieren

Damit die Umstellung reibungslos verläuft, haben wir einen speziellen Übersetzungs-Agent-Skill entwickelt: migrating-device-run.

Wenn Sie KI-Coding-Agents wie Antigravity, Claude Code oder Codex verwenden, können Sie Ihre benutzerdefinierten Testskripts ganz einfach übersetzen. Kopieren Sie einfach die URL des Schemas für die Migrations-Skill und fügen Sie sie wie hier beschrieben in Ihren KI-Assistenten-Arbeitsbereich ein.

Migrations-Prompt-Vorlage

You are an expert migration assistant. I want to migrate my test command and
configuration to the new `gcloud beta device-run` command format.

Use this migration guideline as your ruleset:
https://docs.cloud.google.com/developer-device-platform/device-run/migrate/migration-skill

Translate the following command and configuration to the new `gcloud beta
device-run` CLI: (Insert your raw Firebase Test / Flank YAML or bash script
here.)

Manuell migrieren

Folgen Sie unserer Anleitung zum Migrieren von Befehlen und Flags, um manuell von Firebase Test Lab zu DDP zu migrieren. Beachten Sie bei der Vorbereitung der Migration die folgenden strukturellen Unterschiede:

  • Ressourcenorientierte CLI-Architektur: gcloud beta device-run verwendet ein modernes <resource> <verb>-Befehlsmuster für drei Hauptressourcengruppen:
    • devices: Direkter CLI-Zugriff auf den Gerätekatalog und umfassende Gerätedetails, die fragmentierte Legacy-firebase test android/ios models/versions/locales-Befehle ersetzen.
    • software-versions: Direkter CLI-Zugriff auf unterstützte Softwareversionen (z. B. Xcode- und Android Test Orchestrator-Versionen) als Ersatz für das alte firebase test ios xcode-versions list.
    • sessions: End-to-End-Sitzungslebenszyklusverwaltung direkt im Terminal, einschließlich sessions submit instrumentation, sessions submit xctest, sessions wait, sessions describe [--full], sessions list und sessions cancel.
  • Unterbefehlsstruktur: Testtypen sind standardisiert und werden als übersichtliche Unterbefehle unter sessions submit verschachtelt, anstatt Typ-Flags zu verwenden.
    • DDP: gcloud beta device-run sessions submit instrumentation (Android) oder gcloud beta device-run sessions submit xctest (iOS)
    • Test Lab: gcloud firebase test android run --type=instrumentation (Android) oder gcloud firebase test ios run --type=xctest (iOS)
  • Apps mit Pluralisierung und zusammengeführte Apps: Standard- und Zusatz-APKs werden unter der Liste mit --apps-Flags mit Pluralisierung zusammengeführt (z. B. --apps=app.apk,helper.apk) statt in --app und --additional-apks aufgeteilt.
  • Strukturierte Wörterbuch- und Listenargumente: Durch kommagetrennte Dateien oder Umgebungslisten wurden durch strukturierte CLI-Wörterbuch- und Listenformate ersetzt: --other-files-to-push KEY=VALUE, --additional-test-options KEY=VALUE, --paths-to-pull und --test-targets.
  • Einheitliche Sharding- und Wiederholungssteuerung: Nahtlose Unterstützung für Uniform Sharding und Smart Sharding sowie parallele Wiederholungen (--flaky-test-parallel-retry, --flaky-test-retry-level) und Laufzeitdiagnose (--dumpsys, --bugreport, --video).
  • Asynchrone Ausführung: gcloud beta device-run unterstützt die asynchrone Ausführung. So können Sie Tests ausführen, ohne auf den Abschluss warten zu müssen. Verwenden Sie gcloud beta device-run sessions wait <SESSION_ID>, um auf den Abschluss zu warten.
  • Deklarative YAML-Konfiguration (--flags-file): Teams, die von Flank migrieren und versionierte YAML-Dateien Shell-Script-Strings vorziehen, können die universelle --flags-file=device-run-flags.yaml-Unterstützung von gcloud nutzen.

Nächste Schritte

  1. Kurzanleitung
  2. In unserem Gerätekatalog finden Sie alle verfügbaren Geräte.
  3. Weitere Informationen zu Device Run
  4. In unserer Übersicht der Befehls- und Flag-Übersetzungen finden Sie eine Zuordnung von Test Lab- und Flank-Flags zu DDP.