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. Z tego artykułu dowiesz się, jak używać narzędzia Atest do uruchamiania testów na Androida.

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

Informacje o ogólnej strukturze 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, wykonaj przepływ pracy dla programistów w Atest.

Konfigurowanie środowiska

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

Podstawowe użycie

Polecenia testowania mają następującą 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 (pliki APK) na urządzeniu. (domyślna)
-t --test Uruchamia testy. (domyślna)
-s --serial Uruchamia testy na określonym urządzeniu. W danym momencie można testować 1 urządzenie.
-d --disable-teardown Wyłącza testowanie i czyszczenie.
--dry-run Uruchamia próbnie uruchomienie Atest bez konieczności tworzenia, instalowania czy uruchamiania testów.
-m --rebuild-module-info Wymusza ponowne utworzenie pliku module-info.json.
-w --wait-for-debugger Czeka na zakończenie działania debugera przed wykonaniem polecenia.
-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] Ponowne uruchamianie nieudanych testów do czasu, gdy zostaną zaliczone lub osiągnięta zostanie maksymalna liczba 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 Testy są przeprowadzane na wszystkich dostępnych architekturach urządzeń.
--host Przeprowadza cały test na hoście bez urządzenia.
Uwaga: testowanie hosta, które wymaga urządzenia z --host, zakończy się niepowodzeniem.
--history Pokazuje wyniki testów w kolejności chronologicznej.
--latest-result Wypisuje najnowszy wynik testu.

Więcej informacji o opcjach -b, -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 TradeF
  • Ścieżka pliku
  • Nazwa pakietu

Oddziel odwołania do wielu testów za pomocą spacji. Przykład:

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 testowej klasy w pliku .java. 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 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.

Uruchom z Androida repo-root:

atest cts/tests/video

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

    atest .

Uruchamianie zajęć testowych

Poniższy przykład pokazuje, jak uruchomić określoną klasę w module CtsVideoTestCases za pomocą ścieżki pliku.

Na urządzeniu z Androidem repo-root:

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

Przeprowadzanie testu integracji

Ten przykład pokazuje, jak uruchomić 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 należy wykonać, użyj opcji -b, -i i -t. Jeśli nie wybierzesz opcji, zostaną wykonane wszystkie czynności.

-t
  • Tylko środowisko docelowe kompilacji: atest -b test-to-run
  • 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 konkretnych metod

Atest obsługuje uruchamianie określonych metod w ramach klasy testu. Chociaż trzeba skompilować cały moduł, to spowoduje to skrócenie czasu potrzebnego na wykonanie 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

Uruchamianie wielu 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. Aby uruchomić te testy na wszystkich dostępnych architekturach urządzeń, użyj opcji -a. W tym przykładzie są to armeabi-v7a (ARM 32-bitowy) i arm64-v8a (ARM 64-bitowy).

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, korzystając z tych opcji:

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Przeprowadź testy w aplikacji TEST_MAPPING

Atest może uruchamiać testy w plikach TEST_MAPPING.

Bezpośrednie uruchamianie testów przed przesłaniem

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

Uruchamianie określonej grupy testów

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 folderze /path/to/project i jego nadrzędnych katalogach:

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 tylko testy w plikach TEST_MAPPING w kierunku od bieżącego katalogu w górę (od bieżącego lub podanego 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

Uruchom 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 dobiegnie do dziesiątej (domyślnie) rundy.
    atest test-to-run --rerun-until-failure
    
  • Zatrzymaj się, gdy wystąpi błąd lub iteracja osiągnie 100 okrążeń.
    atest test-to-run --rerun-until-failure 100
    

Sposób 2. Uruchamiaj tylko nieudane testy, dopóki nie zostaną zaliczone lub nie zostanie osiągnięta maksymalna liczba iteracji.

  • Załóżmy, że test-to-run ma wiele przypadków testowych i jeden z testów zakończył się niepowodzeniem. Przeprowadź tylko nieudany test 10 razy (domyślnie) lub do czasu, aż test się powiedzie.
    atest test-to-run --retry-any-failure
    
  • Zatrzymaj nieudany test, gdy go przejdziesz lub dojdzie do 100 runda.
    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ć AVD i budować artefakty, a potem uruchom testy, korzystając z tych przykładów.

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.