Szablony testowe

AOSP zawiera szablony testów dla modułów testowych, które nie są podklasą języka Python po stronie hosta testu BaseTest modułu uruchamiającego VTS.

Programiści mogą używać tych szablonów, aby zminimalizować wysiłek związany z integracją takich testów. W tej sekcji opisano konfigurowanie i używanie szablonów testów (znajdujących się w katalogu przypadków testowych/template VTS) oraz podano przykłady często używanych szablonów.

Szablon testu binarnego

Użyj szablonu BinaryTest , aby zintegrować testy wykonywane na urządzeniu docelowym w VTS. Testy po stronie docelowej obejmują:

• Testy oparte na języku C++ skompilowane i przesłane do urządzenia
• Testy języka Python po stronie docelowej skompilowane jako pliki binarne
• Skrypty powłoki wykonywalne na urządzeniach

Testy te można zintegrować z VTS z szablonem BinaryTest lub bez niego.

Zintegruj testy po stronie docelowej z szablonem BinaryTest

Szablon BinaryTest został zaprojektowany, aby pomóc programistom w łatwej integracji testów po stronie docelowej. W większości przypadków możesz dodać kilka prostych linii konfiguracyjnych w AndroidTest.xml . Przykładowa konfiguracja z VtsDeviceTreeEarlyMountTest :

<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ą specyficzne dla szablonu.
• Określenie względnej ścieżki hosta testowego źródła binarnego umożliwia szablonowi obsługę przygotowania, wypychania plików, wykonywania testów, analizowania wyników i czyszczenia.
• Szablon zawiera metody związane z tworzeniem przypadków testowych, które można zastąpić podklasami.
• W szablonie przyjęto jeden przypadek testowy na każdy testowy moduł binarny, a jako nazwę przypadku testowego domyślnie używana jest binarna nazwa pliku źródłowego.

Opcje konfiguracji

Szablon BinaryTest obsługuje następujące opcje konfiguracji:

W przypadku opcji z strings wartościowymi można dodać wiele wartości, powtarzając opcje w konfiguracji. Na przykład dwukrotnie ustaw binary-test-source (jak pokazano w przykładzie VtsDeviceTreeEarlyMountTest ).

Testuj tagi

Możesz dodać znaczniki testowe, poprzedzając je opcjami z wartościami strings i używając :: jako ogranicznika. Tagi testowe są szczególnie przydatne, gdy dołączane są źródła binarne o tej samej nazwie, ale z inną bitowością lub katalogami nadrzędnymi. Na przykład, aby uniknąć kolizji nazw plików lub wyników w przypadku źródeł o tej samej nazwie, ale z różnych katalogów źródłowych, możesz określić różne znaczniki dla tych źródeł.

Jak pokazano w przykładzie VtsDeviceTreeEarlyMountTest z dwoma źródłami dt_early_mount_test , znaczniki testowe to przedrostki _32bit:: i _64bit:: w binary-test-source . Tagi kończące się na 32bit lub 64bit automatycznie oznaczają testy jako dostępne dla jednego bitu ABI; tzn. testy ze znacznikiem _32bit nie są wykonywane w 64-bitowym ABI. Nieokreślenie znacznika jest równoznaczne z użyciem znacznika z pustym ciągiem znaków.

Opcje z tymi samymi tagami są pogrupowane i izolowane od innych tagów. Na przykład argumenty binary-test-args ze znacznikiem _32bit są stosowane tylko do binary-test-source z tym samym znacznikiem i wykonywane w binary-test-working-directory z tym samym znacznikiem. Opcja binary-test-working-directory jest opcjonalna w przypadku testów binarnych i umożliwia określenie jednego katalogu roboczego dla znacznika. Jeśli opcja binary-test-working-directory pozostanie nieokreślona, ​​dla każdego znacznika używane będą katalogi domyślne.

Nazwa tagu jest dodawana bezpośrednio do nazwy przypadku testowego w raporcie wyników. Na przykład przypadek testowy testcase1 ze znacznikiem _32bit pojawia się w raporcie wyników jako testcase1_32bit .

Zintegruj testy po stronie docelowej bez szablonu BinaryTest

W VTS domyślnym formatem testu są testy Pythona po stronie hosta rozszerzone z BaseTest w module uruchamiającym VTS. Aby zintegrować testy po stronie docelowej, należy najpierw wypchnąć pliki testowe na urządzenie, wykonać testy za pomocą poleceń powłoki, a następnie przeanalizować wyniki za pomocą skryptów Pythona po stronie hosta.

Pliki binarne testu push

Zalecamy wypychanie plików przy użyciu narzędzia przygotowującego cele 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 następujące czynności:

1. Sprawdza łączność urządzenia.
2. Określa bezwzględną ścieżkę pliku źródłowego.
3. Wypycha pliki za pomocą polecenia adb push .
4. Usuwa pliki po zakończeniu testów.

Alternatywnie możesz przesyłać pliki ręcznie, korzystając ze skryptu testowego Pythona po stronie hosta, który działa zgodnie z podobną procedurą.

Uruchom testy

Po wypchnięciu plików na urządzenie uruchom test, używając poleceń powłoki w skrypcie testowym 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

Szablon GtestBinaryTest zawiera pliki binarne testów GTest, z których każdy zwykle zawiera wiele przypadków testowych. Ten szablon rozszerza szablon BinaryTest, zastępując metody konfiguracji, tworzenia przypadków testowych i analizowania wyników, dzięki czemu wszystkie konfiguracje BinaryTest są dziedziczone.

GtestBinaryTest dodaje opcję gtest-batch-mode :

