Tests ausführen (Atest)

Atest ist ein Befehlszeilentool, mit dem Nutzer Android-Tests lokal erstellen, installieren und ausführen können. Dadurch werden Wiederholungen von Tests erheblich beschleunigt, ohne dass Kenntnisse der Befehlszeilenoptionen des Trade Federation Test Harness erforderlich sind. Auf dieser Seite wird erläutert, wie Sie mit Atest Android-Tests ausführen.

Allgemeine Informationen zum Erstellen von Tests für Android finden Sie unter Tests für die Android-Plattform.

Informationen zur Gesamtstruktur von Atest finden Sie im Atest-Entwicklerleitfaden.

Informationen zum Ausführen von Tests in TEST_MAPPING-Dateien über Atest finden Sie unter Tests in TEST_MAPPING-Dateien ausführen.

Wenn Sie Atest eine Funktion hinzufügen möchten, folgen Sie dem Atest-Entwickler-Workflow.

Umgebung einrichten

Folgen Sie der Anleitung unter Umgebung einrichten, Ziel auswählen und Code erstellen, um die Atest-Umgebung einzurichten.

Grundlegende Nutzung

Atestbefehle haben folgende Form:

atest test-to-run [optional-arguments]

Optionale Argumente

In der folgenden Tabelle sind die am häufigsten verwendeten Argumente aufgeführt. Eine vollständige Liste finden Sie unter atest --help.

Option	Lange Option	Beschreibung
-b	--build	Erstellt Testziele. (Standard)
-i	--install	Installiert Testartefakte (APKs) auf dem Gerät. (Standard)
-t	--test	Führt die Tests aus. (Standard)
-s	--serial	Führt die Tests auf dem angegebenen Gerät aus. Es kann jeweils nur ein Gerät getestet werden.
-d	--disable-teardown	Deaktiviert das Auflösen und Bereinigen von Tests.
	--dry-run	Bei einem Trockenlauf werden keine Tests erstellt, installiert oder ausgeführt.
-m	--rebuild-module-info	Erzwingt einen Neuaufbau der module-info.json-Datei.
-w	--wait-for-debugger	Wartet vor der Ausführung auf den Abschluss des Debuggers.
-v	--verbose	Zeigt Protokolle auf DEBUG-Ebene an.
	--iterations	Bei Schleifen werden Tests ausgeführt, bis die maximale Iteration erreicht ist. (Standard: 10)
	--rerun-until-failure [COUNT=10]	Alle Tests werden wiederholt, bis ein Fehler auftritt oder die maximale Iteration erreicht ist. (Standard: 10)
	--retry-any-failure [COUNT=10]	Fehlgeschlagene Tests werden wiederholt, bis sie bestanden sind oder die maximale Iteration erreicht wird. (standardmäßig 10)
	--start-avd	Erstellt automatisch eine AVD und führt Tests auf dem virtuellen Gerät aus.
	--acloud-create	Erstellt eine AVD mit dem Befehl acloud.
	--[CUSTOM_ARGS]	Hier können Sie benutzerdefinierte Argumente für die Testläufer angeben.
-a	--all-abi	Die Tests werden für alle verfügbaren Gerätearchitekturen ausgeführt.
	--host	Der Test wird vollständig auf dem Host ohne Gerät ausgeführt. Hinweis: Wenn für einen Hosttest ein Gerät mit --host erforderlich ist, schlägt der Test fehl.
	--history	Testergebnisse werden in chronologischer Reihenfolge angezeigt.
	--latest-result	Das neueste Testergebnis wird ausgegeben.

Weitere Informationen zu -b, -i und -t finden Sie im Abschnitt Schritte angeben: erstellen, installieren oder ausführen.

Tests angeben

Geben Sie einen oder mehrere Tests mit einer der folgenden IDs an, um sie auszuführen:

• Modulname
• Modul:Klasse
• Kursname
• Tradefed-Integrationstest
• Dateipfad
• Paketname

Trennen Sie Verweise auf mehrere Tests durch Leerzeichen, z. B. so:

atest test-identifier-1 test-identifier-2

Modulname

Wenn Sie ein gesamtes Testmodul ausführen möchten, verwenden Sie den Modulnamen. Geben Sie den Namen so ein, wie er in den Variablen LOCAL_MODULE oder LOCAL_PACKAGE_NAME in der Datei Android.mk oder Android.bp dieses Tests angezeigt wird.

