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. Dzięki temu unikniesz sytuacji, w której obiekty te wykonują określone zadania z poziomu 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 interfejsu CtsGestureTestCases.apk i uruchamia instrumentację w stosunku do 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.
Wyjątek dotyczący tagu metrics_collector
metrics_collector jest dozwolony, ale nie jest ograniczony do klasy FilePullerLogCollector, by określić plik lub katalog, który ma być pobierany i logowany przez moduł. Jest to przydatne, jeśli pozostawiasz 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 tworzyć mylne wrażenie, że moduł nie otrzyma żadnych informacji o kompilacji. To nieprawda.
Informacje o kompilacji pochodzą z konfiguracji na poziomie pakietu i są dostępne dla wszystkich modułów w tym pakiecie. 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ł kompilacji Compatibility Test Suite (CTS) osobno wysyłał zapytanie o informacje o urządzeniu, typy itp., konfiguracja na poziomie zestawu CTS (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 wykonywanie testów. Służy głównie do celów organizacyjnych.
Aktualną listę dozwolonych komponentów dla CTS znajdziesz na stronie CtsConfigLoadingTest. Ten test nie powiedzie się przed przesłaniem, jeśli do modułu CTS zostanie dodany nieistniejący komponent.
Za pomocą właściwości module-metadata-include-filter i module-metadata-exclude-filter możesz filtrować uruchomienia pakietu na podstawie komponentów.
Przykład:
--module-metadata-include-filter component framework
W tym przykładzie uruchamiany jest tylko moduł testowy opatrzony adnotacjami za pomocą komponentu framework.
Parametr
Metadane parameter mają charakter informacyjny i wpływają na wykonanie testu. Określa on tryb Androida, którego dotyczy moduł testowy.
W takim przypadku tryby są ograniczone do trybów Androida na wysokim poziomie, takich jak instant apps, secondary users lub different abis.
Jeśli podczas uruchamiania pakietu tryb ma zastosowanie do testu, na jego podstawie zostanie utworzonych kilka wersji modułu testu. Każda odmiana przeprowadza podobne testy, ale w innych 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 odmianę testów, które instalują pliki APK i przeprowadzają 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.
Kolektory danych na poziomie modułu i podmioty przetwarzające dane mogą być powiązane z różnymi modułami.
Nie zalecamy określania procesorów końcowych zarówno na poziomie najwyższego poziomu, 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" />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>