Die Gesamtstruktur der Modulkonfiguration folgt einem ähnlichen Muster wie die reguläre Tradefed-XML-Konfiguration. Es gibt jedoch einige Einschränkungen, da sie als Teil einer Suite ausgeführt werden.
Liste der zulässigen Tags
AndroidTest.xml oder allgemeiner die Modulkonfiguration darf nur die folgenden XML-Tags enthalten: target_preparer, multi_target_preparer, test und metrics_collector.
Diese Liste sieht zwar restriktiv aus, ermöglicht Ihnen aber, die Anforderungen für die Einrichtung des Testmoduls und den auszuführenden Test genau zu definieren.
HINWEIS: Weitere Informationen zu den verschiedenen Tags findest du unter Tradefed-XML-Konfiguration.
Objekte wie build_provider oder result_reporter lösen einen ConfigurationException aus, wenn versucht wird, innerhalb einer Modulkonfiguration auszuführen. Damit soll vermieden werden, dass diese Objekte tatsächlich eine Aufgabe innerhalb eines Moduls 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 installiert sein muss und mit dem eine Instrumentierung für das Paket android.gesture.cts ausgeführt wird.
Einschluss-Tags <include> und <template-include>
Die Verwendung von <include> und <template-include> in Modulkonfigurationen wird nicht empfohlen. Es kann nicht garantiert werden, dass sie wie erwartet funktionieren.
Sonderfall für das Tag „metrics_collector“
Der Befehl metrics_collector ist zulässig, aber auf die Klasse FilePullerLogCollector beschränkt. Damit kann eine bestimmte Datei oder ein bestimmtes Verzeichnis für das Modul abgerufen und protokolliert werden. Das ist nützlich, wenn Sie Protokolle an einem bestimmten Speicherort ablegen und sie 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-Informationen oder Downloads?
Die Definition der zulässigen Tags kann den falschen Eindruck erwecken, dass für ein Modul keine Build-Informationen abgerufen werden. Das ist nicht richtig.
Die Build-Informationen werden bei der Einrichtung auf Suite-Ebene bereitgestellt und von allen Modulen der Suite gemeinsam genutzt. Dies ermöglicht eine einzelne Einrichtung der Suite auf oberster Ebene, um alle Module der Suite auszuführen.
Anstatt beispielsweise jedes Modul der Kompatibilitätstest-Suite (CTS) einzeln die Geräteinformationen, -typen usw. abzufragen, wird die Einrichtung auf Ebene der CTS-Suite (cts.xml) einmal durchgeführt 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 bei der regulären Tradefed-Konfiguration: die IBuildReceiver-Schnittstelle implementieren, um die IBuildInfo zu empfangen. 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 mit dem Modul getestet werden soll. Sie hat keine direkten Auswirkungen auf die Testausführung und wird hauptsächlich zu organisatorischen Zwecken verwendet.
Eine aktuelle Liste der zulässigen Komponenten für CTS finden Sie unter CtsConfigLoadingTest. Dieser Test schlägt in der Vorabprüfung fehl, wenn einem CTS-Modul eine nicht vorhandene Komponente hinzugefügt wird.
Mit module-metadata-include-filter und module-metadata-exclude-filter können Sie einen Suite-Lauf nach den Komponenten filtern.
Beispiel:
--module-metadata-include-filter component framework
In diesem Beispiel wird nur das Testmodul ausgeführt, das mit der framework-Komponente kommentiert ist.
Parameter
Die parameter-Metadaten dienen nur Informationszwecken und wirken sich auf die Testausführung aus. Hier wird angegeben, auf welchen Android-Modus sich das Testmodul bezieht.
In diesem Fall sind Modi auf Android-Modi auf hoher Ebene wie instant apps, secondary users oder different abis beschränkt.
Wenn der Modus während der Ausführung der Suite auf den Test angewendet wird, werden je nach Modus mehrere Varianten des Testmoduls erstellt. Mit jeder Variante werden ähnliche Tests durchgeführt, jedoch in unterschiedlichen Modi.
instant_app: Erstellen Sie eine Variante der Tests, bei der APKs als Instant-Apps installiert werden.multi_abi: Erstellen Sie eine Variante der Tests für jede vom Gerät unterstützte ABI.secondary_user: Erstellen Sie eine Variante der Tests, bei der APKs installiert und Tests als sekundärer Nutzer ausgeführt werden.
Messwerterfassung und Nachverarbeitung 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 Messwert-Collectors und Nachbearbeiter auf Modulebene können modulspezifisch sein.
Es wird nicht empfohlen, Postprozessoren sowohl auf oberster Ebene als auch auf Modulebene anzugeben.
Eine Leistungstestmodulkonfiguration muss die test-type-Metadaten mit dem Wert performance enthalten, z. B.:
xml
<option name="config-descriptor:metadata" key="test-type" value="performance" />
Wenn eine Testkonfiguration metric_collector enthält, das nicht FilePullerLogCollector oder metric_post_processor ist, schlägt der Test vor dem Einreichen fehl.
Beispielkonfiguration für das 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>