Ogólnie rzecz biorąc, ustawienie trybu gtest-batch-mode na true zwiększa wydajność, jednocześnie nieznacznie zmniejszając niezawodność. W testach zgodności VTS wiele modułów korzysta z trybu wsadowego w celu poprawy wydajności. Jednak ze względu na niezawodność, jeśli tryb nie jest określony, domyślnie jest to tryb niewsadowy.

Tryb nie wsadowy

Tryb inny niż wsadowy powoduje indywidualne wywołania pliku binarnego GTest dla każdego przypadku testowego. Na przykład, jeśli plik binarny GTest zawiera 10 przypadków testowych (po przefiltrowaniu według konfiguracji po stronie hosta), plik binarny jest wywoływany 10 razy w powłoce urządzenia za każdym razem z innym filtrem testowym. Dla każdego przypadku testowego generowany jest unikalny wynik XML wyniku GTest, który jest analizowany przez szablon.

Zalety korzystania z trybu niewsadowego obejmują:

• Izolacja przypadku testowego . Awaria lub zawieszenie w jednym przypadku testowym nie ma wpływu na inne przypadki testowe.
• Ziarnistość . Łatwiejsze uzyskanie profilowania/pomiaru zasięgu dla każdego przypadku testowego, systrace, raportu o błędach, logcat itp. Wyniki testów i dzienniki są pobierane natychmiast po zakończeniu każdego przypadku testowego.

Wady korzystania z trybu innego niż wsadowy obejmują:

• Nadmiarowe ładowanie . Za każdym razem, gdy wywoływany jest plik binarny GTest, ładuje powiązane biblioteki i wykonuje początkowe konfiguracje klas.
• Narzut komunikacyjny . Po zakończeniu testu host i urządzenie docelowe komunikują się w celu analizy wyników i wydania kolejnych poleceń (możliwe przyszłe optymalizacje).

Tryb wsadowy

W trybie wsadowym GTest plik binarny testowy jest wywoływany tylko raz z długą wartością filtra testowego zawierającą wszystkie przypadki testowe filtrowane według konfiguracji po stronie hosta (pozwala to uniknąć problemu z redundantnym ładowaniem w trybie niewsadowym). Wyniki testów dla narzędzia GTest można analizować przy użyciu pliku Output.xml lub danych wyjściowych terminala.

Podczas korzystania z pliku wyjściowego.xml (domyślnie):

Podobnie jak w trybie innym niż wsadowy, wynik testu jest analizowany za pomocą wyjściowego pliku xml narzędzia GTest. Ponieważ jednak wyjściowy plik XML jest generowany po zakończeniu wszystkich testów, w przypadku awarii przypadku testowego pliku binarnego lub urządzenia nie jest generowany żaden wynikowy plik XML.

W przypadku korzystania z wyjścia terminalowego:

Gdy GTest jest uruchomiony, drukuje dziennik testów i postęp na terminalu w formacie, który może zostać przeanalizowany przez platformę pod kątem statusu testu, wyników i dzienników.

Zalety korzystania z trybu wsadowego obejmują:

• Izolacja przypadku testowego . Zapewnia ten sam poziom izolacji przypadków testowych, co tryb inny niż wsadowy, jeśli platforma ponownie uruchamia plik binarny/urządzenie po awarii ze zredukowanym filtrem testowym (z wyłączeniem zakończonych i uszkodzonych przypadków testowych).
• Ziarnistość . Zapewnia taką samą szczegółowość przypadków testowych jak tryb inny niż wsadowy.

Wady korzystania z trybu wsadowego obejmują:

• Koszty utrzymania . Jeśli zmieni się format rejestrowania GTest, wszystkie testy zostaną przerwane.
• Dezorientacja . Przypadek testowy może wydrukować coś podobnego do formatu postępu GTest, co może zmylić format.

Ze względu na te wady tymczasowo usunęliśmy opcję korzystania z danych wyjściowych wiersza poleceń. W przyszłości ponownie rozważymy tę opcję, aby poprawić niezawodność tej funkcji.

Szablon HostBinaryTest

Szablon HostBinaryTest zawiera pliki wykonywalne po stronie hosta, które nie istnieją w innych katalogach ani w skryptach Pythona. Testy te obejmują:

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

Jednym z przykładów jest test po stronie hosta polityki VTS Security SELinux :

<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 używa podobnych konfiguracji testowych. W powyższym przykładzie opcja binary-test-source określa względną ścieżkę po stronie hosta do pliku wykonywalnego testu, a binary-test-type to host_binary_test . Podobnie jak w przypadku szablonu BinaryTest, jako nazwa przypadku testowego domyślnie używana jest nazwa pliku binarnego.

Rozszerz istniejące szablony

Możesz użyć szablonów bezpośrednio w konfiguracji testu, aby uwzględnić testy inne niż Python lub rozszerzyć je w podklasie, aby obsłużyć określone wymagania testowe. Szablony w repozytorium VTS mają następujące rozszerzenia:

Zachęcamy programistów do rozszerzenia dowolnego istniejącego szablonu o dowolne specyficzne wymagania testowe. Typowe powody rozszerzania szablonów to:

• Specjalne procedury konfiguracji testu, takie jak przygotowanie urządzenia za pomocą specjalnych poleceń.
• Generowanie różnych przypadków testowych i nazw testów.
• Analizowanie wyników poprzez odczytanie danych wyjściowych polecenia lub użycie innych warunków.

Aby ułatwić rozszerzanie istniejących szablonów, szablony zawierają metody wyspecjalizowane dla każdej funkcjonalności. Jeśli masz ulepszone projekty istniejących szablonów, zachęcamy do wniesienia wkładu w bazę kodów VTS.