Ü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-Testing-CLI: gcloud beta device-run

In diesem Leitfaden 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. 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).

  • Legacy 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. Dieser Wert 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 alpha 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 Übersetzung von Befehlen

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

Beispiel: Standard-Instrumentierungstest ausführen

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

DDP-CLI-Übersetzung:

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 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 ist die Flag-Zuordnung für die Migration von Testkonfigurationen von Flank oder gcloud firebase test android/ios run zu den neuen DDP-Befehlen gcloud beta device-run sessions submit instrumentation und gcloud alpha device-run sessions submit xctest.

Wichtige Parameter und Assets

Legacy-Parameter (Test Lab / Flank) Ziel-DDP-Parameter Format / Conversion-Logik
--app --apps Liste Wenn mehrere APKs/AABs für die Anwendung bereitgestellt werden, übergeben Sie sie alle an --apps, und zwar 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 Instrumentierungstests, 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 das Modell und die Betriebssystemversion einem einzelnen --device-ID-String zuordnet. Das Flag --device von DDP akzeptiert mehrere Geräte-IDs, die durch Kommas getrennt sind (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. Täuscht GPS-Standortkoordinaten des Geräts vor (z. B. --coordinates=37.4220,-122.0841).

Ausführungskontrolle und Unzuverlässigkeit

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 Test-Fragment. 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 wiederholt werden sollen (standardmäßig false für die sequenzielle Ausführung).
– --flaky-test-retry-level String Definiert, ob die Wiederholung auf der Ebene shard oder auf der Ebene einzelner 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 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 / 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 Wörterbuch der auszuführenden Testziele oder Zielfilter. Jedes Ziel muss mit dem Paketnamen oder Klassennamen, der Schlüssel wie package, notPackage, class, notClass, annotation, notAnnotation und size unterstützt, vollständig qualifiziert werden. Die Formate testfile und notTestfile werden nicht unterstützt.
--use-orchestrator --orchestrator-version Gibt an, ob Android Test Orchestrator verwendet werden soll. Nimmt 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 Instrumentierungstest-Runner-Klasse (z. B. com.foo.MyRunner) zu 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 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 hochgeladen werden, einschließlich lokaler Eingabedateien, Testausgabedateien und Zeitaufzeichnungen für Smart Sharding (Standardwert ist gs://[PROJECT_ID]-devicerun, wenn nicht angegeben).
--results-dir Automatisch verwaltet Nicht unterstützt. Unterpfade werden in Cloud Storage automatisch unter automation/sessions/{session_id}/ organisiert.

Fragmentierungskonfiguration

Legacy-Parameter (Test Lab / Flank) Ziel-DDP-Parameter Format / Konvertierungslogik
--num-uniform-shards {N} --sharding-option=uniform --uniform-sharding-count={N} String und Ganzzahl. Durch die kombinierte Flag-Konfiguration wird sowohl die einheitliche Sharding-Strategie aktiviert als auch die maximale Anzahl von Shards festgelegt (gültiger Bereich: 1–20 physische, 1–200 virtuelle Shards).
Flanke --max-test-shards {N} --sharding-option=smart --smart-sharding-max-shard-count={N} String und Integer. Die kombinierte Flag-Konfiguration aktiviert die Smart Sharding-Strategie und legt die maximale Shard-Anzahl fest (gültiger Bereich: 0–20 physische, 0–200 virtuelle Shards).
Flanke --shard-time {S} --sharding-option=smart --smart-sharding-target-duration={S} ERFORDERLICH String. Aktiviert intelligentes 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 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ühren Sie zusätzliche Listenwerte direkt in der Hauptliste --apps zusammen.
– --bugreport String Erfassen Sie einen vollständigen 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. Wann während des Testlaufs ein Video des Gerätebildschirms aufgenommen werden soll.Gültige Werte sind always oder on-failure.

iOS-spezifische Flags

In dieser Tabelle werden die alten gcloud firebase test ios run-Flags den neuen device-run-Entsprechungen zugeordnet:

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 Geräte-ID des Zielgeräts.
--device locale={L} --locale={L} String für die Zielsprache (language-region, z. B. --locale=en-US).
--timeout --xctest-timeout Dauer (z.B. 5m). Bereich: 1m bis 1h.
--xcode-version --xcode-version Katalog-ID oder Versionsstring von Xcode, der 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 Benutzerdefinierter GCS-Ziel-Bucket.
--async --async Standardmäßig synchron. Übergeben Sie den Wert, um die Ausführung sofort zu 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-plist.
--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 zu stellen oder unserem Diskussionsforum beizutreten.