Przeprowadzanie testów (Atest)

Atest to narzędzie wiersza poleceń, które umożliwia użytkownikom kompilowanie, instalowanie i uruchamianie testów Androida lokalnie, znacznie przyspieszając ponowne uruchamianie testów bez konieczności znajomości opcji wiersza poleceń Trade Federation test harness. Na tej stronie wyjaśniamy, jak używać Atest do przeprowadzania testów aplikacji na Androida.

Ogólne informacje o pisaniu testów na Androida znajdziesz w artykule Testowanie na platformie Android.

Informacje o ogólnej strukturze interfejsu Atest znajdziesz w przewodniku dla programistów Atest.

Informacje o uruchamianiu testów w plikach TEST_MAPPING za pomocą Atest znajdziesz w artykule Przeprowadzanie testów w plikach TEST_MAPPING.

Aby dodać funkcję do Atest, postępuj zgodnie z przepływem pracy programisty Atest.

Konfigurowanie środowiska

Aby skonfigurować środowisko Atest, wykonaj instrukcje podane w artykułach Konfigurowanie środowiska, Wybieranie celu i Tworzenie kodu.

Podstawowe wykorzystanie

Polecenia Atest mają taką postać:

atest test-to-run [optional-arguments]

Opcjonalne argumenty

W tabeli poniżej znajdziesz najczęściej używane argumenty. Pełną listę znajdziesz na stronie atest --help.

Option	Długa opcja	Opis
-b	--build	Tworzy środowiska docelowe testowe. (domyślna)
-i	--install	Instaluje artefakty testowe na urządzeniu. (domyślna)
-t	--test	Przeprowadza testy. (domyślna)
-s	--serial	Uruchamia testy na określonym urządzeniu. W danym momencie można testować tylko jedno urządzenie.
-d	--disable-teardown	Wyłącza testowanie i czyszczenie.
	--dry-run	Testowanie Atest bez faktycznego kompilowania, instalowania i uruchamiania testów.
-m	--rebuild-module-info	Wymusza ponowne utworzenie pliku module-info.json.
-w	--wait-for-debugger	Przed wykonaniem czeka na zakończenie debugowania.
-v	--verbose	Wyświetla logowanie na poziomie DEBUG.
	--iterations	Zapętla testy aż do osiągnięcia maksymalnej liczby iteracji. (domyślnie 10)
	--rerun-until-failure [COUNT=10]	Ponownie uruchamia wszystkie testy, aż wystąpi błąd lub osiągnie maksymalną liczbę iteracji. (domyślnie 10)
	--retry-any-failure [COUNT=10]	Ponownie uruchamia nieudane testy do momentu zaliczenia lub osiągnięcia maksymalnej liczby iteracji. (domyślnie 10)
	--start-avd	Automatycznie tworzy urządzenie AVD i wykonuje testy na tym urządzeniu.
	--acloud-create	Tworzy AVD za pomocą polecenia acloud.
	--[CUSTOM_ARGS]	Określa niestandardowe argumenty dla uczestników testu.
-a	--all-abi	Przeprowadza testy dla wszystkich dostępnych architektur urządzeń.
	--host	Test jest wykonywany całkowicie na hoście bez urządzenia. Uwaga: testowanie hosta, które wymaga urządzenia z --host, zakończy się niepowodzeniem.
	--history	Wyświetla wyniki testu w kolejności chronologicznej.
	--latest-result	Wypisuje najnowszy wynik testu.

Więcej informacji o opcjach -b, -i i -t znajdziesz w sekcji Określ kroki: kompilowanie, instalowanie lub uruchamianie.

Określanie testów

Aby uruchomić testy, określ co najmniej jeden test za pomocą jednego z tych identyfikatorów:

• Nazwa modułu
• Moduł:Klasa
• Nazwa zajęć
• Test integracji z użyciem pliku .aab
• Ścieżka pliku
• Nazwa pakietu

Odwołania do wielu testów oddziel spacjami, np.

atest test-identifier-1 test-identifier-2

Nazwa modułu

Aby uruchomić cały moduł testowy, użyj jego nazwy. Wpisz nazwę w takiej postaci, w jakiej wyświetla się w zmiennych LOCAL_MODULE lub LOCAL_PACKAGE_NAME w pliku Android.mk lub Android.bp danego testu.

Przykłady:

atest FrameworksServicesTests
atest CtsVideoTestCases

Moduł:klasa

Aby przeprowadzić zajęcia w ramach modułu, użyj opcji Moduł:zajęcia. Module to ten sam parametr, który opisaliśmy w sekcji Nazwa modułu. Class to nazwa klasy testowej w pliku .java. Może to być w pełni kwalifikowana nazwa klasy lub nazwa podstawowa.

Przykłady:

