Die CTS-Testergebnisse werden in der Datei abgelegt:
CTS_ROOT/android-cts/results/start_time.zip
Wenn Sie die CTS selbst erstellt haben, ähnelt CTS_ROOT out/host/linux-x86/cts, unterscheidet sich aber je nach Plattform. Dies ist der Pfad, unter dem Sie das vorkonfigurierte offizielle CTS dekomprimiert haben, das Sie von dieser Website heruntergeladen 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 befindet sich die Datei „test_result.html“. Sie können sie direkt in einem beliebigen HTML5-kompatiblen Webbrowser öffnen.
Ergebnisse 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 beim Verwenden des Chrome-Browsers eine leere Seite angezeigt wird, ändern Sie die Browserkonfiguration, um das Befehlszeilen-Flag --allow-file-access-from-files zu aktivieren.
Testergebnisse lesen
Die Details der Testergebnisse hängen davon ab, welche Version von CTS 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 niedriger die Option „Geräteinformationen“ (Link über der Testzusammenfassung) aus, um Details zum Gerät, zur Firmware (Marke, Modell, Firmware-Build, Plattform) und zur Gerätehardware (Bildschirmauflösung, Wähltastatur, Bildschirmtyp) aufzurufen. In CTS v2 werden keine Geräteinformationen angezeigt.
Testzusammenfassung
Im Abschnitt Testzusammenfassung finden Sie Details zum ausgeführten Testplan, z. B. den Namen des CTS-Plans und den Beginn und das Ende der Ausführung. Außerdem wird eine Gesamtübersicht über die Anzahl der Tests angezeigt, die bestanden, fehlgeschlagen, ein Zeitlimit überschritten oder nicht ausgeführt werden konnten.
Zusammenfassung des CTS-Beispieltests für Android 10
Abbildung 1:Testzusammenfassung für Android 10 CTS
Zusammenfassung des Beispieltests für CTS v2
Abbildung 2:Testzusammenfassung für CTS v2
Zusammenfassung des Beispieltests für CTS v1
Abbildung 3:Zusammenfassung des CTS-v1-Beispieltests
Testbericht
Der nächste Abschnitt, der CTS-Testbericht, enthält eine Zusammenfassung der bestandenen Tests pro Paket.
Darauf folgen Details zu den tatsächlich ausgeführten Tests. Der Bericht enthält das Testpaket, die Testsuite, den Testfall und die ausgeführten Tests. Hier sehen Sie das Ergebnis der Testausführung: „Bestanden“, „Fehlgeschlagen“, „Zeitüberschreitung“ oder „Nicht ausgeführt“. Im Falle eines Testfehlers werden Details zur Diagnose der Ursache bereitgestellt.
Der Stack-Trace des Fehlers ist in der XML-Datei verfügbar, wird aber aus Gründen der Übersichtlichkeit nicht in den Bericht aufgenommen. Wenn Sie die XML-Datei in 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].
Beispieltestbericht für CTS v2 ansehen
Abbildung 4:Beispiel für einen CTS v2-Testbericht
Beispieltestbericht für CTS v1 ansehen
Abbildung 5: CTS v1-Testbericht
test_result.xml auf unvollständige Testmodule prüfen
Um die Anzahl der unvollständigen Module in einer bestimmten Testsession zu ermitteln, führen Sie den Befehl „list results“ aus. Für jede vorherige Sitzung wird die Anzahl der abgeschlossenen Module und die Gesamtzahl der Module aufgeführt. Wenn Sie feststellen möchten, welche Module abgeschlossen sind und welche nicht, ö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.
Fehlgeschlagene Tests aussortieren
Anhand der folgenden Vorschläge können Sie Testfehler einstufen.
- Prüfen Sie, ob Ihre CTS-Umgebung richtig 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.
- Prüfen Sie die Gerätestabilität, die Testeinrichtung oder Umgebungsprobleme, wenn ein Test zu häufig fehlerhaft ist.
- Wiederholen Sie den Test, falls weiterhin ein Fehler auftritt.
- Prüfen Sie, ob externe Faktoren zu Testfehlern führen, z. B.:
- Umgebung einrichten Beispielsweise kann eine falsch konfigurierte Desktopcomputereinrichtung die Ursache für Testfehler bei allen Testgeräten (Device Under-Test, DUTs) (einschließlich Referenzgeräten) sein.
- Externe Abhängigkeiten. Wenn ein Test beispielsweise ab einem bestimmten Zeitpunkt auf allen Geräten auf mehreren Websites fehlschlägt, liegt möglicherweise eine fehlerhafte URL vor.
- Wenn DUT den Sicherheitspatch nicht enthält, ist das Fehlschlagen des Sicherheitstests zu erwarten.
- Prüfen und analysieren Sie die Unterschiede zwischen Geräten, die bestanden und denen, die nicht bestanden haben.
- Analysiere die Behauptung, das Protokoll, den Fehlerbericht und die CTS-Quelle. Bei einem Hosttest können die Behauptung und das Protokoll sehr allgemein sein. Daher ist es hilfreich, auch das Geräte-Logcat zu prüfen und anzuhängen.
- Reichen Sie ein Testverbesserungspatch ein, um Testfehler zu reduzieren.
Teilergebnisse speichern
Tradefed speichert keine teilweisen Testergebnisse, wenn die Testausführung fehlschlägt.
Wenn Tradefed keine Testergebnisse generiert, ist impliziert, dass während des Testlaufs ein schwerwiegendes Problem aufgetreten ist, wodurch das Testergebnis nicht vertrauenswürdig ist. Das Teilergebnis wird als nicht hilfreich erachtet, da es bei der Untersuchung des Geräteproblems keinen Nutzen hat.