Von Firebase Test Lab und Flank zur Developer Device Platform mit KI migrieren

Dieser Skill unterstützt Sie bei der Übersetzung von Legacy-Testlaufkonfigurationen und ‑Arbeitsabläufen (aus Flank oder gcloud firebase test) in die moderne, ressourcenorientierte gcloud beta device-run-Befehlszeile.

Zuordnung von Befehls- und Ressourcenstruktur

In der Device Run CLI werden Befehle nach Ressource organisiert: devices, software-versions und sessions:

1. Gerätekatalog (devices)

  • Geräte auflisten:
    • Legacy (Alt): gcloud firebase test android/ios models list
    • Neu: gcloud beta device-run devices list [--filter="..."]
    • Beispiel: gcloud beta device-run devices list --filter="platform:android"
  • Gerät beschreiben:
    • Legacy (Alt): gcloud firebase test android/ios models describe {MODEL}
    • Neu: gcloud beta device-run devices describe {DEVICE}
    • Beispiel: gcloud beta device-run devices describe redfin-30
  • Gerätekapazitäten und Flottenverfügbarkeit prüfen:
    • Legacy: gcloud firebase test android/ios list-device-capacities
    • Neu: Direkt in die Geräteressource eingebettet (availability.capacity und availability.available). Mit gcloud beta device-run devices describe {DEVICE} prüfen oder direkt mit gcloud beta device-run devices list --filter="availability.capacity=CAPACITY_HIGH" filtern.

2. Softwareversionen (software-versions)

  • Unterstützte Softwareversionen auflisten (Xcode und Android Test Orchestrator):
    • Legacy (Alt): gcloud firebase test ios xcode-versions list
    • Neu: gcloud beta device-run software-versions list
  • Softwareversion beschreiben:
    • Neu: gcloud beta device-run software-versions describe {SOFTWARE_VERSION}
    • Beispiel: gcloud beta device-run software-versions describe xcode-16-4

3. Automatisierungssitzungen (sessions)

  • Android-Instrumentierung einreichen:
    • Legacy: gcloud firebase test android run --type=instrumentation ...
    • Neu: gcloud beta device-run sessions submit instrumentation ...
  • iOS‑XCTest einreichen:
    • Legacy (Alt): gcloud firebase test ios run --type=xctest ...
    • Neu: gcloud beta device-run sessions submit xctest ...
  • Auf Abschluss der Sitzung warten:
    • Legacy: Nur synchrones CLI-Blocking
    • Neu: gcloud beta device-run sessions wait {SESSION}
  • Sitzung beschreiben / untersuchen:
    • Alt: Weblink in der Firebase Console / Cloud Tool Results ansehen
    • Neu: gcloud beta device-run sessions describe {SESSION} [--full]
  • List Past Sessions (Vergangene Sitzungen auflisten):
    • Legacy: Matrixverlauf in der Webkonsole ansehen
    • Neu: gcloud beta device-run sessions list
  • Sitzung abbrechen:
    • Legacy: Nur Webkonsole (kein CLI-Befehl)
    • Neu: gcloud beta device-run sessions cancel {SESSION}

Referenztabellen für die Flag-Zuordnung

In der folgenden Tabelle werden Parameter aus dem alten Firebase Test Lab und Flank ihren unterstützten Entsprechungen in gcloud beta device-run zugeordnet:

