Testvorlagen

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

Mit diesen Vorlagen können Entwickler den Aufwand für die Integration solcher Tests minimieren. In diesem Abschnitt erfahren Sie, wie Sie die Testvorlagen (im VTS-Verzeichnis testcases/template) konfigurieren und verwenden. Außerdem finden Sie Beispiele für häufig verwendete Vorlagen.

BinaryTest-Vorlage

Verwenden Sie die BinaryTest-Vorlage, um Tests zu integrieren, die auf dem Zielgerät in VTS ausgeführt werden. Zu den Zielseitentests gehören:

• C++-basierte Tests werden kompiliert und auf das Gerät übertragen.
• Zielseitige Python-Tests, die als Binärdateien kompiliert wurden
• Shell-Scripts, die auf Geräten ausgeführt werden können

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

Zielseitige Tests mit der BinaryTest-Vorlage einbinden

Die Vorlage „BinaryTest“ soll Entwicklern das Einbinden von serverseitigen Tests erleichtern. In den meisten Fällen reichen ein paar einfache Konfigurationszeilen in AndroidTest.xml aus. Beispielkonfiguration aus 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>

Bei dieser Konfiguration:

• binary-test-source und binary-test-type sind vorlagespezifisch.
• Wenn Sie den relativen Hostpfad der Test-Binärquelle angeben, kann die Vorlage die Vorbereitung, das Pushen von Dateien, die Testausführung, das Parsen von Ergebnissen und die Bereinigung verarbeiten.
• Die Vorlage enthält Methoden zum Erstellen von Testfällen, die von Unterklassen überschrieben werden können.
• Die Vorlage geht von einem Testfall pro Test-Binärmodul aus. Der Name der Binär-Quelldatei wird standardmäßig als Testfallname verwendet.

Konfigurationsoptionen

Die Vorlage „BinaryTest“ unterstützt die folgenden Konfigurationsoptionen:

Bei Optionen mit dem 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 für VtsDeviceTreeEarlyMountTest gezeigt).

Test-Tags

Sie können Test-Tags hinzufügen, indem Sie sie Optionen mit strings-Werten vorangestellt und :: als Trennzeichen verwenden. Test-Tags sind besonders nützlich, wenn binäre Quellen mit demselben Namen, aber unterschiedlicher Bitanzahl oder übergeordneten Verzeichnissen eingeschlossen werden. Wenn Sie beispielsweise Kollisionen beim Dateipush oder beim Ergebnisnamen für Quellen mit demselben Namen, aber aus verschiedenen Quellverzeichnissen vermeiden möchten, können Sie für diese Quellen unterschiedliche Tags angeben.

Wie im Beispiel VtsDeviceTreeEarlyMountTest mit den beiden dt_early_mount_test-Quellen zu sehen, sind die Test-Tags die Präfixe _32bit:: und _64bit:: auf binary-test-source. Tags, die auf 32bit oder 64bit enden, kennzeichnen die Tests automatisch als für eine ABI-Bitanzahl verfügbar. Das bedeutet, dass Tests mit dem Tag _32bit nicht auf einem 64-Bit-ABI ausgeführt werden. Wenn Sie kein Tag angeben, ist das dasselbe, als würden Sie ein Tag mit einem leeren String verwenden.

Optionen mit denselben Tags werden gruppiert und von anderen Tags getrennt. Beispiel: binary-test-args mit dem _32bit-Tag wird nur auf binary-test-source mit demselben Tag angewendet und in binary-test-working-directory mit demselben Tag ausgeführt. Die Option binary-test-working-directory ist für Binärtests optional. Sie können damit ein einzelnes Arbeitsverzeichnis für ein Tag angeben. 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. Beispiel: Testfall testcase1 mit dem Tag _32bit wird im Ergebnisbericht als testcase1_32bit angezeigt.

Zielseitige Tests ohne BinaryTest-Vorlage einbinden

In VTS ist das Standardtestformat hostseitige Python-Tests, die von BaseTest im VTS-Runner erweitert wurden. Wenn Sie zielseitige Tests integrieren möchten, müssen Sie zuerst die Testdateien auf das Gerät übertragen, die Tests mit Shell-Befehlen ausführen und dann die Ergebnisse mit hostseitigen Python-Scripts analysieren.

Push-Test-Binärdateien

Wir empfehlen, Dateien mit dem VtsFilePusher-Zielvorbereitungstool zu pushen. Beispiel:

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

Das VtsFilePusher führt Folgendes aus:

1. Prüft die Geräteverbindung.
2. Bestimmt den absoluten Pfad der Quelldatei.
3. Dateien werden mit dem Befehl adb push gesendet.
4. Die Dateien werden nach Abschluss der Tests gelöscht.

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

Tests ausführen

Nachdem Sie die Dateien auf das Gerät geschoben haben, führen Sie den Test mit Shell-Befehlen in einem hostseitigen Python-Testscript 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 beherbergt GTest-Testbinärdateien, die jeweils in der Regel mehrere Testfälle enthalten. Diese Vorlage erweitert die BinaryTest-Vorlage, indem die Methoden für die Einrichtung, das Erstellen von Testfällen und das Parsen von Ergebnissen überschrieben werden. Alle BinaryTest-Konfigurationen werden also übernommen.

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

