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
AndroidTest.xml oder allgemeiner die Modulkonfiguration darf nur die folgenden XML-Tags enthalten: target_preparer, multi_target_preparer, test und metrics_collector.
Diese Liste mag zwar restriktiv erscheinen, aber sie ermöglicht es Ihnen, die Anforderungen an die Einrichtung des Testmoduls und den durchzufü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 eine ConfigurationException aus, wenn versucht wird, sie innerhalb einer Modulkonfiguration auszuführen. So soll verhindert werden, dass diese Objekte tatsächlich eine Aufgabe innerhalb eines Moduls ausführen.
Beispiel für eine 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. Dabei wird eine Instrumentierung für das android.gesture.cts-Paket ausgeführt.
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 Ort belassen
möchten sie automatisch wiederherstellen.
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 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 dass jedes CTS-Modul (Compatibility Test Suite) die Geräteinformationen, -typen usw. einzeln abfragt, geschieht dies bei der Einrichtung auf CTS-Suite-Ebene (cts.xml) einmal. Jedes Modul erhält diese Informationen dann auf Anfrage.
Damit die Objekte in einem Modul die Build-Informationen erhalten, müssen sie
genauso wie bei der normalen 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 mit dem Modul getestet werden soll. Sie hat keine direkten Auswirkungen auf die Testausführung. es ist
in erster Linie für organisatorische Zwecke verwendet werden.
Eine aktuelle Liste der zulässigen Komponenten für CTS finden Sie unter CtsConfigLoadingTest. Dieser Test schlägt beim Vorabsenden fehl, wenn einer nicht vorhandenen Komponente CTS-Modul.
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 mit dem framework annotierte Testmodul ausgeführt.
Komponente.
Parameter
Die parameter-Metadaten sind informativ 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. Für jede Variante werden ähnliche Tests, aber in verschiedenen Modi ausgeführt.
instant_app: Erstelle eine Variante der Tests, bei denen APKs installiert werden als Instant-Apps.multi_abi: Erstellen Sie eine Variante der Tests für jede vom Gerät unterstützte ABI.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 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.
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>