Device Run auf der Entwicklergeräteplattform

Vorschau

Dieses Produkt oder Feature unterliegt den "Nutzungsbedingungen für Pre-GA-Angebote" 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.

In diesem Leitfaden 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. Dabei wird davon ausgegangen, dass Sie ein Konto und ein Projekt haben. Google Cloud

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 für eine Zusammenfassung der Befehle.

Hinweis

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

Außerdem muss ein Android-Instrumentierungstest bereit sein. Eine Anleitung finden Sie unter Instrumentierte Tests erstellen.

Darüber hinaus 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.

Tipp: Hängen Sie an jeden gcloud-Befehl --help an, um detaillierte Informationen zur Verwendung zu erhalten.

Testen

Nachdem Sie nun 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.

Tipp: Wenn Sie alle verfügbaren Flags aufrufen möchten, führen Sie gcloud beta device-run sessions submit instrumentation --help aus.

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 in etwa 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 mit mehreren durch Kommas getrennten Geräte-IDs an, z. B. --device shiba-34,tokay-36, oder mit mehreren --device-Flags, die jeweils eine andere Geräte-ID angeben (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 jedes Mal, wenn Sie den Befehl ausführen, 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 ihre Cloud Storage-Pfade (gs://) verwenden, um Zeit beim Hochladen zu sparen.

Tipp: Wenn Sie alle verfügbaren Optionen für den Befehl submit instrumentation aufrufen möchten, führen Sie gcloud beta device-run sessions submit instrumentation --help aus.

Der Befehl sessions submit instrumentation blockiert standardmäßig bei Sitzungsergebnissen. Das bedeutet, dass er auf den Abschluss des Testlaufs wartet und Ergebnisse wie die 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 aufteilen. 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.

**Achtung** :Das Sharding von Tests kann mehr kosten. Durch das Test-Sharding wird zwar die Zeit verkürzt, die für die Ausführung aller Tests benötigt wird, aber der Aufwand für das Starten Ihrer App auf jedem Shard kann die Zeiten für einzelne Geräte verlängern.

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 aufteilen, 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.

Hinweis: Die Anzahl der Shards ist konfigurierbar. Wenn die Developer Device Platform viele Shards parallel ausführt, können Testläufe durch die Verfügbarkeit von Geräten eingeschränkt werden. Aus diesem Grund empfehlen wir, dass die Anzahl der Geräte, die im Flag --device angegeben sind, kleiner oder gleich der Anzahl der Shards ist.

Einheitliches Sharding

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

gcloud beta device-run sessions submit instrumentation \
    --test path/to/test.apk \
 --device shiba-34,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 aufteilen 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= in den Befehl sessions submit instrumentation ein:

gcloud beta device-run sessions submit instrumentation \
    --test path/to/test.apk \
    --device shiba-34,shiba-35,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 drei ausgeführte Jobs enthalten:

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

Mit dem folgenden Befehl können Sie alle laufenden und abgeschlossenen Sitzungen auflisten:

gcloud beta device-run sessions list

Sie erhalten eine Ausgabe mit der Liste der Sitzungen in Ihrem Projekt, die in etwa 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
session-67cd0570                              2026-07-16T08:25:55.474Z  DONE
session-17cc299c                              2026-07-14T14:31:33.649Z  DONE
session-911d0763                              2026-07-09T00:39:02.051Z  DONE
session-4e943fea                              2026-07-15T23:08:32.252Z  DONE
session-0132e458                              2026-08-20T18:33:19.751Z  DONE
session-1077f07b                              2026-07-28T22:35:43.848Z  DONE
session-71b054c6                              2026-07-15T01:15:41.643Z  DONE
session-4f8b2e45                              2026-08-06T23:11:56.161Z  DONE

Der Befehl sessions list unterstützt alle Standard-gcloud-Flag Optionen. Beispiel:

gcloud beta device-run sessions list --limit 5

Das Ergebnis sieht in etwa so aus:

SESSION_ID                            START_TIME                STATE
session-4825e153                      2026-07-28T16:38:43.155Z  DONE
session-813ca602                      2026-07-28T22:40:32.415Z  DONE
93ec2df2-d5bf-4c36-b7f7-c2a4fb0dc3ce  2026-07-03T05:10:58.015Z  DONE
session-67cd0570                      2026-07-16T08:25:55.474Z  DONE
session-17cc299c                      2026-07-14T14:31:33.649Z  DONE

Wenn Sie alle laufenden Sitzungen finden möchten, führen Sie Folgendes aus:

gcloud beta device-run sessions list --filter RUNNING

Wenn Sie laufende Sitzungen haben, sehen Sie Ergebnisse wie die folgenden:

SESSION_ID        START_TIME  STATE
session-d7ff8b81              RUNNING

Andernfalls erhalten Sie die Meldung Listed 0 items.

Wenn Sie eine laufende Sitzung abbrechen möchten, führen Sie diesen Befehl mit Ihrer Sitzungs-ID aus:

gcloud beta device-run sessions cancel your_session_id

Der Befehl wird sofort zurückgegeben, da die Sitzung nur zum Abbrechen markiert ist. Der Abbruch erfolgt asynchron im Back-End.

Wenn die Sitzung bereits beendet ist, wird nur der aktuelle Status ausgegeben. Das Anfordern des Abbruchs für eine beendete Sitzung ist kein Fehler.

Nächste Schritte

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