Die CTS-Testergebnisse werden in der folgenden Datei gespeichert:
CTS_ROOT/android-cts/results/start_time.zip
Wenn Sie die CTS selbst erstellt haben, CTS_ROOT ähnelt
out/host/linux-x86/cts unterscheidet sich aber je nach Plattform. Dies ist der Pfad, in dem
Sie die vorgefertigte offizielle CTS-Version
die Sie von dieser Website heruntergeladen haben entpackt haben.
In der ZIP-Datei enthält die Datei „test_result.xml“ die tatsächlichen Ergebnisse.
Ergebnisse für Android 10 und höher anzeigen
Die Datei „test_result.html“ ist im ZIP-Archiv enthalten. Sie können sie direkt in einem beliebigen HTML5-kompatiblen Webbrowser öffnen.
Ergebnisse für Android-Versionen vor Android 10 anzeigen
Öffnen Sie die Datei „test_result.xml“ in einem beliebigen HTML5-kompatiblen Webbrowser, um die Testergebnisse anzusehen.
Wenn in dieser Datei im Chrome-Browser eine leere Seite angezeigt wird,
ändern Sie die Browserkonfiguration
um das --allow-file-access-from-files Befehlszeilen-Flag 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üheren Versionen „Device Information“ (Geräteinformationen) (Link über der Testzusammenfassung) aus, um Details zum Gerät, zur Firmware (Hersteller, Modell, Firmware-Build, Plattform) und zur Gerätehardware (Bildschirmauflösung, Tastatur, Bildschirmtyp) anzusehen. In CTS v2 werden keine Geräteinformationen angezeigt.
Testzusammenfassung
Im Abschnitt Test Summary (Testzusammenfassung) finden Sie Details zum ausgeführten Testplan, z. B. den Namen des CTS-Plans sowie die Start- und Endzeiten der Ausführung. Außerdem wird eine zusammenfassende Übersicht über die Anzahl der Tests angezeigt, die bestanden, fehlgeschlagen oder abgelaufen sind oder nicht ausgeführt werden konnten.
Beispiel für eine CTS-Testzusammenfassung für Android 10
Abbildung 1:Beispiel für eine CTS-Testzusammenfassung für Android 10
Beispiel für eine CTS v2-Testzusammenfassung
Abbildung 2:Beispiel für eine CTS v2-Testzusammenfassung
Beispiel für eine CTS v1-Testzusammenfassung
Abbildung 3:Beispiel für eine CTS v1-Testzusammenfassung
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 Testfall und die ausgeführten Tests aufgeführt. Außerdem wird das Ergebnis der Testausführung angezeigt: „Pass“ (Bestanden), „Fail“ (Fehlgeschlagen), „Timed out“ (Zeitüberschreitung) oder „Not executed“ (Nicht ausgeführt). Im Falle eines Testfehlers werden Details zur Diagnose der Ursache bereitgestellt.
Darüber hinaus ist der Stacktrace des Fehlers in der XML-Datei verfügbar, aber nicht im Bericht enthalten, um ihn kurz zu halten. Wenn Sie die XML-Datei mit einem Texteditor ansehen, sollten Sie Details zum Testfehler finden (suchen Sie nach dem Tag [Test] , das dem fehlgeschlagenen Test entspricht, und suchen Sie darin nach dem Tag [StackTrace] ).
Beispiel für einen CTS v2-Testbericht ansehen
Abbildung 4:Beispiel für einen CTS v2-Testbericht
Beispiel für einen CTS v1-Testbericht ansehen
Abbildung 5:Beispiel für einen CTS v1-Testbericht
„test_result.xml“ auf unvollständige Testmodule prüfen
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. Wenn Sie ermitteln möchten, welche Module vollständig 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.
Testfehler priorisieren
Verwenden Sie die folgenden Vorschläge, um Testfehler zu priorisieren.
- Prüfen Sie, ob Ihre CTS-Umgebung richtig eingerichtet ist, wenn ein Test aufgrund falscher Vorbedingungen fehlschlägt. Dazu gehören die physische Umgebung, die Einrichtung des Desktopcomputers und die Einrichtung des Android-Geräts.
- Prüfen Sie die Gerätestabilität, die Testeinrichtung oder die Umgebungsprobleme, wenn ein Test übermäßig instabil ist.
- Wiederholen Sie den Test isoliert, wenn er immer noch fehlschlägt.
- Prüfen Sie, ob externe Faktoren Testfehler verursachen, z. B.:
- Umgebungseinrichtung. Eine falsch konfigurierte Einrichtung des Desktopcomputers kann beispielsweise die Ursache für Testfehler auf allen zu testenden Geräten (einschließlich Referenzgeräten) sein.
- Externe Abhängigkeiten. Wenn ein Test beispielsweise auf allen Geräten an mehreren Standorten ab einem bestimmten Zeitpunkt fehlschlägt, ist möglicherweise eine fehlerhafte URL die Ursache.
- Wenn das zu testende Gerät den Sicherheitspatch nicht enthält, ist ein Fehler beim Sicherheitstest zu erwarten.
- Validieren und analysieren Sie die Unterschiede zwischen Geräten, bei denen der Test bestanden wurde, und Geräten, bei denen er fehlgeschlagen ist.
- Analysieren Sie die Assertion, das Log, den Fehlerbericht und die CTS-Quelle. Bei einem HostTest können Assertion und Log sehr allgemein sein. Daher ist es hilfreich, auch das Geräte-Logcat zu prüfen und anzuhängen.
- Senden Sie einen Patch zur Testverbesserung, um Testfehler zu reduzieren.
Teilergebnisse speichern
Tradefed speichert keine Teilergebnisse, wenn der Testaufruf fehlschlägt.
Wenn Tradefed keine Testergebnisse generiert, ist während des Testlaufs ein schwerwiegendes Problem aufgetreten, sodass das Testergebnis nicht zuverlässig ist. Das Teilergebnis ist nicht hilfreich, da es bei der Untersuchung von Geräteproblemen keinen Mehrwert bietet.