Ogólna struktura konfiguracji modułu jest podobna do zwykłej konfiguracji Tradefed XML, ale z pewnymi ograniczeniami wynikającymi z faktu, że moduły działają jako część pakietu.
Lista dozwolonych tagów
Konfiguracja modułu AndroidTest.xml lub szerzej szerzej może zawierać wyłącznie następujące tagi XML: target_preparer , multi_target_preparer , test i metrics_collector .
Chociaż lista ta wygląda na restrykcyjną, pozwala precyzyjnie zdefiniować potrzeby konfiguracji modułu testowego i test, który ma zostać uruchomiony.
UWAGA: Zobacz konfigurację Tradefed XML , jeśli potrzebujesz odświeżenia informacji na temat różnych tagów.
Obiekty takie jak build_provider result_reporter zgłoszą wyjątek ConfigurationException w przypadku próby uruchomienia z poziomu konfiguracji modułu. Ma to na celu uniknięcie oczekiwania, że te obiekty faktycznie wykonają jakieś zadanie 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 CtsGestureTestCases.apk i uruchomi instrumentację względem pakietu android.gesture.cts .
Tagi dołączania <include> i <template-include>
Odradza się używanie <include> i <template-include> w konfiguracjach modułów. Nie ma gwarancji, że będą działać zgodnie z oczekiwaniami.
Specjalny przypadek tagu metrics_collector
metrics_collector jest dozwolony, ale ograniczony do klasy FilePullerLogCollector w celu określenia danego pliku lub katalogu, który ma zostać pobrany i zarejestrowany dla modułu. Jest to przydatne, jeśli zostawiasz 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 plikami do pobrania?
Definicja dozwolonych tagów może powodować błędne wrażenie, że moduł nie otrzyma żadnych informacji o kompilacji. To nie jest prawda .
Informacje o kompilacji są dostarczane z poziomu konfiguracji pakietu i będą wspólne dla wszystkich modułów pakietu. Umożliwia to pojedynczą konfigurację najwyższego poziomu pakietu w celu uruchomienia wszystkich modułów wchodzących w skład pakietu.
Na przykład zamiast każdego modułu Compatibility Test Suite (CTS) indywidualnie odpytywać o informacje o urządzeniu, typach itp., konfiguracja na poziomie pakietu CTS ( cts.xml ) robi to raz, a każdy moduł otrzyma te informacje, jeśli o to poprosi.
Aby obiekty w module mogły otrzymać informacje o kompilacji, muszą zrobić to samo, co w zwykłej konfiguracji Tradefed: zaimplementować interfejs IBuildReceiver , aby otrzymać IBuildInfo . Aby uzyskać więcej informacji, zobacz testowanie z urządzeniem .
Pola metadanych
Duża liczba modułów testowych zawiera pewne specyfikacje metadata , z których każdy 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" />
Część
Metadane component opisują ogólny komponent Androida, który moduł zamierza testować. Nie ma to żadnego bezpośredniego wpływu na wykonanie testu; jest używany głównie do celów organizacyjnych.
Aktualna lista dozwolonych komponentów dla CTS dostępna jest w CtsConfigLoadingTest . Ten test nie powiedzie się podczas wstępnego przesłania, jeśli do modułu CTS zostanie dodany nieistniejący komponent.
Możesz filtrować uruchomienie pakietu na podstawie komponentów, używając 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 z adnotacją komponentu framework .
Parametr
Metadane parameter mają charakter informacyjny i wpływają na wykonanie testu. Określa, jakiego trybu Androida dotyczy moduł testowy. W tym przypadku tryby są ograniczone do trybów Androida wysokiego poziomu, takich jak instant apps , secondary users lub different abis .
Podczas uruchamiania zestawu, jeśli tryb dotyczy testu, na podstawie tego trybu tworzonych jest kilka odmian modułu testowego. Każda odmiana przeprowadza podobne testy, ale w różnych trybach.
-
instant_app: utwórz odmianę testów, które instalują pliki APK jako aplikacje błyskawiczne. -
multi_abi: Utwórz odmianę testów dla każdego ABI obsługiwanego przez urządzenie. -
secondary_user: utwórz odmianę testów, które instalują pliki APK i uruchamiają testy jako użytkownik dodatkowy.
Zbieranie metryk i przetwarzanie końcowe dla modułów testów wydajnościowych
W przypadku modułów testów wydajnościowych dozwolone są metrics_collector i metric_post_processor na poziomie modułu, ponieważ są one niezbędne do testów wydajnościowych. Kolektory metryk i postprocesory na poziomie modułu mogą być specyficzne dla modułu. Nie zaleca się określania postprocesorów 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" /> Bez tego, jeśli test config zawiera metric_collector inny niż FilePullerLogCollector lub dowolny metric_post_processor , test przed przesłaniem kończy się niepowodzeniem.
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>