Übersetzung von Firebase Test Lab-Plattformbefehlen und ‑Flags für Entwicklergeräte

Die Developer Device Platform (DDP) ersetzt die alte Firebase Test Lab-Konsole und die Test Lab-CLI-Workflows durch eine einheitliche, leistungsstarke und sichereGoogle Cloud-first-Test-CLI: gcloud beta device-run

In diesem Leitfaden finden Sie Befehlszeilenübersetzungen und Zuordnungen von Flags von Test Lab (oder Flank) zu DDP. Folgen Sie dieser Anleitung, um Ihre Tests manuell zu migrieren. Unter Von Firebase Test Lab zur Developer Device Platform migrieren finden Sie Automatisierungstools, Vorteile, wichtige Unterschiede und Migrationstipps.

Sharding-Migration

DDP modernisiert Sharding-Konfigurationen, indem es sowohl das komplexe Cloud Storage-basierte Smart Sharding von Flank als auch das einheitliche Sharding von Test Lab nativ ersetzt.

Einheitliches Sharding

  • Legen Sie dazu --sharding-option=uniform fest.

  • Legen Sie --uniform-sharding-count={count} fest (1–20 für physische, 1–200 für virtuelle).

  • Altes Firebase Test Lab: --num-uniform-shards {N}

  • DDP-Befehlszeilentool: --sharding-option=uniform --uniform-sharding-count={N}

Smart Sharding

  • Legen Sie dazu --sharding-option=smart fest.
  • Legen Sie --smart-sharding-target-duration={duration} fest (z.B. 2m, 10m, 1h; gültiger Bereich: 2m bis 1h).
  • Legen Sie --smart-sharding-record-name={record_name} fest (verweist auf den YAML-Tracking-Eintrag in --bucket-name unter automation/smart-sharding/).
  • Legen Sie --smart-sharding-max-shard-count={max_count} fest (optionales Höchstlimit: 0–20 für physische, 0–200 für virtuelle).

Verwendung von Zeitmetadaten aus den letzten 30 Tagen:

  • Legacy-Flank:

    max-test-shards: 10
shard-time: 120
smart-flank-gcs-path: gs://my-bucket/smart-sharding/timing-record.yaml

  • DDP-CLI:

    --sharding-option=smart \
--smart-sharding-max-shard-count=10 \
--smart-sharding-target-duration=2m \
--smart-sharding-record-name=timing-record \
--bucket-name=my-bucket

Deklarative YAML-Konfiguration (--flags-file)

Für komplexe Konfigurationen oder Teams, die lieber versionierte Dateien als lange Terminalbefehle verwenden, bietet gcloud einen universellen --flags-file-Argument-Vorprozessor (siehe $ gcloud topic flags-file):

gcloud beta device-run sessions submit instrumentation --flags-file=device-run-flags.yaml

Hier ist ein Beispiel für Flags für mehrwertige Listen und Wörterbücher:

# device-run-flags.yaml
--device:
  -   mediumphone-arm-32
  -   shiba-36
--apps:
  -   app-debug.apk
  -   test-helper.apk
--test: app-debug-androidTest.apk
--bucket-name: my-bucket
--sharding-option: smart
--smart-sharding-target-duration: 2m
--smart-sharding-record-name: timing-record
--paths-to-pull:
  -   /sdcard/screenshots
  -   /sdcard/coverage.ec
--additional-test-options:
  coverage: "true"
  clearPackageData: "true"

Beispiele für die End-to-End-Befehlsübersetzung

Konkrete Beispiele finden Sie in diesen Standard- und komplexen Übersetzungen.

Beispiel: Standard-Instrumentierungstest ausführen

Alte Firebase CLI:

gcloud firebase test android run \
  --app=app-debug.apk \
  --test=app-debug-androidTest.apk \
  --device model=shiba,version=36 \
  --timeout=5m \
  --num-flaky-test-attempts=2 \
  --directories-to-pull=/sdcard/screenshots \
  --environment-variables key=value

Übersetzung mit der DDP CLI:

gcloud beta device-run sessions submit instrumentation \
  --device=shiba-36 \
  --apps=app-debug.apk \
  --test=app-debug-androidTest.apk \
  --instrumentation-timeout=5m \
  --flaky-test-attempts=3 \
  --paths-to-pull=/sdcard/screenshots \
  --additional-test-options key=value

Beispiel: Komplexe Flank-YAML-Konfiguration migrieren

Legacy-Flank-Konfiguration:

app: app-debug.apk
test: app-debug-androidTest.apk
device:
  -   model: shiba
    version: 36
shard-time: 120
smart-flank-gcs-path: gs://my-bucket/smart-sharding/timing-record.yaml

Übersetzung mit der DDP CLI:

gcloud beta device-run sessions submit instrumentation \
  --device=shiba-36 \
  --apps=app-debug.apk \
  --test=app-debug-androidTest.apk \
  --bucket-name=my-bucket \
  --sharding-option=smart \
  --smart-sharding-target-duration=2m \
  --smart-sharding-record-name=timing-record

Nach der Ausführung und dem Abrufen von Ergebnissen

