CTS v2-Befehlskonsole

<ph type="x-smartling-placeholder">

CTS v2-Konsole verwenden

Verwenden Sie für Android 7.0 oder höher CTS v2.

Abos auswählen

Folgende Testpläne sind verfügbar:

  • cts: führt CTS über eine vorhandene CTS-Installation aus.
  • cts-camera: Führt CTS-camera aus einer vorhandenen CTS-Installation aus.
  • cts-java: Führt Core-Java-Tests über eine vorhandene CTS-Installation aus.
  • cts-pdk – Führt Tests aus, die zur Validierung eines PDK-Fusions-Builds nützlich sind.
  • alles: gemeinsame Konfiguration für Kompatibilitätssuites.

Zu den weiteren verfügbaren Konfigurationen gehören:

  • basic-reporters – Konfiguration für einfache CTS-Reporter.
  • Nur Collect-tests: CTS wird über eine vorhandene CTS-Installation ausgeführt.
  • common-compatibility-config – allgemeine Konfiguration für Kompatibilitätssuites
  • cts-filtered-sample: Allgemeine Konfiguration für Kompatibilitätssuites
  • cts-known-failures – Konfiguration mit bekannten CTS-Fehlern
  • cts-preconditions – CTS-Vorbedingungskonfigurationen.
  • host: Ein einzelner hostbasierter Test wird auf einem vorhandenen Gerät ausgeführt.
  • instrument: Ein einzelner Android-Instrumentierungstest auf einem vorhandenen Gerät wird ausgeführt.
  • Native Benchmark – Es wird ein nativer Belastungstest auf einem vorhandenen Gerät durchgeführt.
  • native-stress – führt einen nativen Stresstest auf einem bereits vorhandenen Gerät aus.
  • recharge – Ein gefälschter Test, bei dem auf fast entladene Geräte gewartet wird, um sie zum Aufladen zu halten.
  • testdef – Führt Tests aus, die in test_def.xml-Dateien auf einem vorhandenen Gerät enthalten sind.
  • util/wifi: Das Dienstprogramm konfigurieren Sie das WLAN auf dem Gerät.
  • util/wipe: Die Nutzerdaten werden auf dem Gerät gelöscht.

Alle diese Pläne und Konfigurationen können mit dem Befehl run cts ausgeführt werden.

Referenz für CTS-Konsolenbefehle v2

In dieser Tabelle sind die Befehle der CTS v2-Konsole für für verschiedene Anwendungsfälle.

Host Beschreibung
help Zusammenfassung der am häufigsten verwendeten Befehle anzeigen
help all Vollständige Liste der verfügbaren Befehle aufrufen
version Zeigen Sie die Version an.
exit Schließen Sie die CTS-Konsole ordnungsgemäß. Die Konsole wird geschlossen, wenn derzeit ausgeführte Tests abgeschlossen sind.
extdir

Die komprimierte Downloaddatei wird auf extdir dekomprimiert. Wenn Sie Verwenden Sie die Option -q, um die überhöhte Ausgabe zu entfernen:

unzip -q android-cts-9.0_r15-linux_x86-arm.zip -d extdir

Wenn Sie in das aktuelle Verzeichnis entpacken möchten, verwenden Sie nicht die Option -d, führen Sie einfach Folgendes aus:

unzip -q android-cts-9.0_r15-linux_x86-arm.zip
Laufen Beschreibung
run cts

In Android 10 den Standard-CTS-Tarif und CTS-Instant ausführen (d. h. den vollständigen CTS-Aufruf). Führen Sie für Android 9 oder niedriger die Standardeinstellung Nur mit CTS-Tarif. Nutzen Sie diese umfassende Option (einschließlich Vorbedingungen) für die Gerätevalidierung. Entsprechende Informationen finden Sie unter cts.xml.

Die CTS-Konsole kann während der Tests andere Befehle annehmen.

