Die CTS-Testergebnisse werden in der Datei abgelegt:
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 spiegelt den Pfad wider, in dem Sie das von dieser Website heruntergeladene vorgefertigte offizielle CTS dekomprimiert haben.
In der ZIP-Datei enthält die Datei test_result.xml die tatsächlichen Ergebnisse.
Zeigt Ergebnisse für Android 10 und höher an
Im ZIP-Archiv ist eine test_result.html-Datei vorhanden, die Sie direkt in jedem HTML5-kompatiblen Webbrowser öffnen können
Zeigt Ergebnisse vor Android 10 an
Öffnen Sie die Datei test_result.xml in einem beliebigen HTML5-kompatiblen Webbrowser, um die Testergebnisse anzuzeigen
Wenn diese Datei bei Verwendung des Chrome-Browsers eine leere Seite anzeigt, ändern Sie Ihre Browserkonfiguration , um das Befehlszeilenflag --allow-file-access-from-files zu aktivieren.
Lesen Sie die Testergebnisse
Die Details der Testergebnisse hängen davon ab, welche CTS-Version Sie verwenden:
- CTS v1 für Android 6.0 und früher
- CTS v2 für Android 7.0 und höher
Geräteinformation
Wählen Sie in CTS v1 und früher Geräteinformationen (Link oben in der Testzusammenfassung) aus, um Details zum Gerät, zur Firmware (Marke, Modell, Firmware-Build, Plattform) und zur Gerätehardware (Bildschirmauflösung, Tastatur, Bildschirmtyp) anzuzeigen. CTS v2 zeigt keine Geräteinformationen an.
Testzusammenfassung
Der Abschnitt „Testzusammenfassung“ enthält Details zum ausgeführten Testplan, z. B. den Namen des CTS-Plans sowie die Start- und Endzeiten der Ausführung. Außerdem wird eine aggregierte Zusammenfassung der Anzahl der Tests angezeigt, die bestanden wurden, fehlgeschlagen sind, eine Zeitüberschreitung aufwiesen oder nicht ausgeführt werden konnten.
Zusammenfassung des Android 10 CTS-Beispieltests
Abbildung 1: Zusammenfassung des Android 10 CTS-Beispieltests
Zusammenfassung des CTS v2-Beispieltests
Abbildung 2: Zusammenfassung des CTS v2-Beispieltests
Zusammenfassung des CTS v1-Beispieltests
Abbildung 3: Zusammenfassung des CTS v1-Beispieltests
Testbericht
Der nächste Abschnitt, der CTS-Testbericht, enthält eine Zusammenfassung der pro Paket bestandenen Tests.
Anschließend folgen Einzelheiten zu den tatsächlich durchgeführten Tests. Der Bericht listet das Testpaket, die Testsuite, den Testfall und die ausgeführten Tests auf. Es zeigt das Ergebnis der Testausführung an – bestanden, fehlgeschlagen, Zeitüberschreitung oder nicht ausgeführt. Im Falle eines Testfehlers werden Details bereitgestellt, die bei der Diagnose der Ursache helfen.
Darüber hinaus ist der Stack-Trace des Fehlers in der XML-Datei verfügbar, aus Gründen der Kürze jedoch nicht im Bericht enthalten. Wenn Sie die XML-Datei mit einem Texteditor anzeigen, sollten Sie Details zum Testfehler erhalten (suchen Sie nach dem entsprechenden Tag [Test]). den fehlgeschlagenen Test und suchen Sie darin nach dem [StackTrace] -Tag).
Beispieltestbericht für CTS v2 anzeigen
Abbildung 4: Beispieltestbericht für CTS v2
Beispieltestbericht für CTS v1 anzeigen
Abbildung 5: Beispieltestbericht für CTS v1
Überprüfen Sie test_result.xml auf unvollständige Testmodule
Um die Anzahl unvollständiger Module in einer bestimmten Testsitzung zu ermitteln, 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 festzustellen, welche Module vollständig oder 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.
Triage-Testfehler
Verwenden Sie die folgenden Vorschläge, um Testfehler zu selektieren.
- Überprüfen Sie, ob Ihre CTS-Umgebung korrekt eingerichtet ist, falls 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.
- Überprüfen Sie die Gerätestabilität, den Testaufbau oder Umgebungsprobleme, wenn ein Test übermäßig unzuverlässig erscheint.
- Wiederholen Sie den Test isoliert, wenn er immer noch fehlschlägt.
- Suchen Sie nach externen Faktoren, die Testfehler verursachen, wie zum Beispiel:
- Umwelteinrichtung. Beispielsweise kann ein falsch konfiguriertes Desktop-Computer-Setup die Ursache für Testfehler sein, die auf allen zu testenden Geräten (DUTs) (einschließlich Referenzgeräten) auftreten.
- Externe Abhängigkeiten. Wenn beispielsweise ein Test ab einem bestimmten Zeitpunkt auf allen Geräten an mehreren Standorten fehlschlägt, könnte eine fehlerhafte URL die Ursache sein.
- Wenn das DUT den Sicherheitspatch nicht enthält, ist mit einem Fehlschlagen seines Sicherheitstests zu rechnen.
- Validieren und analysieren Sie die Unterschiede zwischen bestandenen und nicht bestandenen Geräten.
- Analysieren Sie die Behauptung, das Protokoll, den Fehlerbericht und die CTS-Quelle . Bei einem HostTest können Behauptung und Protokoll sehr allgemein sein, daher ist es hilfreich, auch den Geräte-Logcat zu überprüfen und anzuhängen.
- Senden Sie einen Patch zur Testverbesserung, um Testfehler zu reduzieren.
Teilergebnisse speichern
Tradefed speichert keine Teiltestergebnisse, wenn der Testaufruf fehlschlägt.
Wenn Tradefed keine Testergebnisse generiert, bedeutet dies, dass während des Testlaufs ein schwerwiegendes Problem aufgetreten ist und das Testergebnis daher nicht vertrauenswürdig ist. Das Teilergebnis wird als nicht hilfreich erachtet, da es bei der Untersuchung des Geräteproblems keinen Wert liefert.