Badanie

Atest jest narzędziem wiersza poleceń, które pozwala użytkownikom budować, zainstalować i uruchomić testy Android lokalnie, znacznie przyspieszając testowych powtórki bez konieczności znajomości Federacji Handlowej uprzęży testu opcji wiersza poleceń. Ta strona wyjaśnia, jak używać Atest do uruchamiania testów Androida.

Ogólne informacje na temat pisania testów dla Androida, patrz Android Testowanie platformy .

Więcej informacji na temat ogólnej struktury Atest patrz Atest Developer Guide .

Więcej informacji na temat uruchamiania testów w plikach TEST_MAPPING przez Atest, zobacz Uruchamianie testów w plikach TEST_MAPPING .

I dodać funkcję do Atest, wykonaj Atest Developer Workflow .

Konfigurowanie środowiska

Aby uruchomić Atest, wykonaj czynności opisane w poniższych sekcjach, aby skonfigurować środowisko.

Ustaw zmienną środowiskową

Zestaw test_suite dla Soong lub LOCAL_COMPATIBILITY_SUITE dla Marka za Packaging zasady kompilacji skryptów .

Uruchom envsetup.sh

W katalogu głównym kasy źródłowej systemu Android uruchom:

source build/envsetup.sh

Uruchom lunch

Uruchom lunch polecenie, aby przywołać menu obsługiwanych urządzeń. Znajdź urządzenie i uruchom to polecenie.

Na przykład, jeśli masz podłączone urządzenie ARM, uruchom następujące polecenie:

lunch aosp_arm64-eng

To ustawia różne zmienne środowiskowe wymagane do prowadzenia atest i dodaje komendy Atest do $PATH .

Podstawowe zastosowanie

Polecenia Atest mają następującą postać:

atest test-to-run [optional-arguments]

Argumenty opcjonalne

Poniżej znajdują się najczęściej używane argumenty. Pełna lista jest dostępna za pośrednictwem atest --help .

Opcja Długa opcja Opis
-b --build Buduje cele testowe. (domyślny)
-i --install Instaluje artefakty testowe (APK) na urządzeniu. (domyślny)
-t --test Uruchamia testy. (domyślny)
-s --serial Uruchamia testy na określonym urządzeniu. Jedno urządzenie może być testowane na raz.
-d --disable-teardown Wyłącza testowe usuwanie i czyszczenie.
--info Pokazuje odpowiednie informacje o określonych celach i wyjściach.
--dry-run Testowanie na sucho bez budowania, instalowania i przeprowadzania testów w rzeczywistości
-m --rebuild-module-info Wymusza odbudować w module-info.json pliku.
-w --wait-for-debugger Czeka na debugger przed wykonaniem. Tylko do testów oprzyrządowania.
-v --verbose Wyświetla rejestrowanie poziomu DEBUG.
--iterations Testy wykonywania pętli aż do osiągnięcia maksymalnej liczby iteracji. (10 domyślnie)
--rerun-until-failure [COUNT=10] Ponawia wszystkie testy do momentu wystąpienia błędu lub osiągnięcia maksymalnej liczby iteracji. (10 domyślnie)
--retry-any-failure [COUNT=10] Ponawia testy zakończone niepowodzeniem do momentu zaliczenia lub osiągnięcia maksymalnej liczby iteracji. (10 domyślnie)
--start-avd Automatycznie tworzy AVD i uruchamia testy na urządzeniu wirtualnym.
--acloud-create Tworzy AVDs pomocą acloud command.
--[CUSTOM_ARGS] Określa niestandardowe argumenty dla biegaczy testowych.
-a --all-abi Uruchamia testy dla wszystkich dostępnych architektur urządzeń.
--host Uruchamia test całkowicie na hoście bez urządzenia.
(Uwaga: Uruchomienie testu gospodarza, która wymaga urządzenia z --host zawiedzie).
--flakes-info Pokazuje wynik testu z informacjami o płatkach.
--history Pokazuje wynik testu w porządku chronologicznym.
--latest-result Drukuje najnowszy wynik testu.

Aby uzyskać więcej informacji na temat -b , -i i -t , zobacz Określanie czynności: budować, zainstalować lub uruchomić.

Testy do uruchomienia

Można uruchomić jeden lub więcej testów za pomocą test-to-run . Aby uruchomić wiele testów, oddziel odwołania do testów spacjami. Na przykład:

atest test-to-run-1 test-to-run-2

Oto kilka przykładów:

atest FrameworksServicesTests
atest example/reboot
atest FrameworksServicesTests CtsVideoTestCases
atest FrameworksServicesTests:ScreenDecorWindowTests

Aby uzyskać więcej informacji o tym, jak odwołać się do testu, patrz Rozpoznawanie testów.

Testy identyfikujące

