Szablony testowe

AOSP zawiera szablony testowe dla modułów testowych, które nie są Pythonem po stronie hosta podklasa testu BaseTest biegacza VTS.

Rysunek 1. Przetestuj architekturę szablonu.

Deweloperzy mogą używać tych szablonów, aby zminimalizować nakład pracy integrowanie takich testów. Z tej sekcji dowiesz się, jak skonfigurować test i jak z niego korzystać szablonów (znajdujących się w narzędziu VTS, przypadki testowe/szablon ) z przykładami często używanych szablonów.

Szablon BinaryTest

Użyj Test binarny , aby zintegrować w VTS testy, które są przeprowadzane na urządzeniu docelowym. Testy po stronie docelowej obejmują:

  • Testy oparte na C++ kompilowane i przekazywane na urządzenie
  • Testy Pythona po stronie docelowej skompilowane jako pliki binarne
  • Skrypty powłoki wykonywalne na urządzeniach

Testy te można zintegrować z VTS za pomocą narzędzia BinaryTest lub bez niego szablon.

Zintegruj testy po stronie docelowej za pomocą usługi Szablon BinaryTest

Szablon BinaryTest został zaprojektowany tak, aby ułatwić programistom integrację do testów po stronie docelowej. W większości przypadków wystarczy dodać kilka prostych wierszy konfigurację w AndroidTest.xml. Przykładowa konfiguracja z: Test VtsDeviceTreeEarlyMount: 

<configuration description="Config for VTS VtsDeviceTreeEarlyMountTest.">
  ...
<test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
<option name="test-module-name" value="VtsDeviceTreeEarlyMountTest"/>
<option name="binary-test-source" value="_32bit::DATA/nativetest/dt_early_mount_test/dt_early_mount_test" />
<option name="binary-test-source" value="_64bit::DATA/nativetest64/dt_early_mount_test/dt_early_mount_test" />
<option name="test-timeout" value="5m"/>
</test>
</configuration>

W tej konfiguracji:

  • binary-test-source i binary-test-type są na podstawie szablonu.
  • Określenie względnej ścieżki hosta testowego pliku binarnego powoduje włączenie szablonu do przygotowywania, przekazywania plików, wykonywania testów, analizowania wyników czyszczenie danych.
  • Szablon zawiera metody związane z tworzeniem przypadków testowych dla podklas, aby nadpisać.
  • Szablon zakłada, że na każdym testowym module binarnym jest jeden przypadek testowy, a moduł binarny nazwa pliku źródłowego jest domyślnie używana jako nazwa przypadku testowego.

Opcje konfiguracji

Szablon BinaryTest obsługuje te opcje konfiguracji:

Nazwa opcji Typ wartości Opis
źródło-testu-binarnego struny Ścieżki źródeł testów binarnych względem katalogu przypadku testowego vts w hosta.
Przykład: DATA/nativetest/test
katalog-roboczy-testu binarnego struny Katalogi robocze (ścieżka po stronie urządzenia).
Przykład: /data/local/tmp/testing/
Środowisko-test-binarny struny Zmienne środowiskowe dla plików binarnych.
Przykład: PATH=/new:$PATH
argumenty testu binarnego struny Argumenty lub flagi testowe.
Przykład: --gtest_filter=test1
ścieżka-binarnego-testu-ld-library-path struny Zmienna środowiskowa LD_LIBRARY_PATH.
Przykład: /data/local/tmp/lib
plik-test-disable-framework, Wartość logiczna Przed rozpoczęciem testów uruchom aplikację adb stop, aby wyłączyć Android Framework. Przykład: true
serwer-natywny-test-stopień-binarny Wartość logiczna Podczas testowania zatrzymaj wszystkie prawidłowo skonfigurowane serwery natywne. Przykład: true
typ testu binarnego tekst Typ szablonu. Inne typy szablonów wykraczają poza ten szablon, ale nie trzeba określać tej opcji dla tego szablonu, ponieważ określono binary-test-source.

W przypadku opcji o typie wartości strings możesz dodać wiele wartości Powtórz opcje konfiguracji. Na przykład ustaw binary-test-source dwukrotnie (jak widać w polu VtsDeviceTreeEarlyMountTest).

Tagi testowe

Tagi testowe możesz dodać, poprzedzając je prefiksami opcji „strings” z wartościami :: jako separatora. Tagi testowe są szczególnie przydatne przydatne, gdy uwzględniasz źródła binarne o tej samej nazwie, ale o innych czy katalogi nadrzędne. Na przykład, aby uniknąć przekazywania plików lub nazw wyników konflikt źródeł o tej samej nazwie, ale z różnych katalogów źródłowych, możesz określić różne tagi dla tych źródeł.

