Przeprowadzanie testów (Atest)

Atest to narzędzie wiersza poleceń, które umożliwia użytkownikom kompilowanie, instalowanie i uruchamianie Android przeprowadza testy lokalnie, znacznie przyspieszając ponowne przeprowadzanie testów bez konieczności znajomość narzędzi testowych Federacji Handlowej, poleceń wiersza poleceń. Z tego artykułu dowiesz się, jak używać Atest do uruchamiania Androida testów.

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

Informacje o ogólnej strukturze Atest można znaleźć w Przewodnik dla programistów Atest.

Informacje o przeprowadzaniu testów w plikach TEST_MAPPING w Atest znajdziesz tutaj Przeprowadzam testy w plikach TEST_MAPPING.

Aby dodać funkcję do Atest, postępuj zgodnie z Przepływ pracy programistów w Atest.

Konfigurowanie środowiska

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

Podstawowe wykorzystanie

Polecenia Atest mają taką postać:

atest test-to-run [optional-arguments]

Opcjonalne argumenty

W poniższej tabeli znajdziesz najczęściej używane argumenty. Pełna lista to dostępny do atest --help.

Option	Długa opcja	Opis
-b	--build	Tworzy cele testowe. (domyślna)
-i	--install	Instaluje artefakty testowe 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 dezaktywację i czyszczenie testowe.
	--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 do momentu wystąpienia błędu lub do osiągnięcia maksymalnej liczby iteracji. udało się dotrzeć. (domyślnie 10)
	--retry-any-failure [COUNT=10]	Ponownie uruchamia nieudane testy do momentu zaliczenia lub osiągnięcia maksymalnej liczby iteracji. (10) domyślnie)
	--start-avd	Automatycznie tworzy średni czas oglądania i uruchamia testy na urządzeniu wirtualnym.
	--acloud-create	Tworzy usługę AVD przy użyciu 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	Przeprowadza cały test na hoście bez urządzenia. Uwaga: przeprowadzanie testu hosta, który wymaga urządzenia z --host nie powiedzie się.
	--history	Pokazuje wyniki testów w kolejności chronologicznej.
	--latest-result	Drukuje najnowszy wynik testu.

Więcej informacji o -b, -i i -t znajdziesz tutaj Określ kroki: kompilacja, instalacja lub uruchomienie.

Określ testy

Aby przeprowadzić testy, wybierz co najmniej 1 test, używając jednego z tych parametrów identyfikatory:

• 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 wyświetlaną nazwę w zmiennych LOCAL_MODULE lub LOCAL_PACKAGE_NAME w tym teście Android.mk lub Android.bp.

Przykłady:

atest FrameworksServicesTests
atest CtsVideoTestCases

Moduł:klasa

Aby uruchomić pojedynczą klasę w module, użyj polecenia Module:Class. Moduł to tak samo jak w sekcji Nazwa modułu. Class to nazwa klasy klasa testowa w pliku .java i może być w pełni kwalifikowaną nazwą klasy lub podstawowej nazwy.

Przykłady:

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

Nazwa zajęć

Aby uruchomić jedną klasę bez podawania nazwy modułu, użyj klasy imię i nazwisko.

Przykłady:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Test integracji z TradeF

Aby przeprowadzić testy zintegrowane bezpośrednio z TradeFed (które nie są modułami), wpisz w takiej postaci, w jakiej wyświetla się w danych wyjściowych polecenia tradefed.sh list configs. Dla: przykład:

Aby uruchomić Test reboot.xml:

atest example/reboot

Aby uruchomić Test native-benchmark.xml:

atest native-benchmark

Ścieżka pliku

Atest umożliwia przeprowadzanie testów zarówno opartych na modułach, jak i integracyjnych, poprzez podając odpowiednie ścieżki do pliku testowego lub katalogu. Dodatkowo obsługuje uruchamianie jednej klasy przez określenie ścieżki do jej pliku Java. Obsługiwane są zarówno ścieżki względne, jak i bezwzględne.

Uruchom moduł

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

Uruchom z Androida repo-root:

atest cts/tests/video

Uruchom z Androida repo-root/cts/tests/video:

    atest .

Uruchamianie zajęć testowych

Z przykładu poniżej dowiesz się, jak uruchomić określoną klasę w Moduł CtsVideoTestCases przy użyciu ścieżki pliku.

Z Androida repo-root:

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

Przeprowadzanie testu integracji

Przykład poniżej 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 obsługuje 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 określisz żadnej opcji, wówczas wszystkie kroki zostaną wykonane.

-t

• Tylko cele kompilacji: atest -b test-to-run
• Przeprowadź tylko testy: atest -t test-to-run
• Zainstaluj pakiet apk i przeprowadź testy: atest -it test-to-run
• Kompilowanie i uruchamianie, ale nie instaluj: atest -bt test-to-run

Atest może wymusić pominięcie kroku czyszczenia lub demontażu. Wiele testów, np. CTS, wyczyść urządzenie po przeprowadzeniu testu, a potem spróbuj wykonać test ponownie z parametrem -t zakończy się niepowodzeniem bez parametru --disable-teardown. Użyj -d przed -t, aby pominąć etap czyszczenia testowego i przetestować go iteracyjnie.

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ż cały system konieczne jest utworzenie modułu, co skraca czas potrzebny na przeprowadzenie testów. Aby uruchomić określonych metod, wskaż klasę przy użyciu jednego z obsługiwanych sposobów zidentyfikowanie klasy (moduł:klasa, ścieżka pliku itp.) i dołączenie nazwy klasy :

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

