Struktura AndroidTest.xml

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

Lista dozwolonych tagów

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

Chociaż ta lista wygląda na restrykcyjną, pozwala na precyzyjne zdefiniowanie potrzeb konfiguracji modułu testowego oraz test do uruchomienia.

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

Obiekty, takie jak build_provider lub result_reporter , zgłoszą ConfigurationException , jeśli będą próbowały zostać uruchomione z wnętrza 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ę dla pakietu android.gesture.cts .

Szczególny przypadek tagu „metrics_collector”

Parametr metrics_collector jest dozwolony, ale ograniczony do klasy FilePullerLogCollector w celu określenia danego pliku lub katalogu, który ma być ściągnięty i rejestrowany 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 dawać błędne wrażenie, że moduł nie otrzyma żadnych informacji o kompilacji. To nieprawda .

Informacje o kompilacji są dostarczane z konfiguracji na poziomie pakietu i będą współdzielone przez wszystkie moduły 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 pytać o informacje o urządzeniu, typy 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 otrzymywały informacje o kompilacji, muszą zrobić to samo, co w zwykłej konfiguracji Tradefed: zaimplementuj 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" />

Składnik

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 we wstępnym przesłaniu, jeśli nieistniejący składnik zostanie dodany do modułu CTS.

Możesz filtrować uruchomienie pakietu na podstawie komponentów przy użyciu 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 adnotacjami w komponencie framework .

Parametr

Metadane parameter mają charakter informacyjny i wpływają na wykonanie testu. Określa, którego trybu Androida dotyczy moduł testowy. W tym przypadku tryby są ograniczone do trybów wysokiego poziomu Androida, takich jak instant apps , secondary users wtórni lub different abis .

Podczas uruchamiania pakietu, jeśli tryb ma zastosowanie do testu, kilka odmian modułu testowego jest tworzonych w oparciu o tryb. Każda odmiana przeprowadza podobne testy, ale w różnych trybach.

  • instant_app : utwórz odmianę testów, które instalują pakiety 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ą pakiety APK i uruchamiają testy jako użytkownik dodatkowy.