Eine Suite in Tradefed bezieht sich auf eine Einrichtung, in der mehrere Tests unter einem der die gesamte Ausführung steuert.
In Tradefed werden die Suiten
ITestSuite
, mit der Tests unabhängig von ihrer Art hinzugefügt und entfernt werden können.
ausführen.
Definitionen
- Suite: Eine Gruppe von Testmodulen, die so konfiguriert sind, dass sie unter einer ähnlichen Konfiguration auf oberster Ebene ausgeführt werden, um ihre Ergebnisse bei einer einzigen Aufrufung zu erfassen.
- 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. Diese werden auch als modulspezifische Konfigurationen bezeichnet.
- Modulkonfiguration: Bezieht sich auf die gehandelte XML-Datei von
AndroidTest.xml
Konfiguration, die die Module beschreibt und welche Einrichtung auf Modulebene sollte erledigt werden. - 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. Es ist
die von allen großen Testsuites verwendet werden, insbesondere dem Android-Kompatibilitätstest
Suite (CTS) und Android Vendor Test Suite
(VTS) und sorgt für eine einheitliche Ausführung
in allen Suiten.
ITestSuite wird manchmal auch 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:
- Einrichtung auf Modulebene ausführen.
- Modultests ausführen.
- Führen Sie einen Teardown auf Modulebene aus.
Melden Sie die Ergebnisse.
Einrichtung auf oberster Ebene
Aus Tradefed-Sicht ist ITestSuite
nur ein weiterer Test. Er ist komplex, aber im Grunde ist es nur ein Test wie jeder andere IRemoteTest
. Wenn Sie also
Suite-Runner in einer Tradefed-Konfiguration zu verwenden,
Muster der Konfiguration: build_provider
wird ausgeführt, target_preparer
, Test
(in diesem Fall unsere Suite) und target_cleaner
.
Diese Sequenz in der Tradefed-Konfiguration mit der ITestSuite
ist die
auf oberster Ebene.
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 Code 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>
Modul parametrisiert
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.
Für die Parametrisierung muss sie in der Befehlszeile aktiviert werden. durch:
--enable-parameterized-modules
Es ist auch möglich, einen bestimmten Modus mit folgenden Methoden 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
.