Von Firebase Test Lab zur Developer Device Platform migrieren

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

Die gcloud beta device-run-Befehlszeile vereinfacht und modernisiert die Ausführung von Automatisierungs- und Instrumentierungstests auf dem Gerät, sowohl auf physischen als auch auf virtuellen. In der Vorschauversion werden Android Instrumentation und iOS XCTest unterstützt. Eine Anleitung finden Sie in der Übersicht zu Device Run für Anweisungen.

Übersicht und Vorteile

Der Wechsel von Firebase Test Lab zur Developer Device Platform (DDP) bietet mehrere wichtige Vorteile, insbesondere in Bezug auf Kosteneinsparungen, Testausführungsgeschwindigkeit, erweiterte Fehlerbehebung und integrierte Unterstützung für KI-gesteuerte Arbeitsabläufe.

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 vereint diese Funktionen direkt in der Google Cloud CLI. Sie bietet eine robustere, deklarative und skalierbare Backend-Schnittstelle, mit der Tests sowohl auf physischen als auch auf virtuellen Geräten vorhersehbar und effizient ausgeführt werden können.

Zu den wichtigsten Funktionen und Möglichkeiten, die DDP im Vergleich zu Firebase Test Lab zu einer überlegenen Plattform machen, gehören:

Erweiterte Smart Sharding-Funktion

Während Firebase Test Lab Timing-Daten aus einzelnen Testläufen verwendet, um Tests aufzuteilen, ist die Smart Sharding-Funktion von DDP viel intelligenter:

  • _Verlaufsdaten der letzten 30 Tage_: DDP analysiert bis zu 30 Tage Ausführungsverlauf, um Tests in stabile, optimierte Shards aufzuteilen.
  • Gerätespezifische Dauerverfolgung: DDP verfolgt die Testausführungszeiten für jedes Gerätemodell und verwendet nicht die allgemeinen Plattformdurchschnitte für alle Geräte.
  • Modellierung des Orchestrator-Overheads: DDP berücksichtigt den Start-Overhead des Android Test Orchestrator für jede Testinstanz, damit die Shards ihre Zieldauer nicht überschreiten.

Feingranulare und kostengünstige Wiederholungen

Wenn in Test Lab ein einzelner Testfall in einem Shard fehlschlägt, muss der gesamte Shard (potenziell Dutzende von Tests) wiederholt werden. Das erhöht sowohl die Ausführungszeiten als auch die in Rechnung gestellten Kosten. DDP bietet hocheffiziente Wiederholungsmechanismen:

  • Gezielte Wiederholungen auf Testfallebene: Nur die spezifischen Testfälle, die in einem Shard fehlschlagen, werden isoliert und wiederholt.
  • Sequenzielle Wiederholungen von instabilen Tests: Wiederholungen für instabile Tests werden standardmäßig sequenziell ausgeführt (im Gegensatz zu Test Lab, wo sie parallel ausgeführt werden). In Kombination mit Wiederholungen auf Testfallebene werden die Gesamtzahl der Testläufe erheblich reduziert, was zu erheblichen Einsparungen bei den in Rechnung gestellten Kosten für die Gerätenutzung führt.

Erweiterte Unterstützung für Android-Tests

DDP behebt seit Langem bestehende Einschränkungen in der Test Lab Testing API:

  • Nur Test-APK (keine Dummy-Apps): In Test Lab war bisher eine Dummy-App erforderlich, um selbstinstrumentierende Tests auszuführen. Mit DDP können Instrumentierungstests nur mit einer Test-APK ausgeführt werden.
  • Längere Zeitüberschreitung für Shards: DDP erhöht die maximale Ausführungszeit für einen einzelnen Instrumentierungstest-Shard von 45 Minuten in Test Lab auf 3 Stunden.
  • Mehrere Orchestratoren: DDP unterstützt mehrere Versionen des Android Test Orchestrator.
  • Integrierte Unterstützung für C++-Binärdateien: DDP unterstützt die Ausführung von Android C++-Binärdateien.

Erweiterte Geräteinteraktionen und erweiterte Fehlerbehebung

