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 Schreiben von Tests für Android finden Sie unter Android-Plattformtests.

Informationen zur allgemeinen Struktur 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 zum Einrichten einer Atest-Umgebung der Anleitung unter Umgebung einrichten, Ziel auswählen und Code erstellen.

Grundlegende Nutzung

Atest-Befehle 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 ist über atest --help verfügbar.

Option	Lange Option	Beschreibung
-b	--build	Erstellt Testziele. (Standard)
-i	--install	Testartefakte (APKs) werden auf dem Gerät installiert. (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 Teardown und die Bereinigung.
	--dry-run	Bei einem Trockenlauf werden keine Tests erstellt, installiert oder ausgeführt.
-m	--rebuild-module-info	Erzwingt die Neuerstellung der Datei module-info.json.
-w	--wait-for-debugger	Wartet auf den Abschluss des Debuggers, bevor er ausgeführt wird.
-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 wird. (Standard: 10)
	--retry-any-failure [COUNT=10]	Fehlgeschlagene Tests werden wiederholt, bis sie bestanden sind oder die maximale Iteration erreicht wird. (Standard: 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 festlegen: 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

Modul:Klasse

Um eine einzelne Klasse innerhalb eines Moduls auszuführen, verwenden Sie Module:Class. Modul entspricht der Beschreibung unter Modulname. Klasse ist der Name der Testklasse in der Datei .java und kann der vollständig qualifizierte Klassenname oder der einfache Name sein.

Beispiele:

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

Kursname

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

Beispiele:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Tradefed-Integrationstest

Wenn Sie Tests ausführen möchten, die direkt in TradeFed integriert 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 werden zwei Möglichkeiten zum Ausführen des CtsVideoTestCases-Moduls mit einem Dateipfad gezeigt.

Über Android repo-root ausführen:

atest cts/tests/video

Unter 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 ein Integrationstest mit einem Dateipfad von Android repo-root ausgeführt wird:

    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: Erstellen, 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.

• 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

Atest kann erzwingen, dass bei einem Test der Bereinigungs- oder Bereinigungsschritt übersprungen wird. Bei vielen Tests, z. B. beim 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 den Test iterativ durchzuführen.

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

Bestimmte Methoden ausführen

Atest unterstützt das Ausführen bestimmter Methoden innerhalb einer Testklasse. Obwohl das gesamte Modul erstellt werden muss, reduziert sich dadurch die Zeit, die zum Ausführen der Tests benötigt wird. Wenn Sie bestimmte Methoden ausführen möchten, identifizieren Sie die Klasse mithilfe einer der unterstützten Methoden (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

Es können mehrere Methoden 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 bei mehreren Tests durch Leerzeichen. Atest erstellt und führt Klassen effizient aus. Wenn Sie also eine Teilmenge von 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

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 folgenden Befehl aus, um den gesamten Test anzugeben:

atest inputflinger_tests:InputDispatcherTest

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

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Tests in TEST_MAPPING ausführen

Atest kann Tests in TEST_MAPPING-Dateien ausführen.

Vorabtests implizit ausführen

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

atest

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

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

Eine bestimmte Testgruppe ausführen

Die verfügbaren Testgruppen sind: presubmit(Standardeinstellung), 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 postsubmit-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, wird er von Atest wiederholt, 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.

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

  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 ist.

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

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

• Beenden Sie den fehlgeschlagenen Test, wenn er bestanden wird oder die 100. Runde erreicht.

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

Tests auf AVDs 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, wenn Sie acloud create --help ausführen.

Optionen an Modul weitergeben

Atest kann Optionen an Testmodule übergeben. Verwenden Sie die folgende Struktur, um Ihrem Testlauf Befehlszeilenoptionen für TradeFed hinzuzufügen, und achten Sie darauf, dass Ihre benutzerdefinierten Argumente dem Format der Befehlszeilenoptionen von TradeFed 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 reinen Testoptionen findest du unter Optionen an die Module weitergeben.