Ogólna struktura konfiguracji modułu wygląda podobnie do standardowej konfiguracji XML Tradefed, ale z pewnymi ograniczeniami że działają one jako część pakietu.
Lista dozwolonych tagów
AndroidTest.xml lub ogólnie rzecz biorąc, konfiguracja modułu może zawierać tylko
te tagi XML: target_preparer, multi_target_preparer, test i
metrics_collector.
Lista jest ograniczona, ale pozwala precyzyjnie konfiguracji modułu testowego i testu do uruchomienia.
UWAGA: zobacz utracona konfiguracja XML. jeśli chcesz przypomnieć sobie informacje o różnych tagach.
Obiekty takie jak build_provider lub result_reporter spowodują wywołanie zapytania
ConfigurationException, jeśli próbowano uruchomić go z poziomu modułu
konfiguracji. Dzięki temu można uniknąć
za pomocą obiektów wykonujących 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 CtsGestureTestCases.apk do
zostanie zainstalowany i będzie uruchamiać instrumentację w interfejsie android.gesture.cts
pakietu SDK.
Tagi uwzględniania <include> i <template-include>
Wykorzystanie elementów <include> i <template-include> w konfiguracjach modułów jest
odradzamy. Nie ma gwarancji, że będą one działać zgodnie z oczekiwaniami.
Szczególny przypadek w przypadku tagu Metric_collector
Element metrics_collector jest dozwolony, ale nie jest ograniczony do
FilePullerLogCollector.
class w celu określenia pliku lub katalogu, który ma być pobierany i rejestrowany
w module. Jest to przydatne, jeśli pozostawiasz 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 lub pobieranymi plikami?
Definicja dozwolonych tagów może sprawiać wrażenie, że moduł nie pobierze żadnych informacji o kompilacji. To nieprawda.
Informacje o kompilacji pochodzą z konfiguracji pakietu i zostaną przez wszystkie moduły pakietu. Dzięki temu można przeprowadzić jedną konfigurację najwyższego poziomu w celu uruchomienia wszystkich jego modułów.
Na przykład zamiast każdego tagu
Compatibility Test Suite (CTS)
wysyła osobne zapytania o informacje o urządzeniu, typy urządzeń itp., CTS.
konfiguracji na poziomie pakietu (cts.xml) wykonuje się to raz i każdy moduł otrzyma
informacji, o które poprosi.
Aby obiekty w module otrzymały informacje o kompilacji, muszą one zawierać
zrobić to samo, co w zwykłej konfiguracji Tradefed: zaimplementuj tag
IBuildReceiver, aby otrzymać IBuildInfo. Zobacz
testowanie na urządzeniu
.
Pola metadanych
Duża liczba modułów testowych zawiera specyfikacje metadata,
a każdy z nich ma inny 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 w module
który zamierza testować. Nie ma bezpośredniego wpływu na wykonanie testu. to
głównie do celów organizacyjnych.
Aktualna lista dozwolonych komponentów CTS jest dostępna w: CtsConfigLoadingTest. Ten test kończy się niepowodzeniem we wstępnym przesłaniu, jeśli do komponentu został dodany nieistniejący komponent Moduł CTS.
Uruchomienie pakietu można filtrować na podstawie komponentów z zastosowaniem
module-metadata-include-filter i module-metadata-exclude-filter.
Przykład:
--module-metadata-include-filter component framework
W tym przykładzie uruchamiamy tylko moduł testowy z adnotacją framework
.
Parametr
Metadane parameter mają charakter informacyjny i wpływają na test
Określa on tryb Androida, którego dotyczy moduł testowy.
W tym przypadku tryby są ograniczone do trybów wysokiego poziomu Androida, takich jak:
instant apps, secondary users lub different abis.
Jeśli podczas uruchamiania pakietu tryb ma zastosowanie do testu, kilka wersji modułu testowego na podstawie trybu. Każda odmiana jest aktywna w podobnych testach, ale w innych trybach.
instant_app: utwórz odmianę testów, które instalują pliki APK jako aplikacji błyskawicznych.multi_abi: utwórz odmianę testów dla każdego interfejsu ABI obsługiwanego przez urządzenia.secondary_user: utwórz odmianę testów, które instalują pliki APK i uruchamiać testy jako użytkownik dodatkowy.
Zbieranie wskaźników i przetwarzanie po ich zakończeniu w modułach testów wydajności
W przypadku modułów do testów skuteczności, modułów metrics_collector i
metric_post_processor są dozwolone, ponieważ są kluczowe w testach skuteczności.
Kolektory danych i podmioty przetwarzające dane na poziomie modułu mogą być związane z różnymi modułami.
Nie zalecamy określania podmiotów przetwarzających zarówno na najwyższym poziomie,
na poziomie modułu.
Konfiguracja modułu testu wydajności musi zawierać metadane test-type
o wartości performance, na przykład:
xml
<option name="config-descriptor:metadata" key="test-type" value="performance" />
Bez tego, jeśli konfiguracja testowa zawiera element metric_collector inny niż
FilePullerLogCollector lub dowolny metric_post_processor, test
nie udało się przesłać wstępnie.
Przykładowa konfiguracja modułu testu skutecznoś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>