Uruchamianie testów (Atest), Uruchamianie testów (Atest)

Atest to narzędzie wiersza poleceń, które pozwala użytkownikom budować, instalować i uruchamiać testy Androida lokalnie, znacznie przyspieszając ponowne uruchamianie testów bez konieczności znajomości opcji wiersza poleceń wiązki testowej Federacji Handlowej . Ta strona wyjaśnia, jak używać Atest do uruchamiania testów Androida.

Aby uzyskać ogólne informacje na temat pisania testów dla systemu Android, zobacz Testowanie platformy Android .

Aby uzyskać informacje na temat ogólnej struktury Atest, zapoznaj się z Przewodnikiem programisty Atest .

Aby uzyskać informacje na temat uruchamiania testów w plikach TEST_MAPPING za pośrednictwem Atest, zobacz Uruchamianie testów w plikach TEST_MAPPING .

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

Konfigurowanie środowiska

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

Ustaw zmienną środowiskową

Ustaw test_suite dla Soong lub LOCAL_COMPATIBILITY_SUITE dla Make po regułach skryptu budowania pakietu .

Uruchom envsetup.sh

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

source build/envsetup.sh

Uruchom lunch

Uruchom polecenie lunch , aby wyświetlić 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

Ustawia to różne zmienne środowiskowe wymagane do uruchomienia Atest i dodaje polecenie Atest do $PATH .

Podstawowe zastosowanie

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

atest test-to-run [optional-arguments]

Argumenty opcjonalne

W poniższej tabeli wymieniono najczęściej używane argumenty. Pełna lista jest dostępna poprzez atest --help .

Opcja Długa opcja Opis
-b --build Buduje cele testowe. (domyślna)
-i --install Instaluje artefakty testowe (APK) na urządzeniu. (domyślna)
-t --test Uruchamia testy. (domyślna)
-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.
<c> --info Wyświetla odpowiednie informacje o określonych celach, a następnie kończy działanie.
<c> --dry-run Testowanie na sucho bez faktycznego budowania, instalowania lub przeprowadzania testów.
-m --rebuild-module-info Wymusza odbudowę pliku module-info.json .
-w --wait-for-debugger Czeka na zakończenie debugera przed wykonaniem.
-v --verbose Wyświetla rejestrowanie poziomu DEBUG.
<c> --iterations Testy wykonywania pętli aż do osiągnięcia maksymalnej liczby iteracji. (10 domyślnie)
<c> --rerun-until-failure [COUNT=10] Ponawia wszystkie testy do momentu wystąpienia błędu lub osiągnięcia maksymalnej liczby iteracji. (10 domyślnie)
<c> --retry-any-failure [COUNT=10] Ponawia nieudane testy, dopóki nie zostaną zaliczone lub nie zostanie osiągnięta maksymalna liczba iteracji. (10 domyślnie)
<c> --start-avd Automatycznie tworzy AVD i uruchamia testy na urządzeniu wirtualnym.
<c> --acloud-create Tworzy AVD za pomocą polecenia acloud .
<c> --[CUSTOM_ARGS] Określa niestandardowe argumenty dla programów uruchamiających test.
-a --all-abi Uruchamia testy dla wszystkich dostępnych architektur urządzeń.
<c> --host Uruchamia test całkowicie na hoście bez urządzenia.
Uwaga: uruchomienie testu hosta wymagającego urządzenia z --host zakończy się niepowodzeniem.
<c> --flakes-info Pokazuje wynik testu z informacjami o płatkach.
<c> --history Pokazuje wyniki testu w porządku chronologicznym.
<c> --latest-result Drukuje najnowszy wynik testu.

Aby uzyskać więcej informacji na temat -b , -i i -t , zobacz sekcję Określanie kroków: kompilacja, instalacja lub uruchomienie .

Określ testy

Aby uruchomić testy, określ co najmniej jeden test, używając jednego z następujących identyfikatorów:

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

Oddziel odniesienia do wielu testów spacjami, na przykład:

atest test-identifier-1 test-identifier-2

Nazwa modułu

Aby uruchomić cały moduł testowy, użyj jego nazwy. Wprowadź nazwę w takiej postaci, w jakiej pojawia się 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ł jest taki sam, jak opisano w Nazwa modułu . Klasa to nazwa klasy testowej w pliku .java i może być w pełni kwalifikowaną nazwą klasy lub nazwą podstawową.

