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 eines der Testmodule ausgeführt wird.
- 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. Sie 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 eine Suite-Ausführung steuert. Sie wird von allen großen Testsuiten gemeinsam genutzt, insbesondere der Android Compatibility Test Suite (CTS) und der Android Vendor Test Suite (VTS), und sorgt für eine einheitliche Ausführung in allen Suiten.
ITestSuite wird manchmal als Suite Runner bezeichnet.
Der Suite Runner führt bei der Ausführung folgende Schritte aus:
- Laden Sie die Konfiguration des Moduls und legen Sie fest, 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.
Beispiel für Metadaten:
<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
Mit dem obigen Befehl werden alle Module mit framework als component-Metadaten ausgeführt.
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.
Der Instant-App-Modus erzwingt beispielsweise die APK-Installation als Instant-Modus.
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
.