Im Allgemeinen erhöht sich die Leistung, wenn Sie gtest-batch-mode auf true festlegen, während die Zuverlässigkeit leicht sinkt. Bei VTS-Compliance-Tests wird in vielen Modulen der Batch-Modus verwendet, um die Leistung zu verbessern. Aus Gründen der Zuverlässigkeit wird jedoch standardmäßig der Modus „Nicht-Batch“ verwendet, wenn der Modus nicht angegeben ist.

Modus ohne Batch-Datei

Im Nicht-Batch-Modus werden für jeden Testfall einzelne Aufrufe des GTest-Binärprogramms ausgeführt. Wenn die GTest-Binärdatei beispielsweise 10 Testfälle enthält (nach der Filterung nach der konfiguration auf Hostseite), wird die Binärdatei 10 Mal mit jeweils einem anderen Testfilter auf der Geräteshell aufgerufen. Für jeden Testfall wird eine eindeutige GTest-Ergebnisausgabe in XML generiert und von der Vorlage geparst.

Der Modus ohne Batch-Verarbeitung bietet folgende Vorteile:

• Testfallisolierung Ein Absturz oder eine Verzögerung in einem Testfall hat keine Auswirkungen auf andere Testfälle.
• Detaillierungsgrad Es ist einfacher, pro Testfall Profiling/Abdeckungsmessung, Systrace, Bugreport, Logcat usw. zu erhalten. Testergebnisse und Protokolle werden sofort nach Abschluss jedes Testfalls abgerufen.

Die Nachteile des Nicht-Batch-Modus:

• Redundantes Laden: Jedes Mal, wenn die GTest-Binärdatei aufgerufen wird, werden zugehörige Bibliotheken geladen und die ersten Klassen eingerichtet.
• Kommunikationsoverhead: Nach Abschluss eines Tests kommunizieren der Host und das Zielgerät zum Parsen der Ergebnisse und für die nächsten Befehle (zukünftige Optimierungen möglich).

Batch-Modus

Im GTest-Batchmodus wird das Test-Binary nur einmal mit einem langen Testfilterwert aufgerufen, der alle Testfälle enthält, die nach der hostseitigen Konfiguration gefiltert wurden. Dadurch wird das Problem des redundanten Ladens im Nicht-Batch-Modus vermieden. Sie können Testergebnisse für GTest mit „output.xml“ oder mit der Terminalausgabe parsen.

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

Wie im Nicht-Batch-Modus wird das Testergebnis über die GTest-Ausgabe-XML-Datei geparst. Da die Ausgabe-XML-Datei jedoch erst nach Abschluss aller Tests generiert wird, wird keine XML-Ergebnisdatei generiert, wenn ein Testfall zum Absturz der Binärdatei oder des Geräts geführt hat.

Bei der Verwendung der Terminalausgabe:

Während GTest ausgeführt wird, werden das Testprotokoll und der Fortschritt in einem Format an das Terminal ausgegeben, das vom Framework für Teststatus, Ergebnisse und Protokolle geparst werden kann.

Der Batch-Modus bietet folgende Vorteile:

• Testfallisolierung Bietet dieselbe Testfallisolierung wie im Nicht-Batch-Modus, wenn das Framework das Binary/Gerät nach einem Absturz mit einem reduzierten Testfilter neu startet (ausgenommen abgeschlossene und abgestürzte Testfälle).
• Detaillierungsgrad Bietet dieselbe Testfallgranularität wie im Modus ohne Batch.

Der Batchmodus hat folgende Nachteile:

• Wartungskosten Wenn sich das GTest-Protokollierungsformat ändert, funktionieren alle Tests nicht mehr.
• Verwirrung. Ein Testfall kann etwas Ähnliches wie das Fortschrittsformat von GTest drucken, 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 prüfen, um die Zuverlässigkeit dieser Funktion zu verbessern.

HostBinaryTest-Vorlage

Die HostBinaryTest-Vorlage enthält hostseitige ausführbare Dateien, die nicht in anderen Verzeichnissen oder in Python-Scripts vorhanden sind. Folgende Tests sind verfügbar:

• Kompilierte Test-Binärdateien, die auf dem Host ausführbar sind
• Ausführbare Scripts in Shell, Python oder anderen Sprachen

Ein Beispiel hierfür ist der VTS-Sicherheitstest für SELinux-Richtlinien auf Hostseite:

<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 aber ähnliche Testkonfigurationen. Im obigen Beispiel gibt die Option binary-test-source einen relativen Pfad auf der Hostseite zur ausführbaren Testdatei an und binary-test-type ist host_binary_test. Ähnlich wie bei der Vorlage „BinaryTest“ wird der Name der Binärdatei standardmäßig als Testfallname verwendet.

Vorhandene Vorlagen erweitern

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-Repository haben die folgenden Erweiterungen:

Entwickler können vorhandene Vorlagen für bestimmte Testanforderungen erweitern. Häufige Gründe für die Erweiterung von Vorlagen:

• Spezielle Testeinrichtungsverfahren, z. B. die Vorbereitung eines Geräts mit speziellen Befehlen.
• Erstellen verschiedener Testfälle und Testnamen
• Ergebnisse durch Lesen der Befehlsausgabe oder Verwendung anderer Bedingungen parsen

Damit bestehende Vorlagen leichter erweitert werden können, enthalten sie Methoden, die auf die einzelnen Funktionen spezialisiert sind. Wenn Sie Designs für vorhandene Vorlagen verbessert haben, können Sie zur VTS-Codebasis beitragen.