Da DDP nicht mit einer grafischen Web-UI (wie der alten Firebase-Konsole) gestartet wird, müssen Entwickler Ergebnisse direkt über die CLI oder programmatische REST APIs verwalten, beschreiben und prüfen:

# 1. List active and completed test sessions
gcloud beta device-run sessions list

# 2. Get a summary and direct Cloud Storage bucket link of a session's results
gcloud beta device-run sessions describe session-number

# 3. Get detailed metadata and print full results
gcloud beta device-run sessions describe session-number --full

# 4. Cancel a running session (replaces console cancellation)
gcloud beta device-run sessions cancel session-number

Referenz zur Flag-Zuordnung

Hier finden Sie die Flag-Zuordnung für die Migration von Testkonfigurationen von Flank oder gcloud firebase test android/ios run zum neuen DDP-Befehl gcloud beta device-run sessions submit instrumentation.

Wichtige Parameter und Assets

Legacy-Parameter (Test Lab / Flank) Ziel-DDP-Parameter Format-/Konvertierungslogik
--app --apps Liste Wenn mehrere Anwendungs-APKs/AABs bereitgestellt werden, übergeben Sie sie alle an --apps in der Reihenfolge, in der sie auf dem Gerät installiert werden sollen. Der Pfad kann lokal oder in Cloud Storage (gs://...) sein.
--test --test ERFORDERLICH String. Pfad zum Test-APK mit Instrumentation-Tests, entweder lokal oder in Cloud Storage.
--client-details --labels Dictionary mit key=value-Paaren, die an die Testsitzung angehängt werden sollen.

Gerätekonfiguration und ‑targeting

Legacy-Parameter (Test Lab / Flank) Ziel-DDP-Parameter Format-/Konvertierungslogik
--device model={M},version={V} --device={M}-{V} ERFORDERLICH String, der Modell und Betriebssystemversion einer einzelnen --device-ID zuordnet. Für das DDP-Flag --device können mehrere durch Kommas getrennte Geräte-IDs angegeben werden (z. B. --device=shiba-34,tokay-36) oder mehrere --device-Flags, die jeweils eine eindeutige Geräte-ID angeben (z. B. --device=shiba-34 --device=tokay-36).
--device locale={L} --locale={L} String Ordnet das Geräte-Locale dem --locale-Flag der obersten Ebene zu (language-region, z. B. --locale=en-US), um das Gerät vor dem Ausführen des Tests zu wechseln.
--device orientation={O} --orientation={O} String Ordnet die Geräteausrichtung dem --orientation-Flag der obersten Ebene (portrait oder landscape) zu.
– --coordinates String Simuliert die GPS-Standortkoordinaten des Geräts (z. B. --coordinates=37.4220,-122.0841).

Ausführungskontrolle und Instabilität

Legacy-Parameter (Test Lab / Flank) Ziel-DDP-Parameter Format-/Konvertierungslogik
--num-flaky-test-attempts {R} --flaky-test-attempts {A} Ganzzahl. Die maximale Anzahl von Ausführungsversuchen pro Testshard. Wiederholungsanzahl R in die Gesamtzahl der Versuche A umwandeln: A = R + 1 (Standardwert: 1).
– --flaky-test-parallel-retry Boolean. Gibt an, ob Testfehler parallel wiederholt werden sollen (standardmäßig false für die sequenzielle Ausführung).
– --flaky-test-retry-level String Gibt an, ob die Wiederholung auf der Ebene von shard oder auf der Ebene der einzelnen test erfolgen soll (Standardeinstellung ist shard).
--async --async Boolean. Maps 1:1 Der Befehl wird standardmäßig synchron ausgeführt. Übergeben Sie diesen Wert, um sofort zum Terminal zurückzukehren. Wird sofort nach dem Hochladen der Datei beendet und gibt Vorgangs- und Sitzungs-IDs aus.

Test-Runner und Ziele

Legacy-Parameter (Test Lab / Flank) Ziel-DDP-Parameter Format-/Konvertierungslogik
--environment-variables --additional-test-options Dictionary mit Optionen, die an den Instrumentierungstest-Runner übergeben werden. In --test-targets unterstützte Formate sind hier nicht zulässig.
--test-targets --test-targets Dictionary mit Testzielen oder Zielfiltern, die ausgeführt werden sollen. Jedes Ziel muss mit dem Paketnamen oder Klassennamen, der Schlüssel wie package, notPackage, class, notClass, annotation, notAnnotation und size unterstützt, voll qualifiziert werden. Die Formate testfile oder notTestfile werden nicht unterstützt.
--use-orchestrator --orchestrator-version Ob Android Test Orchestrator verwendet werden soll. Akzeptiert auto (Standard-Orchestrator) oder einen bestimmten Versionsstring (z. B. 1.6). Verfügbare Versionen können mit gcloud beta device-run software-versions list abgefragt werden.
--test-runner-class --test-runner-class String Die vollständig qualifizierte Klasse des Instrumentierungstest-Runners (z. B. com.foo.MyRunner) verwenden. Wenn nicht angegeben, wird eine Standard-Runner-Klasse durch Untersuchen des Anwendungsmanifests bestimmt.
--directories-to-pull --paths-to-pull Liste Verzeichnisse, die nach dem Testlauf vom Gerät heruntergeladen werden sollen.
--other-files --other-files-to-push Dictionary. Durch Kommas getrennte SOURCE=DEST-Liste mit Hilfsdateien, die vor dem Testlauf auf das Gerät übertragen werden sollen.

Ausgabe und Speicherung

Legacy-Parameter (Test Lab / Flank) Ziel-DDP-Parameter Format-/Konvertierungslogik
--results-bucket --bucket-name String Cloud Storage-Bucket, in den Testartefakte wie lokale Eingabedateien, Testausgabedateien und Smart Sharding-Zeitaufzeichnungen hochgeladen werden (Standardwert ist gs://[PROJECT_ID]-devicerun, sofern nicht anders angegeben).
--results-dir Automatisch verwaltet Nicht unterstützt. Unterpfade werden in Cloud Storage automatisch unter automation/sessions/{session_id}/ organisiert.

Sharding-Konfiguration

Legacy-Parameter (Test Lab / Flank) Ziel-DDP-Parameter Format-/Konvertierungslogik
--num-uniform-shards {N} --sharding-option=uniform --uniform-sharding-count={N} String und Integer. Die kombinierte Flag-Konfiguration aktiviert sowohl die einheitliche Sharding-Strategie als auch die maximale Anzahl von Shards (gültiger Bereich: 1–20 physisch, 1–200 virtuell).
Flanke --max-test-shards {N} --sharding-option=smart --smart-sharding-max-shard-count={N} String und Integer. Die kombinierte Flag-Konfiguration aktiviert sowohl die Smart-Sharding-Strategie als auch die maximale Anzahl von Shards (gültiger Bereich: 0–20 physisch, 0–200 virtuell).
Flanke --shard-time {S} --sharding-option=smart --smart-sharding-target-duration={S} ERFORDERLICH String. Aktiviert Smart Sharding mit Zielausführungszeit (z. B. 2m, 10m, 1h). Gültiger Bereich: 2m bis 1h.
Flanke --smart-flank-gcs-path --smart-sharding-record-name={name} --bucket-name={bucket} ERFORDERLICH String. Name des Sharding-Datensatz-YAML (ohne Dateiendung) in --bucket-name unter smart-sharding/ in Cloud Storage.

Android-spezifische Flags

In dieser Tabelle sehen Sie, wie die alten gcloud firebase test android run-Flags den neuen device-run-Flags zugeordnet werden:

Legacy-Parameter (firebase android) Ziel-DDP-Parameter Format-/Konvertierungslogik
--additional-apks --apps Liste Fügen Sie zusätzliche Listenwerte direkt in die Hauptliste --apps ein.
– --bugreport String Erfassen Sie eine vollständige bugreport vom Gerät (Werte: always, on-failure).
– --dumpsys String Systemstatus mit dumpsys erfassen (Werte: always, on-failure).
--timeout --instrumentation-timeout Dauer (z. B. 10m, 20s, 1h). Gültiger Bereich: 1m bis 3h (Standardwert: 5m).
--record-video --video String Gibt an, wann während des Testlaufs ein Video des Gerätebildschirms aufgezeichnet werden soll.Gültige Werte sind always oder on-failure.

iOS-spezifische Flags

In dieser Tabelle sehen Sie, wie die alten gcloud firebase test ios run-Flags den neuen device-run-Flags zugeordnet werden:

Legacy-Parameter (firebase ios) Ziel-DDP-Parameter Format-/Konvertierungslogik
--test --test Pfad zur erstellten XCTest-ZIP-Datei.
--device model={M},version={V} --device={M}-{V} String mit der ID des Zielgeräts.
--timeout --xctest-timeout Dauer (z.B. 5m). Bereich: 1m bis 1h.
--xcode-version --xcode-version Katalog-ID oder Versionsstring von Xcode, die verwendet werden soll (z. B. xcode-16-4 oder 16.4). Verfügbare Versionen können mit gcloud beta device-run software-versions list abgefragt werden.
--results-bucket --bucket-name GCS-Bucket für benutzerdefiniertes Ziel.
--async --async Standardmäßig synchron. Übergabe zum sofortigen Beenden.
--other-files --other-files-to-push Wörterbuch im Format SOURCE=BUNDLE_ID:DEST.
--directories-to-pull --paths-to-pull Liste im Format BUNDLE_ID:DEVICE_PATH.
--additional-ipas --additional-apps Liste der zu installierenden Helper-IPAs vor dem Test.
--xctestrun-file --xctestrun-file Pfad zur benutzerdefinierten .xctestrun-Plist-Datei.
--num-flaky-test-attempts --flaky-test-attempts Ganzzahl für die Anzahl der Wiederholungsversuche, z.B. 3.
--client-details --labels Schlüssel/Wert-Paare (KEY=VALUE).

Feedback und Fragen

Wenden Sie sich an uns, um Fehler zu melden und Feature-Anfragen zu stellen oder unserem Diskussionsforum beizutreten.