Wenn keine Geräte verbunden sind, wartet der CTS-Desktopcomputer (oder -Host) ein Gerät verbunden sein, bevor Tests gestartet werden. Wenn mehrere Gerät verbunden ist, wählt der CTS-Host ein Gerät aus automatisch.

run cts-instant

Führen Sie für Android 9 den Standardtarif CTS-Instant aus.

run cts --module-parameter INSTANT_APP

Führen Sie unter Android 10 den Standardtarif für CTS-Instant aus.

run cts --module-parameter INSTANT_APP --module/-m test_module_name

Führen Sie in Android 10 das angegebene CTS-Instant-Testmodul aus. oder Module.
run retry

Nur für Android 9 oder höher. Alle fehlgeschlagenen oder nicht ausgeführten Tests wiederholen aus den vorherigen Sitzungen. Beispiel: run retry --retry -s oder run retry --retry --shard-count mit TF-Fragmentierung.

run cts --retry ist nicht ab Android 9 zulässig.
run cts-sim

Für Android 11 oder höher. Führt die Teilmenge der Tests für eine Gerät mit SIM-Karte.
--device-token

Für Android 8.1 oder niedriger Gibt an, dass ein bestimmtes Gerät die Token. Beispiel: --device-token 1a2b3c4d:sim-card.
--enable-token-sharding

Nur für Android 10 oder höher Automatisch mit dem Test übereinstimmt, erfordert den entsprechenden SIM-Typ. Für die Ausführung muss keine Geräte-Seriennummer angegeben werden SIM-bezogene Testläufe. Unterstützte SIM-Karten: SIM_CARD, UICC_SIM_CARD, und SECURE_ELEMENT_SIM_CARD.

run cts-dev

Führen Sie den Standard-CTS-Plan aus (d. h. den vollständigen CTS-Aufruf), aber Überspringen von Vorbedingungen, um Laufzeit für die iterative Entwicklung einer neuen testen. Dadurch wird die Überprüfung und Einrichtung der Konfiguration, indem Sie beispielsweise Mediendateien übertragen oder die WLAN-Verbindung prüfen Verbindung, wie es bei Verwendung der Option --skip-preconditions der Fall ist. Dieses Außerdem werden die Erfassung von Geräteinformationen und alle Systemstatusprüfungen übersprungen. Außerdem führt die Tests nur mit einem einzigen ABI aus. Vermeiden Sie bei der Gerätevalidierung diese Optimierung und alle Voraussetzungen und Prüfungen enthalten. Weitere Informationen finden Sie unter cts-dev.xml für Ausschlüsse

Die CTS-Konsole kann während der Tests andere Befehle annehmen.

Wenn keine Geräte verbunden sind, wartet der CTS-Desktopcomputer (oder -Host) ein Gerät verbunden sein, bevor Tests gestartet werden. Wenn mehrere Gerät verbunden ist, wählt der CTS-Host ein Gerät aus automatisch.
--subplan subplan_name Führen Sie den angegebenen Teilplan aus.
--module/-m test_module_name --test/-t test_name  Führen Sie das angegebene Modul aus und testen Sie es. Beispiel: run cts -m Gesture --test android.gesture.cts.GestureTest#testGetStrokes das spezifische Paket, die Klasse oder den Test ausführt.
--retry Wiederholen Sie alle Tests, die fehlgeschlagen sind oder in den vorherigen Sitzungen nicht ausgeführt wurden. Verwenden Sie list results, um die Sitzungs-ID abzurufen.
--retry-type NOT_EXECUTED Wiederholen Sie nur Tests, die in den vorherigen Sitzungen nicht ausgeführt wurden. Verwenden Sie list results, um die Sitzungs-ID abzurufen.
--shards number_of_shards Android 8.1 oder niedriger CTS fragmentieren werden in einer vorgegebenen Anzahl unabhängiger Blöcke unterteilt, die auf mehreren Geräten ausgeführt werden können. .
--shard-count number_of_shards Für Android 9 Fragmentieren eines CTS-Laufs in eine bestimmte Anzahl von um auf mehreren Geräten gleichzeitig ausgeführt zu werden.
--serial/-s deviceID Führen Sie CTS auf dem jeweiligen Gerät aus.
--include-filter "test_module_name test_name" Mit den angegebenen Modulen oder Testpaketen, Klassen und Fällen ausführen. Beispiel: run cts --include-filter "CtsCalendarcommon2TestCases android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking" das angegebene Modul enthält.

