Testvorlagen

AOSP enthält Testvorlagen für Testmodule, die keine hostseitige Python-Unterklasse von BaseTest des VTS-Runners sind.

Mithilfe dieser Vorlagen können Entwickler den Aufwand für die Integration solcher Tests minimieren. Dieser Abschnitt behandelt die Konfiguration und Verwendung der Testvorlagen (im VTS-Verzeichnis testcases/template ) und enthält Beispiele für häufig verwendete Vorlagen.

BinaryTest-Vorlage

Verwenden Sie die BinaryTest-Vorlage, um Tests, die auf dem Zielgerät ausgeführt werden, in VTS zu integrieren. Zielseitige Tests umfassen:

• C++- basierte Tests werden kompiliert und auf das Gerät übertragen
• Als Binärdateien kompilierte zielseitige Python- Tests
• Auf Geräten ausführbare Shell-Skripte

Diese Tests können mit oder ohne die BinaryTest-Vorlage in VTS integriert werden.

Integrieren Sie zielseitige Tests mit der BinaryTest-Vorlage

Die BinaryTest-Vorlage soll Entwicklern dabei helfen, zielseitige Tests einfach zu integrieren. In den meisten Fällen können Sie in AndroidTest.xml ein paar einfache Konfigurationszeilen hinzufügen. Beispielkonfiguration von VtsDeviceTreeEarlyMountTest :

<configuration description="Config for VTS VtsDeviceTreeEarlyMountTest.">
  ...
<test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
<option name="test-module-name" value="VtsDeviceTreeEarlyMountTest"/>
<option name="binary-test-source" value="_32bit::DATA/nativetest/dt_early_mount_test/dt_early_mount_test" />
<option name="binary-test-source" value="_64bit::DATA/nativetest64/dt_early_mount_test/dt_early_mount_test" />
<option name="test-timeout" value="5m"/>
</test>
</configuration>

In dieser Konfiguration:

• binary-test-source und binary-test-type sind vorlagenspezifisch.
• Durch die Angabe des relativen Hostpfads der Testbinärquelle kann die Vorlage Vorbereitung, Dateiübertragung, Testausführung, Ergebnisanalyse und Bereinigung durchführen.
• Die Vorlage enthält Methoden zur Testfallerstellung, die von Unterklassen überschrieben werden können.
• Die Vorlage geht von einem Testfall pro Testbinärmodul aus und der Name der binären Quelldatei wird standardmäßig als Testfallname verwendet.

Einstellmöglichkeiten

Die BinaryTest-Vorlage unterstützt die folgenden Konfigurationsoptionen:

Für Optionen mit Werttyp strings können Sie mehrere Werte hinzufügen, indem Sie die Optionen in der Konfiguration wiederholen. Legen Sie beispielsweise binary-test-source zweimal fest (wie im Beispiel VtsDeviceTreeEarlyMountTest gezeigt).

Test-Tags

Sie können Test-Tags hinzufügen, indem Sie ihnen Optionen mit strings voranstellen und :: als Trennzeichen verwenden. Test-Tags sind besonders nützlich, wenn Binärquellen mit demselben Namen, aber unterschiedlicher Bitzahl oder übergeordneten Verzeichnissen einbezogen werden. Um beispielsweise Datei-Push oder Ergebnisnamenkonflikte für Quellen mit demselben Namen, aber aus unterschiedlichen Quellverzeichnissen zu vermeiden, können Sie für diese Quellen unterschiedliche Tags angeben.

Wie im VtsDeviceTreeEarlyMountTest Beispiel mit den beiden dt_early_mount_test Quellen gezeigt, sind die Test-Tags die Präfixe _32bit:: und _64bit:: auf binary-test-source . Tags, die mit 32bit oder 64bit enden, markieren die Tests automatisch als verfügbar für eine ABI-Bitstufe; Dh Tests mit dem Tag _32bit werden auf 64-Bit-ABI nicht ausgeführt. Das Nichtangeben eines Tags ist gleichbedeutend mit der Verwendung eines Tags mit einer leeren Zeichenfolge.

Optionen mit denselben Tags werden gruppiert und von anderen Tags isoliert. Beispielsweise wird binary-test-args mit dem Tag _32bit nur auf binary-test-source mit demselben Tag angewendet und im binary-test-working-directory mit demselben Tag ausgeführt. Die Option binary-test-working-directory ist für Binärtests optional und ermöglicht Ihnen die Angabe eines einzelnen Arbeitsverzeichnisses für ein Tag. Wenn die Option binary-test-working-directory nicht angegeben wird, werden für jedes Tag Standardverzeichnisse verwendet.