Beispiele:

atest FrameworksServicesTests
atest CtsVideoTestCases

Hinweis :Wenn Sie nicht in TradeFed (TF) integrierte Tests ausführen möchten, verwenden Sie stattdessen TF Integrationstest als Kennung.

Modul:Klasse

Wenn Sie eine einzelne Klasse innerhalb eines Moduls ausführen möchten, verwenden Sie Modul:Klasse. Modul entspricht der Beschreibung unter Modulname. Class ist der Name der Testklasse in der Datei .java. Dies kann der vollständig qualifizierte Klassenname oder der Basisname sein.

Beispiele:

atest CtsVideoTestCases:VideoEncoderDecoderTest
atest FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests

Hinweis :Um die Zeit zu verkürzen, die Atest benötigt, um den richtigen Test zu finden, empfehlen wir, den vollständigen Klassenpfad zu verwenden, wie im letzten Beispiel gezeigt.

Kursname

Wenn Sie eine einzelne Klasse ausführen möchten, ohne explizit einen Modulnamen anzugeben, verwenden Sie den Klassennamen.

Beispiele:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Hinweis: Um die Zeit zu verkürzen, die Atest benötigt, um den richtigen Test zu finden, empfehlen wir, nach Möglichkeit Modul:Klasse anstelle des Klassennamens zu verwenden.

Tradefed-Integrationstest

Wenn Sie Tests ausführen möchten, die direkt in TradeFed eingebunden sind (keine Module), geben Sie den Namen so ein, wie er in der Ausgabe des Befehls tradefed.sh list configs angezeigt wird. Beispiel:

So führen Sie den reboot.xml-Test aus:

atest example/reboot

So führen Sie den native-benchmark.xml-Test aus:

atest native-benchmark

Dateipfad

Atest unterstützt sowohl modulbasierte als auch integrationsbasierte Tests. Geben Sie dazu den Pfad zur Testdatei oder zum Testverzeichnis ein. Es unterstützt auch das Ausführen einer einzelnen Klasse, indem der Pfad zur Java-Datei der Klasse angegeben wird. Es werden sowohl relative als auch absolute Pfade unterstützt.

Modul ausführen

In den folgenden Beispielen wird gezeigt, wie Sie das CtsVideoTestCases-Modul mit einem Dateipfad ausführen.

Über Android repo-root ausführen:

atest cts/tests/video

Über Android repo-root/cts/tests/video ausführen:

    atest .

Testklasse ausführen

Im folgenden Beispiel wird gezeigt, wie eine bestimmte Klasse innerhalb des CtsVideoTestCases-Moduls mit einem Dateipfad ausgeführt wird.

Unter Android repo-root:

    atest cts/tests/video/src/android/video/cts/VideoEncoderDecoderTest.java

Integrationstest ausführen

Das folgende Beispiel zeigt, wie Sie einen Integrationstest mit einem Dateipfad aus Android repo-root ausführen:

    atest tools/tradefederation/contrib/res/config/example/reboot.xml

Paketname

Atest unterstützt die Suche nach Tests anhand des Paketnamens.

Beispiele:

    atest com.android.server.wm
    atest com.android.uibench.janktests

Schritte angeben: Build, Installieren oder Ausführen

Mit den Optionen -b, -i und -t können Sie angeben, welche Schritte ausgeführt werden sollen. Wenn Sie keine Option angeben, werden alle Schritte ausgeführt.

Hinweis :-b und -t können einzeln ausgeführt werden, -i jedoch nicht ohne -t.

• Nur Build-Ziele: atest -b test-to-run
• Nur Tests ausführen: atest -t test-to-run
• APK installieren und Tests ausführen: atest -it test-to-run
• Erstellen und ausführen, aber nicht installieren: atest -bt test-to-run

Mit Atest können Sie erzwingen, dass der Schritt „Bereinigung“ oder „Aufbau“ übersprungen wird. Bei vielen Tests, z. B. CTS, wird das Gerät nach dem Test bereinigt. Wenn Sie also versuchen, den Test mit -t noch einmal auszuführen, schlägt dies ohne den Parameter --disable-teardown fehl. Verwenden Sie -d vor -t, um den Schritt zur Bereinigung des Tests zu überspringen und iterativ zu testen.

atest -d test-to-run
atest -t test-to-run