Przykłady:

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

Nazwa klasy

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

Przykłady:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Test integracji Tradefed

Aby uruchomić testy zintegrowane bezpośrednio z TradeFed (niemoduły), wprowadź nazwę wyświetlaną w danych wyjściowych 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 obsługuje uruchamianie zarówno testów modułowych, jak i testów integracyjnych, wprowadzając odpowiednią ścieżkę do ich pliku testowego lub katalogu. Obsługuje również uruchamianie pojedynczej klasy, określając ścieżkę do pliku Java klasy. Obsługiwane są zarówno ścieżki względne, jak i bezwzględne.

Uruchom moduł

Poniższe przykłady pokazują dwa sposoby uruchamiania modułu CtsVideoTestCases przy użyciu ścieżki pliku.

Uruchom z repo-root Androida:

atest cts/tests/video

Uruchom z systemu Android repo-root/cts/tests/video :

    atest .

Uruchom klasę testową

Poniższy przykład pokazuje, jak uruchomić określoną klasę w module CtsVideoTestCases przy użyciu ścieżki pliku.

Z repo-root Androida :

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

Uruchom test integracyjny

Poniższy przykład pokazuje, jak uruchomić test integracji przy użyciu ścieżki do pliku z repo-root Android :

    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: Zbuduj, zainstaluj lub uruchom

Użyj opcji -b , -i , i -t , aby określić kroki do uruchomienia. Jeśli nie określisz opcji, zostaną uruchomione wszystkie kroki.

  • Tylko cele kompilacji: atest -b test-to-run
  • Uruchom tylko testy: atest -t test-to-run
  • Zainstaluj apk i uruchom testy: atest -it test-to-run
  • Twórz i uruchamiaj, ale nie instaluj: atest -bt test-to-run

Atest może zmusić test do pominięcia kroku czyszczenia lub rozkładania. Wiele testów, takich jak CTS, czyści urządzenie po jego uruchomieniu, więc próba ponownego uruchomienia testu z -t zakończy się niepowodzeniem bez parametru --disable-teardown . Użyj -d przed -t , aby pominąć krok czyszczenia testu 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 klasie testowej. 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

Określając wiele 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

Poniższe dwa przykłady pokazują preferowane sposoby uruchamiania pojedynczej metody testFlagChange . Te przykłady są preferowane zamiast używania tylko nazwy klasy, ponieważ określenie modułu lub lokalizacji pliku Java umożliwia Atest znacznie szybsze odnalezienie testu.

Korzystanie z modułu:Klasa:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Z repo-root Androida :

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 w przypadku uruchamiania 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.

Aby uruchomić dwie klasy w tym samym module:

atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests

Aby uruchomić dwie klasy w różnych modułach:

atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest

Uruchom pliki binarne Gtest

Atest może uruchamiać pliki binarne GTest. Użyj -a , aby uruchomić te testy dla wszystkich dostępnych architektur urządzeń, które w tym przykładzie to armeabi-v7a (ARM 32-bitowy) i arm64-v8a (ARM 64-bitowy).

Przykładowy test wejściowy:

atest -a libinput_tests inputflinger_tests

