Die CTS-Testergebnisse werden in der Datei abgelegt:
CTS_ROOT/android-cts/results/start_time.zip
Wenn Sie die CTS selbst erstellt haben, sieht CTS_ROOT
out/host/linux-x86/cts, unterscheidet sich jedoch je nach Plattform. Dies entspricht dem Pfad,
Sie haben die vordefinierte offizielle CTS-Datei
von dieser Website heruntergeladen werden.
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 eine Datei „test_result.html“, die Sie direkt öffnen können. in einem beliebigen HTML5-kompatiblen Webbrowser
Ergebnisse vor Android 10 anzeigen
Öffne die Datei „test_result.xml“ in einem beliebigen HTML5-kompatiblen Webbrowser, um den Test anzusehen Ergebnisse
Wenn diese Datei im Chrome-Browser eine leere Seite anzeigt,
Browserkonfiguration ändern
um das Befehlszeilen-Flag --allow-file-access-from-files zu aktivieren.
Testergebnisse lesen
Die Details der Testergebnisse hängen davon ab, welche CTS-Version Sie verwenden:
- CTS-Version 1 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 Geräteinformationen (Link über Testzusammenfassung) aus, um Details zum Gerät, zur Firmware (Marke, Modell, Firmware-Build, Plattform) und die Hardware des Geräts (Bildschirmauflösung, Wähltastatur, Bildschirmtyp). CTS v2 enthält keine Geräteinformationen angezeigt werden.
Testzusammenfassung
Der Abschnitt Testzusammenfassung enthält Details zum ausgeführten Testplan, wie z. B. die CTS. sowie die Start- und Endzeiten für die Ausführung. Außerdem wird eine Zusammenfassung Zusammenfassung der Anzahl der bestandenen, fehlgeschlagenen oder abgelaufenen Tests bzw. Tests, die nicht ausgeführt werden konnten ausgeführt haben.
Android 10-CTS-Beispieltestzusammenfassung
Abbildung 1:Testzusammenfassung für Android 10 CTS
Testzusammenfassung für CTS v2
Abbildung 2:Testzusammenfassung für CTS v2
Testzusammenfassung für CTS v1
Abbildung 3:Testzusammenfassung für CTS v1
Testbericht
Der nächste Abschnitt, der CTS-Testbericht, enthält eine Zusammenfassung der Paket.
Darauf folgen Details zu den tatsächlich ausgeführten Tests. Der Bericht das Testpaket, die Testsuite, den Testfall und die ausgeführten Tests auflistet. Er zeigt das Ergebnis der Testausführung – bestanden, nicht bestanden, abgelaufen oder nicht ausgeführt. Im eines Testfehlers werden Details bereitgestellt, um die Ursache zu ermitteln.
Der Stacktrace des Fehlers ist in der XML-Datei verfügbar, die im Bericht enthalten sind, um sie kürzer zu halten. Durch Aufrufen der XML-Datei mit einem Texteditor sollten Details zum Testfehler enthalten. Suchen Sie nach dem Tag [Test]. zu dem fehlgeschlagenen Test und suchen Sie darin nach dem [StackTrace]-Tag.
Beispiel-Testbericht für CTS v2 anzeigen
Abbildung 4: Beispiel-Testbericht für CTS v2
CTS v1-Testbericht anzeigen
Abbildung 5: CTS v1-Testbericht
Überprüfen Sie test_result.xml auf unvollständige Testmodule
Führen Sie den folgenden Befehl aus, um die Anzahl der unvollständigen Module in einer bestimmten Testsitzung zu ermitteln: Befehl "list results". Die Anzahl der abgeschlossenen Module und der Gesamtzahl der Module beträgt vorherigen Sitzung aufgelistet sind. Um zu ermitteln, welche Module abgeschlossen sind unvollständig ist, öffnen Sie die Datei test_result.xml und lesen Sie den Wert der "done". für jedes Modul im Ergebnisbericht. Module mit Wert erledigt = „false“ nicht bis zum Ende ausgeführt wurden.
Fehler bei Triage-Tests
Verwenden Sie die folgenden Vorschläge, um Testfehler zu erkennen.
- Bestätigen Sie Ihr CTS-Umgebung korrekt eingerichtet ist, wenn ein Test aufgrund falscher Bedingungen fehlschlägt. Dazu gehören die physische Umgebung, die Einrichtung des Desktopcomputers Einrichtung von Android-Geräten
- Gerätestabilität überprüfen, Einrichtung oder Umgebungsprobleme testen wenn ein Test übermäßig instabil erscheint.
- Wiederholen Sie den Test, falls weiterhin ein Fehler auftritt.
- Achte auf externe Faktoren, die zu Testfehlern führen, z. B.:
<ph type="x-smartling-placeholder">
- </ph>
- Umgebungseinrichtung. Beispiel: Ein falsch konfigurierter Desktopcomputer kann die Ursache für Testfehler bei allen Tests (DUTs) (einschließlich Referenzgeräte).
- Externe Abhängigkeiten. Wenn z. B. ein Test auf allen Geräten in zu einem bestimmten Zeitpunkt starten, kann eine fehlerhafte URL ein Fehler vorliegt.
- Wenn die DUT das Sicherheitsattribut nicht enthält ist ein Fehlschlagen des Sicherheitstests zu erwarten.
- Unterschiede zwischen bestandenen und fehlerhaften Geräten validieren und analysieren
- Assertion, Protokoll, Fehlerbericht und CTS-Quelle: Bei einem HostTest können Assertion und Log sehr allgemein sein. Daher ist es hilfreich, auch „Device Logcat“ prüfen und anhängen.
- Reichen Sie ein Testverbesserungspatch ein, um Testfehler zu reduzieren.
Teilergebnisse speichern
Tradefed speichert keine Teiltestergebnisse, wenn der Testaufruf fehlschlägt.
Wenn Tradefed keine Testergebnisse generiert, ist ein schwerwiegendes Problem während des Testlaufs aufgetreten ist, wodurch das Testergebnis nicht vertrauenswürdig wird. Das Teilergebnis wird als nicht hilfreich erachtet, da es keinen Mehrwert bietet, wenn der Untersuchung des Geräteproblems.