Eine Suite in Tradefed bezieht sich auf eine Konfiguration, bei der mehrere Tests unter einem gemeinsamen Test-Runner ausgeführt werden, der die Gesamtausführung steuert.
In Tradefed werden Suites über die Klasse ITestSuite gesteuert, mit der Tests unabhängig von ihrer Ausführung hinzugefügt und entfernt werden können.
Definitionen
- Suite: Eine Gruppe von Testmodulen, die so konfiguriert sind, dass sie unter einer ähnlichen Einrichtung auf oberster Ebene ausgeführt werden, um ihre Ergebnisse in einem einzigen Aufruf zu melden.
- Einrichtung auf oberster Ebene: Die Einrichtung wird auf die Geräte angewendet, bevor die Testmodule ausgeführt werden.
- Hauptkonfiguration: Die Tradefed-XML-Konfiguration auf Suite-Ebene, die beschreibt, welche Module ausgeführt und welche übergeordnete Einrichtung verwendet werden soll.
- Einrichtung auf Modulebene: Die Einrichtung wird direkt vor dem Ausführen des Moduls auf den Geräten angewendet. Diese werden auch als modulspezifische Konfigurationen bezeichnet.
- Modulkonfiguration: Bezieht sich auf die
AndroidTest.xml-Tradefed-XML-Konfiguration, die die Module beschreibt und die Einrichtung auf Modulebene angibt. - Modul: Testeinheit, die aus einem Einrichtungsschritt (Einrichtung auf Modulebene), einem Testausführungsschritt und einem Rückbauschritt besteht.
- Wiederholung innerhalb des Moduls: Automatische Wiederholung durch das Netzwerk innerhalb des Moduls.
- Suite-Wiederholung: Die zuvor fehlgeschlagenen Tests der Suite werden vollständig wiederholt.
ITestSuite-Struktur
ITestSuite in Tradefed bezieht sich auf die gemeinsame Basisklasse, die die Ausführung einer Suite steuert. Sie wird von allen wichtigen Testsuites verwendet, insbesondere von der Android Compatibility Test Suite (CTS) und der Android Vendor Test Suite (VTS), und sorgt für eine einheitliche Ausführung in allen Suites.
ITestSuite wird manchmal als Suite Runner bezeichnet.
Der Suite-Runner führt bei der Ausführung die folgenden Schritte aus:
- Laden Sie die Konfiguration des Moduls und bestimmen Sie, welcher Satz ausgeführt werden soll.
Führen Sie jedes Modul aus:
- Führen Sie die Einrichtung auf Modulebene aus.
- Modultests ausführen
- Führen Sie einen Teardown auf Modulebene aus.
Melden Sie die Ergebnisse.
Einrichtung auf oberster Ebene
Aus Sicht von Tradefed ist ITestSuite nur ein weiterer Test. Er ist komplex, aber im Grunde ist es nur ein Test wie jeder andere IRemoteTest. Wenn Sie also den Suite-Runner in einer Tradefed-Konfiguration angeben, folgt Tradefed dem üblichen Muster der Konfiguration: build_provider, target_preparer, Test (unsere Suite in diesem Fall) und target_cleaner werden ausgeführt.
Diese Sequenz in der Tradefed-Konfiguration mit der ITestSuite ist die oberste Ebene der Einrichtung.
Beispiel:
<configuration description="Common config for Compatibility suites">
<build_provider class="com.android.compatibility.common.tradefed.build.CompatibilityBuildProvider" />
<!-- Setup applied before the suite: so everything running in the suite will
have this setup beforehand -->
<target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
<option name="run-command" value="settings put global package_verifier_enable 0" />
<option name="teardown-command" value="settings put global package_verifier_enable 1"/>
</target_preparer>
<!-- Our ITestSuite implementation -->
<test class="com.android.compatibility.common.tradefed.testtype.suite.CompatibilityTestSuite" />
<result_reporter class="com.android.compatibility.common.tradefed.result.ConsoleReporter" />
</configuration>
Modulmetadaten
Als Modulmetadaten bezeichnen wir zusätzliche Informationen, die im Testmodul AndroidTest.xml angegeben sind. Mit diesen Metadaten können Sie zusätzliche Informationen zum Modul angeben. Außerdem können Module anhand der Metadaten gefiltert werden.
Beispielmetadaten:
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
Beispiel für einen Filter nach Metadaten:
--module-metadata-include-filter component=framework
Der obige Code würde alle Module mit einem Framework als Komponentenmetadaten ausführen.
Vollständiges AndroidTest.xml-Beispiel:
<configuration description="Config for CTS Gesture test cases">
<option name="test-suite-tag" value="cts" />
<!-- Metadata -->
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
<!-- End: metadata -->
<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>
Parametrisiertes Modul
Ein spezieller Metadatentyp ist parameter.
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
Diese Metadaten geben an, dass das Modul in einem anderen Modus ausgeführt werden muss, z. B. als Instant-App anstelle eines Standard-App-Modus.
Alle möglichen Modi oder Parameter werden von ModuleParameters beschrieben und haben einen zugehörigen Handler in ModuleParametersHelper, mit dem Sie die Modulkonfiguration so ändern können, dass sie im jeweiligen Modus ausgeführt wird.
Im Instant App-Modus wird beispielsweise die APK-Installation im Instant App-Modus erzwungen.
Damit die Parameterisierung erfolgen kann, muss sie in der Befehlszeile mit folgendem Befehl aktiviert werden:
--enable-parameterized-modules
Es ist auch möglich, einen bestimmten Modus mit folgenden Befehlen auszuführen:
--enable-parameterized-modules --module-parameter <Mode>
--enable-parameterized-modules --module-parameter INSTANT_APP
Wenn eine parametrisierte Version eines Moduls ausgeführt wird, werden die Ergebnisse unter einem parametrisierten Modulnamen erfasst, z. B. CtsGestureTestCases[instant] im Vergleich zur Basis CtsGestureTestCases.