Uruchom testy (Atest)

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 .