Device Run auf der Entwicklergeräteplattform

In dieser Anleitung wird beschrieben, wie Sie mit der gcloud beta device-run CLI einen Android-Instrumentierungstest ausführen und die Ergebnisse in der Google Cloud Console aufrufen. Dazu benötigen Sie ein Konto und ein Google Cloud Projekt.

Wenn Sie diese Google Cloud CLI verwenden möchten, müssen Sie Ihre Google Cloud Projekt ID angeben.

Hinweis

Bei diesen Schritten wird davon ausgegangen, dass Sie bereits ein Google Cloud Projekt erstellt, die Einrichtungsschritte im Schnellstartleitfaden zur Developer Device Platform ausgeführt und sich im Terminal mit gcloud authentifiziert haben.

Außerdem muss ein Android-Instrumentierungstest zur Ausführung bereit sein. Weitere Informationen finden Sie unter Instrumentierte Tests erstellen.

Außerdem sollten Sie die Geräte-IDs der Geräte ermittelt haben, auf denen Sie Ihre Arbeitslasten ausführen möchten. Eine Anleitung finden Sie unter Geräteverzeichnis.

Testen

Nachdem Sie die IDs der Geräte kennen, die zum Testen Ihrer App verfügbar sind, können Sie Geräte mit dem gcloud beta device-run sessions submit instrumentation Befehl und dem --device Flag angeben, um Instrumentierungstests auszuführen.

Führen Sie zum Ausführen des Tests einen Befehl aus, der dem folgenden ähnelt, aber Ihre eigenen Geräte-IDs und Ihren Testpfad enthält:

gcloud beta device-run sessions submit instrumentation \
--device shiba-34 \
--apps /path/to/app.apk \
--test /path/to/test.apk

Der Ordner mit dem Ergebnisbericht des Jobs befindet sich unter einem Cloud Storage-Pfad wie gs://<your_project_id>/automation/sessions/session-id/. Den Link finden Sie in der Testausgabe. Er sieht so aus: https://console.cloud.google.com/storage/browser/your_project_id/automation/sessions/session-id/.

Testlauf konfigurieren

Nachdem Sie einen Test ausgeführt haben, können Sie einige Konfigurationsoptionen ausprobieren:

  • Wenn Sie dieselben Tests auf mehreren Geräten ausführen möchten, geben Sie das --device Flag mehrmals an, z. B. --device shiba-34 --device tokay-36.
  • Optional können Sie mit dem Flag --apps=path1,path2,...,path_n eine oder mehrere APKs angeben, die vor dem Ausführen der Tests installiert werden sollen. Die Reihenfolge, in der Sie sie angeben, ist die Reihenfolge, in der diese Apps installiert werden.
  • Sie müssen Ihre Test-APK mit dem Flag --test angeben.
  • Wenn Sie mit den Flags --apps oder --test einen lokalen Pfad angeben, kopiert die Google Cloud CLI ihn bei jeder Ausführung des Befehls automatisch in Ihren Cloud Storage-Bucket unter gs://my-project-id/automation/inputs/date_time_four_chars_suffix/.
  • Da das Hochladen großer APKs zeitaufwendig sein kann, können Sie direkt auf Ihre APKs verweisen, indem Sie die gs://-Pfade von Cloud Storage verwenden, um Zeit beim Hochladen zu sparen.

Der Befehl sessions submit instrumentation blockiert standardmäßig bei Sitzungsergebnissen. Das bedeutet, dass er wartet, bis der Testlauf abgeschlossen ist, und Ergebnisse ähnlich den folgenden ausgibt:

