Przeprowadzanie testów (Atest)

Atest to narzędzie wiersza poleceń, które umożliwia użytkownikom lokalne tworzenie, instalowanie i uruchamianie testów Androida, co znacznie przyspiesza ponowne uruchamianie testów bez konieczności znajomości opcji wiersza poleceń platformy testowej Trade Federation. Na tej stronie dowiesz się, jak używać narzędzia Atest do uruchamiania testów Androida.

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

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

Informacje o przeprowadzaniu testów w plikach TEST_MAPPING za pomocą Atest znajdziesz w sekcji Przeprowadzanie testów w plikach TEST_MAPPING.

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

Konfigurowanie środowiska

Aby skonfigurować środowisko Atest, postępuj zgodnie z instrukcjami w sekcjach Konfigurowanie środowiska, Wybieranie celu i Kompilowanie kodu.

Podstawowe użycie

Polecenia atestu mają następującą formę:

atest test-to-run [optional-arguments]

Argumenty opcjonalne

W tabeli poniżej znajdziesz listę najczęściej używanych argumentów. Pełna lista jest dostępna atest --help.

Opcja Długa opcja Opis
-b --build Tworzy testowe środowiska docelowe. (domyślna)
-i --install Instaluje na urządzeniu artefakty testowe (pliki APK). (domyślna)
-t --test Uruchamia testy. (domyślna)
-s --serial Uruchamia testy na określonym urządzeniu. W tym samym czasie można przetestować tylko 1 urządzenie.
-d --disable-teardown Wyłącza zamykanie i czyszczenie testu.
--dry-run Uruchomienia próbne Atest bez kompilowania, instalowania ani 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.
-v --verbose Wyświetla logowanie na poziomie DEBUG.
--iterations Pętla wykonuje testy do momentu osiągnięcia maksymalnej liczby iteracji. (domyślnie 10)
--rerun-until-failure [COUNT=10] Ponownie uruchamia wszystkie testy, dopóki nie wystąpi błąd lub nie zostanie osiągnięta maksymalna liczba iteracji. (domyślnie 10)
--retry-any-failure [COUNT=10] Ponownie uruchamia testy, które zakończyły się niepowodzeniem, dopóki nie zostaną zaliczone lub nie zostanie osiągnięta maksymalna liczba iteracji. (domyślnie 10)
--start-avd Automatycznie tworzy AVD i przeprowadza testy na urządzeniu wirtualnym.
--acloud-create Tworzy AVD za pomocą polecenia acloud.
--[CUSTOM_ARGS] Określa niestandardowe argumenty dla programów do uruchamiania testów.
-a --all-abi Uruchamia testy dla wszystkich dostępnych architektur urządzeń.
--host Przeprowadza test w całości na hoście bez urządzenia.
Uwaga: uruchomienie testu hosta, który wymaga urządzenia z --host, zakończy się niepowodzeniem.
--history Wyświetla wyniki testu w kolejności chronologicznej.
--latest-result Wyświetla ostatni wynik testu.

Więcej informacji o -b, -i i -t znajdziesz w sekcji Określanie kroków: kompilacja, instalacja lub uruchomienie.

Określanie testów

Aby uruchomić testy, określ co najmniej 1 test, używając jednego z tych identyfikatorów:

  • Nazwa modułu
  • Moduł:Klasa
  • Nazwa zajęć
  • Test integracji Tradefed
  • Ścieżka pliku
  • Nazwa pakietu

Odwołania do kilku 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ę taką, jaka 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ł to to samo, co opisano w sekcji Nazwa modułu. Class to nazwa klasy testowej 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 Tradefed

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

Aby przeprowadzić test reboot.xml:

atest example/reboot

Aby przeprowadzić test native-benchmark.xml:

atest native-benchmark

Ścieżka pliku

Atest obsługuje uruchamianie testów opartych na modułach i testów integracyjnych przez wprowadzanie ścieżki do pliku lub katalogu testowego. Umożliwia też uruchomienie pojedynczej klasy przez podanie ścieżki do pliku Java klasy. Obsługiwane są zarówno ścieżki względne, jak i bezwzględne.

Uruchamianie modułu

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

Uruchom z urządzenia z Androidem repo-root:

atest cts/tests/video

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

    atest .

Uruchamianie klasy testowej

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

Z urządzenia z Androidem repo-root:

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

Uruchamianie testu integracji

Poniższy przykład pokazuje, jak uruchomić test integracyjny 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ślanie kroków: kompilacja, instalacja lub uruchomienie

Użyj opcji -b, -i i -t, aby określić, które kroki mają zostać wykonane. Jeśli nie określisz opcji, zostaną wykonane wszystkie kroki.

  • Tylko środowiska docelowe kompilacji: atest -b test-to-run
  • Przeprowadzaj tylko testy: atest -t test-to-run
  • Zainstaluj plik APK i przeprowadź testy: atest -it test-to-run
  • Tworzenie i uruchamianie bez instalowania: atest -bt test-to-run

