CTS v2-Befehlskonsole

Verwenden Sie die CTS v2-Konsole

Für Android 7.0 oder höher verwenden Sie CTS v2.

Wählen Sie Pläne aus

Zu den verfügbaren Testplänen gehören:

  • cts – Führt CTS von einer bereits vorhandenen CTS-Installation aus.
  • cts-camera – Führt CTS-camera von einer bereits vorhandenen CTS-Installation aus.
  • cts-java – Führt Core-Java-Tests von einer bereits vorhandenen CTS-Installation aus.
  • cts-pdk – Führt Tests durch, die bei der Validierung eines PDK-Fusion-Builds nützlich sind.
  • Everything – Gemeinsame Konfiguration für Kompatibilitätssuiten.

Zu den weiteren verfügbaren Konfigurationen gehören die folgenden:

  • basic-reporters – Konfiguration mit grundlegenden CTS-Reportern.
  • Collect-Tests-only – Führt CTS von einer bereits vorhandenen CTS-Installation aus.
  • common-compatibility-config – Gemeinsame Konfiguration für Kompatibilitätssuiten.
  • cts-filtered-sample – Allgemeine Konfiguration für Kompatibilitätssuiten.
  • cts-known-failures – Konfiguration mit bekannten CTS-Fehlern.
  • cts-preconditions – CTS-Vorbedingungskonfigurationen.
  • Host – Führt einen einzelnen hostbasierten Test auf einem vorhandenen Gerät aus.
  • instrument – ​​Führt einen einzelnen Android-Instrumentierungstest auf einem vorhandenen Gerät aus.
  • native-benchmark – Führt einen nativen Stresstest auf einem vorhandenen Gerät durch.
  • native-stress – Führt einen nativen Stresstest auf einem vorhandenen Gerät durch.
  • Aufladen – Ein gefälschter Test, der auf fast entladene Geräte wartet und diese zum Aufladen zurückhält.
  • testdef – Führt Tests aus, die in test_def.xml-Dateien enthalten sind, auf einem vorhandenen Gerät aus.
  • util/wifi – Dienstprogrammkonfiguration zum Konfigurieren von WLAN auf dem Gerät.
  • util/wipe – Löscht Benutzerdaten auf dem Gerät.

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

CTS v2-Konsolenbefehlsreferenz

In dieser Tabelle sind die CTS v2-Konsolenbefehle für verschiedene Verwendungszwecke zusammengefasst.

Gastgeber Beschreibung
help Zeigt eine Zusammenfassung der am häufigsten verwendeten Befehle an
help all Zeigt die vollständige Liste der verfügbaren Befehle an
version Version anzeigen.
exit Verlassen Sie die CTS-Konsole ordnungsgemäß. Die Konsole wird geschlossen, wenn alle aktuell ausgeführten Tests abgeschlossen sind.
extdir

Die komprimierte Download-Datei wird nach extdir dekomprimiert. Wenn Sie die überhöhte Ausgabe loswerden möchten, verwenden Sie die Option -q :

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 , sondern führen Sie einfach Folgendes aus:

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

Laufen Beschreibung
run cts

Führen Sie in Android 10 den Standard-CTS-Plan und CTS-Instant zusammen aus (d. h. den vollständigen CTS-Aufruf). Führen Sie für Android 9 oder niedriger nur den Standard-CTS-Plan aus. Nutzen Sie diese umfassende Möglichkeit (inkl. Vorbedingungen) zur Gerätevalidierung. Einschlüsse finden Sie in cts.xml .

Die CTS-Konsole kann während der Ausführung von Tests andere Befehle akzeptieren.

Wenn keine Geräte angeschlossen sind, wartet der CTS-Desktop-Rechner (oder Host) auf die Verbindung eines Geräts, bevor er mit den Tests beginnt. Wenn mehr als ein Gerät angeschlossen ist, wählt der CTS-Host automatisch ein Gerät aus.

run cts-instant

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

run cts --module-parameter INSTANT_APP

Führen Sie in Android 10 den Standardplan CTS-Instant aus.

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

Führen Sie in Android 10 das oder die angegebenen CTS-Instant-Testmodule aus.

run retry

Nur für Android 9 oder höher. Wiederholen Sie alle Tests, die in den vorherigen Sitzungen fehlgeschlagen sind oder nicht ausgeführt wurden. run retry --retry -s oder run retry --retry --shard-count mit TF-Sharding aus.

run cts --retry ist für Android 9 oder höher nicht zulässig.

run cts-sim

Für Android 11 oder höhere Versionen. Führt die Teilmenge der Tests auf einem Gerät mit SIM-Karte aus.

--device-token

Für Android 8.1 oder niedrigere Versionen. Gibt an, dass ein bestimmtes Gerät über das angegebene Token verfügt. Beispiel: --device-token 1a2b3c4d:sim-card .

--enable-token-sharding

Nur für Android 10 oder höher . Entspricht automatisch dem Test, der den jeweiligen SIM-Typ erfordert. Es ist nicht erforderlich, eine Geräteseriennummer anzugeben, um SIM-bezogene Testfälle auszuführen. Unterstützte SIMs: SIM_CARD , UICC_SIM_CARD und SECURE_ELEMENT_SIM_CARD .

run cts-dev

Führen Sie den Standard-CTS-Plan (d. h. den vollständigen CTS-Aufruf) aus, überspringen Sie jedoch die Vorbedingungen, um Laufzeit für die iterative Entwicklung eines neuen Tests zu sparen. Dadurch wird die Überprüfung und Einrichtung der Gerätekonfiguration umgangen, z. B. das Übertragen von Mediendateien oder die Überprüfung der WLAN-Verbindung, wie dies bei Verwendung der Option --skip-preconditions der Fall ist. Dieser Befehl überspringt auch die Erfassung von Geräteinformationen und alle Systemstatusprüfungen. Außerdem werden die Tests nur auf einem einzigen ABI ausgeführt. Vermeiden Sie bei der Gerätevalidierung diese Optimierung und schließen Sie alle Vorbedingungen und Prüfungen ein. Ausschlüsse finden Sie in cts-dev.xml .