Hinweis: Da -t sowohl die Einrichtung/Installation als auch die Deaktivierung/Bereinigung des Geräts deaktiviert, können Sie den Test mit atest -t test-to-run beliebig oft wiederholen.

Bestimmte Methoden ausführen

Atest unterstützt das Ausführen bestimmter Methoden innerhalb einer Testklasse. Das gesamte Modul muss zwar erstellt werden, aber die Zeit für die Ausführung der Tests wird dadurch verkürzt. Wenn Sie bestimmte Methoden ausführen möchten, identifizieren Sie die Klasse auf eine der unterstützten Arten (Modul:Klasse, Dateipfad usw.) und hängen Sie den Namen der Methode an:

atest reference-to-class#method1

Wenn Sie mehrere Methoden angeben, trennen Sie sie durch Kommas:

atest reference-to-class#method1,method2,method3

Beispiele:

atest com.android.server.wm.ScreenDecorWindowTests#testMultipleDecors
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval

Die folgenden beiden Beispiele zeigen die bevorzugten Methoden zum Ausführen einer einzelnen Methode, testFlagChange. Diese Beispiele sind vorzuziehen, da Atest den Test viel schneller finden kann, wenn das Modul oder der Speicherort der Java-Datei angegeben wird.

Verwendung von „Modul:Klasse“:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Unter Android repo-root:

atest frameworks/base/services/tests/wmtests/src/com/android/server/wm/ScreenDecorWindowTests.java#testFlagChange

Mehrere Methoden können aus verschiedenen Klassen und Modulen ausgeführt werden:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors

Mehrere Kurse ausführen

Wenn Sie mehrere Klassen ausführen möchten, trennen Sie sie wie beim Ausführen mehrerer Tests durch Leerzeichen. Atest erstellt und führt Klassen effizient aus. Wenn Sie also eine Teilmenge der Klassen in einem Modul angeben, wird die Leistung im Vergleich zum Ausführen des gesamten Moduls verbessert.

So führen Sie zwei Klassen im selben Modul aus:

atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests

So führen Sie zwei Klassen in verschiedenen Modulen aus:

atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest

GTest-Binärdateien ausführen

Atest kann GTest-Binärdateien ausführen. Mit -a können Sie diese Tests für alle verfügbaren Gerätearchitekturen ausführen. In diesem Beispiel sind das armeabi-v7a (ARM 32-Bit) und arm64-v8a (ARM 64-Bit).

Beispiel für einen Eingabetest:

atest -a libinput_tests inputflinger_tests

Hinweis :Wenn Sie nur Tests für eine bestimmte Gerätearchitektur ausführen möchten, verwenden Sie atest -- --abi arm64-v8a oder atest -- --abi armeabi-v7a.

