Tests ausführen (Atest)

Atest ist ein Befehlszeilentool, mit dem Benutzer Android-Tests lokal erstellen, installieren und ausführen können, wodurch Testwiederholungen erheblich beschleunigt werden, ohne dass Kenntnisse über die Befehlszeilenoptionen des Trade Federation-Testgeschirrs erforderlich sind. Auf dieser Seite wird erläutert, wie Sie Atest zum Ausführen von Android-Tests verwenden.

Allgemeine Informationen zum Schreiben von Tests für Android finden Sie unter Android Platform Testing .

Informationen zur Gesamtstruktur von Atest finden Sie im Atest Developer Guide .

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

Um eine Funktion zu Atest hinzuzufügen, folgen Sie dem Atest-Entwickler-Workflow .

Richten Sie Ihre Umgebung ein

Befolgen Sie zum Einrichten Ihrer Atest-Umgebung die Anweisungen unter Einrichten der Umgebung , Auswählen eines Ziels und Erstellen des Codes .

Grundlegende Verwendung

Atest-Befehle haben das folgende Format:

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.

Möglichkeit	Lange Option	Beschreibung
-b	--build	Erstellt Testziele. (Standard)
-i	--install	Installiert Testartefakte (APKs) auf dem Gerät. (Standard)
-t	--test	Führt die Tests durch. (Standard)
-s	--serial	Führt die Tests auf dem angegebenen Gerät aus. Es kann jeweils ein Gerät getestet werden.
-d	--disable-teardown	Deaktiviert den Testabbau und die Bereinigung.
	--info	Zeigt die relevanten Informationen zu den angegebenen Zielen an und wird dann beendet.
	--dry-run	Führt einen Probelauf von Atest durch, ohne tatsächlich Tests zu erstellen, zu installieren oder auszuführen.
-m	--rebuild-module-info	Erzwingt eine Neuerstellung der Datei module-info.json .
-w	--wait-for-debugger	Wartet, bis der Debugger fertig ist, bevor er ausgeführt wird.
-v	--verbose	Zeigt die Protokollierung auf DEBUG-Ebene an.
	--iterations	Führt Tests in einer Schleife durch, bis die maximale Iteration erreicht ist. (Standardmäßig 10)
	--rerun-until-failure [COUNT=10]	Führt alle Tests erneut aus, bis ein Fehler auftritt oder die maximale Iteration erreicht ist. (Standardmäßig 10)
	--retry-any-failure [COUNT=10]	Führt fehlgeschlagene Tests erneut aus, bis sie bestanden wurden oder die maximale Iteration erreicht ist. (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]	Gibt benutzerdefinierte Argumente für die Testläufer an.
-a	--all-abi	Führt die Tests für alle verfügbaren Gerätearchitekturen aus.
	--host	Führt den Test vollständig auf dem Host ohne Gerät aus. Hinweis: Das Ausführen eines Hosttests, der ein Gerät mit --host erfordert, schlägt fehl.
	--history	Zeigt Testergebnisse in chronologischer Reihenfolge.
	--latest-result	Druckt das neueste Testergebnis.

Weitere Informationen zu -b , -i und -t finden Sie im Abschnitt „Schritte angeben: Erstellen, Installieren oder Ausführen“ .

Geben Sie Tests an

Um Tests auszuführen, geben Sie einen oder mehrere Tests mit einem der folgenden Bezeichner an:

• Modulname
• Modul:Klasse
• Klassenname
• Tradefed-Integrationstest
• Dateipfad
• Paketnamen

Trennen Sie Verweise auf mehrere Tests durch Leerzeichen, etwa so:

atest test-identifier-1 test-identifier-2

Modulname

Um ein gesamtes Testmodul auszuführen, verwenden Sie seinen Modulnamen. Geben Sie den Namen so ein, wie er in den Variablen LOCAL_MODULE oder LOCAL_PACKAGE_NAME in der Android.mk oder Android.bp Datei dieses Tests erscheint.

Beispiele:

atest FrameworksServicesTests
atest CtsVideoTestCases

Modul:Klasse

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

Beispiele:

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

Klassenname

Um eine einzelne Klasse auszuführen, ohne explizit einen Modulnamen anzugeben, verwenden Sie den Klassennamen.

Beispiele:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Tradefed-Integrationstest

Um Tests auszuführen, 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. Zum 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 die Ausführung sowohl modulbasierter Tests als auch integrationsbasierter Tests durch Eingabe des Pfads zu ihrer Testdatei oder ihrem Verzeichnis entsprechend. Es unterstützt auch die Ausführung einer einzelnen Klasse durch Angabe des Pfads zur Java-Datei der Klasse. Es werden sowohl relative als auch absolute Pfade unterstützt.

Führen Sie ein Modul aus

Die folgenden Beispiele zeigen zwei Möglichkeiten, das CtsVideoTestCases Modul mithilfe eines Dateipfads auszuführen.

Vom Android- repo-root ausführen:

atest cts/tests/video

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

    atest .

Führen Sie eine Testklasse durch

Das folgende Beispiel zeigt, wie eine bestimmte Klasse innerhalb des CtsVideoTestCases -Moduls mithilfe eines Dateipfads ausgeführt wird.

Aus dem Android- repo-root :

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

Führen Sie einen Integrationstest durch

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

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

Paketnamen

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

Beispiele:

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

Geben Sie die Schritte an: Erstellen, Installieren oder Ausführen

