Testergebnisse für die Entwicklergeräteplattform aufrufen

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/

So suchen Sie in der Weboberfläche der Google Cloud Console nach Ihren Logs:

  1. Hängen Sie in einem Browser den Projektnamen, wie er im Befehl gcloud config set project verwendet wird, an die URL https://console.cloud.google.com/?project= an und laden Sie die Seite.
  2. Maximieren Sie das Menü oben links.
  3. Suchen Sie nach Cloud Storage.
  4. Wählen Sie im Speichermenü die Option Buckets aus.
  5. Klicken Sie in der ersten Spalte auf den Namen Ihres Projekts.
  6. Klicke auf Automatisierung.
  7. Klicken Sie auf Sitzungen.
  8. Fügen Sie im Feld Filter die Sitzungs-ID aus dem letzten Testlauf ein (siehe Testausgabe).
  9. Klicken Sie auf den Namen der Sitzung.
  10. 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.
  11. Öffnen Sie execution-* (oder execution-*-rerun-*, wenn Wiederholungen instabiler Tests mit --flaky-test-attempts konfiguriert 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.
  12. 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.log für die Rohausgabe des Instrumentierungs-Runners und logcat.txt für das geräteweite Android-Systemprotokoll. Wenn die Option mit --bugreport, --dumpsys oder --video aktiviert ist, enthält das Ausführungsverzeichnis auch bugreport.zip, dumpsys.txt und 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, sowie logcat.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 --video aktiviert ist, wird jedes aufgezeichnete Video des UI-Testlaufs unter testcases/TEST_CLASS/TEST_METHOD/video.mp4 gespeichert.
  • Abgerufene Gerätedateien, die mit --paths-to-pull angegeben wurden, werden im Unterordner artifacts/ des Ausführungsverzeichnisses gespeichert.
    • Bei Android-Ausführungen behalten abgerufene Dateien ihren Gerätepfad unter artifacts/ bei (z. B. artifacts/sdcard/output.txt oder artifacts/data/local/tmp/results.json).
    • Bei iOS-XCTest-Ausführungen werden Dateien, die mit --paths-to-pull=BUNDLE_ID:DEVICE_PATH aus einem App-Datencontainer abgerufen werden, nach Paket-ID unter artifacts/ organisiert:
      • Wenn com.example.app die zu testende App ist, wird sie direkt unter artifacts/output.txt gespeichert.
      • Wenn com.example.app eine zusätzliche App (--additional-apps) ist, wird sie unter artifacts/com.example.app-genfiles/output.txt gespeichert.

Zusätzliche Dokumentation

Nächste Schritte

Als Nächstes können Sie die Device Streaming API der Developer Device Platform ausprobieren.