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 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 |
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
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.