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>