DDP bietet umfassendere On-Device-Interaktionen und viel detailliertere Artefakte für die Fehlerbehebung als Test Lab:

  • Simulierte Standortdaten: DDP unterstützt das Mocking von GPS-Koordinaten des Geräts.
  • Unterstützung für 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 ressourcenintensiven Umgebungskatalog von Test Lab durch eine komplett neu entwickelte Gerätekatalog API:

  • Serverseitige Filterung: Beschleunigt Abfragen und reduziert die Nutzlastlatenz, da Entwickler Geräte serverseitig filtern können.
  • Verfügbarkeitsdaten in Echtzeit: DDP stellt Informationen zur Geräteverfügbarkeit in Echtzeit direkt für Device Run bereit. So können Sie hochverfügbare Geräte auswählen und lange Wartezeiten vermeiden. Diese Funktion ist in Test Lab nicht verfügbar.

Migrationspfad auswählen

Migration mit KI automatisieren

Um den Übergang zu erleichtern, haben wir eine spezielle Übersetzungsfunktion für Agenten entwickelt: migrating-device-run.

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

Prompt-Vorlage für die Migration

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

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 unseren Befehls- und Flag-Übersetzungen, um manuell von Firebase Test Lab zu DDP zu migrieren. Beachten Sie bei der Vorbereitung der Migration die folgenden strukturellen Unterschiede:

  • Ressourcenorientierte Befehlszeilenarchitektur: gcloud beta device-run verwendet ein modernes <resource> <verb> Befehlsmuster für drei Hauptressourcen gruppen:
    • devices: Direkter Befehlszeilenzugriff auf den Gerätekatalog und umfassende Gerätedetails, ersetzt die fragmentierten Legacy-firebase test android/ios models/versions/locales Befehle.
    • software-versions: Direkter Befehlszeilenzugriff auf unterstützte Softwareversionen (z. B. Xcode- und Android Test Orchestrator-Versionen), ersetzt den Legacy-Befehl firebase test ios xcode-versions list.
    • sessions: End-to-End-Lebenszyklusverwaltung von Sitzungen 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 als saubere Unterbefehle unter sessions submit verschachtelt, anstatt Typ-Flags zu verwenden.
    • DDP: gcloud beta device-run sessions submit instrumentation (Android) oder gcloud alpha 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)
  • Pluralisierte und zusammengeführte Apps: Standard- und Zusatz-APKs werden zusammengeführt unter der pluralisierten --apps Flag-Liste (z. B. --apps=app.apk,helper.apk) anstatt in --app und --additional-apks aufgeteilt zu werden.
  • Strukturierte Wörterbuch- und Listenargumente: Kommagetrennte Dateien oder Umgebungslisten wurden durch strukturierte Wörterbuch- und Listenformate für die Befehlszeile ersetzt: --other-files-to-push KEY=VALUE, --additional-test-options KEY=VALUE, --paths-to-pull und --test-targets.
  • Einheitliche Steuerung von Sharding und Wiederholungen: Nahtlose Unterstützung für Uniform Sharding und Smart Sharding sowie parallele Wiederholungen (--flaky-test-parallel-retry, --flaky-test-retry-level) und Laufzeit diagnosen (--dumpsys, --bugreport, --video).
  • Asynchrone Ausführung: gcloud beta device-run unterstützt die asynchrone Ausführung, sodass Sie Tests ausführen können, ohne auf deren 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 YAML-Dateien mit Versionsverwaltung anstelle von Shell-Script-Strings bevorzugen, können die universelle gcloud's --flags-file=device-run-flags.yaml-Unterstützung verwenden.

Nächste Schritte

  1. Folgen Sie unserer Kurzanleitung, um die Developer Device Platform einzurichten.
  2. Im Gerätekatalog finden Sie alle verfügbaren Geräte.
  3. Weitere Informationen zu Device Run finden Sie hier, um Tests auszuführen.
  4. Auf unserer Seite mit Befehls- und Flag-Übersetzungen finden Sie eine Zuordnung von Test Lab- und Flank-Flags zu DDP.