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>