Jak widać w przykładzie VtsDeviceTreeEarlyMountTest z parametrem dwóch źródeł dt_early_mount_test, tagi testowe to tagi Prefiksy _32bit:: i _64bit:: włączone binary-test-source. Tagi kończące się na 32bit lub 64bit automatycznie oznacza testy jako dostępne dla 1 bitu ABI; tj. testy z tagiem _32bit nie są wykonywane w 64-bitowym interfejsie ABI. Nie określenie tagu jest równoznaczne z używaniem tagu z pustym ciągiem znaków.

Opcje z tymi samymi tagami są grupowane i oddzielone od innych tagów. Dla: Przykład: binary-test-args z tagiem _32bit to zastosowano tylko do binary-test-source z tym samym tagiem i wykonano w: binary-test-working-directory z tym samym tagiem. Opcja binary-test-working-directory jest opcjonalna w przypadku testów binarnych. co pozwala określić pojedynczy katalog roboczy dla tagu. Gdy Opcja binary-test-working-directory pozostaje nieokreślona, domyślna dla każdego tagu.

Nazwa tagu jest bezpośrednio dołączana do nazwy przypadku testowego w raporcie o wynikach. Na przykład: przypadek testowy testcase1 z tagiem _32bit w raporcie wyników ma wartość testcase1_32bit.

Zintegruj testy po stronie docelowej bez Szablon BinaryTest

W systemie VTS domyślnym formatem testów są testy Pythona po stronie hosta rozszerzone z Test BaseTest w narzędziu VTS. Aby zintegrować testy po stronie docelowej, musisz najpierw przekazać testować pliki na urządzeniu, uruchamiać testy za pomocą poleceń powłoki, a następnie analizować za pomocą skryptów Python po stronie hosta.

Przekazywanie plików binarnych testów w trybie push

Zalecamy przekazywanie plików za pomocą narzędzia do przygotowywania środowiska docelowego VtsFilePusher. Przykład:

<target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher">
        <option name="push" value="DATA/test->/data/local/tmp/test"/>
    </target_preparer>

VtsFilePusher wykonuje te działania:

  1. Sprawdza połączenia z urządzeniem.
  2. Określa bezwzględną ścieżkę pliku źródłowego.
  3. Przekazuje pliki przy użyciu polecenia adb push.
  4. Po zakończeniu testów usuwa pliki.

Możesz też ręcznie przekazać pliki za pomocą testu Pythona po stronie hosta skrypt o podobnej procedurze.

Przeprowadzanie testów

Po przekazaniu plików na urządzenie uruchom test, używając poleceń powłoki w skrypt testowy Pythona po stronie hosta. Przykład:

device = self.android_devices[0]
res = device.shell.Execute(["chmod a+x /data/local/tmp/test", "/data/local/tmp/test"])
asserts.AssertFalse(any(res[return_codes]))

Szablon GtestBinaryTest

TestBinary Test hostuje pliki binarne testowe GTest, z których każdy zawiera zwykle dla wielu przypadków testowych. Ten szablon rozszerza szablon BinaryTest przez zastąpienie konfiguracji, tworzenia przypadków testowych i metod analizy wyników, więc wszystkie a konfiguracje są dziedziczone.

GtestBinaryTest dodaje opcję gtest-batch-mode:

Nazwa opcji Typ wartości Opis
typ testu binarnego tekst Typ szablonu. Używa wartości gtest.
tryb-grupowy gtest Wartość logiczna Uruchamiaj pliki binarne Gtest w trybie wsadowym. Przykład: true

Ogólnie ustawienie gtest-batch-mode na true poprawia wydajność, nieznacznie zmniejszając niezawodność. Zgodność z VTS testów, wiele modułów korzysta z trybu wsadowego, aby zwiększyć wydajność. Niezawodność Jeśli jednak ten tryb nie zostanie określony, domyślnie zostanie ustawiony tryb niewsadowy.

Tryb inny niż wsadowy

W trybie innym niż wsadowy wysyła osobne wywołania pliku binarnego GTest dla każdego przypadku testowego. Dla: na przykład: plik binarny GTest zawiera 10 przypadków testowych (po przefiltrowaniu według hosta) konfiguracji bocznej), plik binarny jest za każdym razem wywoływany 10 razy w powłoce urządzenia za pomocą innego filtra testowego. Dla każdego przypadku testowego unikalny wynik GTest Kod XML jest generowany i analizowany przez szablon.

Rysunek 2. W trybie innym niż wsadowy.

Zalety korzystania z trybu innego niż wsadowy:

  • Izolacja przypadku testowego. Awaria lub zawieszenie w jednym przypadku testowego nie wpływa na inne przypadki testowe.
  • Szczegółowość. Łatwiejsze profilowanie/pokrycie dla poszczególnych testów pomiar, systrace, raport o błędach, logcat itd. Wyniki i dzienniki testów pobierane natychmiast po zakończeniu każdego przypadku testowego.

