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 wygląda na ograniczoną, pozwala precyzyjnie określić potrzeby konfiguracji modułu testowego i testu do uruchomienia.
UWAGA: jeśli chcesz przypomnieć sobie różne tagi, zapoznaj się z artykułem Konfiguracja XML Tradefed.
Obiekty takie jak build_provider lub result_reporter spowodują zgłoszenie ConfigurationException, jeśli próba ich uruchomienia zostanie podjęta w konfiguracji modułu. Ma to na celu uniknięcie oczekiwania, że te obiekty będą wykonywać 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 uruchomi instrumentację w pakiecie android.gesture.cts.
Tagi włączenia <include> i <template-include>
Używanie <include> i <template-include> w konfiguracjach modułów jest odradzane. Nie ma gwarancji, że będą działać zgodnie z oczekiwaniami.
Przypadek specjalny dotyczący tagu metrics_collector
Znak metrics_collector jest dozwolony, ale ograniczony do klasy FilePullerLogCollector, aby określić dany plik lub katalog, który ma zostać pobrany i zarejestrowany w module. Jest to przydatne, jeśli zostawiasz dzienniki 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 i pobieraniem?
Definicja dozwolonych tagów może wywoływać błędne wrażenie, że moduł nie będzie otrzymywać żadnych informacji o kompilacji. To nieprawda.
Informacje o kompilacji są podawane w konfiguracji na poziomie pakietu i będą udostępniane wszystkim modułom pakietu. Dzięki temu można skonfigurować pakiet na najwyższym poziomie, aby uruchamiać wszystkie moduły wchodzące w jego skład.
Na przykład zamiast tego, aby każdy moduł Compatibility Test Suite (CTS) oddzielnie wysyłał zapytanie 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 przypadku zwykłej konfiguracji Tradefed: zaimplementować interfejs IBuildReceiver, aby otrzymywać IBuildInfo. Więcej informacji znajdziesz w sekcji 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 testować. Nie ma to bezpośredniego wpływu na wykonanie testu. Jest to używane 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.
Możesz filtrować uruchomienie pakietu na podstawie komponentów za pomocą symboli module-metadata-include-filter i module-metadata-exclude-filter.
Przykład:
--module-metadata-include-filter component framework
W tym przykładzie uruchamiany jest tylko moduł testowy oznaczony adnotacją framework
component.
Parametr
parameter metadane mają charakter informacyjny i wpływają na wykonanie testu. Określa, do którego trybu Androida odnosi się moduł testowy.
W tym przypadku tryby są ograniczone do trybów Androida wyższego poziomu, takich jak instant apps, secondary users lub different abis.
Jeśli podczas wykonywania zestawu tryb ma zastosowanie do testu, na jego podstawie tworzonych jest kilka wariantów modułu testowego. Każda wersja przeprowadza podobne testy, ale w różnych trybach.
instant_app: Utwórz odmianę testów, w której pliki APK są instalowane jako aplikacje błyskawiczne.multi_abi: utwórz odmianę testów dla każdego interfejsu ABI obsługiwanego przez urządzenie.secondary_user: Utwórz odmianę testów, które instalują pliki APK i przeprowadzają testy jako użytkownik dodatkowy.
Zbieranie danych i przetwarzanie końcowe w modułach 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 w testach wydajności.
Kolektory danych i procesory końcowe na poziomie modułu mogą być specyficzne dla danego 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 o wartości performance, np.:xml
<option name="config-descriptor:metadata" key="test-type" value="performance" />Bez tego, jeśli konfiguracja testu zawiera metric_collector inne niż FilePullerLogCollector lub dowolne metric_post_processor, test zakończy się niepowodzeniem 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>