Można określić test-to-run argument z nazwy testowej modułu, moduł: klasa, nazwa klasy, test integracji TF, ścieżkę pliku lub nazwy pakietu.

Nazwa modułu

Aby uruchomić cały moduł testowy, użyj jego nazwy modułu. Wprowadź nazwę, gdyż pojawia się w LOCAL_MODULE lub LOCAL_PACKAGE_NAME zmiennych w tym teście jest Android.mk lub Android.bp pliku.

Przykłady:

atest FrameworksServicesTests
atest CtsVideoTestCases

Moduł:Klasa

Aby uruchomić jedną klasę w obrębie modułu, należy użyć modułu: Class. Moduł jest taka sama jak opisana w nazwę modułu . Klasa jest nazwą klasy testowej w .java pliku i może być w pełni kwalifikowana nazwa klasy lub podstawową nazwę.

Przykłady:

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

Nazwa klasy

Aby uruchomić pojedynczą klasę bez jawnego podania nazwy modułu, użyj nazwy klasy.

Przykłady:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Korzystanie z modułu: odniesienie klasa jest zalecany, gdy to możliwe, ponieważ Atest wymaga więcej czasu wyszukiwania kompletny drzewa źródłowego dla potencjalnych meczów jeśli moduł nie jest powiedziane.

Przykłady (w kolejności od najszybszego do najwolniejszego):

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

Test integracji TF

Aby uruchomić testy, które są zintegrowane bezpośrednio w TradeFed (bez modułów), wprowadź nazwę, gdyż pojawia się na wyjściu tradefed.sh list configs polecenia. Na przykład:

Aby uruchomić reboot.xml testu :

atest example/reboot

Aby uruchomić native-benchmark.xml testu :

atest native-benchmark

Ścieżka pliku

Możesz uruchamiać zarówno testy modułowe, jak i testy integracyjne, wprowadzając odpowiednią ścieżkę do ich pliku testowego lub katalogu. Możesz również uruchomić pojedynczą klasę, określając ścieżkę do pliku Java klasy. Obsługiwane są zarówno ścieżki względne, jak i bezwzględne.

Przykład: Dwie sposoby prowadzą CtsVideoTestCases moduł torem

  1. Uruchomić moduł z Androidem repo-root :

    atest cts/tests/video
    
  2. Z Android repo-root / CTS / testy / wideo:

    atest .
    

Przykład: Run klasy specyficzne w CtsVideoTestCases modułu torem. Z Android repo-root :

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

Przykład: Uruchom test integracji za pośrednictwem ścieżki. Z Android 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ślanie kroków: kompilacja, instalacja lub uruchomienie

Można określić, jakie kroki, aby uruchomić za pomocą -b , -i , a -t opcje. Jeśli nie określisz opcji, zostaną uruchomione wszystkie kroki.

  • Cele tylko budować: atest -b test-to-run
  • Badania prowadzone tylko: atest -t test-to-run
  • Zainstalować apk i przeprowadzenie testów: atest -it test-to-run
  • Zbudować i uruchomić, ale nie należy instalować: atest -bt test-to-run

Atest może wymusić, aby test pominął etap czyszczenia/usuwania. Wiele testów, takich jak CTS, czyszczenia urządzenia po test jest uruchamiany, więc próbuje ponownie uruchomić test z -t nie powiedzie się bez --disable-teardown parametru. Użyj -d przed -t pominąć czystą zintensyfikowania testów i badań iteracyjnie.

atest -d test-to-run
atest -t test-to-run

Uruchamianie określonych metod

W klasie testowej można uruchamiać określone metody. Chociaż cały moduł musi zostać zbudowany, skraca to czas potrzebny na wykonanie testów. Aby uruchomić określone metody, zidentyfikuj klasę za pomocą dowolnego z obsługiwanych sposobów identyfikacji klasy (Moduł:Klasa, ścieżka pliku itp.) i dołącz nazwę metody.

atest reference-to-class#method1

Możesz określić wiele metod, używając przecinków.

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

Przykłady:

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

Poniższe dwa przykłady pokazują korzystne możliwości uruchomienia jedną metodę testFlagChange . Te przykłady są preferowane zamiast używania tylko nazwy klasy, ponieważ określenie modułu lub lokalizacji pliku Java umożliwia Atestowi znacznie szybsze znalezienie testu:

  1. Korzystanie z modułu: klasa

    atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange
    
  2. Z Android repo-root

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

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

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors

Prowadzenie wielu zajęć

Aby uruchomić wiele klas, oddziel je spacjami w taki sam sposób, jak uruchamianie wielu testów. Atest wydajnie kompiluje i uruchamia klasy, więc określenie podzbioru klas w module poprawia wydajność w porównaniu z uruchamianiem całego modułu.

Przykłady:

  • Dwie klasy w tym samym module:

    atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests
    
  • Dwie klasy w różnych modułach:

    atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest
    

