Struktura pliku AndroidTest.xml

Ogólna struktura konfiguracji modułów jest podobna do zwykłej konfiguracji Tradefed XML, ale z pewnymi ograniczeniami wynikającymi z faktu, że działają one jako część pakietu.

Lista dozwolonych tagów

AndroidTest.xml lub szerzej konfiguracja modułu może zawierać tylko następujące tagi XML: target_preparer , multi_target_preparer , test i metrics_collector .

Chociaż ta lista wygląda na restrykcyjną, pozwala precyzyjnie zdefiniować potrzeby konfiguracji modułu testowego i test do uruchomienia.

UWAGA: Zobacz konfigurację Tradefed XML , jeśli potrzebujesz odświeżenia różnych tagów.

Obiekty takie jak build_provider lub result_reporter zgłoszą wyjątek ConfigurationException w przypadku próby uruchomienia z wnętrza konfiguracji modułu. Ma to na celu uniknięcie oczekiwania, że ​​te obiekty rzeczywiście wykonują 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 oprzyrządowanie względem pakietu android.gesture.cts .

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 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 plikami do pobrania?

Definicja dozwolonych tagów może dawać błędne wrażenie, że moduł nie otrzyma żadnych informacji o kompilacji. To nie jest prawda .

Informacje o kompilacji pochodzą z konfiguracji na poziomie pakietu i będą współużytkowane przez wszystkie moduły pakietu. Pozwala to na pojedynczą konfigurację najwyższego poziomu dla 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 sprawdzać informacje o urządzeniach, 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 otrzymały informacje o kompilacji, muszą zrobić to samo, co w zwykłej konfiguracji Tradefed: zaimplementować interfejs IBuildReceiver , aby otrzymać IBuildInfo . Zobacz testowanie z urządzeniem , aby uzyskać więcej informacji.

Pola metadanych

Duża liczba modułów testowych zawiera pewne specyfikacje metadata , z których każdy 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" />

Część

Metadane component opisują ogólny komponent Androida, który moduł zamierza przetestować. Nie ma to bezpośredniego wpływu na wykonanie testu; jest używany głównie do celów organizacyjnych.

Aktualna lista dozwolonych składników dla CTS jest dostępna w CtsConfigLoadingTest . Ten test kończy się niepowodzeniem podczas wstępnego przesyłania, jeśli do modułu CTS zostanie dodany nieistniejący komponent.

Uruchomienie pakietu można filtrować na podstawie składników przy użyciu module-metadata-include-filter i module-metadata-exclude-filter .

Przykład:

  --module-metadata-include-filter component framework

Ten przykład uruchamia tylko moduł testowy z adnotacją komponentu framework .

Parametr

Metadane parameter mają charakter informacyjny i wpływają na wykonanie testu. Określa, do którego trybu Androida odnosi się moduł testowy. W takim przypadku tryby są ograniczone do zaawansowanych trybów Androida, takich jak instant apps , secondary users lub different abis .

Podczas uruchamiania pakietu, jeśli tryb ma zastosowanie do testu, na podstawie tego trybu tworzonych jest kilka odmian modułu testowego. Każda odmiana przeprowadza podobne testy, ale w innych 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.