AOSP zawiera szablony testów dla modułów testowych, które nie są podklasą Pythona po stronie hosta BaseTest.
Programiści mogą używać tych szablonów, aby zminimalizować wysiłek związany z integracją takich testów. Z tej sekcji dowiesz się, jak konfigurować i używać szablonów testów (znajdujących się w katalogu testcases/template w VTS) oraz znajdziesz przykłady najczęściej używanych szablonów.
Szablon BinaryTest
Aby zintegrować testy, które są wykonywane na urządzeniu docelowym w VTS, użyj szablonu BinaryTest. Testy po stronie docelowej obejmują:
- Testy oparte na języku C++ skompilowane i przesłane na urządzenie
- testy Pythona po stronie docelowej skompilowane jako pliki binarne;
- Skrypty powłoki, które można uruchomić na urządzeniach
Te testy można zintegrować z VTS z wykorzystaniem szablonu BinaryTest lub bez niego.
Integrowanie testów po stronie docelowej za pomocą szablonu BinaryTest
Szablon BinaryTest został zaprojektowany tak, aby ułatwić programistom integrację testów po stronie docelowej. W większości przypadków możesz dodać kilka prostych wierszy konfiguracji w pliku 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-sourceibinary-test-typesą specyficzne dla szablonu.- Podanie ścieżki względnej do hosta źródła binarnego testu umożliwia szablonowi przygotowanie, przesyłanie plików, wykonanie testu, analizę wyników i sprzątanie.
- Szablon zawiera metody związane z tworzeniem testów, które podklasy mogą zastąpić.
- Szablon zakłada 1 przypadek testowy na moduł binarny testu, a nazwa pliku źródłowego binarnego jest domyślnie używana jako nazwa przypadku testowego.
Opcje konfiguracji
Szablon BinaryTest obsługuje te opcje konfiguracji:
| Nazwa opcji | Typ wartości | Opis |
|---|---|---|
| binary-test-source | strings | Ścieżki źródeł testów binarnych względem katalogu testów vts na hoście. Przykład: DATA/nativetest/test |
| binary-test-working-directory | strings | Katalogi robocze (ścieżka po stronie urządzenia). Przykład: /data/local/tmp/testing/ |
| binary-test-envp | strings | Zmienne środowiskowe dla pliku binarnego. Przykład: PATH=/new:$PATH |
| binary-test-args | strings | Testowanie argumentów lub flag. Przykład: --gtest_filter=test1 |
| binary-test-ld-library-path | strings | zmiennej środowiskowej LD_LIBRARY_PATH.Przykład: /data/local/tmp/lib |
| binary-test-disable-framework | wartość logiczna | Przed testem wyłącz platformę Android Framework, aby to zrobić, uruchom adb stop.
Przykład: true |
| binary-test-stop-native-servers | wartość logiczna | Zatrzymaj wszystkie prawidłowo skonfigurowane serwery natywnych podczas testowania. Przykład:
true |
| binary-test-type | ciąg znaków | Typ szablonu. Inne typy szablonów rozszerzają ten szablon, ale nie musisz podawać tej opcji w przypadku tego szablonu, ponieważ już podano binary-test-source. |
W przypadku opcji z typem wartości strings możesz dodać większą liczbę wartości, powtarzając opcje w konfiguracji. Możesz na przykład ustawić binary-test-source 2 razy (jak w przykładzie VtsDeviceTreeEarlyMountTest).
Tagi testowe
Tagi testowe możesz dodawać, dodając je do opcji jako prefiks z wartościami strings i używaniem :: jako separatora. Tagi testowe są szczególnie przydatne, gdy uwzględniasz źródła binarne o tej samej nazwie, ale o różnej rozdzielczości lub w różnych katalogach nadrzędnych. Aby na przykład uniknąć konfliktu nazw plików lub wyników w przypadku źródeł o tej samej nazwie, ale z różnych katalogów źródeł, możesz dla tych źródeł podać różne tagi.
Jak widać na przykładzie VtsDeviceTreeEarlyMountTest z 2 źródłami dt_early_mount_test, tagi testowe to tagi z prefiksami _32bit:: i _64bit:: w tagach binary-test-source. Tagi zakończone 32bit lub 64bit automatycznie oznaczają testy jako dostępne dla jednej wersji ABI, co oznacza, że testy z tagiem _32bit nie są wykonywane w wersji 64-bitowej ABI. Nieokreślenie tagu jest równoważne użyciu tagu z pustym ciągiem znaków.
Opcje z tymi samymi tagami są grupowane i izolowane od innych tagów. Na przykład tag binary-test-args z tagiem _32bit jest stosowany tylko do tagu binary-test-source z tym samym tagiem i wykonany w tagu binary-test-working-directory z tym samym tagiem. Opcja binary-test-working-directory jest opcjonalna w przypadku testów binarnych. Umożliwia ona określenie pojedynczego katalogu roboczego dla tagu. Jeśli opcja binary-test-working-directory nie jest określona, w przypadku każdego tagu używane są domyślne katalogi.
Nazwa tagu jest dodawana bezpośrednio do nazwy testu w raporcie wyników.
Na przykład przypadek testowy testcase1 z tagiem _32bit będzie widoczny w raporcie wyników jako testcase1_32bit.
Integrowanie testów po stronie docelowej bez szablonu BinaryTest
Domyślny format testu w VTS to testy Pythona po stronie hosta rozszerzone o BaseTest w VTS runner. Aby zintegrować testy po stronie docelowej, musisz najpierw przesłać pliki testowe na urządzenie, wykonać testy za pomocą poleceń powłoki, a potem przeanalizować wyniki za pomocą skryptów Pythona po stronie hosta.
Testowanie binarnych plików binarnych w push
Zalecamy przesyłanie plików za pomocą narzędzia do przygotowywania danych docelowych 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:
- Sprawdzanie połączenia z urządzeniem.
- Określa bezwzględną ścieżkę do pliku źródłowego.
- Przesyła pliki za pomocą polecenia
adb push. - usuwa pliki po zakończeniu testów.
Możesz też przesłać pliki ręcznie, korzystając z testowego skryptu Pythona po stronie hosta, który działa według podobnej procedury.
Przeprowadzanie testów
Po przesłaniu plików na urządzenie uruchom test za pomocą 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 hostuje binarne pliki testowe GTest, z których każdy zawiera zwykle kilka przypadków testowych. Ten szablon rozszerza szablon BinaryTest przez zastąpienie metod konfiguracji, tworzenia przypadków testowych i analizowania wyników, dzięki czemu wszystkie konfiguracje BinaryTest są dziedziczone.
GtestBinaryTest dodaje opcję gtest-batch-mode:
| Nazwa opcji | Typ wartości | Opis |
|---|---|---|
| binary-test-type | ciąg znaków | Typ szablonu. Używa wartości gtest. |
| gtest-batch-mode | wartość logiczna | Uruchamianie binarnych plików Gtest w trybie zbiorczym. Przykład: true |
Ogólnie rzecz biorąc, ustawienie wartości gtest-batch-mode na true zwiększa wydajność przy jednoczesnym nieznacznym zmniejszeniu niezawodności. W testach zgodności VTS wiele modułów korzysta z trybu zbiorczego, aby zwiększyć wydajność. Ze względu na niezawodność, jeśli tryb nie zostanie określony, domyślnie jest używany tryb niepartii.
Tryb niegrupujący
Tryb niegrupowany powoduje wywołanie poszczególnych binarnych plików GTest w przypadku każdego przypadku testowego. Jeśli na przykład binarny plik GTest zawiera 10 przypadków testowych (po odfiltrowaniu według konfiguracji po stronie hosta), to w poszczególnych przypadkach z różnym filtrem testu wywoływany jest 10 razy w powłoce urządzenia. W przypadku każdego testu tworzony jest niepowtarzalny kod XML wyników GTest, który jest następnie analizowany przez szablon.
Zalety korzystania z trybu niepartyjnego:
- Izolacja testów. Awaria lub zawieszenie w jednym przypadku testowym nie ma wpływu na inne przypadki testowe.
- Szczegółowość. Łatwiej uzyskać profilowanie/zakres testowania na podstawie poszczególnych elementów testowania (pomiarów, systrace, bugreport, logcat itp.). Wyniki testów i dzienniki są pobierane natychmiast po zakończeniu każdego elementu testowania.
Wady korzystania z trybu niegrupowego:
- Niepotrzebne wczytywanie. Za każdym razem, gdy wywoływana jest binarna wersja GTest, wczytuje ona powiązane biblioteki i wykonuje początkowe konfiguracje klas.
- Nakłady na komunikację. Po zakończeniu testu host i urządzenie docelowe komunikują się ze sobą w celu zanalizowania wyników i wysyłania kolejnych poleceń (możliwe przyszłe optymalizacje).
Tryb zbiorczy
W trybie zbiorczym GTest binarny plik testowy jest wywoływany tylko raz z długą wartością filtra testu zawierającą wszystkie przypadki testowe odfiltrowane przez konfigurację po stronie hosta (zapobiega to problemowi z nadmiarowym wczytywaniem w trybie innym niż zbiorczy). Wyniki testów GTest możesz przeanalizować za pomocą pliku output.xml lub danych wyjściowych w terminalu.
W przypadku pliku output.xml (domyślnie):
Podobnie jak w trybie niepartyjnym, wynik testu jest analizowany za pomocą pliku XML danych wyjściowych GTest. Plik XML danych wyjściowych jest generowany po zakończeniu wszystkich testów, ale jeśli testowy przypadek użycia spowodował awarię binarnego lub urządzenia, nie generuje się plik XML z wynikami.
Jeśli używasz danych wyjściowych terminala:
Podczas działania GTest drukuje dziennik testu i postęp w terminalu w formacie, który może być analizowany przez framework w celu uzyskania stanu testu, wyników i dzienników.
Zalety korzystania z trybu zbiorczego:
- Izolacja testów. Zapewnia ten sam poziom izolacji testu co tryb niegrupowy, jeśli framework ponownie uruchamia binar/urządzenie po awarii z ograniczonym filtrem testu (z wyjątkiem zakończonych i zawieszonych testów).
- Szczegółowość. Zapewnia taką samą szczegółowość testów jak w trybie niepartyjnym.
Wady korzystania z tego trybu to:
- Koszty konserwacji. Jeśli format logowania GTest ulegnie zmianie, wszystkie testy przestaną działać.
- Niejasność. Przypadek testowy może wydrukować coś podobnego do formatu postępu GTest, co może wprowadzać w błąd.
Z tego powodu tymczasowo usunęliśmy opcję używania danych wyjściowych w wierszu poleceń. W przyszłości wrócimy do tej opcji, aby zwiększyć niezawodność tej funkcji.
Szablon HostBinaryTest
Szablon HostBinaryTest zawiera pliki wykonywalne po stronie hosta, których nie ma w innych katalogach ani w skryptach Pythona. Te testy obejmują:
- Kompilowane testowe pliki binarne, które można uruchomić na hoście
- skrypty wykonywalne w powłoce, Pythonie lub innych językach;
Przykładem jest test VTS Security SELinux na 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 używa podobnych konfiguracji testów. W powyższym przykładzie opcja binary-test-source określa ścieżkę względną po stronie hosta do testowego pliku wykonywalnego, a binary-test-type to host_binary_test. Podobnie jak w przypadku szablonu BinaryTest, domyślnie nazwa pliku binarnego jest używana jako nazwa przypadku testu.
Rozszerzanie istniejących szablonów
Możesz używać szablonów bezpośrednio w konfiguracji testu, aby uwzględnić testy inne niż Pythona lub rozszerzyć je w podklasie, aby spełnić określone wymagania dotyczące testów. Szablony w repozytorium VTS mają te rozszerzenia:
Zachęcamy deweloperów do rozszerzania istniejących szablonów o specyficzne wymagania testowe. Oto najczęstsze powody rozszerzania szablonów:
- specjalne procedury konfiguracji testów, takie jak przygotowanie urządzenia za pomocą specjalnych poleceń;
- generowanie różnych przypadków testowych i nazwy testów.
- analizowanie wyników przez odczytywanie danych wyjściowych polecenia lub za pomocą innych warunków.
Aby ułatwić rozszerzanie istniejących szablonów, zawierają one metody wyspecjalizowane do poszczególnych funkcji. Jeśli masz ulepszone wersje dotychczasowych szablonów, zachęcamy do udostępnienia ich w formie kodu źródłowego VTS.