Oto zalety korzystania z trybu innego niż wsadowy:

  • Nadmiarowe wczytywanie. Przy każdym wywołaniu pliku binarnego GTest wczytuje powiązane biblioteki i przeprowadza wstępne konfiguracje klas.
  • Nakład komunikacji. Po zakończeniu testu host i urządzenia docelowego komunikują się na potrzeby analizy wyników i kolejnych poleceń (przyszłe polecenia możliwe optymalizacje).

Tryb wsadowy

W trybie wsadowym GTest testowy plik binarny jest wywoływany tylko raz podczas długiego testu. filtra zawierającego wszystkie przypadki testowe odfiltrowane według konfiguracji po stronie hosta (ta pozwala uniknąć problemu z nadmiarowym wczytywaniem w trybie innym niż wsadowy). Test możesz analizować w przypadku GTest za pomocą plikuoutput.xml lub danych wyjściowych terminala.

Jeśli używasz plikuoutput.xml (domyślnie):

Rysunek 3. w trybie wsadowym (output.xml).

Tak jak w trybie innym niż zbiorcze, wynik testu jest analizowany za pomocą danych wyjściowych GTest w formacie XML. . Ponieważ jednak wynikowy plik XML jest generowany po wykonaniu wszystkich testów zakończono, jeśli przypadek testowy uległ awarii, plik binarny lub na urządzeniu, nie ma wyniku .

Podczas korzystania z danych wyjściowych terminala:

Rysunek 4. Tryb wsadowy, dane wyjściowe w terminalu.

Podczas działania GTest drukuje dziennik testu i przekazuje informacje o postępie do terminala. w formacie, który można analizować w ramach platformy pod kątem stanu testu, wyników dzienników.

Zalety korzystania z trybu wsadowego:

  • Izolacja przypadku testowego. Zapewnia ten sam poziom testu izolacja przypadku jako tryb inny niż wsadowy, jeśli platforma uruchomi ponownie plik binarny/urządzenie po awarii przy zastosowaniu ograniczonego filtra testowego (z wyłączeniem testu zakończonego i zakończonego awarii) przypadków).
  • Szczegółowość. Zapewnia taki sam poziom szczegółowości przypadku testowego jak w trybie innym niż wsadowy.

Oto zalety korzystania z trybu wsadowego:

  • Koszt konserwacji. Jeśli format logowania GTest ulegnie zmianie, wszystkie testy przestaną się wyświetlać.
  • Zdezorientowanie. Element testowy może wyświetlić tekst podobny do GTest. i postępu, co może dezorientować.

Ze względu na te wady tymczasowo usunęliśmy opcję stosowania w wierszu poleceń. W przyszłości wrócimy do tej opcji, aby poprawić niezawodność tej funkcji.

Szablon HostBinaryTest

Szablon HostBinaryTest zawiera nieistniejące pliki wykonywalne po stronie hosta w innych katalogach lub skryptach Pythona. Te testy to między innymi:

  • Skompilowano testowe pliki binarne wykonywalne na hoście
  • skrypty wykonywalne w powłoce, w Pythonie lub w innych językach;

Jednym z przykładów jest VTS Test zasad zabezpieczeń SELinux po stronie hosta:

<configuration description="Config for VTS  Security SELinux policy host-side test cases">
    ...
    <test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
        <option name="test-module-name" value="VtsSecuritySelinuxPolicyHost"/>
        <option name="binary-test-source" value="out/host/linux-x86/bin/VtsSecuritySelinuxPolicyHostTest" />
        <option name="binary-test-type" value="host_binary_test"/>
    </test>
</configuration>

HostBinaryTest nie rozszerza szablonu BinaryTest, ale korzysta z podobnego i testowania konfiguracji. W tym przykładzie binary-test-source określa ścieżkę względną po stronie hosta do testowego pliku wykonywalnego oraz binary-test-type – host_binary_test. Podobne do BinaryTest, nazwa pliku binarnego jest używana jako nazwa przypadku testowego wartość domyślną.

Rozszerzanie istniejących szablonów

Możesz użyć szablonów bezpośrednio w konfiguracji testowej, aby uwzględnić testy inne niż Python lub rozszerzać je do podklasy, aby spełnić określone wymagania testowe. Szablony w repozytorium VTS mają te rozszerzenia:

Rysunek 5. Rozszerzanie istniejących szablonów w VTS z repozytorium.

Zachęcamy programistów do rozszerzania istniejącego szablonu pod kątem wymagania testów. Typowe przyczyny rozszerzenia szablonów:

  • specjalne procedury konfiguracji testów, takie jak przygotowanie urządzenia do stosowania poleceń.
  • Generuję różne przypadki testowe i nazwy testów.
  • Analiza wyników przez odczytanie danych wyjściowych polecenia lub użycie innych warunków.

Aby ułatwić rozszerzanie istniejących szablonów, zawierają metody do każdej funkcji. Jeśli poprawisz wygląd aplikacji szablonów, zachęcamy do wzięcia udziału w bazie kodu VTS.