Użyj konsoli CTS v2
W przypadku Androida 7.0 lub nowszego użyj CTS v2.
Wybierz plany
Dostępne plany testów obejmują:
- cts — uruchamia CTS z istniejącej instalacji CTS.
- cts-camera — Uruchamia kamerę CTS z istniejącej instalacji CTS.
- cts-java — Uruchamia podstawowe testy Java z istniejącej instalacji CTS.
- cts-pdk — Uruchamia testy przydatne do sprawdzania poprawności kompilacji fuzyjnej PDK.
- wszystko — wspólna konfiguracja dla pakietów zgodności.
Inne dostępne konfiguracje obejmują:
- basic-reporters — Konfiguracja z podstawowymi reporterami CTS.
- Collect-tests-only — uruchamia CTS z istniejącej instalacji CTS.
- common-compatibility-config — wspólna konfiguracja dla pakietów zgodności.
- cts-filtered-sample — wspólna konfiguracja dla pakietów zgodności.
- cts-known-failures — konfiguracja ze znanymi awariami CTS.
- cts-preconditions — konfiguracje warunków wstępnych CTS.
- host — uruchamia pojedynczy test oparty na hoście na istniejącym urządzeniu.
- instrument — uruchamia pojedynczy test oprzyrządowania Androida na istniejącym urządzeniu.
- native-benchmark — uruchamia natywny test warunków skrajnych na istniejącym urządzeniu.
- native-stres — uruchamia natywny test warunków skrajnych na istniejącym urządzeniu.
- recharge — fałszywy test, który czeka na prawie rozładowane urządzenia i wstrzymuje je do ładowania.
- testdef — Uruchamia testy zawarte w plikach test_def.xml na istniejącym urządzeniu.
- util/wifi — Konfiguracja narzędzia do konfiguracji Wi-Fi na urządzeniu.
- util/wipe — Usuwa dane użytkownika z urządzenia.
Wszystkie te plany i konfiguracje można wykonać za pomocą polecenia run cts .
Informacje o poleceniach konsoli CTS v2
W poniższej tabeli podsumowano polecenia konsoli CTS v2 do różnych zastosowań.
| Gospodarz | Opis |
|---|---|
help | Wyświetl podsumowanie najczęściej używanych poleceń |
help all | Wyświetl pełną listę dostępnych poleceń |
version | Pokaż wersję. |
exit | Delikatnie wyjdź z konsoli CTS. Konsola zamyka się po zakończeniu wszystkich aktualnie uruchomionych testów. |
extdir | Spakowany plik do pobrania jest dekompresowany do Jeśli chcesz rozpakować do bieżącego katalogu, nie używaj opcji |
| Uruchomić | Opis |
run cts | W systemie Android 10 uruchom jednocześnie domyślny plan CTS i CTS-Instant (czyli pełne wywołanie CTS). W przypadku systemu Android 9 lub starszego uruchom tylko domyślny plan CTS. Użyj tej kompleksowej opcji (w tym warunków wstępnych) do sprawdzania poprawności urządzenia. Informacje o dołączeniach można znaleźć w pliku cts.xml . Konsola CTS może przyjmować inne polecenia w trakcie testów. Jeśli nie jest podłączone żadne urządzenie, komputer stacjonarny CTS (lub host) będzie czekać na podłączenie urządzenia przed rozpoczęciem testów. Jeśli podłączonych jest więcej niż jedno urządzenie, host CTS automatycznie wybierze urządzenie. |
run cts-instant | W systemie Android 9 uruchom domyślny plan CTS-Instant. |
run cts --module-parameter INSTANT_APP | W systemie Android 10 uruchom domyślny plan CTS-Instant. |
run cts --module-parameter INSTANT_APP --module/-m test_module_name | W systemie Android 10 uruchom określony moduł lub moduły testowe CTS-Instant. |
run retry | Tylko dla Androida 9 lub nowszego. Ponów wszystkie testy, które nie powiodły się lub nie zostały wykonane w poprzednich sesjach. Na przykład |
run cts-sim | Dla wersji Androida 11 lub nowszych. Uruchamia podzbiór testów na urządzeniu z kartą SIM. |
--device-token | Dla Androida 8.1 lub starszych wersji. Określa, że dane urządzenie ma dany token. Na przykład |
--enable-token-sharding | Tylko dla Androida 10 lub nowszego . Automatycznie dopasowuje test wymagający odpowiedniego typu karty SIM. Nie ma potrzeby podawania numeru seryjnego urządzenia, aby wykonać przypadki testowe związane z kartą SIM. Obsługiwane karty SIM: |
run cts-dev | Uruchom domyślny plan CTS (tzn. pełne wywołanie CTS), ale pomiń warunki wstępne, aby zaoszczędzić czas działania na iteracyjne opracowywanie nowego testu. Pomija to weryfikację i konfigurację konfiguracji urządzenia, taką jak przesyłanie plików multimedialnych lub sprawdzanie połączenia Wi-Fi, jak ma to miejsce w przypadku użycia opcji Konsola CTS może przyjmować inne polecenia w trakcie testów. Jeśli nie jest podłączone żadne urządzenie, komputer stacjonarny CTS (lub host) będzie czekać na podłączenie urządzenia przed rozpoczęciem testów. Jeśli podłączonych jest więcej niż jedno urządzenie, host CTS automatycznie wybierze urządzenie. |
--subplan subplan_name | Uruchom określony podplan. |
--module/-m test_module_name --test/-t test_name | Uruchom określony moduł i przetestuj. Na przykład run cts -m Gesture --test android.gesture.cts.GestureTest#testGetStrokes uruchamia określony pakiet, klasę lub test. |
--retry | Ponów wszystkie testy, które nie powiodły się lub nie zostały wykonane w poprzednich sesjach. Użyj list results , aby uzyskać identyfikator sesji. |
--retry-type NOT_EXECUTED | Ponów próbę tylko w przypadku testów, które nie zostały wykonane w poprzednich sesjach. Użyj list results , aby uzyskać identyfikator sesji. |
--shards number_of_shards | Dla Androida 8.1 lub starszych wersji . Podziel działanie CTS na określoną liczbę niezależnych fragmentów, aby uruchomić je równolegle na wielu urządzeniach. |
--shard-count number_of_shards | Dla Androida 9 . Podziel działanie CTS na określoną liczbę niezależnych fragmentów, aby uruchomić je równolegle na wielu urządzeniach. |
--serial/-s deviceID | Uruchom CTS na konkretnym urządzeniu. |
--include-filter "test_module_name test_name" | Uruchom z określonymi modułami lub pakietami testowymi, klasami i przypadkami. Na przykład run cts --include-filter "CtsCalendarcommon2TestCases android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking" zawierający określony moduł.Ta opcja polecenia nie jest obsługiwana w przypadku ponawiania próby. |
--exclude-filter "test_module_name test_name" | Wyklucz określone moduły lub pakiety testowe, klasy i przypadki z przebiegu. Na przykład run cts --exclude-filter "CtsCalendarcommon2Test android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking" wyklucza określony moduł. |
--log-level-display/-l log_level | Uruchom z minimalnym określonym poziomem dziennika wyświetlanym na STDOUT . Prawidłowe wartości: [ VERBOSE , DEBUG , INFO , WARN , ERROR , ASSERT ]. |
--abi abi_name | Wymuś uruchomienie testu na podanym ABI, 32 lub 64. Domyślnie CTS uruchamia test raz dla każdego ABI obsługiwanego przez urządzenie. |
--logcat-on-failure ,--bugreport-on-failure ,--screenshoot-on-failure | Zapewniają lepszy wgląd w awarie i mogą pomóc w diagnostyce. |
--device-token | Określa, że dane urządzenie ma dany token, taki jak --device-token 1a2b3c4d:sim-card . |
--skip-device-info | Pomija zbieranie informacji o urządzeniu. |
--skip-preconditions | Pomiń warunki wstępne, aby zaoszczędzić czas na iteracyjne opracowywanie nowego testu. Pomija to weryfikację i konfigurację konfiguracji urządzenia, taką jak przesyłanie plików multimedialnych lub sprawdzanie połączenia Wi-Fi. |
| Lista | Opis |
list modules | Lista wszystkich dostępnych modułów testowych w repozytorium. |
list plans lub list configs | Lista wszystkich dostępnych planów testów (konfiguracji) w repozytorium. |
list subplans | Lista wszystkich dostępnych podplanów w repozytorium. |
list invocations | Lista poleceń „uruchom” aktualnie wykonywanych na urządzeniach. |
list commands | Wyświetl listę wszystkich poleceń „uruchom”, znajdujących się obecnie w kolejce i oczekujących na przypisanie do urządzeń. |
list results | Lista wyników CTS aktualnie przechowywanych w repozytorium. |
list devices | Lista aktualnie podłączonych urządzeń i ich stanu. Urządzenia „dostępne” działają, urządzenia są bezczynne, są dostępne do przeprowadzenia testów. Urządzenia „niedostępne” to urządzenia widoczne przez adb, ale nie reagujące na polecenia adb i nie zostaną przydzielone do testów. „Przydzielone” urządzenia to urządzenia, na których aktualnie przeprowadzane są testy. |
| Wysypisko | Opis |
dump logs | Zrzuć dzienniki przekazane dla wszystkich uruchomionych wywołań. |
| Dodać | Opis |
add subplan --name/-n subplan_name | Utwórz podplan na podstawie poprzedniej sesji; ta opcja generuje podplan, którego można użyć do uruchomienia podzbioru testów. Jedyną wymaganą opcją jest --session . Inne są opcjonalne, ale jeśli są uwzględnione, musi po nich następować wartość. Opcja --result-type jest powtarzalna; na przykład add subplan --session 0 --result-type passed --result-type failed jest prawidłowy. |