Wenn Sie ein bestimmtes GTest-Binary ausführen möchten, geben Sie den Testnamen mit einem Doppelpunkt (:) und eine einzelne Methode mit einem Hashtag (#) an.

Beispiel für die folgende Testdefinition:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Führen Sie den folgenden Befehl aus, um den gesamten Test anzugeben:

atest inputflinger_tests:InputDispatcherTest

Sie können auch einen einzelnen Test mit dem folgenden Befehl ausführen:

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Tests in TEST_MAPPING ausführen

Mit Atest können Tests in TEST_MAPPING-Dateien ausgeführt werden.

Vorabtests implizit ausführen

Führen Sie Presubmit-Tests in TEST_MAPPING-Dateien im aktuellen und übergeordneten Verzeichnis aus:

atest

Presubmit-Tests in TEST_MAPPING-Dateien in /path/to/project und den übergeordneten Verzeichnissen ausführen:

atest --test-mapping /path/to/project

Eine bestimmte Testgruppe ausführen

Verfügbare Testgruppen sind presubmit(Standard), postsubmit, mainline-presubmit und all.

Führen Sie Post-Submit-Tests in TEST_MAPPING-Dateien im aktuellen und übergeordneten Verzeichnis aus:

atest :postsubmit

Tests aus allen Gruppen in TEST_MAPPING-Dateien ausführen:

atest :all

Führen Sie Post-Submit-Tests in TEST_MAPPING-Dateien in /path/to/project und den übergeordneten Verzeichnissen aus:

atest --test-mapping /path/to/project:postsubmit

Führen Sie Haupttests in TEST_MAPPING-Dateien in /path/to/project und den übergeordneten Verzeichnissen aus:

atest --test-mapping /path/to/project:mainline-presubmit

Tests in Unterverzeichnissen ausführen

Standardmäßig sucht Atest nur in TEST_MAPPING-Dateien nach oben (vom aktuellen oder angegebenen Verzeichnis bis zu den übergeordneten Verzeichnissen). Wenn Sie auch Tests in TEST_MAPPING-Dateien in den Unterverzeichnissen ausführen möchten, verwenden Sie --include-subdirs, um Atest zu zwingen, auch diese Tests einzubeziehen:

atest --include-subdirs /path/to/project

Tests in Iterationen ausführen

Wenn Sie Tests in einer Iteration ausführen möchten, geben Sie das Argument --iterations an. Unabhängig davon, ob der Test bestanden oder fehlgeschlagen ist, wiederholt Atest den Test, bis die maximale Iteration erreicht ist.

Beispiele:

Standardmäßig wird Atest zehnmal ausgeführt. Die Anzahl der Iterationen muss eine positive Ganzzahl sein.

atest test-to-run --iterations
atest test-to-run --iterations 5

Mit den folgenden Ansätzen lassen sich fehlerhafte Tests leichter erkennen:

Methode 1: Alle Tests ausführen, bis ein Fehler auftritt oder die maximale Iteration erreicht ist.

• Die Iteration wird beendet, wenn ein Fehler auftritt oder die 10. Runde (standardmäßig) erreicht wird.

  atest test-to-run --rerun-until-failure
  

• Beenden Sie die Iteration, wenn ein Fehler auftritt oder die 100. Runde erreicht wird.

  atest test-to-run --rerun-until-failure 100
  

Ansatz 2: Nur fehlgeschlagene Tests ausführen, bis sie bestanden sind oder die maximale Iteration erreicht wird.

• Angenommen, test-to-run hat mehrere Testfälle und einer der Tests schlägt fehl. Führen Sie den fehlgeschlagenen Test nur zehnmal (standardmäßig) oder so lange aus, bis er bestanden ist.

  atest test-to-run --retry-any-failure
  

• Beenden Sie den fehlgeschlagenen Test, wenn er erfolgreich ist oder die 100. Runde erreicht.

  atest test-to-run --retry-any-failure 100
  

Tests auf virtuellen Geräten ausführen

Mit Atest können Tests auf einer neu erstellten AVD ausgeführt werden. Führen Sie acloud create aus, um eine AVD zu erstellen und Artefakte zu erstellen, und verwenden Sie dann die folgenden Beispiele, um Ihre Tests auszuführen.

So starten Sie eine AVD und führen Tests darauf aus:

acloud create --local-instance --local-image && atest test-to-run

So starten Sie eine AVD im Rahmen eines Testlaufs:

atest test-to-run --acloud-create "--local-instance --local-image"

Weitere Informationen erhalten Sie durch Ausführung von acloud create --help.

Hinweis: --acloud-create muss das LETZTE optionale Argument sein. Alle nachfolgenden Argumente werden als Positionsargumente für die AVD behandelt.

Hinweis :Mit --acloud-create und --start-avd werden neu erstellte AVDs nicht gelöscht. Nutzer müssen sie manuell löschen.

Optionen an das Modul übergeben

Atest kann Optionen an Testmodule übergeben. Wenn Sie Ihrem Testlauf TradeFed-Befehlszeilenoptionen hinzufügen möchten, verwenden Sie die folgende Struktur und achten Sie darauf, dass Ihre benutzerdefinierten Argumente dem Format der TradeFed-Befehlszeilenoptionen entsprechen.

atest test-to-run -- [CUSTOM_ARGS]

Übergeben Sie Testmoduloptionen an Zielvorbereiter oder Testausführer, die in der Testkonfigurationsdatei definiert sind:

atest test-to-run -- --module-arg module-name:option-name:option-value
atest GtsPermissionTestCases -- --module-arg GtsPermissionTestCases:ignore-business-logic-failure:true

Optionen an einen Läufertyp oder eine Läuferklasse übergeben:

atest test-to-run -- --test-arg test-class:option-name:option-value
atest CtsVideoTestCases -- --test-arg com.android.tradefed.testtype.JarHosttest:collect-tests-only:true

Weitere Informationen zu Optionen, die nur für Tests gelten, finden Sie unter Optionen an die Module übergeben.