CTS-Ergebnisse interpretieren

Die CTS-Testergebnisse werden in der Datei gespeichert:

CTS_ROOT/android-cts/results/start_time.zip

Wenn Sie das CTS selbst erstellt haben, ähnelt CTS_ROOT out/host/linux-x86/cts, unterscheidet sich jedoch je nach Plattform. Dies entspricht dem Pfad, in dem Sie das vorgefertigte offizielle CTS, das Sie von dieser Website heruntergeladen haben, entpackt haben.

Die Datei „test_result.xml“ in der ZIP-Datei enthält die tatsächlichen Ergebnisse.

Ergebnisse für Android 10 und höher anzeigen

Im ZIP-Archiv ist eine Datei „test_result.html“ vorhanden. Sie können sie direkt in einem beliebigen HTML5-kompatiblen Webbrowser öffnen.

Ergebnisse für Versionen vor Android 10 anzeigen

Öffnen Sie die Datei „test_result.xml“ in einem beliebigen HTML5-kompatiblen Webbrowser, um die Testergebnisse aufzurufen.

Wenn in dieser Datei im Chrome-Browser eine leere Seite angezeigt wird, ändern Sie Ihre Browserkonfiguration, um das Befehlszeilenflag --allow-file-access-from-files zu aktivieren.

Testergebnisse lesen

Die Details der Testergebnisse hängen davon ab, welche CTS-Version Sie verwenden:

  • CTS v1 für Android 6.0 und niedriger
  • CTS v2 für Android 7.0 und höher

Geräteinformationen

Wählen Sie in CTS v1 und früher „Device Information“ (Geräteinformationen) aus (Link über der Testzusammenfassung), um Details zum Gerät, zur Firmware (Hersteller, Modell, Firmware-Build, Plattform) und zur Gerätehardware (Bildschirmauflösung, Tastatur, Bildschirmtyp) aufzurufen. In CTS v2 werden keine Geräteinformationen angezeigt.

Testzusammenfassung

Der Abschnitt Test Summary (Testzusammenfassung) enthält Details zum ausgeführten Testplan, z. B. den Namen des CTS-Plans sowie Start- und Endzeit der Ausführung. Außerdem wird eine zusammenfassende Übersicht über die Anzahl der Tests angezeigt, die bestanden, fehlgeschlagen oder nicht ausgeführt werden konnten oder bei denen das Zeitlimit überschritten wurde.

Zusammenfassung der CTS-Beispieltests für Android 10

Zusammenfassung der CTS-Tests für Android 10

Abbildung 1:Zusammenfassung des CTS-Beispieltests für Android 10

CTS v2 – Zusammenfassung der Beispieltests

Zusammenfassung der CTS v2-Tests

Abbildung 2:Zusammenfassung des CTS v2-Beispieltests

CTS v1 – Zusammenfassung der Beispieltests

Zusammenfassung der CTS v1-Tests

Abbildung 3:Zusammenfassung des CTS v1-Beispieltests

Testbericht

Im nächsten Abschnitt, dem CTS-Testbericht, finden Sie eine Zusammenfassung der bestandenen Tests pro Paket.

Danach folgen Details zu den tatsächlich ausgeführten Tests. Im Bericht werden das Testpaket, die Testsuite, der Testlauf und die ausgeführten Tests aufgeführt. Hier wird das Ergebnis der Testausführung angezeigt: bestanden, fehlgeschlagen, Zeitüberschreitung oder nicht ausgeführt. Bei einem Testfehler werden Details zur Diagnose der Ursache angegeben.

Außerdem ist der Stacktrace des Fehlers in der XML-Datei verfügbar, wird aber nicht in den Bericht aufgenommen, um ihn kurz zu halten. Wenn Sie die XML-Datei mit einem Texteditor öffnen, sollten Sie Details zum Testfehler finden. Suchen Sie dazu nach dem Tag [Test], das dem fehlgeschlagenen Test entspricht, und darin nach dem Tag [StackTrace].

CTS v2-Beispieltestbericht anzeigen

CTS v2-Testbericht

Abbildung 4:CTS v2-Beispieltestbericht

CTS v1-Beispieltestbericht anzeigen

CTS v1-Testbericht

Abbildung 5:CTS v1-Beispieltestbericht

Überprüfen Sie „test_result.xml“ auf unvollständige Testmodule.

Wenn Sie die Anzahl der unvollständigen Module in einer bestimmten Testsitzung ermitteln möchten, führen Sie den Befehl „list results“ aus. Die Anzahl der abgeschlossenen Module und die Gesamtzahl der Module werden für jede vorherige Sitzung aufgeführt. Um herauszufinden, welche Module abgeschlossen und welche unvollständig sind, öffnen Sie die Datei „test_result.xml“ und lesen Sie den Wert des Attributs „done“ für jedes Modul im Ergebnisbericht. Module mit dem Wert „done“ = „false“ wurden nicht vollständig ausgeführt.

Fehler bei Tests beheben

Mithilfe der folgenden Vorschläge können Sie Testfehler beheben.

  • Prüfen Sie, ob Ihre CTS-Umgebung korrekt eingerichtet ist, wenn ein Test aufgrund falscher Voraussetzungen fehlschlägt. Dazu gehören die physische Umgebung, die Einrichtung des Desktop-Computers und die Einrichtung des Android-Geräts.
  • Wenn ein Test übermäßig unzuverlässig erscheint, sollten Sie die Gerätestabilität, den Testaufbau oder Umgebungsprobleme überprüfen.
  • Wenn der Test weiterhin fehlschlägt, versuchen Sie es noch einmal.
  • Prüfen Sie, ob externe Faktoren zu Testfehlern führen, z. B.:
    • Umgebung einrichten Beispielsweise kann eine falsch konfigurierte Desktop-Einrichtung die Ursache für Testfehler auf allen zu testenden Geräten (DUTs), einschließlich Referenzgeräten, sein.
    • Externe Abhängigkeiten. Wenn ein Test beispielsweise auf allen Geräten auf mehreren Websites ab einem bestimmten Zeitpunkt fehlschlägt, liegt möglicherweise ein Problem mit einer URL vor.
    • Wenn das DUT den Sicherheitspatch nicht enthält, ist ein fehlgeschlagener Sicherheitstest zu erwarten.
  • Untersuchen Sie die Unterschiede zwischen Geräten, die den Test bestehen, und Geräten, die ihn nicht bestehen.
  • Analysieren Sie die Assertion, das Log, den Bugreport und die CTS-Quelle. Bei einem HostTest können Assertion und Log sehr allgemein sein. Daher ist es hilfreich, auch den Geräte-Logcat zu prüfen und anzuhängen.
  • Reichen Sie einen Patch zur Verbesserung des Tests ein, um Testfehler zu reduzieren.

Teilergebnisse speichern

Tradefed speichert keine Teilergebnisse, wenn der Testaufruf fehlschlägt.

Wenn Tradefed keine Testergebnisse generiert, ist davon auszugehen, dass während des Testlaufs ein schwerwiegendes Problem aufgetreten ist, das das Testergebnis unzuverlässig macht. Das Teilergebnis wird als nicht hilfreich eingestuft, da es bei der Untersuchung von Geräteproblemen keinen Mehrwert bietet.