Poniższe 2 przykłady pokazują preferowane sposoby uruchamiania pojedynczej metody: testFlagChange Te przykłady są preferowane zamiast samej nazwy klasy bo określenie lokalizacji modułu lub pliku Java umożliwia Atest znalezienie testujemy znacznie szybciej.

Użycie właściwości Module:Class:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Z Androida repo-root:

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

W różnych klasach i modułach można uruchamiać wiele metod:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors

Uruchamianie wielu zajęć

Aby uruchomić kilka zajęć, rozdziel je spacjami, tak samo jak w przypadku biegania wielu testów. Atest skutecznie kompiluje i uruchamia klasy, więc określenie podzbioru klas w module poprawia wydajność w porównaniu z całym .

Aby uruchomić 2 zajęcia w jednym 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 kodu -a, aby uruchomić te testy dla wszystkich dostępnych architektury urządzeń, czyli w tym przykładzie armeabi-v7a (32-bitowy ARM) arm64-v8a (64-bitowa ARM).

Przykładowy test danych wejściowych:

atest -a libinput_tests inputflinger_tests

Aby wybrać konkretny plik binarny GTest do uruchomienia, wskaż test dwukropkiem (:). i hashtagu (#), aby dokładniej określić metodę.

Na przykład dla tej definicji testu:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Uruchom to polecenie, aby określić cały test:

atest inputflinger_tests:InputDispatcherTest

Możesz też przeprowadzić pojedynczy test za pomocą tego:

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Przeprowadź testy w TEST_MAPPING

Atest może uruchamiać testy w plikach TEST_MAPPING.

Bezpośrednie uruchamianie testów przed przesłaniem

Uruchamiaj testy wstępnego przesyłania w plikach TEST_MAPPING w katalogach bieżących i nadrzędnych:

atest

Przeprowadzaj testy przed przesłaniem w TEST_MAPPING plikach w /path/to/project i jego katalogi nadrzędne:

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

Uruchom określoną grupę testową

Dostępne grupy testowe: presubmit(wartość domyślna), postsubmit, mainline-presubmit i all.

Uruchamiaj testy po przesłaniu w plikach TEST_MAPPING w katalogach bieżących i nadrzędnych:

atest :postsubmit

Przeprowadź testy ze wszystkich grup w plikach TEST_MAPPING:

atest :all

Przeprowadzaj testy po przesłaniu w plikach TEST_MAPPING w /path/to/project i jego katalogi nadrzędne:

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

Przeprowadzaj testy głównej linii w plikach TEST_MAPPING w /path/to/project i jego katalogi nadrzędne:

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

Przeprowadzanie testów w podkatalogach

Domyślnie Atest wyszukuje testy w plikach o liczbie TEST_MAPPING wzwyż (od bieżącego lub podanego katalogu do katalogów nadrzędnych). Jeśli chcesz też dodać aby przeprowadzić testy w plikach TEST_MAPPING w podkatalogach, użyj --include-subdirs , aby wymóc w Atest dołączenie tych testów:

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

Przeprowadzanie testów w iteracji

Uruchamiaj testy w iteracji, przekazując argument --iterations. czy spełnia wymagania, lub nie powiedzie się, Atest będzie powtarzać test aż do osiągnięcia maksymalnej liczby iteracji.

Przykłady:

Domyślnie test Atest jest powtarzany 10 razy. Liczba iteracji musi być liczbą dodatnią liczba całkowita.

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

Te metody ułatwiają wykrywanie niepewnych testów:

Sposób 1. Uruchamiaj wszystkie testy aż do wystąpienia błędu lub osiągnięcia maksymalnej liczby iteracji.

• Zatrzymaj, gdy wystąpi błąd lub iteracja dobiegnie do dziesiątej (domyślnie) rundy.

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

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

  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 nie powiodły się. Uruchom tylko nieudane test 10 razy (domyślnie) lub do momentu zdanych testów.

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

• Zatrzymaj test zakończony niepowodzeniem, gdy zakończy się on lub dobiegnie końca do dziesiątej rundy.

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

Przeprowadzanie testów na urządzeniach AVD

Atest może uruchamiać testy na nowo utworzonym AVD. Uruchom acloud create, aby utworzyć AVD i artefakty kompilacji, a potem przeprowadź testy, korzystając z podanych niżej przykładów.

Uruchom AVD i przeprowadź na nim testy:

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

W ramach uruchomienia testowego uruchom AVD:

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

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

Opcje przekazywania do modułu

Atest może przekazywać opcje modułów testowych. Aby dodać wiersz poleceń TradeFed do testu, zastosuj poniższą strukturę i upewnij się, że niestandardowy są zgodne z formatem opcji wiersza poleceń Tradefed.

atest test-to-run -- [CUSTOM_ARGS]

Zaliczaj opcje modułu testów, aby kierować do osób przygotowujących lub wykonujących testy określone w testowy plik konfiguracyjny:

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

Przekaż opcje 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 dostępnych tylko do testów: Opcje przekazywania do modułów.