Ü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 dieser Anleitung finden Sie Befehlszeilenübersetzungen und Zuordnungen von Flags aus Test Lab (oder Flank) zu DDP. Mit dieser Anleitung können Sie Ihre Tests manuell migrieren. Weitere Informationen zu Automatisierungstools, Vorteilen, wichtigen Unterschieden und Migrationstipps finden Sie unter Von Firebase Test Lab zur Developer Device Platform migrieren.

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.

Einheitliche Fragmentierung

  • 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 CLI: --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-Datensatz 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 Produkte, 0–200 für virtuelle Produkte).

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):

Android

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

iOS

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

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

Android

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

iOS

# device-run-flags.yaml
--device:

    -   iphonese3-18-4
    -   iphone16pro-18-3
--test: MyTests.zip
--additional-apps:
    -   helper-app.ipa
--xcode-version: '16.4'
--xctest-timeout: 15m
--other-files-to-push:
  /local/path/test-config.json: com.example.app:/Documents/test-config.json
--paths-to-pull:
    -   com.example.app:/Documents/screenshots
--labels:
  env: staging
  team: mobile-qa

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

Alte 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 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 Abrufen der Ergebnisse

Da DDP nicht mit einer grafischen Weboberfläche (wie die alte 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 / Conversion-Logik
--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 zur Test-APK mit Instrumentationstests, 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 / Conversion-Logik
--device model={M},version={V} --device={M}-{V} ERFORDERLICH String, der Modell und Betriebssystemversion einer einzelnen --device-ID zuordnet. Das --device-Flag von DDP akzeptiert mehrere durch Kommas getrennte Geräte-IDs (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 die Sprache des Geräts dem --locale-Flag der obersten Ebene zu (language-region, z. B. --locale=en-US), um das Gerät auszuwählen, auf das vor dem Ausführen des Tests gewechselt werden soll.
--device orientation={O} --orientation={O} String Ordnet die Geräteausrichtung dem --orientation-Flag auf oberster Ebene zu (portrait oder landscape).
– --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 / Conversion-Logik
--num-flaky-test-attempts {R} --flaky-test-attempts {A} Ganzzahl Die maximale Anzahl von Ausführungsversuchen pro Testshard. Anzahl der Wiederholungsversuche R in Gesamtzahl der Versuche A umwandeln: A = R + 1 (Standardwert: 1).
– --flaky-test-parallel-retry Boolean. Gibt an, ob Testfehler parallel noch einmal versucht werden sollen (standardmäßig false für die sequenzielle Ausführung).
– --flaky-test-retry-level String Gibt an, ob die Wiederholung auf shard- oder auf individueller test-Ebene erfolgen soll (Standardwert: shard).
--async --async Boolean. Maps 1:1 Der Befehl wird standardmäßig synchron ausgeführt. Geben Sie dies ein, um sofort zum Terminal zurückzukehren. Wird unmittelbar 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 / Conversion-Logik
--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 sein. 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 voll qualifizierte Instrumentierungstest-Runner-Klasse (z. B. com.foo.MyRunner) verwendet werden. 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 der Hilfsdateien, die vor dem Testlauf auf das Gerät übertragen werden sollen.

Ausgabe und Speicherung

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

Sharding-Konfiguration

Legacy-Parameter (Test Lab / Flank) Ziel-DDP-Parameter Format / Conversion-Logik
--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. Bei der kombinierten Flag-Konfiguration wird sowohl die Smart-Sharding-Strategie aktiviert als auch die maximale Anzahl von Shards festgelegt (gültiger Bereich: 0–20 physisch, 0–200 virtuell).
Flanke --shard-time {S} --sharding-option=smart --smart-sharding-target-duration={S} ERFORDERLICH String. Aktiviert das intelligente Sharding mit der 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 der YAML-Datei für den Sharding-Datensatz (ohne Dateiendung) in --bucket-name unter smart-sharding/ in Cloud Storage.

Android-spezifische Flags

In dieser Tabelle finden Sie die entsprechenden neuen device-run-Flags für die alten gcloud firebase test android run-Flags:

Legacy-Parameter (firebase android) Ziel-DDP-Parameter Format / Conversion-Logik
--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 finden Sie die entsprechenden neuen device-run-Flags für die alten gcloud firebase test ios run-Flags:

Legacy-Parameter (firebase ios) Ziel-DDP-Parameter Format / Conversion-Logik
--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 SOURCE=BUNDLE_ID:DEST-Format.
--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-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 Requests einzureichen oder an unserem Diskussionsforum teilzunehmen.