Testvorlagen

AOSP enthält Testvorlagen für Testmodule, die kein Python auf Hostseite sind der VTS-Runner-BaseTest-Klasse.

Entwickelnde können diese Vorlagen verwenden, um den Aufwand die Integration solcher Tests. In diesem Abschnitt geht es um das Konfigurieren und Verwenden des Vorlagen (in der VTS) Testfälle/Vorlage Verzeichnis) und enthält Beispiele für häufig verwendete Vorlagen.

BinaryTest-Vorlage

Verwenden Sie die Methode Binärtest , um Tests zu integrieren, die auf dem Zielgerät in VTS ausgeführt werden. Zielseitige Tests umfassen:

• C++-basierte Tests, kompiliert und auf das Gerät übertragen
• Als Binärprogramme kompilierte Python-Tests auf Zielseite
• Ausführbare Shell-Scripts auf Geräten

Diese Tests können mit oder ohne „BinaryTest“ in VTS eingebunden werden Vorlage.

Integrieren Sie zielseitige Tests mit BinaryTest-Vorlage

Die BinaryTest-Vorlage soll Entwicklern dabei helfen, zielseitigen Tests. In den meisten Fällen können Sie ein paar Konfiguration in AndroidTest.xml. Konfigurationsbeispiel 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 gilt:

• binary-test-source und binary-test-type sind vorlagenspezifisch sind.
• Wenn Sie den relativen Hostpfad der binären Testquelle angeben, wird die Vorlage aktiviert für die Vorbereitung, das Senden von Dateien, Testausführungen, das Parsen von Ergebnissen bereinigt werden.
• Die Vorlage enthält Methoden zum Erstellen von Testläufen für Unterklassen für überschreiben.
• In der Vorlage wird von einem Testfall pro binärem Testmodul und dem Binärprogramm ausgegangen. Der Name der Quelldatei wird standardmäßig als Name für den Testlauf verwendet.

Konfigurationsoptionen

Die BinaryTest-Vorlage unterstützt die folgenden Konfigurationsoptionen:

Optionsname	Werttyp	Beschreibung
binary-test-source	Zeichenfolgen	Quellpfade für binäre Tests relativ zum vTS-Testfallverzeichnis ein Host. Beispiel: DATA/nativetest/test
binary-test-working-directory	Zeichenfolgen	Arbeitsverzeichnisse (geräteseitiger Pfad). Beispiel: /data/local/tmp/testing/
binary-test-envp	Zeichenfolgen	Umgebungsvariablen für Binärcode. Beispiel: PATH=/new:$PATH
binary-test-args	Zeichenfolgen	Testen Sie Argumente oder Flags. Beispiel: --gtest_filter=test1
binary-test-ld-library-path	Zeichenfolgen	LD_LIBRARY_PATH. Beispiel: /data/local/tmp/lib
binary-test-disable-framework	boolean	Führen Sie adb stop aus, um das Android-Framework vor dem Test zu deaktivieren. Beispiel: true
binary-test-stop-native-server	boolean	Halten Sie während des Tests alle ordnungsgemäß konfigurierten nativen Server an. Beispiel: true
Binärtesttyp	string	Vorlagentyp. Andere Vorlagentypen stammen aus dieser Vorlage, aber Sie Sie müssen diese Option für diese Vorlage nicht angeben, angegeben: binary-test-source.

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

Tags testen

Sie können Test-Tags hinzufügen, indem Sie ihnen strings voranstellen und :: als Trennzeichen verwenden. Test-Tags eignen sich besonders nützlich, wenn binäre Quellen mit demselben Namen, aber unterschiedlichen Bitness oder übergeordnete Verzeichnisse ein. Um beispielsweise Dateiübertragungen oder Ergebnisnamen zu vermeiden mehrere Quellen mit demselben Namen, aus unterschiedlichen Quellverzeichnissen, können Sie verschiedene Tags für diese Quellen angeben.