Der Tag-Name wird im Ergebnisbericht direkt an den Testfallnamen angehängt. Beispielsweise wird der Testfall testcase1 mit dem Tag _32bit im Ergebnisbericht als testcase1_32bit angezeigt.

Integrieren Sie zielseitige Tests ohne BinaryTest-Vorlage

In VTS ist das Standardtestformat hostseitige Python-Tests, die von BaseTest im VTS-Runner erweitert werden. Um zielseitige Tests zu integrieren, müssen Sie zunächst die Testdateien auf das Gerät übertragen, die Tests mit Shell-Befehlen ausführen und dann die Ergebnisse mit hostseitigen Python-Skripten analysieren.

Push-Test-Binärdateien

Wir empfehlen, Dateien mit VtsFilePusher Zielvorbereiter zu übertragen. Beispiel:

<target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher">
        <option name="push" value="DATA/test->/data/local/tmp/test"/>
    </target_preparer>

Der VtsFilePusher führt Folgendes aus:

1. Überprüft die Gerätekonnektivität.
2. Bestimmt den absoluten Quelldateipfad.
3. Verschiebt die Dateien mit dem Befehl adb push .
4. Löscht die Dateien nach Abschluss der Tests.

Alternativ können Sie Dateien manuell mithilfe eines hostseitigen Python-Testskripts übertragen, das einem ähnlichen Verfahren folgt.

Führen Sie Tests durch

Nachdem Sie die Dateien auf das Gerät übertragen haben, führen Sie den Test mit Shell-Befehlen in einem hostseitigen Python-Testskript aus. Beispiel:

device = self.android_devices[0]
res = device.shell.Execute(["chmod a+x /data/local/tmp/test", "/data/local/tmp/test"])
asserts.AssertFalse(any(res[return_codes]))

GtestBinaryTest-Vorlage

Die GtestBinaryTest-Vorlage hostet GTest-Testbinärdateien, von denen jede normalerweise mehrere Testfälle enthält. Diese Vorlage erweitert die BinaryTest-Vorlage, indem sie Setup-, Testfallerstellungs- und Ergebnisanalysemethoden überschreibt, sodass alle BinaryTest-Konfigurationen geerbt werden.

GtestBinaryTest fügt die Option gtest-batch-mode hinzu:

Im Allgemeinen erhöht die Einstellung von gtest-batch-mode auf true die Leistung, während die Zuverlässigkeit leicht verringert wird. Bei VTS-Konformitätstests verwenden viele Module den Batch-Modus, um die Leistung zu verbessern. Aus Gründen der Zuverlässigkeit wird der Modus jedoch standardmäßig auf „Nicht-Batch“ eingestellt, wenn er nicht angegeben ist.

Nicht-Batch-Modus

Der Nicht-Batch-Modus führt für jeden Testfall individuelle Aufrufe der GTest-Binärdatei durch. Wenn die GTest-Binärdatei beispielsweise 10 Testfälle enthält (nach der Filterung durch hostseitige Konfiguration), wird die Binärdatei 10 Mal auf der Geräte-Shell aufgerufen, jedes Mal mit einem anderen Testfilter. Für jeden Testfall wird eine eindeutige GTest-Ergebnisausgabe-XML generiert und von der Vorlage analysiert.

Zu den Vorteilen der Verwendung des Nicht-Batch-Modus gehören:

• Testfallisolierung . Ein Absturz oder ein Hängenbleiben in einem Testfall hat keine Auswirkungen auf andere Testfälle.
• Die Granularität . Einfachere Erstellung von Profilen/Abdeckungsmessungen pro Testfall, Systrace, Bugreport, Logcat usw. Testergebnisse und Protokolle werden sofort nach Abschluss jedes Testfalls abgerufen.

Zu den Nachteilen der Verwendung des Nicht-Batch-Modus gehören:

• Redundantes Laden . Jedes Mal, wenn die GTest-Binärdatei aufgerufen wird, lädt sie zugehörige Bibliotheken und führt erste Klassen-Setups durch.
• Kommunikationsaufwand . Nach Abschluss eines Tests kommunizieren Host und Zielgerät für die Ergebnisanalyse und die nächsten Befehle (zukünftige Optimierungen möglich).

Batch-Modus