Atest może wymusić pominięcie kroku czyszczenia lub zamykania testu. Wiele testów, np. CTS, czyści urządzenie po uruchomieniu, więc próba ponownego uruchomienia testu za pomocą polecenia -t zakończy się niepowodzeniem bez parametru --disable-teardown. Użyj -d przed -t, aby pominąć krok czyszczenia testu i przeprowadzać testy 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 na przeprowadzenie testów. Aby uruchomić konkretne metody, zidentyfikuj klasę w dowolny obsługiwany sposób (moduł:klasa, ścieżka do pliku itp.) i dołącz nazwę metody:

atest reference-to-class#method1

Jeśli podajesz kilka metod, oddziel je przecinkami:

atest reference-to-class#method1,method2,method3

Przykłady:

atest com.android.server.wm.ScreenDecorWindowTests#testMultipleDecors
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval

W 2 przykładach poniżej pokazujemy 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 Class:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Z urządzenia z Androidem repo-root:

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

Wiele metod można uruchamiać z różnych klas i modułów:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors

Prowadzenie wielu zajęć

Aby uruchomić kilka klas, oddziel je spacjami w taki sam sposób jak w przypadku uruchamiania wielu testów. Atest tworzy i uruchamia klasy w efektywny sposób, 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 uruchomić 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 symbolu -a, aby uruchomić te testy dla wszystkich dostępnych architektur urządzeń, które w tym przykładzie to armeabi-v7a (ARM 32-bit) i arm64-v8a (ARM 64-bit).

Przykładowy test danych wejściowych:

atest -a libinput_tests inputflinger_tests

Aby wybrać konkretny plik binarny GTest do uruchomienia, użyj dwukropka (:) do określenia nazwy testu i znaku hash (#) do określenia konkretnej metody.

Na przykład w przypadku tej definicji testu: 

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Aby określić cały test, uruchom to polecenie: 

atest inputflinger_tests:InputDispatcherTest

Możesz też uruchomić pojedynczy test, korzystając z tego polecenia: 

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Uruchamianie testów w pliku TEST_MAPPING

Atest może przeprowadzać testy w plikach TEST_MAPPING.

Uruchamianie testów przed przesłaniem w sposób niejawny

Uruchom testy przed przesłaniem w plikach TEST_MAPPING w bieżącym katalogu i katalogach nadrzędnych:

atest

Uruchom testy przed przesłaniem w plikach TEST_MAPPING w /path/to/project i jego katalogach nadrzędnych:

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

Uruchamianie określonej grupy testowej

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 testy główne w plikach TEST_MAPPING w /path/to/project i jego katalogach nadrzędnych:

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

Przeprowadzanie testów w podkatalogach

Domyślnie Atest wyszukuje testy tylko w plikach TEST_MAPPING 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 --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 zakończy się powodzeniem czy nie, Atest będzie go powtarzać, aż osiągnie maksymalną liczbę iteracji.

Przykłady:

Domyślnie Atest wykonuje 10 iteracji. Liczba iteracji musi być dodatnią liczbą całkowitą.

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

Wykrywanie niestabilnych testów ułatwiają te metody:

Podejście 1. Uruchom wszystkie testy, aż wystąpi błąd lub zostanie osiągnięta maksymalna liczba iteracji.

  • Zatrzymanie, gdy wystąpi błąd lub iteracja osiągnie 10 rundę (domyślnie). 
    atest test-to-run --rerun-until-failure
  • Zatrzymaj się, gdy wystąpi błąd lub iteracja osiągnie 100 rundę. 
    atest test-to-run --rerun-until-failure 100

Podejście 2. Uruchamiaj tylko testy zakończone niepowodzeniem, dopóki nie zakończą się powodzeniem lub nie zostanie osiągnięta maksymalna liczba iteracji.

  • Załóżmy, że test-to-run ma wiele przypadków testowych i jeden z nich zakończył się niepowodzeniem. Uruchom tylko nieudany test 10 razy (domyślnie) lub do momentu, aż test się powiedzie. 
    atest test-to-run --retry-any-failure
  • Zatrzymaj nieudany test, gdy przejdzie on pomyślnie lub osiągnie 100 rundę. 
    atest test-to-run --retry-any-failure 100

Przeprowadzanie testów na AVD

Atest może przeprowadzać testy na nowo utworzonym AVD. Uruchom acloud create, aby utworzyć AVD i artefakty kompilacji, a potem użyj tych 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"

Więcej informacji znajdziesz po uruchomieniu polecenia acloud create --help.

Przekazywanie opcji do modułu

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

atest test-to-run -- [CUSTOM_ARGS]

Przekaż opcje modułu testowego do preparatorów lub narzędzi do uruchamiania testów 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

Przekazywanie opcji do typu lub klasy wykonawcy:

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 dostępnych tylko w trybie testowym znajdziesz w artykule Przekazywanie opcji do modułów.