Atest to narzędzie wiersza poleceń, które umożliwia użytkownikom tworzenie, instalowanie i uruchamianie testów systemu Android lokalnie, co znacznie przyspiesza 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.
Ogólne informacje na temat pisania testów dla systemu Android można znaleźć w artykule Testowanie platformy Android .
Informacje na temat ogólnej struktury programu Atest można znaleźć w Przewodniku 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 narzędzia Atest, postępuj zgodnie z procedurą pracy programisty Atest .
Skonfiguruj swoje środowisko
Aby skonfigurować środowisko Atest, postępuj zgodnie z instrukcjami w Konfigurowanie środowiska , Wybieranie celu i Tworzenie kodu .
Podstawowe użycie
Polecenia testowe mają następującą formę:
atest test-to-run [optional-arguments]
Opcjonalne argumenty
W poniższej tabeli wymieniono najczęściej używane argumenty. Pełna lista jest dostępna poprzez atest --help
.
Opcja | Opcja długa | Opis |
---|---|---|
-b | --build | Buduje cele testowe. (domyślny) |
-i | --install | Instaluje artefakty testowe (APK) na urządzeniu. (domyślny) |
-t | --test | Uruchamia testy. (domyślny) |
-s | --serial | Uruchamia testy na określonym urządzeniu. Jednorazowo można testować jedno urządzenie. |
-d | --disable-teardown | Wyłącza demontaż i czyszczenie testu. |
| --info | Wyświetla odpowiednie informacje o określonych celach, a następnie kończy działanie. |
| --dry-run | Testy próbne bez konieczności budowania, instalowania lub przeprowadzania 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 | Wykonuje testy w pętli aż do osiągnięcia maksymalnej iteracji. (domyślnie 10) |
| --rerun-until-failure [COUNT=10] | Uruchamia ponownie wszystkie testy, aż do wystąpienia awarii lub osiągnięcia maksymalnej iteracji. (domyślnie 10) |
| --retry-any-failure [COUNT=10] | Powtarza nieudane testy do momentu 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 modułów testujących. |
-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 testów w porządku chronologicznym. |
| --latest-result | Drukuje najnowszy wynik testu. |
Aby uzyskać więcej informacji na temat -b
, -i
i -t
, zobacz sekcję Określanie kroków: kompilacja, instalacja 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
- Test integracji w handlu
- Ścieżka pliku
- Nazwa pakietu
Oddzielne 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ę wyświetlaną 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 to nazwa klasy testowej w pliku .java
i może to być pełna nazwa klasy lub nazwa podstawowa.
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
Test integracji w handlu
Aby uruchomić testy zintegrowane bezpośrednio z TradeFed (nie moduły), wprowadź nazwę wyświetlaną w wynikach 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 uruchamianie zarówno testów modułowych, jak i testów integracyjnych, wprowadzając odpowiednio ścieżkę do pliku testowego lub katalogu. Obsługuje także uruchamianie pojedynczej klasy poprzez określenie ścieżki do pliku Java klasy. Obsługiwane są ścieżki względne i bezwzględne.
Uruchom moduł
Poniższe przykłady pokazują dwa sposoby uruchomienia modułu CtsVideoTestCases
przy użyciu ścieżki pliku.
Uruchom z repo-root
Androida:
atest cts/tests/video
Uruchom z repo-root/cts/tests/video
:
atest .
Uruchom zajęcia testowe
Poniższy przykład pokazuje, jak uruchomić określoną klasę w module CtsVideoTestCases
przy użyciu ścieżki pliku.
Z repo-root
Androida:
atest cts/tests/video/src/android/video/cts/VideoEncoderDecoderTest.java
Uruchom test integracyjny
Poniższy przykład pokazuje, jak uruchomić test integracji przy użyciu ścieżki pliku z repo-root
Androida:
atest tools/tradefederation/contrib/res/config/example/reboot.xml
Nazwa pakietu
Atest umożliwia wyszukiwanie testów po nazwie pakietu.
Przykłady:
atest com.android.server.wm
atest com.android.uibench.janktests
Określ kroki: Kompiluj, instaluj lub uruchamiaj
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ą uruchomione.
- Kompiluj tylko cele:
atest -b test-to-run
- Uruchom tylko testy:
atest -t test-to-run
- Zainstaluj apk i uruchom testy:
atest -it test-to-run
- Kompiluj i uruchamiaj, ale nie instaluj:
atest -bt test-to-run
Test może wymusić pominięcie kroku czyszczenia lub usuwania w teście. 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
Uruchom określone metody
Atest umożliwia uruchamianie określonych metod w klasie testowej. Choć trzeba zbudować cały moduł, skraca to czas potrzebny na przeprowadzenie 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
W przypadku podawania wielu metod należy je oddzielić 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ą preferowane zamiast używania samej nazwy klasy, ponieważ określenie modułu lub lokalizacji pliku Java pozwala programowi Atest 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
Uruchom wiele klas
Aby uruchomić wiele klas, należy je oddzielić spacjami w taki sam sposób, jak w przypadku uruchamiania wielu testów. Atest efektywnie buduje i uruchamia klasy, więc określenie podzbioru klas w module poprawia wydajność w porównaniu z uruchamianiem 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 -a
aby uruchomić te testy dla wszystkich dostępnych architektur urządzeń, którymi w tym przykładzie są armeabi-v7a
(32-bitowy ARM) i arm64-v8a
(64-bitowy ARM).
Przykładowy test wejściowy:
atest -a libinput_tests inputflinger_tests
Aby wybrać konkretny plik binarny GTest do uruchomienia, użyj dwukropka (:), aby określić nazwę testu i 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 katalogach bieżącym i nadrzędnym:
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ślnie), postsubmit
, mainline-presubmit
i all
.
Uruchom testy po przesłaniu w plikach TEST_MAPPING w katalogach bieżącym i nadrzędnym:
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 /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 w górę (od bieżącego lub podanego katalogu do katalogów nadrzędnych). Jeśli chcesz także uruchomić testy w plikach TEST_MAPPING w podkatalogach, użyj --include-subdirs
aby wymusić na Atest włączenie również tych testów:
atest --include-subdirs /path/to/project
Uruchom testy w iteracji
Uruchom testy w iteracji, przekazując argument --iterations
. Niezależnie od tego, czy test zakończy się powodzeniem, czy niepowodzeniem, Atest będzie powtarzał 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
Poniższe podejścia ułatwiają wykrycie niestabilnych testów:
Podejście 1: Uruchom wszystkie testy, aż wystąpi awaria 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: Wykonuj tylko testy zakończone niepowodzeniem, aż do ich zaliczenia lub osiągnięcia maksymalnej iteracji.
- Załóżmy, że
test-to-run
obejmuje wiele przypadków testowych i jeden z testów kończy się niepowodzeniem. Uruchom tylko test zakończony niepowodzeniem 10 razy (domyślnie) lub do momentu zaliczenia testu.atest test-to-run --retry-any-failure
- Przestań przeprowadzać nieudany test, gdy zakończy się pomyślnie lub osiągnie setną rundę.
atest test-to-run --retry-any-failure 100
Uruchom testy na AVD
Atest jest w stanie przeprowadzić testy na nowo utworzonym AVD. Uruchom acloud create
, aby utworzyć AVD i skompilować artefakty, a następnie skorzystaj z poniższych przykładów, aby uruchomić testy.
Uruchom AVD i uruchom na nim testy:
acloud create --local-instance --local-image && atest test-to-run
Uruchom AVD w ramach uruchomienia testowego:
atest test-to-run --acloud-create "--local-instance --local-image"
Aby uzyskać więcej informacji, uruchom acloud create --help
.
Przekaż opcje do modułu
Atest może przekazywać opcje do modułów testowych. Aby dodać opcje wiersza poleceń TradeFed do przebiegu testowego, użyj poniższej 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 docelowym osobom przygotowującym lub uruchamiającym testy zdefiniowanym 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
Opcje przekazywania 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 testowych, zobacz Przekazywanie opcji do modułów .