Using the default Cloud Storage bucket [gs://<my-project-id>] for input and result files. Will create the bucket if it does not exist.
Uploading [app.apk].
Uploading [test.apk].

Initiated long-running operation [operation-number] to create session.
Creating session [session-id] in location [global].
Result files will be stored at [https://console.cloud.google.com/storage/browser/<my-project-id>/automation/sessions/session-id/].
Waiting for session [session-id] to complete....done.

Session [session-id] finished with result [FAILED].
JOB NAME  EXECUTION NAME  EXECUTION RESULT
job-000   all             FAILED: 2 test cases failed, 5 passed

Wenn Sie den Befehl asynchron ausführen möchten, fügen Sie das Flag --async ein. Dadurch kann der Befehl sofort beendet werden, nachdem Dateien in Cloud Storage hochgeladen und die Vorgangs-ID und Sitzungs-ID ausgegeben wurden. Sie können mit dem Befehl operations wait und der Vorgangs-ID auf die Ausführung warten. Er wird blockiert, bis der Job abgeschlossen ist:

gcloud beta device-run operations wait your_operation_id

Sharding verwenden

Wenn Sie die Developer Device Platform in einen CI/CD-Workflow (Continuous Integration und Continuous Delivery) einbeziehen möchten, sollten Sie Ihre Tests sharden. Beim Test-Sharding wird eine Reihe von Tests in Untergruppen (Shards) unterteilt, die separat und isoliert ausgeführt werden. Die Developer Device Platform führt jeden Shard automatisch parallel auf mehreren Geräten aus und schließt die gesamte Testreihe in kürzerer Zeit ab.

Sharding-Optionen

Wenn Ihre Jobs nur eine kleine Anzahl von Testfällen haben oder die Gesamtausführungszeit aller Testfälle nicht lang ist, ist es nicht erforderlich, Sharding zu verwenden. Wenn Sie eine große Anzahl von Testfällen haben oder die Gesamtausführungszeit aller Testfälle lang ist, sollten Sie Sharding verwenden.

Die Developer Device Platform unterstützt sowohl intelligentes als auch einheitliches Sharding. Bei der Entscheidung, wie Sie Ihre Tests sharden, sollten Sie die folgenden Optionen berücksichtigen:

  • Wenn alle Testfälle ungefähr gleich viel Zeit in Anspruch nehmen, verwenden Sie einheitliches Sharding, indem Sie alle Testfälle in n Shards aufteilen.

  • Wenn die Ausführungszeit der verschiedenen Testfälle stark variiert, verwenden Sie intelligentes Sharding. Die Developer Device Platform verwendet die bisherige Testausführungszeit, um verschiedene Shards zu erstellen, und versucht, alle Shards in einer ähnlichen Zeit abzuschließen.

Einheitliches Sharding

Wenn Sie Ihre Tests mit einheitlichem Sharding sharden möchten, fügen Sie die Flags --sharding-option=uniform und --uniform-sharding-count= wie folgt in den Befehl sessions submit instrumentation ein:

gcloud beta device-run sessions submit instrumentation \
    --test path/to/test.apk \
    --device shiba-34 \
    --device tokay-36 \
    --sharding-option=uniform \
    --uniform-sharding-count=2

Die Ausgabe sollte Job status: 2 running enthalten. Der Dienst erstellt zwei Jobs, einen für jedes Gerät. Da die Eingaben für beide Jobs identisch sind, zentralisiert der Dienst die Validierung und führt sie nur einmal aus.

Die beiden Jobs werden in der endgültigen Ausgabe des Befehls nach Abschluss separat aufgeführt:

JOB NAME  EXECUTION NAME  EXECUTION RESULT
job-000   execution-000   PASSED
job-001   execution-000   PASSED

Intelligentes Sharding

Wenn Sie Ihre Tests mit intelligentem Sharding sharden möchten, fügen Sie die Flags --sharding-option=smart, --smart-sharding-max-shard-count=, --smart-sharding-target-duration= (in Minuten oder 1 Stunde) und --smart-sharding-record-name= wie folgt in den Befehl sessions submit instrumentation ein:

gcloud beta device-run sessions submit instrumentation \
    --test path/to/test.apk \
    --device shiba-34 \
    --device shiba-35 \
    --device tokay-36 \
    --sharding-option=smart \
    --smart-sharding-max-shard-count=3 \
    --smart-sharding-target-duration=5m \
    --smart-sharding-record-name=test.yaml

Die endgültige Ausgabe sollte angeben, dass drei Jobs ausgeführt wurden:

Session [session-3cd0564a] finished with result [ERROR].
JOB NAME  EXECUTION NAME  EXECUTION RESULT
job-000   execution-000   PASSED
job-001   execution-000   PASSED
job-002   execution-000   PASSED

Hier ist eine Zusammenfassung der hier verwendeten Flags für intelligentes Sharding:

  • --smart-sharding-max-shard-count=SMART_SHARDING_MAX_SHARD_COUNT : Specify the maximum number of shards to create for smart sharding. Wenn nicht festgelegt oder auf 0 gesetzt, werden vom System definierte Höchstwerte verwendet. Der gültige Bereich liegt zwischen 0 und 20 für physische Geräte und zwischen 0 und 200 für virtuelle Geräte.--smart-sharding-max-shard-count: Gibt die maximale Anzahl der zu erstellenden Shards an. Die Anzahl der im Flag --device angegebenen Geräte muss kleiner oder gleich diesem Wert sein.

  • --smart-sharding-target-duration=SMART_SHARDING_TARGET_DURATION : Gibt die Zielausführungszeit (z.B. 2 Minuten, 10 Minuten, 1 Stunde) pro Shard für intelligentes Sharding an. Der gültige Bereich liegt zwischen 2 Minuten und 1 Stunde. Erforderlich, wenn --sharding-option=smart.

  • --smart-sharding-record-name=SMART_SHARDING_RECORD_NAME : Gibt den Namen der Aufzeichnungsdatei für intelligentes Sharding ohne Dateiendung an. Erforderlich, wenn `--sharding-option=smart`. Diese YAML-Datei befindet sich im Google Cloud Storage-Bucket, der mit --bucket-name angegeben wurde, im smart-sharding/ Verzeichnis. Wenn die Datei nicht vorhanden ist, wird sie automatisch erstellt. Andernfalls wird ihr Inhalt nach Abschluss der Sitzung aktualisiert.

Testlauf untersuchen und verwalten

Sowohl im asynchronen als auch im synchronen Modus des Befehls sessions submit instrumentation können Sie mit dem Befehl sessions describe den Jobstatus während der Ausführung abfragen oder das Ergebnis nach Abschluss abrufen:

gcloud beta device-run sessions describe <session_id>

Die Ausgabe fasst die Testergebnisse zusammen und enthält Links zu den Ergebnissen in der Google Cloud Console. Beispiel:

Session [session-id] finished with result [FAILED].
Result files are stored at [https://console.cloud.google.com/storage/browser/your_project_id-devicerun/automation/sessions/session-id/].
JOB NAME  EXECUTION NAME  EXECUTION RESULT
job-000   all             FAILED: 2 test cases failed, 5 passed

Verwenden Sie den folgenden Befehl, um alle laufenden und abgeschlossenen Sitzungen aufzulisten:

gcloud beta device-run sessions list

Sie erhalten eine Ausgabe mit der Liste der Sitzungen in Ihrem Projekt, die so aussieht:

SESSION_ID                                    START_TIME                STATE
session-4825e153                              2026-07-28T16:38:43.155Z  DONE
session-813ca602                              2026-07-28T22:40:32.415Z  DONE

Führen Sie diesen Befehl mit Ihrer Sitzungs-ID aus, um eine laufende Sitzung abzubrechen:

gcloud beta device-run sessions cancel your_session_id

Nächste Schritte

Als Nächstes müssen Sie Logs suchen und analysieren.