Aby wybrać konkretny plik binarny GTest do uruchomienia, użyj dwukropka (:) w celu określenia nazwy testu oraz hashtagu (#) w celu dalszego określenia indywidualnej metody.

Na przykład dla następującej definicji testu:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Uruchom następujące polecenie, aby określić cały test:

atest inputflinger_tests:InputDispatcherTest

Lub uruchom indywidualny test, używając następującego:

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Uruchom testy w TEST_MAPPING

Atest może uruchamiać testy w plikach TEST_MAPPING .

Niejawne uruchamianie testów przed przesłaniem

Uruchom wstępne testy w plikach TEST_MAPPING w bieżącym i nadrzędnym katalogu:

atest

Uruchom testy TEST_MAPPING w /path/to/project i jego katalogach nadrzędnych:

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

Uruchom określoną grupę testową

Dostępne grupy testowe to: presubmit (domyślnie), postsubmit , mainline-presubmit i all .

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

<pre>
<code class="devsite-terminal">atest :postsubmit</code>
</pre>

Uruchom testy ze wszystkich grup w plikach TEST_MAPPING:

<pre>
<code class="devsite-terminal">atest :all</code>
</pre>

Uruchom testy postsubmit w plikach TEST_MAPPING w /path/to/project i jego katalogach nadrzędnych:

<pre>
<code class="devsite-terminal">atest --test-mapping <var>/path/to/project</var>:postsubmit</code>
</pre>

Uruchom testy mainline w plikach TEST_MAPPING w /path/to/project i jego katalogach nadrzędnych:

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

Uruchom testy 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 również uruchomić testy w plikach TEST_MAPPING w podkatalogach, użyj --include-subdirs , aby wymusić uwzględnienie przez Atest również tych testów:

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

Uruchom testy w iteracji

Uruchom testy w iteracji, przekazując argument --iterations . Niezależnie od tego, czy zakończy się pomyślnie, czy nie, Atest będzie powtarzał test aż do osiągnięcia maksymalnej liczby iteracji.

Przykłady:

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

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

Następujące podejścia ułatwiają wykrywanie niestabilnych testów:

Podejście 1: Uruchom wszystkie testy do wystąpienia awarii lub osiągnięcia maksymalnej liczby 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.

  • Załóżmy, że test-to-run ma wiele przypadków testowych i jeden z testów kończy się niepowodzeniem. Uruchom tylko test zakończony niepowodzeniem 10 razy (domyślnie) lub do momentu pomyślnego zakończenia testu.
    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
    

Uruchom testy na AVD

Atest może przeprowadzać testy na nowo utworzonym AVD. Uruchom acloud create , aby utworzyć AVD i skompilować artefakty, a następnie użyj poniższych przykładów, aby uruchomić testy.

Uruchom AVD i uruchom na nim testy:

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

Uruchom AVD w ramach uruchomienia testowego:

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

Aby uzyskać więcej informacji, uruchom acloud create --help .

Przekaż opcje do modułu

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

atest test-to-run -- [CUSTOM_ARGS]

Przekaż opcje modułu testowego do docelowych przygotowujących lub prowadzą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

Opcje przekazywania do typu biegacza lub klasy:

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 opcji tylko testowych, zobacz Przekazywanie opcji do modułów .

,

Atest to narzędzie wiersza poleceń, które pozwala użytkownikom budować, instalować i uruchamiać testy Androida lokalnie, znacznie przyspieszając ponowne uruchamianie testów bez konieczności znajomości opcji wiersza poleceń wiązki testowej Federacji Handlowej . Ta strona wyjaśnia, jak używać Atest do uruchamiania testów Androida.

Aby uzyskać ogólne informacje na temat pisania testów dla systemu Android, zobacz Testowanie platformy Android .

Aby uzyskać informacje na temat ogólnej struktury Atest, zapoznaj się z Przewodnikiem programisty Atest .

Aby uzyskać informacje na temat uruchamiania testów w plikach TEST_MAPPING za pośrednictwem Atest, zobacz Uruchamianie testów w plikach TEST_MAPPING .

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

Konfigurowanie środowiska

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

Ustaw zmienną środowiskową

Ustaw test_suite dla Soong lub LOCAL_COMPATIBILITY_SUITE dla Make po regułach skryptu budowania pakietu .

Uruchom envsetup.sh

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

source build/envsetup.sh

Uruchom lunch

Uruchom polecenie lunch , aby wyświetlić 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

Ustawia to różne zmienne środowiskowe wymagane do uruchomienia Atest i dodaje polecenie Atest do $PATH .

Podstawowe zastosowanie

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

atest test-to-run [optional-arguments]

Argumenty opcjonalne

W poniższej tabeli wymieniono najczęściej używane argumenty. Pełna lista jest dostępna poprzez atest --help .

Opcja Długa opcja Opis
-b --build Buduje cele testowe. (domyślna)
-i --install Instaluje artefakty testowe (APK) na urządzeniu. (domyślna)
-t --test Uruchamia testy. (domyślna)
-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.
<c> --info Wyświetla odpowiednie informacje o określonych celach, a następnie kończy działanie.
<c> --dry-run Testowanie na sucho bez faktycznego budowania, instalowania lub przeprowadzania testów.
-m --rebuild-module-info Wymusza odbudowę pliku module-info.json .
-w --wait-for-debugger Czeka na zakończenie debugera przed wykonaniem.
-v --verbose Wyświetla rejestrowanie poziomu DEBUG.
<c> --iterations Testy wykonywania pętli aż do osiągnięcia maksymalnej liczby iteracji. (10 domyślnie)
<c> --rerun-until-failure [COUNT=10] Ponawia wszystkie testy do momentu wystąpienia błędu lub osiągnięcia maksymalnej liczby iteracji. (10 domyślnie)
<c> --retry-any-failure [COUNT=10] Ponawia nieudane testy, dopóki nie zostaną zaliczone lub nie zostanie osiągnięta maksymalna liczba iteracji. (10 domyślnie)
<c> --start-avd Automatycznie tworzy AVD i uruchamia testy na urządzeniu wirtualnym.
<c> --acloud-create Tworzy AVD za pomocą polecenia acloud .
<c> --[CUSTOM_ARGS] Określa niestandardowe argumenty dla programów uruchamiających test.
-a --all-abi Uruchamia testy dla wszystkich dostępnych architektur urządzeń.
<c> --host Uruchamia test całkowicie na hoście bez urządzenia.
Uwaga: uruchomienie testu hosta wymagającego urządzenia z --host zakończy się niepowodzeniem.
<c> --flakes-info Pokazuje wynik testu z informacjami o płatkach.
<c> --history Pokazuje wyniki testu w porządku chronologicznym.
<c> --latest-result Drukuje najnowszy wynik testu.

Aby uzyskać więcej informacji na temat -b , -i i -t , zobacz sekcję Określanie kroków: kompilacja, instalacja lub uruchomienie .

Określ testy

Aby uruchomić testy, określ co najmniej jeden test, używając jednego z następujących identyfikatorów:

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

Oddziel odniesienia do wielu testów spacjami, na przykład:

atest test-identifier-1 test-identifier-2

Nazwa modułu

Aby uruchomić cały moduł testowy, użyj jego nazwy. Wprowadź nazwę w takiej postaci, w jakiej pojawia się 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ł jest taki sam, jak opisano w Nazwa modułu . Klasa to nazwa klasy testowej w pliku .java i może być w pełni kwalifikowaną nazwą klasy lub nazwą podstawową.

Przykłady:

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

Nazwa klasy

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

Przykłady:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Test integracji Tradefed

Aby uruchomić testy zintegrowane bezpośrednio z TradeFed (niemoduły), wprowadź nazwę wyświetlaną w danych wyjściowych 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 obsługuje uruchamianie zarówno testów modułowych, jak i testów integracyjnych, wprowadzając odpowiednią ścieżkę do ich pliku testowego lub katalogu. Obsługuje również uruchamianie pojedynczej klasy, określając ścieżkę do pliku Java klasy. Obsługiwane są zarówno ścieżki względne, jak i bezwzględne.

Uruchom moduł

Poniższe przykłady pokazują dwa sposoby uruchamiania modułu CtsVideoTestCases przy użyciu ścieżki pliku.

Uruchom z repo-root Androida:

atest cts/tests/video

Uruchom z systemu Android repo-root/cts/tests/video :

    atest .

Uruchom klasę testową

Poniższy przykład pokazuje, jak uruchomić określoną klasę w module CtsVideoTestCases przy użyciu ścieżki pliku.

Z repo-root Androida :

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

Uruchom test integracyjny

Poniższy przykład pokazuje, jak uruchomić test integracji przy użyciu ścieżki do pliku z repo-root Android :

    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: Zbuduj, zainstaluj lub uruchom

Użyj opcji -b , -i , i -t , aby określić kroki do uruchomienia. Jeśli nie określisz opcji, zostaną uruchomione wszystkie kroki.

  • Tylko cele kompilacji: atest -b test-to-run
  • Uruchom tylko testy: atest -t test-to-run
  • Zainstaluj apk i uruchom testy: atest -it test-to-run
  • Twórz i uruchamiaj, ale nie instaluj: atest -bt test-to-run

Atest może zmusić test do pominięcia kroku czyszczenia lub rozkładania. Wiele testów, takich jak CTS, czyści urządzenie po jego uruchomieniu, więc próba ponownego uruchomienia testu z -t zakończy się niepowodzeniem bez parametru --disable-teardown . Użyj -d przed -t , aby pominąć krok czyszczenia testu 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 klasie testowej. 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

Określając wiele 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

Poniższe dwa przykłady pokazują preferowane sposoby uruchamiania pojedynczej metody testFlagChange . Te przykłady są preferowane zamiast używania tylko nazwy klasy, ponieważ określenie modułu lub lokalizacji pliku Java umożliwia Atest znacznie szybsze odnalezienie testu.

Korzystanie z modułu:Klasa:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Z repo-root Androida :

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 w przypadku uruchamiania 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.

Aby uruchomić dwie klasy w tym samym module:

atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests

Aby uruchomić dwie klasy w różnych modułach:

atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest

Uruchom pliki binarne Gtest

Atest może uruchamiać pliki binarne GTest. Użyj -a , aby uruchomić te testy dla wszystkich dostępnych architektur urządzeń, które w tym przykładzie to armeabi-v7a (ARM 32-bitowy) i arm64-v8a (ARM 64-bitowy).

Przykładowy test wejściowy:

atest -a libinput_tests inputflinger_tests

Aby wybrać konkretny plik binarny GTest do uruchomienia, użyj dwukropka (:) w celu określenia nazwy testu oraz hashtagu (#) w celu dalszego określenia indywidualnej metody.

Na przykład dla następującej definicji testu:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Uruchom następujące polecenie, aby określić cały test:

atest inputflinger_tests:InputDispatcherTest

Lub uruchom indywidualny test, używając następującego:

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Uruchom testy w TEST_MAPPING

Atest może uruchamiać testy w plikach TEST_MAPPING .

Niejawne uruchamianie testów przed przesłaniem

Uruchom wstępne testy w plikach TEST_MAPPING w bieżącym i nadrzędnym katalogu:

atest

Uruchom testy TEST_MAPPING w /path/to/project i jego katalogach nadrzędnych:

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

Uruchom określoną grupę testową

Dostępne grupy testowe to: presubmit (domyślnie), postsubmit , mainline-presubmit i all .

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

<pre>
<code class="devsite-terminal">atest :postsubmit</code>
</pre>

Uruchom testy ze wszystkich grup w plikach TEST_MAPPING:

<pre>
<code class="devsite-terminal">atest :all</code>
</pre>

Uruchom testy postsubmit w plikach TEST_MAPPING w /path/to/project i jego katalogach nadrzędnych:

<pre>
<code class="devsite-terminal">atest --test-mapping <var>/path/to/project</var>:postsubmit</code>
</pre>

Uruchom testy mainline w plikach TEST_MAPPING w /path/to/project i jego katalogach nadrzędnych:

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

Uruchom testy 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 również uruchomić testy w plikach TEST_MAPPING w podkatalogach, użyj --include-subdirs , aby wymusić uwzględnienie przez Atest również tych testów:

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

Uruchom testy w iteracji

Uruchom testy w iteracji, przekazując argument --iterations . Niezależnie od tego, czy zakończy się pomyślnie, czy nie, Atest będzie powtarzał test aż do osiągnięcia maksymalnej liczby iteracji.

Przykłady:

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

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

Następujące podejścia ułatwiają wykrywanie niestabilnych testów:

Podejście 1: Uruchom wszystkie testy do wystąpienia awarii lub osiągnięcia maksymalnej liczby 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.

  • Załóżmy, że test-to-run ma wiele przypadków testowych i jeden z testów kończy się niepowodzeniem. Uruchom tylko test zakończony niepowodzeniem 10 razy (domyślnie) lub do momentu pomyślnego zakończenia testu.
    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
    

Uruchom testy na AVD

Atest może przeprowadzać testy na nowo utworzonym AVD. Uruchom acloud create , aby utworzyć AVD i skompilować artefakty, a następnie użyj poniższych przykładów, aby uruchomić testy.

Uruchom AVD i uruchom na nim testy:

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

Uruchom AVD w ramach uruchomienia testowego:

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

Aby uzyskać więcej informacji, uruchom acloud create --help .

Przekaż opcje do modułu

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

atest test-to-run -- [CUSTOM_ARGS]

Przekaż opcje modułu testowego do docelowych przygotowujących lub prowadzą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

Opcje przekazywania do typu biegacza lub klasy:

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 opcji tylko testowych, zobacz Przekazywanie opcji do modułów .