atest CtsVideoTestCases:VideoEncoderDecoderTest
atest FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests

Nazwa zajęć

Aby uruchomić pojedynczą klasę bez podawania nazwy modułu, użyj nazwy klasy.

Przykłady:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Test integracji z użyciem pliku .aab

Aby uruchomić testy zintegrowane bezpośrednio z TradeFed (niemoduły), wpisz nazwę tak, jak jest ona widoczna w wyniku polecenia tradefed.sh list configs. 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 testów opartych na module i testów opartych na integracji. W tym celu należy podać ścieżkę do odpowiedniego pliku lub katalogu testowego. Umożliwia też uruchamianie pojedynczej klasy przez podanie ścieżki do pliku Java klasy. Obsługiwane są ścieżki względne i bezwzględne.

Uruchamianie modułu

Poniższe przykłady pokazują 2 sposoby uruchamiania modułu CtsVideoTestCases za pomocą ścieżki pliku.

Uruchamianie z urządzenia z Androidem repo-root:

atest cts/tests/video

Uruchamianie z urządzenia z Androidem repo-root/cts/tests/video:

    atest .

Uruchamianie testowej klasy

Ten przykład pokazuje, jak uruchomić konkretną klasę w module CtsVideoTestCases za pomocą ścieżki pliku.

Z Androida repo-root:

    atest cts/tests/video/src/android/video/cts/VideoEncoderDecoderTest.java

Przeprowadzanie testu integracji

Poniższy przykład pokazuje, jak przeprowadzić test integracji za pomocą ścieżki pliku z Androida repo-root:

    atest tools/tradefederation/contrib/res/config/example/reboot.xml

Nazwa pakietu

Atest umożliwia wyszukiwanie testów według nazwy pakietu.

Przykłady:

    atest com.android.server.wm
    atest com.android.uibench.janktests

Określ kroki: kompilacja, instalacja lub uruchomienie

Aby określić, które kroki mają być wykonywane, użyj opcji -b, -i i -t. Jeśli nie wybierzesz opcji, zostaną wykonane wszystkie czynności.

• Tylko środowisko docelowe kompilacji: atest -b test-to-run
• Przeprowadź tylko testy: atest -t test-to-run
• Zainstaluj plik APK i przeprowadź testy: atest -it test-to-run
• Kompilowanie i uruchamianie, ale bez instalowania: atest -bt test-to-run

Atest może zmusić test do pominięcia kroku czyszczenia lub demontażu. Wiele testów, np. CTS, oczyszcza urządzenie po ich uruchomieniu, więc ponowne uruchomienie testu-t nie powiedzie się bez parametru --disable-teardown. Użyj -d przed -t, aby pominąć krok czyszczenia testu i przeprowadzić testy stopniowo.

atest -d test-to-run
atest -t test-to-run

Uruchamianie określonych metod

Atest obsługuje uruchamianie określonych metod w ramach klasy testowej. Chociaż trzeba zbudować cały moduł, skraca to czas potrzebny na przeprowadzenie testów. Aby uruchomić określone metody, zidentyfikuj klasę, korzystając z dowolnej metody identyfikacji klasy (Module:Class, ścieżka pliku itp.) i dołącz nazwę metody:

atest reference-to-class#method1

Jeśli podajesz kilka 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

Te 2 przykłady pokazują preferowane sposoby uruchamiania pojedynczej metody:testFlagChange. Te przykłady są preferowane zamiast używania nazwy klasy, ponieważ określenie modułu lub lokalizacji pliku Java umożliwia Atest znacznie szybsze znalezienie testu.

Korzystanie z modułu:zajęcia:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Na urządzeniu z Androidem repo-root:

atest frameworks/base/services/tests/wmtests/src/com/android/server/wm/ScreenDecorWindowTests.java#testFlagChange

Z różnych klas i modułów można wywoływać wiele metod:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors

Prowadź wiele zajęć

Aby uruchomić wiele klas, oddziel je spacjami w taki sam sposób jak w przypadku uruchamiania wielu testów. Atest buduje i uruchamia klasy efektywnie, więc określenie podzbioru klas w module poprawia wydajność w porównaniu z uruchomieniem całego modułu.

Aby uruchomić 2 klasy w tym samym module:

atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests

Aby przeprowadzić 2 zajęcia w różnych modułach:

atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest

Uruchamianie plików binarnych GTest

Atest może uruchamiać pliki binarne GTest. Użyj -a, aby uruchomić te testy dla wszystkich dostępnych architektur urządzeń, czyli w tym przykładzie to armeabi-v7a (32-bitowy ARM) i arm64-v8a (64-bitowy ARM).

Przykładowy test danych wejściowych:

atest -a libinput_tests inputflinger_tests

