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 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 proces dla deweloperów.

Konfigurowanie środowiska

Aby skonfigurować środowisko Atest, wykonaj instrukcje podane w artykułach Konfigurowanie środowiska, Wybieranie celu i Tworzenie 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 Przeprowadza testy. (domyślna)
-s --serial Uruchamia testy na określonym urządzeniu. W danym momencie można testować tylko 1 urządzenie.
-d --disable-teardown Wyłącza testy demontażu i czyszczenia.
--dry-run Uruchomienie próbne Atest bez faktycznego kompilowania, instalowania lub 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 Testy są wykonywane w pętli do osiągnięcia maksymalnej iteracji. (domyślnie 10)
--rerun-until-failure [COUNT=10] Ponownie uruchamia wszystkie testy, aż do wystąpienia błędu lub osiągnięcia maksymalnej liczby 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 narzędzi do testowania.
-a --all-abi Testy są przeprowadzane na wszystkich dostępnych architekturach 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 Wyniki testów są wyświetlane 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 1 test za pomocą jednego z tych identyfikatorów:

  • Nazwa modułu
  • Moduł:Klasa
  • Nazwa zajęć
  • Test integracji z użyciem pliku .tfm
  • Ś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ł testu, użyj jego nazwy. Wpisz nazwę taką, jak jest ona widoczna w zmiennych LOCAL_MODULE lub LOCAL_PACKAGE_NAME w pliku Android.mk lub Android.bp testu.

Przykłady:

atest FrameworksServicesTests
atest CtsVideoTestCases

Moduł:Klasa

Aby przeprowadzić zajęcia w ramach modułu, użyj opcji Moduł:zajęcia. Moduł to ten sam moduł, który został opisany 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 .tfm

Aby uruchomić testy zintegrowane bezpośrednio z TradeFed (niemoduły), wpisz nazwę taką, jaką podano w wyniku polecenia tradefed.sh list configs. Przykład:

Aby przeprowadzićreboot.xml test:

atest example/reboot

Aby przeprowadzićnative-benchmark.xml test:

atest native-benchmark

Ścieżka pliku

Atest obsługuje uruchamianie testów opartych na modułach i testów opartych na integracji. W tym celu należy podać ścieżkę do odpowiedniego pliku testowego lub katalogu. 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.

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 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
  • Tylko testy: atest -t test-to-run
  • Zainstaluj pakiet APK i przeprowadź testy: atest -it test-to-run
  • Kompilowanie i uruchamianie, ale bez instalowania: atest -bt test-to-run

Atest może wymusić pominięcie 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ć testowanie iteracyjne.

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.), a potem dodaj 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ą lepsze niż używanie tylko nazwy klasy, ponieważ określenie modułu lub lokalizacji pliku Java pozwala Atestowi znaleźć test znacznie szybciej.

Korzystanie z Modułu:klasy:

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 prowadzić 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 przeprowadzić 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 #, 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

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

Przeprowadzanie testów przed przesłaniem w plikach TEST_MAPPING w katalogu /path/to/project i jego nadrzędnych katalogach:

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

Uruchamianie określonej grupy testów

Dostępne grupy testów: presubmit(domyślnie), 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

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

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

Uruchamianie 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 osiągnie 10 okrąg (domyślnie). 
    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

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. Przeprowadź tylko nieudany test 10 razy (domyślnie) lub do czasu, aż test się powiedzie. 
    atest test-to-run --retry-any-failure
  • Przerwij 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ć AVD i pliki kompilacji, 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 biegacza:

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.