Developer Device Platform – Übersicht über Geräteausführungen

Vorschau

Dieses Produkt oder diese Funktion unterliegt den „Pre-GA-Angebotsbedingungen“ im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Features sind "im Ist-Zustand" verfügbar und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie unter den Beschreibungen der Startphase.

Willkommen bei Developer Device Platform Device Run. Damit können Sie Tests und ausführbare Dateien auf physischen und virtuellen Android-Geräten sowie auf physischen iOS-Geräten in der Cloud ausführen. Auf dieser Seite werden die Funktionen zusammengefasst und die Gemeinsamkeiten zwischen der Ausführung von Android-Instrumentierungstests, ausführbaren Android-Dateien und iOS-XCTest-Tests beschrieben.

Wenn Sie von Firebase Test Lab zur Developer Device Platform migrieren, lesen Sie unsere Migrationsanleitung, die Übersetzung von Befehlen und Flags und die Migrationsfähigkeit für KI-Agenten.

Wenn Sie diese Google Cloud CLI verwenden möchten, müssen Sie Ihre Google Cloud -Projekt-ID angeben. Eine Zusammenfassung der Befehle finden Sie unter gcloud beta device-run.

Tipp: Hängen Sie --help an einen beliebigen gcloud-Befehl an, um detaillierte Nutzungsinformationen aufzurufen.

Hauptmerkmale

Developer Device Platform Device Run ist ein Dienst von Google Cloud , mit dem Sie automatisierte Test-Suites auf physischen und virtuellen Mobilgeräten ausführen können. Device Run wurde für moderne CI/CD-Workflows (Continuous Integration und Continuous Delivery) entwickelt und bietet eine Befehlszeilensteuerung über die Google Cloud CLI (gcloud beta device-run). So können Teams Test-Suites auf dedizierter Hardware und in virtuellen Umgebungen ausführen, verwalten und skalieren.

1. Plattformübergreifende automatisierte Tests

• Unterstützung für Android und iOS: Device Run unterstützt integrierte Test-Frameworks, darunter Android-Instrumentierungstests (.apk), ausführbare Android-Dateien (kompilierte Binärdateien) und iOS-XCTests (.ipa oder .zip).
• Flexibles Geräte-Targeting: Mit dem Flag --device können Sie bestimmte physische oder virtuelle Geräte, die im Gerätekatalog aufgeführt sind, anhand von Betriebssystem- und Modellkennungen (z.B. Pixel- oder iPhone-Modelle) als Ziel festlegen.
• Parallele Ausführung auf mehreren Geräten: Sie können identische Test-Suites gleichzeitig auf mehreren Geräten ausführen, indem Sie kommagetrennte Geräte-IDs angeben oder mehrere --device-Flags angeben.

2. Flexible Ausführungsmodi und Steuerelemente

• Synchrone und asynchrone Einreichungen: Testläufe werden standardmäßig synchron ausgeführt und zeigen nach Abschluss eine Zusammenfassung an. Wenn Sie das Flag --async hinzufügen, wird sofort eine Sitzungs-ID für die nicht blockierende Ausführung zurückgegeben, die später mit gcloud beta device-run sessions wait überwacht werden kann.
• Benutzerdefinierte Zeitlimits für die Ausführung*: Konfigurieren Sie Limits für die Ausführungsdauer mit --instrumentation-timeout oder --xctest-timeout.
• Wiederholungen instabiler Tests: Legen Sie mit dem Flag --flaky-test-attempts die maximale Anzahl von Wiederholungsversuchen für instabile Testausführungen fest.

3. Verwaltung von Softwareversionen und Abhängigkeiten

• Konfigurierbare Testumgebungen*: Sie können vor dem Starten von Testläufen bestimmte Versionen von Softwareumgebungen wie AndroidX Test Orchestrator und Apple Xcode finden, prüfen und auswählen.
• Versionserkennung: Verwenden Sie die Befehle gcloud beta device-run software-versions list und describe, um aktive Softwarepakete, unterstützte Betriebssystemversionen und Standardspezifikationen für die Laufzeit aufzurufen.

4. Speicher- und Artefaktverwaltung

• Cloud Storage-Integration: Testeingaben (APKs, IPAs, unterstützende Apps) und Ausgabeartefakte (Logs, Testberichte) werden in Cloud Storage gespeichert.
• Bucket-Flexibilität: Standardmäßig wird ein Projekt-Bucket mit dem Namen PROJECT_ID-devicerun verwendet oder die Weiterleitung erfolgt an einen benutzerdefinierten Bucket, der über das Flag --bucket-name angegeben wird. Sie haben die volle Kontrolle über diesen Bucket und müssen seinen Inhalt manuell entfernen, wenn er nicht mehr benötigt wird, oder die automatisierte Verwaltung des Lebenszyklus für den Bucket konfigurieren. Eine Anleitung finden Sie unter Informationen zum Löschen von Objekten.
• Direkte Cloud-Pfade: Verweisen Sie bei großen Dateien direkt auf vorhandene gs://-Pfade, um den Upload-Overhead zu vermeiden.

5. Erweiterte Android-Testfunktionen

• Android Test Orchestrator: Isoliert die Testausführung, indem jeder Test in einer eigenen Instrumentation-Instanz ausgeführt wird. Dadurch wird verhindert, dass der App-Status geteilt wird, und App-Abstürze werden isoliert.
• Test-Fragmentierung:
  • Gleichmäßiges Sharding: Testfälle werden gleichmäßig auf eine bestimmte Anzahl von Shards (--sharding-option=uniform) aufgeteilt.
  • Intelligentes Sharding: Verwendet Verlaufsdaten zur Testausführung, um Testfälle dynamisch auf Shards zu verteilen, wobei eine bestimmte Gesamtausführungsdauer (--sharding-option=smart) angestrebt wird.