Testtyp Featuregruppe Alter Parameter (firebase/Flank) Zielparameter (device-run) Format-/Konvertierungslogik
Gemeinsam (Android und iOS) Wichtige Parameter und Assets Flanke --project --project Standard Google Cloud globaler Flag (--project=PROJECT_ID) oder aktive Google Cloud CLI-Konfiguration.
Allgemein (Android und iOS) Wichtige Parameter und Assets --client-details --labels Dictionary mit Schlüssel/Wert-Paaren.
Allgemein (Android und iOS) Gerätekonfiguration und ‑targeting --device model={M},version={V} --device={M}-{V} Ordnet das Kartenmodell und die Betriebssystemversion dem --device-ID-String zu. Akzeptiert eine durch Kommas getrennte Liste mehrerer Geräte in einem einzelnen Flag (z. B. --device=mediumphone-arm-32,shiba-36).
Gemeinsam (Android und iOS) Ausführungskontrolle und Instabilität --async --async Maps 1:1 Der Befehl bleibt standardmäßig synchron. Übergeben Sie diesen Parameter, um sofort zurückzukehren. Mit gcloud beta device-run sessions wait <SESSION_ID> überwachen oder warten.
Gemeinsam (Android und iOS) Ausführungskontrolle und Instabilität --num-flaky-test-attempts {R} --flaky-test-attempts {A} Ganzzahl. Wandeln Sie die Anzahl der Wiederholungsversuche $R$ in das Limit für die Gesamtzahl der Versuche um: $A = R + 1$ (Standardwert: 1).
Gemeinsam (Android und iOS) Ausführungskontrolle und Instabilität – --flaky-test-parallel-retry Boolean. Gibt an, ob Testfehler parallel noch einmal versucht werden sollen (standardmäßig sequenziell).
Gemeinsam (Android und iOS) Ausführungskontrolle und Instabilität – --flaky-test-retry-level String Wiederholungsversuch: shard oder test (Standard: shard).
Gemeinsam (Android und iOS) Ausgabe und Speicherung --results-bucket --bucket-name Bucket, in den Testausgabe-Artefakte hochgeladen werden (standardmäßig gs://[PROJECT_ID]-devicerun).
Gemeinsam (Android und iOS) Ausgabe und Speicherung --results-dir Automatisch verwaltet Das Festlegen benutzerdefinierter Unterverzeichnisse wird nicht unterstützt. Alle Testartefakte werden automatisch unter automation/sessions/{session_id}/ im Bucket organisiert, der durch --bucket-name angegeben wird.
Gemeinsam (Android und iOS) Ausgabe und Speicherung --record-video --video Gültige Werte: always oder on-failure.
Gemeinsam (Android und iOS) Ausgabe und Speicherung --directories-to-pull --paths-to-pull Liste der Pfade, die nach dem Ausführen vom Gerät abgerufen werden sollen.
Allgemeine Android- Wichtige Parameter und Assets --app --apps Liste Wenn mehrere Anwendungs-APKs/AABs angegeben werden, müssen sie alle an --apps übergeben werden.
Allgemeine Android- Wichtige Parameter und Assets --additional-apks --apps Liste Führen Sie zusätzliche Listenwerte direkt in die Hauptliste --apps ein.
Allgemeine Android- Wichtige Parameter und Assets --obb-files --other-files-to-push Dictionary im Format SOURCE=DEST. OBB-Dateien direkt an den Gerätepfad senden (/sdcard/Android/obb/{package_name}/)
Allgemeine Android- Wichtige Parameter und Assets --other-files --other-files-to-push Dictionary im SOURCE=DEST-Format.
Allgemeine Android- Gerätekonfiguration und ‑targeting --device locale={L} --locale={L} Ordnet das Gebietsschema des Geräts dem Flag der obersten Ebene --locale zu (language-region, z. B. --locale=en-US) verwenden.
Allgemeine Android- Gerätekonfiguration und ‑targeting --device orientation={O} --orientation={O} Ordnet die Geräteausrichtung dem Flag --orientation auf oberster Ebene zu (portrait oder landscape).
Allgemeine Android- Gerätekonfiguration und ‑targeting – --coordinates Koordinaten für simulierte Standortdaten (latitude,longitude, z. B. 37.4220,-122.0841).
Allgemeine Android- Ausführungskontrolle und Instabilität --grant-permissions Automatisierte Standardeinstellung Automatisiert Laufzeitberechtigungen werden standardmäßig automatisch gewährt (entspricht --grant-permissions=all).|
Allgemeine Android- Ausgabe und Speicherung – --dumpsys Sammeln Sie Dumpsys-Daten vom Gerät (always oder on-failure).
Allgemeine Android- Ausgabe und Speicherung – --bugreport Erfasse einen Fehlerbericht vom Gerät (always oder on-failure).
Android-Instrumentierung Wichtige Parameter und Assets --type=instrumentation sessions submit instrumentation Die Struktur des Unterbefehls bestimmt den Testtyp anstelle eines --type-Flags.
Android-Instrumentierung Wichtige Parameter und Assets --test --test Pfad zur Binärdatei mit Instrumentierungstests.
Android-Instrumentierung Ausführungskontrolle und Instabilität --timeout --instrumentation-timeout Dauer (z. B. 10m, 20s, 1h). Gültiger Bereich: 1m bis 3h (Standardwert: 5m).
Android-Instrumentierung Ausführungskontrolle und Instabilität --num-uniform-shards {N} --sharding-option=uniform
--uniform-sharding-count={N} 		Durch die Flag-Konfiguration wird eine einheitliche Sharding-Strategie aktiviert (gültiger Zählbereich: 1–20 physisch, 1–200 virtuell).
Android-Instrumentierung Ausführungskontrolle und Instabilität Flanke --shard-time {S} --sharding-option=smart
--smart-sharding-target-duration={S} 		Aktiviert Smart Sharding mit der Zielausführungszeit (z. B. 2m, 10m, 1h). Gültiger Bereich: 2m bis 1h.
Android-Instrumentierung Ausführungskontrolle und Instabilität Flanke --smart-flank-gcs-path --smart-sharding-record-name={name}
--bucket-name={bucket} 		Name des Sharding-Datensatz-YAML (ohne Erweiterung) in --bucket-name unter automation/smart-sharding/.
Android-Instrumentierung Ausführungskontrolle und Instabilität Flanke --max-test-shards {N} --smart-sharding-max-shard-count={N} Wird einem maximalen Shard-Grenzwert zugeordnet, wenn Smart Sharding aktiviert ist (0–20 physisch, 0–200 virtuell).
Android-Instrumentierung Test-Runner und Ziele --test-runner-class --test-runner-class Vollständig qualifizierte Runner-Klasse.
Android-Instrumentierung Test-Runner und Ziele --test-targets --test-targets Wörterbuch mit Unterstützung für Schlüssel wie package, notPackage, class, notClass, annotation, notAnnotation und size. Formate wie testfile oder notTestfile werden nicht unterstützt.
Android-Instrumentierung Test-Runner und Ziele --use-orchestrator --orchestrator-version Akzeptiert auto (Standard-Orchestrator) oder einen bestimmten Versionsstring (z. B. 1.6).
Android-Instrumentierung Test-Runner und Ziele --environment-variables --additional-test-options Dictionary mit Optionen, die an den Test-Runner übergeben werden. In --test-targets unterstützte Formate sind hier nicht zulässig.
Gängige iOS-Versionen Wichtige Parameter und Assets --additional-ipas --additional-apps Liste der .ipa-Dateien, die vor dem Testlauf auf dem Gerät installiert werden sollen.
Gängige iOS-Versionen Wichtige Parameter und Assets --other-files --other-files-to-push Dictionary im SOURCE=BUNDLE_ID:DEVICE_PATH-Format.
Gängige iOS-Versionen Ausgabe und Speicherung --directories-to-pull --paths-to-pull Liste der Dateien oder Verzeichnisse, die nach dem Test im Format BUNDLE_ID:DEVICE_PATH abgerufen werden sollen.
Nur iOS XCTest Wichtige Parameter und Assets --type=xctest sessions submit xctest Die Struktur des Unterbefehls bestimmt den Testtyp anstelle eines --type-Flags.
Nur iOS XCTest Wichtige Parameter und Assets --test --test Der Pfad zur ZIP-Datei mit der iOS-App und den XCTest-Dateien.
Nur iOS XCTest Ausführungskontrolle und Instabilität --timeout --xctest-timeout Maximal zulässige Dauer für den XCTest-Lauf (gültiger Bereich: 1m bis 1h, Standardwert: 5m).
Nur iOS XCTest Test-Runner und Ziele --xctestrun-file --xctestrun-file Der Pfad zur benutzerdefinierten .xctestrun-Datei.
Nur iOS XCTest Test-Runner und Ziele --xcode-version --xcode-version Katalog-ID oder Versionsstring von Xcode, der verwendet werden soll (z. B. xcode-16-4 oder 16.4). Abfrage mit software-versions list.

Praxistaugliche Übersetzungsanleitung

Befolgen Sie diese Richtlinien, um Firebase Test Lab- und Flank-Konfigurationen in Geräteausführungen zu übersetzen:

1. Gerätespezifikationen

In gcloud beta device-run akzeptiert --device eine durch Kommas getrennte Liste von Modell- und Versions-ID-Strings. Im Gegensatz zu Firebase, wo ein --device-Flag pro Gerät erforderlich war, können mit „device-run“ mehrere Geräte in einem Flag angegeben werden. Gerätesprache, Ausrichtung und Mock-Koordinaten werden mit separaten Flags der obersten Ebene angegeben:

  • ❌ --device model=MediumPhone.arm,version=32,locale=en,orientation=portrait
  • ✅ --device=mediumphone-arm-32 --locale=en-US --orientation=portrait

2. Wörterbücher und Listen

Kommagetrennte Flags in Listen (--apps, --paths-to-pull) oder Schlüssel-Wert-Paare (--other-files-to-push, --additional-test-options) umwandeln:

  • ❌ --other-files /sdcard/file1.txt=local/file1.txt,/sdcard/file2.txt=local/file2.txt
  • ✅ --other-files-to-push local/file1.txt=/sdcard/file1.txt,local/file2.txt=/sdcard/file2.txt

3. Fragmentierungsstrategien

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

4. Asynchrone Ausführung

  • Asynchron & Warten: Wenn --async angegeben ist, gibt die CLI sofort die erstellte Sitzungs-ID zurück. Sie können in CI/CD-Workflows mit folgenden Methoden auf den Abschluss einer Sitzung warten: gcloud beta device-run sessions wait <SESSION_ID>

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

!NOTE Warum sind Schlüssel für -- erforderlich? gcloud fügt YAML-Schlüssel direkt als Befehlszeilen-Flags in den CLI-Parser ein. Jeder Schlüssel in der YAML-Datei muss mit -- beginnen (z. B. --device:, --apps:). Ohne -- lehnt gcloud sie als unbekannte Positionsargumente ab.

Hier ein Beispiel für Flags mit mehrwertigen Listen und Wörterbüchern:

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

Beispielübersetzungen

Anhand dieser Beispiele können Sie Ihre vorhandenen Firebase Test Lab- und Flank-Konfigurationen in geräteausgeführte Tests übersetzen.

Firebase Test Lab für die Ausführung auf Geräten

firebase cmd:

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 coverage=true

Übersetzt:

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 coverage=true

Flank-Konfigurationen für Geräteausführung

flank options (flank.yml):

gcloud:
  app: app-debug.apk
  test: app-debug-androidTest.apk
  device:
    -   model: mediumphone-arm
      version: 32
  shard-time: 120
  smart-flank-gcs-path: gs://my-bucket/automation/smart-sharding/timing-record.yaml

Wird übersetzt als:

Übersetzen Sie direkt in den modernen CLI-Befehl:

gcloud beta device-run sessions submit instrumentation \
  --device=mediumphone-arm-32 \
  --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

Option 2: Deklarative YAML-Flags-Datei (--flags-file)

Wenn Sie Konfigurationen lieber in einer versionsverwalteten YAML-Datei als in Shell-Script-Strings verwalten möchten, verwenden Sie das integrierte --flags-file-Feature von gcloud:

# device-run-flags.yaml
# Note: gcloud requires keys to start with '--'
--device:
  -   mediumphone-arm-32
--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

Über die Befehlszeile einreichen:

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

Sie können auch Flags in der Befehlszeile anhängen oder überschreiben, z. B. durch Hinzufügen von --async.

Gerätekatalog-Erkennung

listing & inspecting devices:

# List all available Android devices
gcloud beta device-run devices list --filter="platform:android"

# Filter devices with high fleet capacity (replaces legacy list-device-capacities)
gcloud beta device-run devices list --filter="availability.capacity=CAPACITY_HIGH"

# Describe a specific device (OS versions, form factors, orientation, locales, capacity)
gcloud beta device-run devices describe redfin-30

Vollständiger Sitzungslebenszyklus in CI/CD

submitting, waiting, and inspecting sessions:

# 1. Submit asynchronously and capture session ID
SESSION_ID=$(gcloud beta device-run sessions submit instrumentation \
  --apps=app-debug.apk \
  --test=app-debug-androidTest.apk \
  --device=mediumphone-arm-32 \
  --async \
  --format="value(name)")

# 2. Wait for session completion in CI/CD pipeline
gcloud beta device-run sessions wait "$SESSION_ID"

# 3. Describe session summary (or pass --full for complete details)
gcloud beta device-run sessions describe "$SESSION_ID"

# 4. Cancel a running session if aborted
gcloud beta device-run sessions cancel "$SESSION_ID"