Die CTS-Konsole kann während der Ausführung von Tests andere Befehle akzeptieren.

Wenn keine Geräte angeschlossen sind, wartet der CTS-Desktop-Rechner (oder Host) auf die Verbindung eines Geräts, bevor er mit den Tests beginnt. Wenn mehr als ein Gerät angeschlossen ist, wählt der CTS-Host automatisch ein Gerät aus.

--subplan subplan_name Führen Sie den angegebenen Unterplan aus.
--module/-m test_module_name --test/-t test_name Führen Sie das angegebene Modul aus und testen Sie es. run cts -m Gesture --test android.gesture.cts.GestureTest#testGetStrokes um das spezifische Paket, die Klasse oder den Test auszuführen.
--retry Wiederholen Sie alle Tests, die in den vorherigen Sitzungen fehlgeschlagen sind oder nicht ausgeführt wurden. Verwenden Sie list results , um die Sitzungs-ID zu erhalten.
--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 zu erhalten.
--shards number_of_shards Für Android 8.1 oder niedrigere Versionen . Teilen Sie einen CTS-Lauf in eine bestimmte Anzahl unabhängiger Blöcke auf, um ihn auf mehreren Geräten parallel auszuführen.
--shard-count number_of_shards Für Android 9 . Teilen Sie einen CTS-Lauf in eine bestimmte Anzahl unabhängiger Blöcke auf, um ihn auf mehreren Geräten parallel auszuführen.
--serial/-s deviceID Führen Sie CTS auf dem jeweiligen Gerät aus.
--include-filter "test_module_name test_name" Führen Sie es mit den angegebenen Modulen oder Testpaketen, Klassen und Fällen aus. run cts --include-filter "CtsCalendarcommon2TestCases android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking" um das angegebene Modul einzuschließen.

Diese Befehlsoption wird beim Ausführen von Wiederholungen nicht unterstützt.

--exclude-filter "test_module_name test_name" Schließen Sie die angegebenen Module oder Testpakete, Klassen und Fälle von der Ausführung aus. run cts --exclude-filter "CtsCalendarcommon2Test android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking" um das angegebene Modul auszuschließen.
--log-level-display/-l log_level Führen Sie die Ausführung mit der minimalen angegebenen Protokollebene aus, die auf STDOUT angezeigt wird. Gültige Werte: [ VERBOSE , DEBUG , INFO , WARN , ERROR , ASSERT ].
--abi abi_name Erzwingen Sie die Ausführung des Tests mit dem angegebenen ABI, 32 oder 64. Standardmäßig führt CTS einen Test einmal für jeden ABI durch, den das Gerät unterstützt.
--logcat-on-failure ,
--bugreport-on-failure ,
--screenshoot-on-failure
Bietet mehr Einblick in Fehler und kann bei der Diagnose helfen.
--device-token Gibt an, dass ein bestimmtes Gerät über das angegebene Token verfügt, z. B. --device-token 1a2b3c4d:sim-card .
--skip-device-info Überspringt die Sammlung von Informationen über das Gerät.
--skip-preconditions Überspringen Sie Vorbedingungen, um Laufzeit für die iterative Entwicklung eines neuen Tests zu sparen. Dadurch wird die Überprüfung und Einrichtung der Gerätekonfiguration umgangen, z. B. das Übertragen von Mediendateien oder die Überprüfung der WLAN-Verbindung.
Aufführen Beschreibung
list modules Listen Sie alle verfügbaren Testmodule im Repository auf.
list plans oder list configs Listen Sie alle verfügbaren Testpläne (Konfigurationen) im Repository auf.
list subplans Listen Sie alle verfügbaren Unterpläne im Repository auf.
list invocations Listen Sie „Ausführungs“-Befehle auf, die derzeit auf Geräten ausgeführt werden.
list commands Listet alle „Ausführen“-Befehle auf, die sich derzeit in der Warteschlange befinden und darauf warten, Geräten zugewiesen zu werden.
list results Listet CTS-Ergebnisse auf, die derzeit im Repository gespeichert sind.
list devices Listet aktuell verbundene Geräte und deren Status auf.

„Verfügbare“ Geräte sind funktionierende, inaktive Geräte, die für die Ausführung von Tests verfügbar sind.

„Nicht verfügbare“ Geräte sind Geräte, die über ADB sichtbar sind, aber nicht auf ADB-Befehle reagieren und nicht für Tests zugewiesen werden.

„Zugewiesene“ Geräte sind Geräte, die derzeit Tests ausführen.

Entsorgen Beschreibung
dump logs Sichern Sie die Tradefed-Protokolle für alle laufenden Aufrufe.
Hinzufügen Beschreibung
add subplan --name/-n subplan_name
--result-type
[pass | fail | timeout | notExecuted]
[--session session_id ]
Erstellen Sie einen aus der vorherigen Sitzung abgeleiteten Unterplan. Diese Option generiert einen Unterplan, der zum Ausführen einer Teilmenge von Tests verwendet werden kann.

Die einzige erforderliche Option ist --session . Andere sind optional, müssen jedoch, wenn sie enthalten sind, von einem Wert gefolgt werden. Die Option --result-type ist wiederholbar; Beispielsweise ist add subplan --session 0 --result-type passed --result-type failed gültig.