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 te tagi XML: target_preparer, multi_target_preparer, test i metrics_collector.
Chociaż ta lista może wyglądać na restrykcyjną, pozwala dokładnie określić wymagania dotyczące konfiguracji modułu testowego i testu do wykonania.
UWAGA: jeśli chcesz przypomnieć sobie różne tagi, zapoznaj się z konfiguracją pliku XML Tradefed.
Obiekty takie jak build_provider lub result_reporter wywołają błąd ConfigurationException, jeśli spróbujesz uruchomić je z poziomu konfiguracji modułu. Ma to na celu uniknięcie oczekiwań dotyczących tych obiektów, które faktycznie wykonują jakieś zadanie w ramach modułu.
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 CtsGestureTestCases.apk i uruchamia instrumentację dla pakietu android.gesture.cts.
Tagi uwzględnienia <include> i <template-include>
Nie zalecamy używania parametrów <include> i <template-include> w konfiguracjach modułów. Nie ma gwarancji, że będą działać zgodnie z oczekiwaniami.
Specjalny przypadek tagu metrics_collector
Funkcja metrics_collector jest dozwolona, ale ograniczona do klasy FilePullerLogCollector, aby określić plik lub katalog, który ma zostać pobrany i zapisany w ramach modułu. Jest to przydatne, jeśli pozostawiasz dzienniki w konkretnej 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 tworzyć mylne wrażenie, że moduł nie otrzyma żadnych informacji o kompilacji. To nieprawda.
Informacje o kompilacji są udostępniane na poziomie konfiguracji pakietu i będą udostępniane wszystkim modułom pakietu. Dzięki temu wystarczy jedno ustawienie najwyższego poziomu dla pakietu, aby uruchomić wszystkie moduły wchodzące w jego skład.
Na przykład zamiast tego, aby każdy moduł Compatibility Test Suite (CTS) osobno wysyłał zapytanie o informacje o urządzeniu, typy itp., konfiguracja CTS na poziomie zestawu (cts.xml) wykonuje to raz, a każdy moduł otrzyma te informacje, jeśli je zażąda.
Aby obiekty w module mogły otrzymywać informacje o kompilacji, muszą wykonać te same czynności co w przypadku zwykłej konfiguracji Tradefed: wdrożyć interfejs IBuildReceiver, aby odbierać IBuildInfo. Więcej informacji znajdziesz w artykule Testowanie za pomocą urządzenia.
Pola metadanych
Duża liczba modułów testowych zawiera specyfikacje metadata, z których każda ma swój 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 ma być testowany przez moduł. Nie ma on bezpośredniego wpływu na wykonanie testu; służy głównie do celów organizacyjnych.
Aktualna lista dozwolonych komponentów CTS jest dostępna w CtsConfigLoadingTest. Ten test nie powiedzie się przed przesłaniem, jeśli do modułu CTS zostanie dodany nieistniejący komponent.
Za pomocą parametrów module-metadata-include-filter i module-metadata-exclude-filter możesz filtrować uruchomienie pakietu na podstawie komponentów.
Przykład:
--module-metadata-include-filter component framework
W tym przykładzie uruchamiany jest tylko moduł testowy z adnotacją framework.
Parametr
Metadane parameter mają charakter informacyjny i wpływają na wykonanie testu. Określa, do którego trybu Androida ma zastosowanie moduł testu.
W takim przypadku tryby są ograniczone do trybów Androida na wysokim poziomie, takich jak instant apps, secondary users lub different abis.
Podczas wykonywania zestawu testów, jeśli tryb ma zastosowanie do testu, tworzone są różne wersje modułu testu na podstawie tego trybu. Każda wersja testuje podobne testy, ale w różnych trybach.
instant_app: utwórz wariant testów, które instalują pliki APK jako aplikacje błyskawiczne.multi_abi: utwórz wariant testów dla każdego interfejsu ABI obsługiwanego przez urządzenie.secondary_user: utwórz wariant testów, które instalują pliki APK i uruchamiają testy jako użytkownik dodatkowy.
Zbieranie danych i ich przetwarzanie w przypadku modułów testów wydajności
W przypadku modułów testów wydajności dozwolone są tagi metrics_collector i metric_post_processor na poziomie modułu, ponieważ są one niezbędne do testów wydajności.
Zbieracze i postprocesory danych na poziomie modułu mogą być specyficzne dla modułu.
Nie zalecamy określania postprocesorów na poziomie najwyższym i na poziomie modułu.
Konfiguracja modułu testu wydajności musi zawierać metadane test-type o 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 dowolny metric_post_processor, test nie przechodzi weryfikacji przed przesłaniem.
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>