Aby wybrać do uruchomienia konkretny plik binarny GTest, użyj dwukropka (:), aby określić nazwę testu, i znaku hashtaga (#), aby dokładniej określić poszczególną metodę.

Na przykład w przypadku tej definicji testu:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Aby określić cały test, wykonaj te czynności:

atest inputflinger_tests:InputDispatcherTest

Możesz też uruchomić pojedynczy test za pomocą tych opcji:

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Przeprowadzanie testów w TEST_MAPPING

Atest może przeprowadzać testy w plikach TEST_MAPPING.

uruchamianie testów przed przesłaniem w sposób domyślny,

Przeprowadzanie testów przed przesłaniem w plikach TEST_MAPPING w bieżącym katalogu i katalogach nadrzędnych:

atest

Przeprowadź 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: presubmit(wartość domyślna), postsubmit, mainline-presubmit i all.

Przeprowadzanie testów po przesłaniu w plikach TEST_MAPPING w bieżącym katalogu i katalogu 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 pliku /path/to/project i w jego katalogach nadrzędnych:

atest --test-mapping /path/to/project:postsubmit

Przeprowadź testy główne w plikach TEST_MAPPING w folderze /path/to/project i jego katalogach nadrzędnych:

atest --test-mapping /path/to/project:mainline-presubmit

Uruchamianie testów w katalogach podrzędnych

Domyślnie Atest wyszukuje testy tylko w plikach TEST_MAPPING w górę (od bieżącego lub danego katalogu do jego katalogów nadrzędnych). Jeśli chcesz też uruchamiać testy w plikach TEST_MAPPING w podkatalogach, użyj opcji --include-subdirs, aby wymusić uwzględnienie tych testów przez Atest:

atest --include-subdirs /path/to/project

Przeprowadzanie testów w iteracji

Uruchamiaj testy w iteracji, przekazując argument --iterations. Niezależnie od tego, czy test się powiedzie, czy nie, Atest będzie go powtarzać, aż osiągnie maksymalną liczbę iteracji.

Przykłady:

Domyślnie Atest powtarza się 10 razy. Liczba iteracji musi być dodatnią liczbą całkowitą.

atest test-to-run --iterations
atest test-to-run --iterations 5

Aby ułatwić wykrywanie niestabilnych testów, możesz skorzystać z tych metod:

Metoda 1. Wykonuj wszystkie testy, aż wystąpi błąd lub osiągniesz maksymalną liczbę iteracji.

• Zatrzymaj, gdy wystąpi błąd lub iteracja osiągnie 10 okrążenie (domyślnie).

  atest test-to-run --rerun-until-failure
  

• Zatrzymaj, gdy wystąpi błąd lub iteracja osiągnie 100. rundę.

  atest test-to-run --rerun-until-failure 100
  

Metoda 2. Uruchamiaj tylko nieudane testy, aż do ich przejścia lub osiągnięcia maksymalnej liczby iteracji.

• Załóżmy, że test-to-run ma wiele przypadków testowych, a jeden z nich kończy się niepowodzeniem. Wykonaj tylko nieudany test 10 razy (domyślnie) lub dopóki test nie będzie udany.

  atest test-to-run --retry-any-failure
  

• Zatrzymaj nieudany test, gdy zostanie zaliczony lub osiągnie 100 okrążeń.

  atest test-to-run --retry-any-failure 100
  

Przeprowadzanie testów na urządzeniach AVD

Atest może przeprowadzać testy na nowo utworzonym AVD. Uruchom acloud create, aby utworzyć narzędzie AVD i artefakty kompilacji, a następnie przeprowadź testy zgodnie z poniższymi przykładami.

Uruchom AVD i przeprowadź testy:

acloud create --local-instance --local-image && atest test-to-run

Rozpoczynanie AVD w ramach testu:

atest test-to-run --acloud-create "--local-instance --local-image"

Aby dowiedzieć się więcej, uruchom polecenie acloud create --help.

Przekazywanie opcji do modułu

Atest może przekazywać opcje do testowania modułów. Aby dodać opcje wiersza poleceń TradeFed do testu, użyj tej struktury i upewnij się, że Twoje argumenty niestandardowe są zgodne z formatem opcji wiersza poleceń Tradefed.

atest test-to-run -- [CUSTOM_ARGS]

Przekazywanie opcji modułu testu do docelowych przygotowujących lub uruchamiających testy zdefiniowanych w pliku konfiguracji testu:

atest test-to-run -- --module-arg module-name:option-name:option-value
atest GtsPermissionTestCases -- --module-arg GtsPermissionTestCases:ignore-business-logic-failure:true

Przekazywanie opcji do typu lub klasy Runner:

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

Więcej informacji o opcjach tylko do testowania znajdziesz w artykule Przekazywanie opcji do modułów.