Wie im Beispiel VtsDeviceTreeEarlyMountTest mit dem Parameter aus zwei dt_early_mount_test-Quellen besteht, sind die Test-Tags die Präfixe _32bit:: und _64bit:: aktiviert binary-test-source Tags mit der Endung 32bit oder 64bit kennzeichnet die Tests automatisch als für eine ABI-Bitness verfügbar. Das heißt, Tests mit dem Tag _32bit werden nicht auf 64-Bit-ABIs ausgeführt. Nicht Angeben eines Tags ist gleichbedeutend mit der Verwendung eines Tags mit einem leeren String.

Optionen mit denselben Tags werden gruppiert und von anderen Tags isoliert. Für Beispiel: binary-test-args mit dem Tag _32bit ist wird nur auf binary-test-source mit demselben Tag angewendet und ausgeführt in binary-test-working-directory mit demselben Tag. Die Die Option binary-test-working-directory ist für binäre Tests optional. mit dem Sie ein einziges Arbeitsverzeichnis für ein Tag angeben können. Wenn der Parameter Option „binary-test-working-directory“ wurde nicht angegeben, Standardeinstellung Verzeichnisse für jedes Tag verwendet werden.

Der Tag-Name wird direkt an den Namen des Testlaufs im Ergebnisbericht angehängt. Beispiel: Testfall testcase1 mit dem Tag _32bit erscheint im Ergebnisbericht als testcase1_32bit.

Zielseitige Tests integrieren, ohne BinaryTest-Vorlage

In VTS ist das Standardtestformat hostseitige Python-Tests, erweitert von BaseTest im VTS-Runner. Um zielseitige Tests zu integrieren, müssen Sie zuerst die Methode Testdateien auf dem Gerät, führen die Tests mit Shell-Befehlen aus und parsen die mit Python-Skripten auf Hostseite.

Push-Test-Binärprogramme

Wir empfehlen, Dateien mit dem Zielvorbereitungs-VtsFilePusher 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. Prüft die Geräteverbindung.
2. Bestimmt den absoluten Pfad der Quelldatei.
3. Sendet die Dateien mit dem Befehl adb push per Push.
4. Löscht die Dateien nach Abschluss der Tests.

Alternativ können Sie Dateien manuell mit einem hostseitigen Python-Test übertragen. Skript mit einem ähnlichen Verfahren.

Tests ausführen

Nachdem Sie die Dateien per Push auf das Gerät übertragen haben, führen Sie den Test mit Shell-Befehlen in einem für das Python-Testskript auf der Hostseite. 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, die jeweils Folgendes enthalten: mehrere Testläufe. Diese Vorlage erweitert die BinaryTest-Vorlage durch Überschreiben und Methoden zum Parsen von Ergebnissen, sodass alle BinaryTest- Konfigurationen übernommen werden.

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

Optionsname	Werttyp	Beschreibung
Binärtesttyp	string	Vorlagentyp. Verwendet den Wert gtest.
gtest-batch-mode	boolean	Führen Sie Gtest-Binärdateien im Batchmodus aus. Beispiel: true

Im Allgemeinen wird gtest-batch-mode auf true festgelegt. erhöht die Leistung und verringert die Zuverlässigkeit geringfügig. VTS-Compliance Tests verwenden, verwenden viele Module den Batchmodus, um die Leistung zu verbessern. Für mehr Zuverlässigkeit Wenn der Modus jedoch nicht angegeben ist, wird standardmäßig kein Batch verwendet.

Nicht-Batchmodus

Im Nicht-Batchmodus werden für jeden Testlauf einzelne Aufrufe an das GTest-Binärprogramm ausgeführt. Für Wenn die GTest-Binärdatei zehn Testfälle enthält (nach dem Filtern nach Host Nebenkonfiguration), wird das Binärprogramm jedes Mal 10-mal in der Geräte-Shell aufgerufen mit einem anderen Testfilter. Für jeden Testfall ein eindeutiges GTest-Ergebnis XML wird von der Vorlage generiert und geparst.

Die Verwendung des Nicht-Batch-Modus bietet unter anderem folgende Vorteile:

• Testlauf-Isolation. Ein Absturz oder Aufhängen in einem Testlauf nicht auf andere Testfälle aus.
• Detaillierungsgrad: Einfachere Profilerstellung/Abdeckung pro Testlauf Messung, Systrace, Fehlerbericht, Logcat usw. unmittelbar nach Abschluss eines Testlaufs abgerufen.

