Atest to narzędzie wiersza poleceń, które umożliwia użytkownikom budowanie, instalowanie i uruchamianie testów Androida lokalnie, znacznie przyspieszając ponowne uruchamianie testów bez konieczności znajomości opcji wiersza poleceń wiązek testowych Federacji Handlowej . Na tej stronie wyjaśniono, jak używać narzędzia Atest do przeprowadzania testów systemu Android.
Aby uzyskać ogólne informacje na temat pisania testów dla systemu Android, zobacz Testowanie platformy systemu Android .
Aby uzyskać informacje na temat ogólnej struktury Atest, zapoznaj się z Przewodnikiem programisty Atest .
Aby uzyskać informacje na temat uruchamiania testów w plikach TEST_MAPPING za pomocą narzędzia Atest, zobacz Uruchamianie testów w plikach TEST_MAPPING .
Aby dodać funkcję do Atest, postępuj zgodnie z Przepływem pracy programisty Atest .
Skonfiguruj swoje środowisko
Aby skonfigurować środowisko Atest, postępuj zgodnie z instrukcjami w sekcjach Konfigurowanie środowiska , Wybieranie celu i Budowanie kodu .
Podstawowe użycie
Komendy Atest mają następującą postać:
atest test-to-run [optional-arguments]
Argumenty opcjonalne
W poniższej tabeli wymieniono najczęściej używane argumenty. Pełna lista jest dostępna w atest --help
.
Opcja | Długa opcja | Opis |
---|---|---|
-b | --build | Tworzy cele testowe. (domyślny) |
-i | --install | Instaluje artefakty testowe (APK) na urządzeniu. (domyślny) |
-t | --test | Przeprowadza testy. (domyślny) |
-s | --serial | Uruchamia testy na określonym urządzeniu. Jednorazowo można testować jedno urządzenie. |
-d | --disable-teardown | Wyłącza usuwanie i czyszczenie testów. |
| --info | Pokazuje istotne informacje o określonych celach, a następnie kończy działanie. |
| --dry-run | Próbne testy Atestuj bez faktycznego budowania, instalowania lub uruchamiania testów. |
-m | --rebuild-module-info | Wymusza przebudowę pliku module-info.json . |
-w | --wait-for-debugger | Czeka na zakończenie debugera przed wykonaniem. |
-v | --verbose | Wyświetla rejestrowanie poziomu DEBUG. |
| --iterations | Uruchamia testy w pętli, aż do osiągnięcia maksymalnej iteracji. (domyślnie 10) |
| --rerun-until-failure [COUNT=10] | Ponownie uruchamia wszystkie testy do momentu wystąpienia błędu lub osiągnięcia maksymalnej liczby iteracji. (domyślnie 10) |
| --retry-any-failure [COUNT=10] | Ponownie uruchamia testy, które zakończyły się niepowodzeniem, aż do ich zaliczenia lub osiągnięcia maksymalnej liczby iteracji. (domyślnie 10) |
| --start-avd | Automatycznie tworzy AVD i uruchamia testy na urządzeniu wirtualnym. |
| --acloud-create | Tworzy AVD za pomocą polecenia acloud . |
| --[CUSTOM_ARGS] | Określa niestandardowe argumenty dla biegaczy testów. |
-a | --all-abi | Uruchamia testy dla wszystkich dostępnych architektur urządzeń. |
| --host | Uruchamia test całkowicie na hoście bez urządzenia. Uwaga: uruchomienie testu hosta wymagającego urządzenia z --host zakończy się niepowodzeniem. |
| --history | Pokazuje wyniki testu w porządku chronologicznym. |
| --latest-result | Drukuje ostatni wynik testu. |
Aby uzyskać więcej informacji na temat opcji -b
, -i
i -t
, zobacz sekcję Określanie kroków: budowanie, instalowanie lub uruchamianie .
Określ testy
Aby uruchomić testy, określ jeden lub więcej testów, używając jednego z następujących identyfikatorów:
- Nazwa modułu
- Moduł:Klasa
- Nazwa klasy
- Tradefed test integracyjny
- Ścieżka pliku
- Nazwa pakietu
Oddziel odniesienia do wielu testów spacjami, na przykład:
atest test-identifier-1 test-identifier-2
Nazwa modułu
Aby uruchomić cały moduł testowy, użyj jego nazwy modułu. Wprowadź nazwę w takiej postaci, w jakiej występuje w zmiennych LOCAL_MODULE
lub LOCAL_PACKAGE_NAME
w pliku Android.mk
lub Android.bp
tego testu.
Przykłady:
atest FrameworksServicesTests
atest CtsVideoTestCases
Moduł:Klasa
Aby uruchomić pojedynczą klasę w module, użyj Module:Class . Moduł jest taki sam, jak opisano w Nazwa modułu . Klasa jest nazwą klasy testowej w pliku .java
i może być w pełni kwalifikowaną nazwą klasy lub nazwą podstawową.
Przykłady:
atest CtsVideoTestCases:VideoEncoderDecoderTest
atest FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
Nazwa klasy
Aby uruchomić pojedynczą klasę bez jawnego podawania nazwy modułu, użyj nazwy klasy.
Przykłady:
atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest
Tradefed test integracyjny
Aby uruchomić testy, które są zintegrowane bezpośrednio z TradeFed (nie-moduły), wprowadź nazwę tak, jak pojawia się w danych wyjściowych polecenia tradefed.sh list configs
. Na przykład:
Aby uruchomić test reboot.xml
:
atest example/reboot
Aby uruchomić test native-benchmark.xml
:
atest native-benchmark
Ścieżka pliku
Atest obsługuje zarówno testy oparte na modułach, jak i testy oparte na integracji, wprowadzając odpowiednio ścieżkę do ich pliku testowego lub katalogu. Obsługuje również uruchamianie pojedynczej klasy, określając ścieżkę do pliku Java klasy. Obsługiwane są zarówno ścieżki względne, jak i bezwzględne.
Uruchom moduł
Poniższe przykłady przedstawiają dwa sposoby uruchamiania modułu CtsVideoTestCases
przy użyciu ścieżki do pliku.
Uruchom z repo-root
Androida:
atest cts/tests/video
Uruchom z repo-root/cts/tests/video
:
atest .
Uruchom klasę testową
Poniższy przykład pokazuje, jak uruchomić określoną klasę w module CtsVideoTestCases
przy użyciu ścieżki do pliku.
Z repo-root
Androida:
atest cts/tests/video/src/android/video/cts/VideoEncoderDecoderTest.java
Uruchom test integracji
Poniższy przykład pokazuje, jak uruchomić test integracji przy użyciu ścieżki do pliku z repo-root
Android:
atest tools/tradefederation/contrib/res/config/example/reboot.xml
Nazwa pakietu
Atest obsługuje wyszukiwanie testów według nazwy pakietu.
Przykłady:
atest com.android.server.wm
atest com.android.uibench.janktests
Określ kroki: Zbuduj, zainstaluj lub uruchom
Użyj opcji -b
, -i
i -t
, aby określić, które kroki mają zostać wykonane. Jeśli nie określisz opcji, wszystkie kroki zostaną wykonane.
- Tylko cele kompilacji:
atest -b test-to-run
- Uruchom tylko testy:
atest -t test-to-run
- Zainstaluj apk i uruchom testy:
atest -it test-to-run
- Zbuduj i uruchom, ale nie instaluj:
atest -bt test-to-run
Atest może zmusić test do pominięcia kroku czyszczenia lub rozbierania. Wiele testów, takich jak CTS, czyści urządzenie po uruchomieniu testu, więc próba ponownego uruchomienia testu z -t
zakończy się niepowodzeniem bez parametru --disable-teardown
. Użyj -d
przed -t
, aby pominąć krok czyszczenia testu i przetestować iteracyjnie.
atest -d test-to-run
atest -t test-to-run
Uruchamianie określonych metod
Atest obsługuje uruchamianie określonych metod w klasie testowej. Chociaż trzeba zbudować cały moduł, skraca to czas potrzebny do uruchomienia testów. Aby uruchomić określone metody, zidentyfikuj klasę za pomocą dowolnego obsługiwanego sposobu identyfikacji klasy (Moduł:Klasa, ścieżka pliku itp.) i dołącz nazwę metody:
atest reference-to-class#method1
Określając wiele metod, rozdziel je przecinkami:
atest reference-to-class#method1,method2,method3
Przykłady:
atest com.android.server.wm.ScreenDecorWindowTests#testMultipleDecors
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval
Poniższe dwa przykłady pokazują preferowane sposoby uruchamiania pojedynczej metody, testFlagChange
. Te przykłady są lepsze niż używanie tylko nazwy klasy, ponieważ określenie modułu lub lokalizacji pliku Java pozwala Atestowi znacznie szybciej znaleźć test.
Korzystanie z modułu:Klasa:
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange
Z repo-root Androida:
atest frameworks/base/services/tests/wmtests/src/com/android/server/wm/ScreenDecorWindowTests.java#testFlagChange
Z różnych klas i modułów można uruchomić wiele metod:
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors
Prowadzenie wielu zajęć
Aby uruchomić wiele klas, oddziel je spacjami w taki sam sposób, jak w przypadku uruchamiania wielu testów. Atest wydajnie buduje i uruchamia klasy, więc określenie podzbioru klas w module poprawia wydajność w porównaniu z uruchomieniem całego modułu.
Aby uruchomić dwie klasy w tym samym module:
atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests
Aby uruchomić dwie klasy w różnych modułach:
atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest
Uruchom pliki binarne GTest
Atest może uruchamiać pliki binarne GTest. Użyj opcji -a
, aby uruchomić te testy dla wszystkich dostępnych architektur urządzeń, którymi w tym przykładzie są armeabi-v7a
(ARM 32-bitowy) i arm64-v8a
(ARM 64-bitowy).
Przykładowy test wejścia:
atest -a libinput_tests inputflinger_tests
Aby wybrać określony plik binarny GTest do uruchomienia, użyj dwukropka (:), aby określić nazwę testu, oraz hashtagu (#), aby dokładniej określić indywidualną metodę.
Na przykład dla następującej definicji testu:
TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)
Uruchom następujące polecenie, aby określić cały test:
atest inputflinger_tests:InputDispatcherTest
Lub uruchom indywidualny test, używając następującego polecenia:
atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents
Uruchom testy w TEST_MAPPING
Atest może uruchamiać testy w plikach TEST_MAPPING
.
Niejawnie uruchamiaj testy przed przesłaniem
Uruchom testy przed przesłaniem w plikach TEST_MAPPING
w bieżącym i nadrzędnym katalogu:
atest
Uruchom testy przed przesłaniem w plikach TEST_MAPPING
w katalogu /path/to/project i jego katalogach nadrzędnych:
atest --test-mapping /path/to/project
Uruchom określoną grupę testową
Dostępne grupy testowe to: presubmit
(domyślna), postsubmit
, mainline-presubmit
i all
.
Uruchom testy po przesłaniu w plikach TEST_MAPPING w bieżącym i nadrzędnym katalogu:
atest :postsubmit
Uruchom testy ze wszystkich grup w plikach TEST_MAPPING:
atest :all
Uruchom testy po przesłaniu w plikach TEST_MAPPING w katalogu /path/to/project i jego katalogach nadrzędnych:
atest --test-mapping /path/to/project:postsubmit
Uruchom główne testy w plikach TEST_MAPPING w katalogu /path/to/project i jego katalogach nadrzędnych:
atest --test-mapping /path/to/project:mainline-presubmit
Uruchom testy w podkatalogach
Domyślnie Atest wyszukuje testy tylko w plikach TEST_MAPPING wzwyż (od bieżącego lub podanego katalogu do jego katalogów nadrzędnych). Jeśli chcesz również uruchomić testy w plikach TEST_MAPPING w podkatalogach, użyj --include-subdirs
, aby zmusić Atest do uwzględnienia również tych testów:
atest --include-subdirs /path/to/project
Przeprowadzaj testy w iteracjach
Uruchom testy w iteracji, przekazując argument --iterations
. Niezależnie od tego, czy się powiedzie, czy nie, Atest powtórzy test, aż do osiągnięcia maksymalnej iteracji.
Przykłady:
Domyślnie Atest iteruje 10 razy. Liczba iteracji musi być dodatnią liczbą całkowitą.
atest test-to-run --iterations
atest test-to-run --iterations 5
Następujące podejścia ułatwiają wykrywanie niestabilnych testów:
Podejście 1: Uruchom wszystkie testy, aż wystąpi błąd lub zostanie osiągnięta maksymalna iteracja.
- Zatrzymaj, gdy wystąpi awaria lub iteracja osiągnie 10 (domyślnie) rundę.
atest test-to-run --rerun-until-failure
- Zatrzymaj, gdy wystąpi awaria lub iteracja osiągnie setną rundę.
atest test-to-run --rerun-until-failure 100
Podejście 2: Uruchamiaj tylko testy, które zakończyły się niepowodzeniem, dopóki nie zostaną zakończone pomyślnie lub nie zostanie osiągnięta maksymalna iteracja.
- Załóżmy, że
test-to-run
ma wiele przypadków testowych i jeden z testów kończy się niepowodzeniem. Uruchom tylko nieudany test 10 razy (domyślnie) lub do momentu, gdy test zakończy się pomyślnie.atest test-to-run --retry-any-failure
- Zatrzymaj uruchamianie nieudanego testu, gdy przejdzie pomyślnie lub osiągnie setną rundę.
atest test-to-run --retry-any-failure 100
Uruchom testy na AVD
Atest jest w stanie uruchomić testy na nowo utworzonym AVD. Uruchom tworzenie w acloud create
, aby utworzyć AVD i artefakty kompilacji, a następnie użyj poniższych przykładów, aby uruchomić testy.
Uruchom AVD i przeprowadź na nim testy:
acloud create --local-instance --local-image && atest test-to-run
Uruchom AVD w ramach testu:
atest test-to-run --acloud-create "--local-instance --local-image"
Aby uzyskać więcej informacji, uruchom acloud create --help
.
Przekaż opcje do module
Atest jest w stanie przekazać opcje do modułów testowych. Aby dodać opcje wiersza poleceń TradeFed do testu, użyj następującej struktury i upewnij się, że niestandardowe argumenty są zgodne z formatem opcji wiersza poleceń TradeFed.
atest test-to-run -- [CUSTOM_ARGS]
Przekaż opcje modułu testowego do docelowych osób przygotowujących lub przeprowadzających testy zdefiniowanych w pliku konfiguracyjnym testu:
atest test-to-run -- --module-arg module-name:option-name:option-value
atest GtsPermissionTestCases -- --module-arg GtsPermissionTestCases:ignore-business-logic-failure:true
Przekaż opcje do typu biegacza lub klasy:
atest test-to-run -- --test-arg test-class:option-name:option-value
atest CtsVideoTestCases -- --test-arg com.android.tradefed.testtype.JarHosttest:collect-tests-only:true
Aby uzyskać więcej informacji na temat opcji tylko do testowania, zobacz Przekazywanie opcji do modułów .