Verwenden Sie die Optionen -b , -i und -t , um anzugeben, 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 einen Test dazu zwingen, den Bereinigungs- oder Abbauschritt zu überspringen. Viele Tests, wie zum Beispiel CTS, bereinigen das Gerät, nachdem der Test ausgeführt wurde. Daher schlägt der Versuch, Ihren Test mit -t erneut auszuführen, ohne den Parameter --disable-teardown fehl. Verwenden Sie -d vor -t , um den Testbereinigungsschritt zu überspringen und iterativ zu testen.

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

Führen Sie bestimmte Methoden aus

Atest unterstützt die Ausführung bestimmter Methoden innerhalb einer Testklasse. Obwohl das gesamte Modul erstellt werden muss, verkürzt sich dadurch die Zeit, die zum Ausführen der Tests benötigt wird. Um bestimmte Methoden auszuführen, identifizieren Sie die Klasse mithilfe einer der unterstützten Möglichkeiten zur Identifizierung einer Klasse (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 diese 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 Möglichkeiten zum Ausführen einer einzelnen Methode, testFlagChange . Diese Beispiele werden der bloßen Verwendung des Klassennamens vorgezogen, da die Angabe des Moduls oder des Speicherorts der Java-Datei es Atest ermöglicht, den Test viel schneller zu finden.

Verwenden von Module:Class:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Aus dem Android- repo-root :

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

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

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors

Führen Sie mehrere Klassen durch

Um mehrere Klassen auszuführen, trennen Sie sie durch Leerzeichen auf die gleiche Weise wie beim Ausführen mehrerer Tests. Atest erstellt und führt Klassen effizient aus, sodass die Angabe einer Teilmenge von Klassen in einem Modul die Leistung gegenüber der Ausführung des gesamten Moduls verbessert.

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

atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests

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

atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest

Führen Sie GTest-Binärdateien aus

Atest kann GTest-Binärdateien ausführen. Verwenden Sie -a um diese Tests für alle verfügbaren Gerätearchitekturen auszuführen, in diesem Beispiel armeabi-v7a (ARM 32-Bit) und arm64-v8a (ARM 64-Bit).

Beispiel-Eingabetest:

atest -a libinput_tests inputflinger_tests

Um eine bestimmte GTest-Binärdatei zur Ausführung auszuwählen, verwenden Sie einen Doppelpunkt (:), um den Testnamen anzugeben, und ein Hashtag (#), um eine einzelne Methode näher anzugeben.

Zum Beispiel für die folgende Testdefinition:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

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

atest inputflinger_tests:InputDispatcherTest

Oder führen Sie einen einzelnen Test mit folgendem Befehl durch:

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Führen Sie Tests in TEST_MAPPING aus

Atest kann Tests in TEST_MAPPING Dateien ausführen.

Führen Sie Presubmit-Tests implizit aus

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

atest

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

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

Führen Sie eine angegebene Testgruppe aus

Die verfügbaren Testgruppen sind: presubmit (Standard), postsubmit , mainline-presubmit und all .

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

atest :postsubmit

Führen Sie Tests aller Gruppen in TEST_MAPPING-Dateien aus:

atest :all

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

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

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

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

Führen Sie Tests in Unterverzeichnissen aus

Standardmäßig sucht Atest nur nach Tests in TEST_MAPPING-Dateien aufwärts (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, diese Tests ebenfalls einzuschließen:

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

Führen Sie Tests in Iteration durch

Führen Sie Tests in Iteration aus, indem Sie das Argument --iterations übergeben. Unabhängig davon, ob der Test erfolgreich ist oder nicht, wiederholt Atest den Test, bis die maximale Iteration erreicht ist.

Beispiele:

Standardmäßig iteriert Atest zehnmal. Die Anzahl der Iterationen muss eine positive ganze Zahl sein.

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

Die folgenden Ansätze erleichtern die Erkennung von Flockentests:

Ansatz 1: Führen Sie alle Tests aus, bis ein Fehler auftritt oder die maximale Iteration erreicht ist.

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

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

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

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

Ansatz 2: Führen Sie nur fehlgeschlagene Tests aus, bis sie bestanden wurden 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 (Standardeinstellung) oder bis der Test erfolgreich ist.

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

• Beenden Sie die Ausführung des fehlgeschlagenen Tests, wenn er die 100. Runde besteht oder erreicht.

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

Führen Sie Tests für AVDs durch

Atest ist in der Lage, Tests für eine neu erstellte AVD durchzuführen. Führen Sie acloud create , um eine AVD zu erstellen und Artefakte zu erstellen. Verwenden Sie dann die folgenden Beispiele, um Ihre Tests auszuführen.

Starten Sie eine AVD und führen Sie Tests darauf durch:

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

Starten Sie eine AVD im Rahmen eines Testlaufs:

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

Für weitere Informationen führen Sie acloud create --help aus.

Übergeben Sie Optionen an das Modul

Atest ist in der Lage, Optionen an Testmodule zu übergeben. Um TradeFed-Befehlszeilenoptionen zu Ihrem Testlauf hinzuzufügen, verwenden Sie die folgende Struktur und stellen Sie sicher, dass Ihre benutzerdefinierten Argumente dem Format der Tradefed-Befehlszeilenoptionen entsprechen.

atest test-to-run -- [CUSTOM_ARGS]

Übergeben Sie Testmoduloptionen an Zielvorbereiter oder Testläufer, 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

Übergeben Sie Optionen an einen Runner-Typ oder eine Runner-Klasse:

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 Nur-Test-Optionen finden Sie unter Optionen an die Module übergeben .