Ogólna struktura konfiguracji modułu jest podobna do zwykłej konfiguracji XML Tradefed, ale z pewnymi ograniczeniami wynikającymi z tego, że moduły są uruchamiane w ramach pakietu.
Lista dozwolonych tagów
AndroidTest.xml lub szerzej konfiguracja modułu może zawierać tylko następujące tagi XML: target_preparer, multi_target_preparer, test i metrics_collector.
Chociaż ta lista wygląda na ograniczoną, pozwala precyzyjnie określić potrzeby konfiguracji modułu testowego i testu do uruchomienia.
UWAGA: jeśli chcesz przypomnieć sobie informacje o różnych tagach, zapoznaj się z konfiguracją XML Tradefed.
Jeśli spróbujesz uruchomić obiekty takie jak build_provider czy result_reporter z poziomu konfiguracji modułu, zostanie zgłoszony wyjątek ConfigurationException. Ma to na celu uniknięcie oczekiwania, że te obiekty będą wykonywać jakieś zadanie w module.
Przykładowa konfiguracja modułu
<configuration description="Config for CTS Gesture test cases">
<option name="test-suite-tag" value="cts" />
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsGestureTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.gesture.cts" />
<option name="runtime-hint" value="10m50s" />
</test>
</configuration>
Ta konfiguracja opisuje test, który wymaga zainstalowania pliku CtsGestureTestCases.apk i uruchomi instrumentację w pakiecie android.gesture.cts.
Tagi włączania <include> i <template-include>
Używanie tagów <include> i <template-include> w konfiguracjach modułów jest
odradzane. Nie ma gwarancji, że będą one działać zgodnie z oczekiwaniami.
Przypadek specjalny dla tagu metrics_collector
Tag metrics_collector jest dozwolony, ale ograniczony do klasy
FilePullerLogCollector
, aby można było określić plik lub katalog do pobrania i zarejestrowania w
module. Jest to przydatne, jeśli zapisujesz logi w określonej lokalizacji i chcesz je automatycznie odzyskać.
Przykładowa konfiguracja:
<configuration description="Config for CTS UI Rendering test cases">
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.uirendering.cts" />
<option name="runtime-hint" value="11m55s" />
<option name="runner" value="android.uirendering.cts.runner.UiRenderingRunner" />
<option name="isolated-storage" value="false" />
</test>
<!-- Collect the files in the dump directory for debugging -->
<metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
<option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
<option name="collect-on-run-ended-only" value="true" />
</metrics_collector>
</configuration>
A co z informacjami o kompilacji lub pobieraniem?
Definicja dozwolonych tagów może sprawiać wrażenie, że moduł nie będzie otrzymywać żadnych informacji o kompilacji. To nieprawda.
Informacje o kompilacji są dostarczane z konfiguracji na poziomie pakietu i będą udostępniane wszystkim modułom pakietu. Umożliwia to pojedynczą konfigurację najwyższego poziomu dla pakietu, aby uruchomić wszystkie moduły wchodzące w jego skład.
Na przykład zamiast tego, aby każdy
Compatibility Test Suite (CTS)
moduł osobno wysyłał zapytania o informacje o urządzeniu, typy itp., konfiguracja na poziomie pakietu CTS (cts.xml) robi to raz, a każdy moduł otrzyma te
informacje, jeśli o nie poprosi.
Aby obiekty w module otrzymywały informacje o kompilacji, muszą postępować tak samo jak w zwykłej konfiguracji Tradefed: zaimplementować interfejs IBuildReceiver, aby otrzymywać IBuildInfo. Więcej informacji znajdziesz w artykule
Testowanie na urządzeniu.
Pola metadanych
Wiele modułów testowych zawiera specyfikacje metadata, z których każda ma unikalny cel.
Przykład:
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
<option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
<option name="config-descriptor:metadata" key="parameter" value="secondary_user" />
Komponent
Metadane component opisują ogólny komponent Androida, który moduł ma przetestować. Nie mają one bezpośredniego wpływu na wykonanie testu. Są używane głównie do celów organizacyjnych.
Aktualna lista dozwolonych komponentów w CTS jest dostępna w CtsConfigLoadingTest. Ten test nie przejdzie weryfikacji wstępnej, jeśli do modułu CTS zostanie dodany nieistniejący komponent.
Możesz filtrować uruchomienie pakietu na podstawie komponentów za pomocą filtrów module-metadata-include-filter i module-metadata-exclude-filter.
Przykład:
--module-metadata-include-filter component framework
Ten przykład uruchamia tylko moduł testowy oznaczony komponentem framework.
Parametr
Metadane parameter mają charakter informacyjny i wpływają na wykonanie testu. Określają, do którego trybu Androida odnosi się moduł testowy.
W tym przypadku tryby są ograniczone do trybów Androida wysokiego poziomu, takich jak instant apps, secondary users czy different abis.
Jeśli podczas uruchamiania pakietu tryb ma zastosowanie do testu, na podstawie trybu tworzone są różne wersje modułu testowego. Każda wersja uruchamia podobne testy, ale w różnych trybach.
instant_app: utwórz wersję testów, która instaluje pliki APK jako aplikacje błyskawiczne.multi_abi: utwórz wersję testów dla każdego ABI obsługiwanego przez urządzenie.secondary_user: utwórz wersję testów, która instaluje pliki APK i uruchamia testy jako użytkownik dodatkowy.
Zbieranie danych i przetwarzanie końcowe w przypadku modułów testów wydajności
W przypadku modułów testów wydajności dozwolone są metrics_collector i metric_post_processor na poziomie modułu, ponieważ są one niezbędne do testów wydajności.
Kolektory danych i procesory końcowe na poziomie modułu mogą być specyficzne dla modułu.
Nie zalecamy określania procesorów końcowych zarówno na poziomie najwyższym, jak i na poziomie modułu.
Konfiguracja modułu testu wydajności musi zawierać metadane test-type z wartością performance, np.:
xml
<option name="config-descriptor:metadata" key="test-type" value="performance" />
Jeśli konfiguracja testu zawiera metric_collector inny niż
FilePullerLogCollector lub jakikolwiek metric_post_processor, a nie zawiera tych metadanych, test
nie przejdzie weryfikacji wstępnej.
Przykładowa konfiguracja modułu testu wydajności:
<configuration description="Runs sample performance test.">
<!-- Declare as a performance test module -->
<option name="config-descriptor:metadata" key="test-type" value="performance" />
<option name="test-tag" value="hello-world-performance-test" />
<test class="com.android.tradefed.testtype.HostTest" >
<option name="class" value="android.test.example.helloworldperformance.HelloWorldPerformanceTest" />
</test>
<!-- Add module-level post processor MetricFilePostProcessor -->
<metric_post_processor class="com.android.tradefed.postprocessor.MetricFilePostProcessor">
<option name="aggregate-similar-tests" value="true" />
<option name="enable-per-test-log" value="false" />
</metric_post_processor>
</configuration>