Przeprowadzanie testów natywnych

Atest może uruchamiać testy natywne. Używać -a do przeprowadzenia testów na wszystkich dostępnych architektury urządzenia, które w tym przykładzie są armeabi-v7a (ramienia 32-bitowa) oraz arm64-V8A (ARM 64-bitowa).

Przykłady:

  • Testy wejściowe:

    atest -a libinput_tests inputflinger_tests
    

Aby wybrać konkretny test natywny do uruchomienia, użyj dwukropka (:) w celu określenia nazwy testu i hashtagu (#), aby dokładniej określić indywidualną metodę. Na przykład, na poniższej definicji testu:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Można uruchomić cały test używając

atest inputflinger_tests:InputDispatcherTest

lub każdej metody testowej używając

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Uruchamianie testów w TEST_MAPPING

Atest może uruchamiać testy w plikach TEST_MAPPING.

  1. Uruchamiaj wstępne testy niejawnie w plikach TEST_MAPPING w bieżących, nadrzędnych lub określonych katalogach.

    Badania prowadzone w plikach TEST_MAPPING presubmit w obecnych i dominujących katalogów:

    atest
    

    Badania prowadzone w plikach TEST_MAPPING presubmit w /path/to/project i jego katalogów nadrzędnych:

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

  2. Uruchomić określoną grupę testową w TEST_MAPPING plików; dostępne grupy testowe: presubmit (domyślnie), postsubmit , mainline-presubmit i all .

    • Badania prowadzone w plikach TEST_MAPPING postsubmit w obecnych i dominujących katalogów:

      atest :postsubmit
      

    • Badania prowadzone ze wszystkich grup w plikach TEST_MAPPING:

      atest :all
      

    • Badania prowadzone w plikach TEST_MAPPING postsubmit w /path/to/project i jego katalogów nadrzędnych

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

    • Uruchomić testy Mainline w plikach TEST_MAPPING w /path/to/project i jego katalogów nadrzędnych

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

  3. Uruchom testy w plikach TEST_MAPPING, w tym w podkatalogach.

Domyślnie atest wyszukuje testy tylko w plikach TEST_MAPPING w górę (od bieżącego lub podanego do swoich katalogów nadrzędnych). Jeśli chcemy także przeprowadzić testy w plikach TEST_MAPPING w podkatalogów, można użyć opcji --include-subdirs zmusić atest obejmuje te badania, jak również.

Badania prowadzone w plikach TEST_MAPPING presubmit w bieżącym, rodziców i podkatalogów:

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

Uruchamianie testów w iteracji

Aby uruchomić testy w iteracji, po prostu zdać --iterations argument. Niezależnie od tego, czy zakończy się pomyślnie, czy nie, atest nie zatrzyma testowania, dopóki nie zostanie osiągnięta maksymalna liczba iteracji.

Przykłady:

Domyślnie atest iteruje 10 razy, podając liczbę całkowitą zmieniającą rundę iteracji.

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

Dwa podejścia, które pomagają użytkownikom wykrywać niestabilne testy:

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

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

Podejście 2: Uruchamiaj tylko testy zakończone niepowodzeniem do momentu zaliczenia lub osiągnięcia maksymalnej liczby iteracji.

  • Zakładamy test-to-run ma pięć przypadków testowych i jeden z testów zakończy się niepowodzeniem. Uruchom tylko test zakończony niepowodzeniem 10 razy lub do czasu, gdy test się powiedzie.
    atest test-to-run --retry-any-failure
    
  • Przestań przeprowadzać nieudany test, gdy przejdzie lub osiągnie setną rundę.
    atest test-to-run --retry-any-failure 100
    

Przeprowadzanie testów na AVD

Atest może przeprowadzać testy z nowo utworzonym AVD. Atest może zbudować artefakty wraz z systemem acloud create , a testy wykonywane po AVD został pomyślnie utworzony.

Przykłady:

  • AVD rozpocząć przed uruchomieniem testów na tej nowo utworzonej urządzenia:

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

  • Zacznij AVDs przez określania acloud create argumenty i testy prowadzone na tym nowo utworzonego urządzenia.

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

Aby dostać się szczegółów na temat użycia argumentu, uruchom acloud create --help .

Przekaż opcje do modułu

Atest jest w stanie przekazać opcje do modułów. Format krótki w wierszu poleceń Atest dodać opcję wiersza poleceń TradeFed jest

atest test-to-run -- [CUSTOM_ARGS]
W [CUSTOM_ARGS] Należy przestrzegać poleceń Tradefed formatów opcja wiersza.

Przykłady przekazywania opcji modułu testowego do docelowych przygotowujących lub uruchamiających testy 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

Przykłady opcji przekazywania 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

Aby uzyskać więcej informacji na temat testów tylko opcji, zobacz Opcje przejść do modułów