Uruchamianie testów (Atest), Uruchamianie testów (Atest)

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 .