In diesem Leitfaden wird beschrieben, wie Sie die Ergebnisse von Tests und ausführbaren Dateien finden, die gemäß dem Leitfaden Developer Device Platform Device Run ausgelöst wurden.
Hinweis
Bei diesen Schritten wird davon ausgegangen, dass Sie bereits ein Google Cloud -Projekt erstellt, die Einrichtungsschritte in der Kurzanleitung für die Developer Device Platform ausgeführt und sich im Terminal mit gcloud authentifiziert haben.
Über die Befehlszeile
Mit diesem Befehl und Ihrer Sitzungs-ID können Sie eine einfache Zusammenfassung des Testergebnisses oder des Ergebnisses der ausführbaren Datei aufrufen:
gcloud beta device-run sessions describe SESSION_ID
Die Ausgabe sieht in etwa so aus:
Session SESSION_ID finished with result [FAILED].
Result files are stored at [https://console.cloud.google.com/storage/browser/BUCKET_NAME/automation/sessions/SESSION_ID/].
JOB NAME EXECUTION NAME EXECUTION RESULT
job-000 all FAILED: 2 test cases failed, 5 passed
job-001 all PASS
Für jede Gerätetyp-ID, die Sie mit dem Flag --device angegeben haben, wird in der Sitzung ein Job generiert. Der Jobindex folgt der Reihenfolge Ihrer Geräte-IDs. Testfehler sind zu erwarten und sollten durch iterative Verbesserungen und Ausführungen untersucht und behoben werden.
Wenn Sie weitere Details zu einer Sitzung abrufen möchten, hängen Sie --full an den zuvor ausgeführten describe-Befehl an:
gcloud beta device-run sessions describe SESSION_ID --full
Die Ausgabe sieht in etwa so aus:
Android-Instrumentierung
name: projects/PROJECT_ID/locations/global/sessions/session-370961e1
sessionConfig:
displayName: instrumentation-session
jobConfigs:
- action:
androidInstrumentationTest:
testInstallable:
files:
- gcsInputFile:
path: gs://BUCKET_NAME/automation/inputs/2026-07-30_11:28.31915956_8514/app_name_test.apk
allocationConfig:
deviceConfigs:
- actions:
- androidInstallPackages:
installables:
- files:
- gcsInputFile:
path: gs://BUCKET_NAME/automation/inputs/2026-07-30_11:28.31915956_8514/app_name.apk
- androidLogcat: {}
requirement:
deviceId: pa3q-35
displayName: job-000
outputDirectoryConfig:
gcsOutputDirectory:
path: gs://BUCKET_NAME/automation/sessions
sessionReport:
endTime: '2026-07-30T03:30:05.838Z'
id: 6587313f-fdf7-418a-a9b9-b6fa98dff838
jobReports:
- displayName: job-000
endTime: '2026-07-30T03:30:04.601Z'
executionReports:
- displayName: all
endTime: '2026-07-30T03:30:02.151Z'
id: 29b167dd-dde9-4ea9-b2cd-738049083fc9
outputFiles:
- gcsOutputFile:
path: gs://PROJECT_ID-devicerun/automation/sessions/session-370961e1/job-000/execution-000/logcat.txt
- gcsOutputFile:
path: gs://PROJECT_ID-devicerun/automation/sessions/session-370961e1/job-000/execution-000/instrument.log
- gcsOutputFile:
path: gs://PROJECT_ID-devicerun/automation/sessions/session-370961e1/job-000/execution-000/junit.xml
result:
cause:
summary:
message: One or more test assertions or test methods failed. Inspect the
test runner logs and structured test results for details.
reason: TEST_CASE_FAILURE
type: CUSTOMER
resultType: FAILED
startTime: '2026-07-30T03:29:32.769Z'
status:
progressMessages:
- 2 test cases failed, 5 passed
statusType: DONE
id: 7974e37a-2928-4aaf-abba-3a8b6bae853b
result:
cause:
summary:
message: Job has one or more failed tests. See execution reports for details.
reason: JOB_HAS_FAILED_TESTS
resultType: FAILED
startTime: '2026-07-30T03:28:53.756Z'
status:
statusType: DONE
result:
cause:
summary:
message: Session has one or more failed jobs. See job reports for details.
reason: SESSION_HAS_FAILED_JOBS
resultType: FAILED
startTime: '2026-07-30T03:28:52.702Z'
status:
statusType: DONE
Ausführbare Android-Datei
name: projects/PROJECT_ID/locations/global/sessions/session-8a41c2b0
sessionConfig:
displayName: android-executable-session
jobConfigs:
- action:
androidNativeBinary:
androidNativeBinary:
gcsInputFile:
path: gs://BUCKET_NAME/automation/inputs/2026-07-30_11:28.31915956_8514/my_executable
args:
- --example_flag=/data/local/tmp/example_value
- --threads=4
allocationConfig:
deviceConfigs:
- actions:
- androidLogcat: {}
- androidPushFiles:
fileConfigs:
- destinationPath: /data/local/tmp/model.tflite
sourceFile:
gcsInputFile:
path: gs://BUCKET_NAME/automation/inputs/2026-07-30_11:28.31915956_8514/model.tflite
requirement:
deviceId: shiba-34
displayName: job-000
outputDirectoryConfig:
gcsOutputDirectory:
path: gs://BUCKET_NAME/automation/sessions
sessionReport:
endTime: '2026-07-30T03:30:05.838Z'
id: 4b9120ec-fdf7-418a-a9b9-b6fa98dff838
jobReports:
- displayName: job-000
endTime: '2026-07-30T03:30:04.601Z'
executionReports:
- displayName: execution-000
endTime: '2026-07-30T03:30:02.151Z'
id: 19a267dd-dde9-4ea9-b2cd-738049083fc9
outputFiles:
- gcsOutputFile:
path: gs://PROJECT_ID-devicerun/automation/sessions/session-8a41c2b0/job-000/execution-000/logcat.txt
- gcsOutputFile:
path: gs://PROJECT_ID-devicerun/automation/sessions/session-8a41c2b0/job-000/execution-000/output.log
result:
resultType: PASSED
startTime: '2026-07-30T03:29:32.769Z'
status:
statusType: DONE
id: 8874e37a-2928-4aaf-abba-3a8b6bae853b
result:
resultType: PASSED
startTime: '2026-07-30T03:28:53.756Z'
status:
statusType: DONE
result:
resultType: PASSED
startTime: '2026-07-30T03:28:52.702Z'
status:
statusType: DONE
iOS XCTest
Hier ist die tatsächliche bereinigte Ausgabe von gcloud beta device-run sessions
describe SESSION_ID --full aus einem Live-iOS-XCTest-Lauf mit allen aktivierten Flags:
name: projects/PROJECT_ID/locations/global/sessions/session-4b941167-5629-4abb-a8a1-a9814bf16847
sessionConfig:
displayName: xctest-session
jobConfigs:
- action:
iosXcTest:
testsZip:
gcsInputFile:
path: gs://BUCKET_NAME/automation/inputs/2026-10-09_11:33.01234567_ABCD/MyTests.zip
allocationConfig:
deviceConfigs:
- actions:
- iosInstallPackages:
ipas:
- gcsInputFile:
path: gs://BUCKET_NAME/automation/inputs/2026-10-09_11:33.01234567_ABCD/AdditionalApp.ipa
requirement:
deviceId: iphonese3-18-4
displayName: job-000
outputDirectoryConfig:
gcsOutputDirectory:
path: gs://BUCKET_NAME/automation/sessions
In dieser Ausgabe finden Sie die abgerufenen Dateien für die zu testende App unter .../artifacts/output.txt (ohne com.example.app/Documents/).
Im Webbrowser
Wenn Sie alle Details sehen möchten, laden Sie die URL zum Bucket mit Ihren Testergebnissen aus der Testausgabe. Sie sollte in etwa so aussehen:
https://console.cloud.google.com/storage/browser/BUCKET_NAME/automation/sessions/SESSION_ID/
Sitzungen werden im Speicher im folgenden Pfadformat angezeigt:
gs://BUCKET_NAME/automation/sessions/SESSION_ID/job-000/EXECUTION_ID/
Navigation
So suchen Sie in der Weboberfläche der Google Cloud Console nach Ihren Logs:
- Hängen Sie in einem Browser den Projektnamen, wie er im Befehl
gcloud config set projectverwendet wird, an die URLhttps://console.cloud.google.com/?project=an und laden Sie die Seite. - Maximieren Sie das Menü oben links.
- Suchen Sie nach Cloud Storage.
- Wählen Sie im Speichermenü die Option Buckets aus.
- Klicken Sie in der ersten Spalte auf den Namen Ihres Projekts.
- Klicke auf Automatisierung.
- Klicken Sie auf Sitzungen.
- Fügen Sie im Feld Filter die Sitzungs-ID aus dem letzten Testlauf ein (siehe Testausgabe).
- Klicken Sie auf den Namen der Sitzung.
- Wählen Sie job-* aus, um
junit.xml(für Android-Instrumentierung und iOS-XCTest-Ausführungen) aufzurufen. Diese Datei enthält zusammengeführte Ergebnisdetails für alle Ausführungen und Testfälle im Job. - Öffnen Sie execution-* (oder execution-*-rerun-*, wenn Wiederholungen instabiler Tests mit
--flaky-test-attemptskonfiguriert sind), um eine Aufschlüsselung der einzelnen Ausführungen oder Shards zu erhalten. Je nach Sitzungstyp und konfigurierten Flags kann dieser Ordner zahlreiche Artefakte enthalten. Weitere Informationen finden Sie unter Ergebnisse nachvollziehen. - Rufen Sie die öffentlichen und authentifizierten URLs auf, um die Ergebnisse zu sehen.
Dateistruktur
Sehen Sie sich die Logdateien in Ihrem Cloud Storage-Bucket an, um mehr über die Ausführung Ihrer Sitzung zu erfahren. Die Dateistruktur sieht so aus:
Android-Instrumentierung
- gs://BUCKET_NAME/automation
- inputs/
- 2026-05-29_10:13.026220_JZTM
- app.apk
- test.apk
- sessions/
- SESSION_ID
- job-000/
- junit.xml
- execution-000/
- artifacts/
- sdcard/
- output.txt
- bugreport.zip
- dumpsys.txt
- instrument.log
- junit.xml
- logcat.txt
- video.mp4
- execution-001/
- instrument.log
- junit.xml
- logcat.txt
- video.mp4
- job-001/
- SESSION_ID
Ausführbare Android-Datei
- gs://BUCKET_NAME/automation
- inputs/
- 2026-05-29_10:13.026220_JZTM
- my_executable
- model.tflite
- sessions/
- SESSION_ID
- job-000/
- execution-000/
- artifacts/
- data/
- local/
- tmp/
- results.json
- bugreport.zip
- dumpsys.txt
- logcat.txt
- output.log
- video.mp4
- job-001/
- SESSION_ID
iOS XCTest
- gs://BUCKET_NAME/
- automation/
- inputs/
- 2026-10-09_11:33.01234567_ABCD/
- AdditionalApp.ipa
- MyTests.zip
- data.txt
- sessions/
- SESSION_ID/
- job-000/
- execution-000/
- artifacts/
- output.txt
- junit.xml
- system.log
In dieser Ausgabe sehen Sie den abgerufenen Pfad unter artifacts/. Wenn für --paths-to-pull=com.example.app:/Documents/output.txt ein Pull-Vorgang aus der zu testenden App (AUT) ausgeführt wird, entfernt der Dienst /Documents und platziert die Datei direkt unter artifacts/output.txt (nicht artifacts/com.example.app/Documents/output.txt). Wenn ein Pull-Vorgang aus einer zusätzlichen App (--additional-apps) ausgeführt wird, wird die Datei unter artifacts/<bundle_id>-genfiles/output.txt platziert.
Was bedeuten die Ergebnisse?
Bei Android-Instrumentierungstests und iOS-XCTest-Ausführungen sind die in der Ausgabe generierten junit.xml-Dateien standardmäßige JUnit-XML-Dateien. In jedes execution-*-Verzeichnis wird eine junit.xml auf Ausführungsebene und in jedes job-*-Verzeichnis eine zusammengeführte junit.xml geschrieben. Diese Dateien enthalten die Ergebnisse pro Testmethode, sodass Sie den spezifischen Status (bestanden oder nicht bestanden), die Ausführungszeit und die Fehler-Traces für jede einzelne Testmethode prüfen können. Diese Dateien lassen sich problemlos in die meisten CI/CD-Systeme (Continuous Integration/Continuous Delivery) und Testberichtstools einbinden und parsen.
Zusätzlich zu den strukturierten Testergebnissen enthält jedes execution-*-Verzeichnis plattformspezifische Logs und Artefakte:
- Android-Instrumentierungsausführungen umfassen
instrument.logfür die Rohausgabe des Instrumentierungs-Runners undlogcat.txtfür das geräteweite Android-Systemprotokoll. Wenn die Option mit--bugreport,--dumpsysoder--videoaktiviert ist, enthält das Ausführungsverzeichnis auchbugreport.zip,dumpsys.txtund Bildschirmvideoaufnahmen. - Ausführungen von Android-Ausführbaren umfassen
output.log, das die Standardausgabe (stdout) und den Standardfehler (stderr) erfasst, die von Ihrer ausführbaren Datei geschrieben werden, sowielogcat.txt(standardmäßig für jeden Android-Job erfasst), das das geräteweite Android-Systemprotokoll zusammen mit optionalen--bugreport-,--dumpsys- oder--video-Artefakten erfasst. - iOS-XCTest-Ausführungen umfassen
system.log(standardmäßig für jeden iOS-XCTest-Job erfasst), das das unformatierte iOS-Geräte-Syslog erfasst, sowie alle.ips-Diagnoseabsturzberichte, wenn ein Prozess während der Testausführung abgestürzt ist. Wenn diese Option mit--videoaktiviert ist, wird jedes aufgezeichnete Video des UI-Testlaufs untertestcases/TEST_CLASS/TEST_METHOD/video.mp4gespeichert. - Abgerufene Gerätedateien, die mit
--paths-to-pullangegeben wurden, werden im Unterordnerartifacts/des Ausführungsverzeichnisses gespeichert.- Bei Android-Ausführungen behalten abgerufene Dateien ihren Gerätepfad unter
artifacts/bei (z. B.artifacts/sdcard/output.txtoderartifacts/data/local/tmp/results.json). - Bei iOS-XCTest-Ausführungen werden Dateien, die mit
--paths-to-pull=BUNDLE_ID:DEVICE_PATHaus einem App-Datencontainer abgerufen werden, nach Paket-ID unterartifacts/organisiert:- Wenn
com.example.appdie zu testende App ist, wird sie direkt unterartifacts/output.txtgespeichert. - Wenn
com.example.appeine zusätzliche App (--additional-apps) ist, wird sie unterartifacts/com.example.app-genfiles/output.txtgespeichert.
- Wenn
- Bei Android-Ausführungen behalten abgerufene Dateien ihren Gerätepfad unter
Zusätzliche Dokumentation
- Grundlagen des Testens von Android-Apps
- Instrumentierte Tests erstellen
- XCTest-Dokumentation
- Cloud Storage-Buckets
Nächste Schritte
Als Nächstes können Sie die Device Streaming API der Developer Device Platform ausprobieren.