Diese Seite wurde von der Cloud Translation API übersetzt.

AndroidTest.xml-Struktur

Die Gesamtstruktur der Modulkonfiguration folgt einem ähnlichen Muster Standard-XML-Konfiguration von Tradefed, allerdings mit einigen Einschränkungen aufgrund als Teil einer Suite ausgeführt werden.

Liste der zulässigen Tags

Die Modulkonfiguration AndroidTest.xml oder allgemeiner darf nur den Parameter folgenden XML-Tags: target_preparer, multi_target_preparer, test und metrics_collector

Diese Liste sieht zwar restriktiv aus, Sie können damit aber präzise definieren, die Anforderungen an die Einrichtung des Testmoduls und den auszuführenden Test.

HINWEIS: Siehe Tradefed XML-Konfiguration wenn Sie eine Auffrischung zu den verschiedenen Tags benötigen.

Objekte wie build_provider oder result_reporter lösen einen ConfigurationException, wenn versucht wurde, aus einem Modul auszuführen Konfiguration. Damit soll vermieden werden, Objekte, die eine Aufgabe in einem Modul ausführen.

Beispiel für Modulkonfiguration

<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>

Diese Konfiguration beschreibt einen Test, für den CtsGestureTestCases.apk erforderlich ist, installiert und führt eine Instrumentierung für die android.gesture.cts aus. Paket.

Einschluss-Tags `<include>` und `<template-include>`

Die Verwendung von <include> und <template-include> in Modulkonfigurationen ist entmutigt werden. Es kann nicht garantiert werden, dass sie wie erwartet funktionieren.

Sonderfall für das „metric_collector“-Tag

metrics_collector ist zulässig, ist aber auf Folgendes beschränkt: FilePullerLogCollector Klasse, um eine bestimmte Datei oder ein bestimmtes Verzeichnis anzugeben, die bzw. das abgerufen und für die protokolliert werden soll. des Moduls. Dies ist nützlich, wenn Sie Protokolle an einem bestimmten Speicherort möchten sie automatisch wiederherstellen.

Konfigurationsbeispiel:

<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>

Was ist mit Build-Informationen oder Downloads?

Die Definition der zulässigen Tags kann den falschen Eindruck erwecken, dass ein erhält das Modul keine Build-Informationen. Das stimmt nicht.

Die Build-Informationen stammen aus der Einrichtung auf Suite-Ebene und werden die von allen Modulen der Suite genutzt werden. So kann eine einzelne Einrichtung auf oberster Ebene damit alle Module der Suite ausgeführt werden können.

Anstatt beispielsweise alle Kompatibilitätstest-Suite (Compatibility Test Suite, CTS) die Geräteinformationen, -typen usw. individuell abfragt, die CTS auf Suite-Ebene (cts.xml) erfolgt dies einmal und jedes Modul erhält wenn sie darum bitten.

Damit die Objekte in einem Modul die Build-Informationen erhalten, müssen sie wie bei der regulären Tradefed-Konfiguration: IBuildReceiver-Schnittstelle für den Empfang von IBuildInfo. Weitere Informationen finden Sie unter mit dem Gerät testen .

Metadaten-Felder

Eine große Anzahl von Testmodulen enthält einige metadata-Spezifikationen, die jeweils ein eigenes Ziel haben.

Beispiel:

  <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" />

Komponente

Die component-Metadaten beschreiben die allgemeine Android-Komponente, die das Modul enthält. zu testen. Sie hat keine direkten Auswirkungen auf die Testausführung. es ist in erster Linie für organisatorische Zwecke verwendet werden.

Die aktuelle Liste der zulässigen Komponenten für CTS ist verfügbar in CtsConfigLoadingTest. Dieser Test schlägt beim Vorabsenden fehl, wenn einer nicht vorhandenen Komponente CTS-Modul.

Sie können eine Suite-Ausführung nach den Komponenten filtern, indem Sie module-metadata-include-filter und module-metadata-exclude-filter.

Beispiel:

  --module-metadata-include-filter component framework

In diesem Beispiel wird nur das mit dem framework annotierte Testmodul ausgeführt. Komponente.

Parameter

Die parameter-Metadaten dienen nur zu Informationszwecken und wirken sich auf den Test aus Ausführung. Er gibt an, für welchen Android-Modus das Testmodul gilt. In diesem Fall sind modes auf übergeordnete Android-Modi beschränkt, wie z. B. instant apps, secondary users oder different abis.

Wenn der Modus während der Ausführung auf den Test angewendet wird, werden verschiedene Varianten des Testmoduls werden basierend auf dem Modus erstellt. Jede Variante wird ausgeführt aber in unterschiedlichen Modi.

instant_app: Erstelle eine Variante der Tests, bei denen APKs installiert werden als Instant-Apps.
multi_abi: Erstelle eine Variante der Tests für jedes ABI, das vom .
secondary_user: Erstelle eine Variante der Tests, bei denen APKs und Tests als sekundärer Nutzer ausführen.

Messwerterfassung und Nachverarbeitung für Leistungstestmodule

Für Leistungstestmodule metrics_collector auf Modulebene und metric_post_processor sind zulässig, da sie für Leistungstests unerlässlich sind. Die Messwert-Collectors und Postprozessoren auf Modulebene können modulspezifisch sein. Es wird nicht empfohlen, Postprozessoren sowohl auf oberster Ebene als auch Modulebene.

Eine Konfiguration für ein Leistungstestmodul muss die test-type-Metadaten enthalten mit dem Wert performance, zum Beispiel: xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> Andernfalls gilt, wenn eine Testkonfiguration metric_collector enthält, die nicht FilePullerLogCollector oder einem beliebigen metric_post_processor, der Test Vorabreichung schlägt fehl.

Beispiel für die Konfiguration eines Leistungstestmoduls:

<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>