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, wykonaj instrukcje podane w artykułach Konfigurowanie środowiska, Wybieranie celu i Tworzenie kodu.

Podstawowe użycie

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.

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ł testu, 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 uruchomić testy zintegrowane bezpośrednio z TradeFed (niemoduły), wpisz nazwę tak, jak jest ona widoczna w wyniku polecenia tradefed.sh list configs. Na 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ą ścieżki pliku.

Uruchamianie z urządzenia z Androidem 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.

• Tylko środowisko docelowe kompilacji: atest -b test-to-run
• Przeprowadź tylko testy: atest -t test-to-run
• Zainstaluj plik APK i wykonaj 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

Te 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 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. 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ć 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)

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

Przeprowadzanie testów po przesłaniu w plikach TEST_MAPPING w bieżącym katalogu i katalogu nadrzędnym:

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

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 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 nie powiodły się. Przeprowadź tylko nieudany test 10 razy (domyślnie) lub do czasu, aż test się powiedzie.

  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 elementy kompilacji, a potem uruchom testy, korzystając z tych 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.

Przekazywanie opcji 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

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