Diese Befehlsoption wird beim Ausführen von Wiederholungsversuchen nicht unterstützt.
--exclude-filter "test_module_name test_name" Schließen Sie die angegebenen Module oder Testpakete, Klassen und Fälle aus der Ausführung aus. Beispiel: run cts --exclude-filter "CtsCalendarcommon2Test android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking" das angegebene Modul aus.
--log-level-display/-l log_level Ausführung mit der angegebenen Mindestprotokollstufe, die für STDOUT Gültige Werte: [VERBOSE, DEBUG, INFO, WARN ERROR, ASSERT]
--abi abi_name Erzwingt die Ausführung des Tests auf dem angegebenen ABI-Wert 32 oder 64. Standardmäßig CTS führt für jedes vom Gerät unterstützte ABI einen Test durch.
--logcat-on-failure,
--bugreport-on-failure,
--screenshoot-on-failure		 Sie erhalten einen besseren Überblick über Fehler und können bei der Diagnose helfen.
--device-token Gibt an, dass ein bestimmtes Gerät das angegebene Token hat, z. B. --device-token 1a2b3c4d:sim-card
--skip-device-info Überspringt die Erfassung von Geräteinformationen.
--skip-preconditions Überspringen Sie Vorbedingungen, um Laufzeit für die iterative Entwicklung eines neuen Test. Dadurch wird die Überprüfung und Einrichtung der Konfiguration, indem Sie beispielsweise Mediendateien übertragen oder die WLAN-Verbindung prüfen
Liste Beschreibung
list modules Alle verfügbaren Testmodule im Repository auflisten.
list plans oder list configs Alle verfügbaren Testpläne (Konfigurationen) im Repository auflisten.
list subplans Listen Sie alle verfügbaren Teilpläne im Repository auf.
list invocations Hiermit werden run-Befehle aufgelistet, die aktuell auf Geräten ausgeführt werden.
list commands Hiermit werden alle run-Befehle aufgelistet, die sich derzeit in der Warteschlange befinden und darauf warten, Geräten zugewiesen zu werden.
list results Listet die aktuell im Repository gespeicherten CTS-Ergebnisse auf.
list devices Aktuell verbundene Geräte und ihren Status auflisten.

Verfügbare Geräte sind funktionsfähige, inaktive Geräte, die zum Ausführen von Tests zur Verfügung stehen.

Geräte mit dem Status Nicht verfügbar sind Geräte, die über ADB sichtbar sind, aber nicht auf ADB reagieren. und werden nicht für Tests verwendet.

Zugewiesene Geräte sind Geräte, auf denen derzeit Tests ausgeführt werden.
Erfassen Beschreibung
dump logs Dump der Tradefed-Logs für alle laufenden Aufrufe.
Hinzufügen Beschreibung
add subplan --name/-n subplan_name
--result-type
[passed | failed | not_executed]
[--session session_id]		 Einen Teilplan erstellen, der aus der vorherigen Sitzung abgeleitet wurde generiert diese Option Teilplan, mit dem eine Teilmenge von Tests ausgeführt werden kann.

Die einzigen erforderliche Option ist --session. Andere sind optional. enthalten ist, muss ein Wert folgen. Die Die Option --result-type ist wiederholbar. zum Beispiel add subplan --session 0 --result-type passed --result-type failed ist gültig.