Die Verwendung des Nicht-Batch-Modus hat unter anderem folgende Nachteile:

• Redundantes Laden: Bei jedem Aufruf der GTest-Binärdatei zusammengehörige Bibliotheken geladen und erste Klasseneinrichtungen vorgenommen.
• Kommunikationsaufwand: Nach Abschluss eines Tests hat der Host und Zielgerät kommunizieren, um das Ergebnis-Parsing und die nächsten Befehle (zukünftig Optimierungen möglich).

Batchmodus

Im Batchmodus von GTest wird die Testbinärdatei mit einem langen Test nur einmal aufgerufen. Filterwert, der alle Testfälle enthält, gefiltert nach der hostseitigen Konfiguration (dieser vermeidet redundante Ladeprobleme im Nicht-Batchmodus). Sie können Test- Ergebnisse für GTest unter Verwendung von „output.xml“ oder mithilfe der Terminalausgabe.

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

Wie im Nicht-Batch-Modus wird das Testergebnis über die GTest-Ausgabe-XML geparst. -Datei. Da jedoch die XML-Ausgabe generiert wird, nachdem alle Tests abgeschlossen, wenn die Binärdatei oder die XML-Datei ohne Ergebnis durch einen Testfall abgestürzt ist generiert.

Bei Verwendung einer Terminalausgabe:

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

Der Batchmodus bietet unter anderem folgende Vorteile:

• Testlauf-Isolation. Bietet dasselbe Testniveau Case-Isolation als Nicht-Batchmodus, wenn das Framework die Binärdatei/das Gerät neu startet nach einem Absturz mit reduziertem Testfilter (ausgenommen abgeschlossene und abgestürzte Tests) Cases).
• Detaillierungsgrad: Bietet denselben Detaillierungsgrad für den Testfall wie Nicht-Batch-Modus.

Die Verwendung des Batchmodus hat unter anderem folgende Nachteile:

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

Aufgrund dieser Nachteile haben wir die Option zur Nutzung Befehlszeilenausgabe. Wir werden diese Option in Zukunft noch einmal überarbeiten, um die Zuverlässigkeit dieser Funktion.

HostBinaryTest-Vorlage

Die Vorlage „HostBinaryTest“ enthält nicht vorhandene ausführbare Dateien auf Hostseite in anderen Verzeichnissen oder in Python-Skripts. Folgende Tests sind verfügbar:

• Ausführbare Testbinärdateien auf Host
• Ausführbare Skripts in Shell, Python oder anderen Sprachen

Ein Beispiel ist die VTS Hostseitiger Test der SELinux-Richtlinie für die Sicherheit:

<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 zu erstellen. Im obigen Beispiel entspricht der binary-test-source gibt auf Hostseite einen relativen Pfad zur ausführbaren Testdatei an und binary-test-type hat den Wert host_binary_test. Ähnlich wie BinaryTest-Vorlage verwendet, wird der binäre Dateiname von Standardeinstellung.

Vorhandene Vorlagen erweitern

Sie können Vorlagen direkt in der Testkonfiguration verwenden, um Nicht-Python-Tests einzubeziehen oder in einer Unterklasse erweitern, um bestimmte Testanforderungen zu erfüllen. Vorlagen in Das VTS-Repository hat die folgenden Erweiterungen:

Entwicklern wird empfohlen, vorhandene Vorlagen um bestimmte Testanforderungen. Häufige Gründe für die Erweiterung von Vorlagen:

• Spezielle Testeinrichtungsverfahren, wie die Vorbereitung eines Geräts mit speziellen .
• Generieren verschiedener Testfälle und Testnamen
• Parsen von Ergebnissen durch Lesen der Befehlsausgabe oder Verwenden anderer Bedingungen.

Um vorhandene Vorlagen leichter zu erweitern, enthalten die Vorlagen Methoden die auf die einzelnen Funktionen spezialisiert sind. Wenn Sie die Designs für bestehende können Sie zur VTS-Codebasis beitragen.