Struktura pliku AndroidTest.xml

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 ogólnie rzecz biorąc, konfiguracja modułu może zawierać tylko te tagi XML: target_preparer, multi_target_preparer, test i metrics_collector.

Mimo że ta lista może wyglądać na restrykcyjną, pozwala ona dokładnie określić wymagania dotyczące konfiguracji modułu testowego i testu do wykonania.

UWAGA: zobacz utracona konfiguracja XML. jeśli chcesz przypomnieć sobie informacje o różnych tagach.

Obiekty takie jak build_provider lub result_reporter wywołają błąd ConfigurationException, jeśli spróbujesz uruchomić je z poziomu konfiguracji modułu. Ma to na celu uniknięcie oczekiwań, że te obiekty będą wykonywać jakieś zadania w module.

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 uruchamia instrumentację dla pakietu android.gesture.cts.

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 tworzyć mylne wrażenie, że moduł nie otrzyma żadnych informacji o kompilacji. To nieprawda.

Informacje o kompilacji są udostępniane na poziomie konfiguracji pakietu i są współdzielone przez wszystkie moduły pakietu. 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 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 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 w module który zamierza testować. Nie ma on bezpośredniego wpływu na wykonywanie testów. Służy 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ą parametrów 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 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.

Podczas wykonywania zestawu testów, jeśli tryb ma zastosowanie do testu, na podstawie tego trybu tworzone są różne wersje modułu testu. 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 danych i ich przetwarzanie w przypadku modułów 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 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>