Die Gesamtstruktur der Modulkonfiguration folgt einem ähnlichen Muster wie die reguläre XML-Konfiguration von Tradefed, weist jedoch einige Einschränkungen auf, da sie als Teil einer Suite ausgeführt werden.
Liste der erlaubten Tags
AndroidTest.xml
oder allgemeiner gesagt kann die Modulkonfiguration nur die folgenden XML-Tags enthalten: target_preparer
, multi_target_preparer
, test
und metrics_collector
.
Obwohl diese Liste restriktiv erscheint, ermöglicht sie Ihnen, die Anforderungen an die Einrichtung des Testmoduls und den auszuführenden Test genau zu definieren.
HINWEIS: Sehen Sie sich die Tradefed-XML-Konfiguration an, wenn Sie eine Auffrischung der verschiedenen Tags benötigen.
Objekte wie build_provider
oder result_reporter
lösen eine ConfigurationException
aus, wenn versucht wird, sie innerhalb einer Modulkonfiguration auszuführen. Dadurch soll die Erwartung vermieden werden, dass diese Objekte tatsächlich eine Aufgabe innerhalb eines Moduls ausführen.
Beispiel-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, der die Installation CtsGestureTestCases.apk
erfordert und eine Instrumentierung für das Paket android.gesture.cts
ausführt.
Einschluss-Tags <include>
und <template-include>
Von der Verwendung von <include>
und <template-include>
in Modulkonfigurationen wird abgeraten. Es kann nicht garantiert werden, dass sie wie erwartet funktionieren.
Sonderfall für das metrics_collector-Tag
Der metrics_collector
ist zulässig, aber auf die Klasse FilePullerLogCollector
beschränkt, um eine bestimmte Datei oder ein bestimmtes Verzeichnis anzugeben, das für das Modul abgerufen und protokolliert werden soll. Dies ist nützlich, wenn Sie Protokolle an einem bestimmten Ort belassen und diese automatisch wiederherstellen möchten.
Beispielkonfiguration:
<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-Infos oder Downloads?
Die Definition der erlaubten Tags könnte den falschen Eindruck erwecken, dass ein Modul keine Build-Informationen erhält. Das ist nicht wahr .
Die Build-Informationen werden vom Setup auf Suite-Ebene bereitgestellt und von allen Modulen der Suite gemeinsam genutzt. Dies ermöglicht ein einziges Top-Level-Setup für die Suite, um alle Module der Suite auszuführen.
Anstatt beispielsweise jedes Compatibility Test Suite (CTS) -Modul einzeln die Geräteinformationen, Typen usw. abzufragen, führt das Setup auf CTS-Suite-Ebene ( cts.xml
) dies einmal durch und jedes Modul erhält diese Informationen, wenn es sie anfordert.
Damit die Objekte in einem Modul die Build-Informationen erhalten, müssen sie dasselbe tun wie in der regulären Tradefed-Konfiguration: die IBuildReceiver
Schnittstelle implementieren, um die IBuildInfo
zu empfangen. Weitere Einzelheiten finden Sie unter Testen mit dem Gerät .
Metadatenfelder
Eine große Anzahl von Testmodulen enthält einige metadata
, die jeweils ein einzigartiges 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
beschreiben die allgemeine Android-Komponente, die das Modul testen möchte. Es hat keinen direkten Einfluss auf die Testausführung; Es dient in erster Linie organisatorischen Zwecken.
Die aktuelle Liste der zulässigen Komponenten für CTS ist in CtsConfigLoadingTest verfügbar. Dieser Test schlägt im Presubmit fehl, wenn eine nicht vorhandene Komponente zu einem CTS-Modul hinzugefügt wird.
Sie können eine Suite-Ausführung basierend auf den Komponenten mithilfe von module-metadata-include-filter
und module-metadata-exclude-filter
.
Beispiel:
--module-metadata-include-filter component framework
In diesem Beispiel wird nur das mit der framework
Komponente annotierte Testmodul ausgeführt.
Parameter
Die parameter
dienen der Information und wirken sich auf die Testausführung aus. Es gibt an, für welchen Android-Modus das Testmodul gilt. In diesem Fall sind die Modi auf High-Level-Android-Modi beschränkt, z. B. instant apps
, secondary users
oder different abis
.
Wenn der Modus während des Suite-Laufs auf den Test zutrifft, werden basierend auf dem Modus mehrere Variationen des Testmoduls erstellt. Jede Variante führt ähnliche Tests durch, jedoch in unterschiedlichen Modi.
-
instant_app
: Erstellen Sie eine Variation der Tests, die APKs als Instant-Apps installieren. -
multi_abi
: Erstellen Sie eine Variation der Tests für jeden vom Gerät unterstützten ABI. -
secondary_user
: Erstellen Sie eine Variation der Tests, die APKs installieren und Tests als sekundärer Benutzer ausführen.
Metrikerfassung und Nachbearbeitung für Leistungstestmodule
Für Leistungstestmodule sind metrics_collector
und metric_post_processor
auf Modulebene zulässig, da sie für Leistungstests unerlässlich sind. Die Metriksammler und Postprozessoren auf Modulebene können modulspezifisch sein. Es wird nicht empfohlen, Postprozessoren sowohl auf der obersten Ebene als auch auf der Modulebene anzugeben.
Eine Leistungstestmodulkonfiguration muss die test-type
Metadaten mit dem Wert performance
enthalten, wie zum Beispiel: xml <option name="config-descriptor:metadata" key="test-type" value="performance" />
Ohne dies, wenn es sich um einen Test handelt config einen anderen metric_collector
als FilePullerLogCollector
oder einen beliebigen metric_post_processor
enthält, schlägt der Test bei der Vorabsendung fehl.
Beispielkonfiguration für ein Leistungstestmodul:
<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>