6. Sitzungsverwaltung und ‑diagnose

• Vollständige Sitzungssteuerung: Sie können aktive oder historische Testläufe mit sessions list, sessions describe und sessions cancel auflisten, beschreiben, filtern oder abbrechen.
• Frühzeitige Eingabevalidierung: Führt eine automatische Validierung der eingereichten Testbinärdateien und Konfigurationsartefakte durch und zeigt bei Fehlern explizite Fehlerdetails und Ursachen (z. B. Abweichungen beim Zielpaket) an.

Wichtige Einstellungen

Erforderliche Flags

Diese Flags sind erforderlich:

• Gerät: Geben Sie ein Gerät mit --device: --device shiba-35 oder --device iphonese3-18-4 an.
• Test oder Ausführbare Datei: Geben Sie das Testpaket mit --test (--test /path/to/test.apk oder --test /path/to/MyTests.zip) für Testläufe an oder geben Sie die ausführbare Binärdatei oder das Script mit --executable (--executable /path/to/my_executable) für Android-Ausführungen an.

Die folgenden Konfigurationsoptionen sind für Device Run-Sitzungen üblich.

Cloud Storage-Pfade für Eingabe und Ausgabe

• Benutzerdefinierter Cloud Storage-Bucket: Sie können einen benutzerdefinierten Cloud Storage-Bucket für Ein- und Ausgaben angeben: --bucket-name=my-custom-bucket Wenn Sie keinen Cloud Storage-Bucket mit dem Flag --bucket-name= angeben, verwendet die Google Cloud CLI einen Standard-Bucket mit dem Namen PROJECT_ID-devicerun.
• Eingabedateien: Wenn Sie einen lokalen Pfad mit den Flags --test, --executable, --apps, --additional-apps, --other-files-to-push oder --xctestrun-file angeben, kopiert die Google Cloud CLI ihn bei jeder Ausführung des Befehls automatisch in Ihren Cloud Storage-Bucket unter gs://BUCKET_NAME/automation/inputs/DATE_TIME_FOUR_CHARS_SUFFIX/, wobei BUCKET_NAME standardmäßig PROJECT_ID-devicerun ist.
• Cloud-Pfade: Da das Hochladen großer Dateien zeitaufwendig sein kann, können Sie sie direkt über ihre Cloud Storage-gs://-Pfade referenzieren, um Uploadzeit zu sparen.
• Ergebnisdateien: Ausgabeartefakte werden in Ihren Cloud Storage-Bucket unter gs://BUCKET_NAME/automation/sessions/session-[SESSION_ID]/ hochgeladen.

Eingabevalidierung

Die Developer Device Platform versucht, Ihre Eingaben, einschließlich Artefakte, zu validieren. Wenn sie fehlerhafte Eingaben findet, gibt sie einen ERROR anstelle von PASSED oder FAILED zurück:

Session [session-94b57778] finished with result [ERROR].
JOB NAME  EXECUTION NAME  EXECUTION RESULT
job-000   execution-000   ERROR

Hängen Sie jetzt --full an den Befehl sessions describe an, um weitere Details zur Sitzung aufzurufen:

gcloud beta device-run sessions describe --full session-94b57778

Die Ausgabe sieht dann ungefähr so aus:

name: projects/user-test1/locations/global/sessions/session-94b57778
sessionConfig:
  displayName: instrumentation-session
  jobConfigs:
  -   action:
      androidInstrumentationTest:
        testInstallable:
          files:
          -   gcsInputFile:
              path: gs://user-test1-devicerun/automation/inputs/2026-09-16_18:55.17372947_EECF/my-test.apk
    allocationConfig:
      deviceConfigs:
      -   actions:
        -   androidLogcat: {}
        requirement:
          deviceId: mediumphone-arm-34
    displayName: job-000
  outputDirectoryConfig:
    gcsOutputDirectory:
      path: gs://user-test1-devicerun/automation/sessions
sessionReport:
  endTime: '2026-09-16T18:55:49.721Z'
  id: ed681f23-669b-4464-8a93-b28456e58136
  jobReports:
  -   displayName: job-000
    endTime: '2026-09-16T18:55:45.839Z'
    executionReports:
    -   displayName: execution-000
      endTime: '2026-09-16T18:55:46.694Z'
      id: ce370173-af94-4dd7-acc6-0863e4d2e9ec
      result:
        cause:
          summary:
            message: The instrumentation target package does not match any of the
              installable packages.
            reason: INSTRUMENTATION_TARGET_MISMATCH
            type: CUSTOMER
        resultType: ERROR
      startTime: '1970-01-01T00:00:00Z'
      status:
        statusType: PENDING
    id: 953b5106-3c20-40f0-aceb-18af89cd1b83
    result:
      cause:
        summary:
          message: The instrumentation target package does not match any of the installable
            packages.
          reason: INSTRUMENTATION_TARGET_MISMATCH
          type: CUSTOMER
      resultType: ERROR
    startTime: '2026-09-16T18:55:31.651Z'
    status:
      statusType: DONE
  result:
    resultType: ERROR
  startTime: '2026-09-16T18:55:24.442Z'
  status:
    statusType: DONE

Nächste Schritte

Android-Instrumentierungstests, ausführbare Android-Dateien oder iOS-XCTests mit der Developer Device Platform ausführen