Im GTest-Batch-Modus wird die Testbinärdatei nur einmal mit einem langen Testfilterwert aufgerufen, der alle durch die hostseitige Konfiguration gefilterten Testfälle enthält (dies vermeidet das Problem des redundanten Ladens im Nicht-Batch-Modus). Sie können Testergebnisse für GTest mithilfe von „output.xml“ oder mithilfe der Terminalausgabe analysieren.

Bei Verwendung von „output.xml“ (Standard):

Wie im Nicht-Batch-Modus wird das Testergebnis über die GTest-Ausgabe-XML-Datei analysiert. Da die Ausgabe-XML jedoch nach Abschluss aller Tests generiert wird, wird keine Ergebnis-XML-Datei generiert, wenn ein Testfall die Binärdatei oder das Gerät zum Absturz bringt.

Bei Verwendung der Terminalausgabe:

Während GTest ausgeführt wird, druckt es das Testprotokoll und den Fortschritt in einem Format auf dem Terminal, das vom Framework auf Teststatus, Ergebnisse und Protokolle analysiert werden kann.

Zu den Vorteilen der Verwendung des Batch-Modus gehören:

• Testfallisolierung . Bietet das gleiche Maß an Testfallisolation wie der Nicht-Batch-Modus, wenn das Framework die Binärdatei/das Gerät nach einem Absturz mit einem reduzierten Testfilter neu startet (ausgenommen abgeschlossene und abgestürzte Testfälle).
• Die Granularität . Bietet die gleiche Testfallgranularität wie der Nicht-Batch-Modus.

Zu den Nachteilen der Verwendung des Batch-Modus gehören:

• Wartungskosten . Wenn sich das GTest-Protokollierungsformat ändert, werden alle Tests unterbrochen.
• Verwirrung . Ein Testfall kann etwas Ähnliches wie das GTest-Fortschrittsformat ausgeben, was das Format verwirren kann.

Aufgrund dieser Nachteile haben wir die Option zur Verwendung der Befehlszeilenausgabe vorübergehend entfernt. Wir werden diese Option in Zukunft noch einmal in Betracht ziehen, um die Zuverlässigkeit dieser Funktion zu verbessern.

HostBinaryTest-Vorlage

Die HostBinaryTest-Vorlage enthält hostseitige ausführbare Dateien, die in anderen Verzeichnissen oder in Python-Skripten nicht vorhanden sind. Zu diesen Tests gehören:

• Kompilierte Testbinärdateien, die auf dem Host ausführbar sind
• Ausführbare Skripte in Shell, Python oder anderen Sprachen

Ein Beispiel ist der hostseitige Test der VTS Security SELinux-Richtlinie :

<configuration description="Config for VTS  Security SELinux policy host-side test cases">
    ...
    <test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
        <option name="test-module-name" value="VtsSecuritySelinuxPolicyHost"/>
        <option name="binary-test-source" value="out/host/linux-x86/bin/VtsSecuritySelinuxPolicyHostTest" />
        <option name="binary-test-type" value="host_binary_test"/>
    </test>
</configuration>

HostBinaryTest erweitert die BinaryTest-Vorlage nicht, verwendet jedoch ähnliche Testkonfigurationen. Im obigen Beispiel gibt die Option binary-test-source einen hostseitigen relativen Pfad zur ausführbaren Testdatei an, und binary-test-type ist host_binary_test . Ähnlich wie bei der BinaryTest-Vorlage wird standardmäßig der Binärdateiname als Testfallname verwendet.

Erweitern Sie bestehende Vorlagen

Sie können Vorlagen direkt in der Testkonfiguration verwenden, um Nicht-Python-Tests einzubinden, oder sie in einer Unterklasse erweitern, um bestimmte Testanforderungen zu erfüllen. Vorlagen im VTS-Repo haben die folgenden Erweiterungen:

Entwicklern wird empfohlen, jede vorhandene Vorlage für spezifische Testanforderungen zu erweitern. Häufige Gründe für die Erweiterung von Vorlagen sind:

• Spezielle Testaufbauverfahren, z. B. Vorbereiten eines Geräts mit speziellen Befehlen.
• Generierung verschiedener Testfälle und Testnamen.
• Analysieren von Ergebnissen durch Lesen der Befehlsausgabe oder Verwenden anderer Bedingungen.

Um die Erweiterung bestehender Vorlagen zu erleichtern, enthalten die Vorlagen auf die einzelnen Funktionen spezialisierte Methoden. Wenn Sie verbesserte Designs für vorhandene Vorlagen haben, empfehlen wir Ihnen, zur VTS-Codebasis beizutragen.