Laufende Tests (Atest)

Atest ist ein Befehlszeilentool, das es Benutzern ermöglicht, Android-Tests lokal zu erstellen, zu installieren und auszuführen, wodurch Testwiederholungen erheblich beschleunigt werden, ohne dass Kenntnisse über die Befehlszeilenoptionen von 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 Testen der Android-Plattform .

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

Möglichkeit Lange Option Beschreibung
-b --build Erstellt Testziele. (Ursprünglich)
-i --install Installiert Testartefakte (APKs) auf dem Gerät. (Ursprünglich)
-t --test Führt die Tests aus. (Ursprünglich)
-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 Test-Teardown und -Bereinigung.
--info Zeigt die relevanten Informationen zu den angegebenen Zielen an und wird dann beendet.
--dry-run Führt Atest trocken aus, 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 beendet ist, bevor er ausgeführt wird.
-v --verbose Zeigt die Protokollierung auf DEBUG-Ebene an.
--iterations Führt Tests in einer Schleife aus, bis die maximale Iteration erreicht ist. (10 standardmäßig)
--rerun-until-failure [COUNT=10] Führt alle Tests erneut aus, bis ein Fehler auftritt oder die maximale Iteration erreicht ist. (10 standardmäßig)
--retry-any-failure [COUNT=10] Wiederholt fehlgeschlagene Tests, bis sie bestanden oder die maximale Iteration erreicht ist. (10 standardmäßig)
--start-avd Erstellt automatisch ein AVD und führt Tests auf dem virtuellen Gerät aus.
--acloud-create Erstellt eine AVD mit dem acloud Befehl.
--[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 ohne Gerät auf dem Host aus.
Hinweis: Das Ausführen eines Hosttests, der ein Gerät mit --host erfordert, schlägt fehl.
--history Zeigt Testergebnisse in chronologischer Reihenfolge an.
--latest-result Druckt das letzte Testergebnis.

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

Prüfungen angeben

Geben Sie zum Ausführen von Tests einen oder mehrere Tests mit einer der folgenden Kennungen an:

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

Trennen Sie Verweise auf mehrere Tests durch Leerzeichen wie folgt:

atest test-identifier-1 test-identifier-2

Modulname

Um ein vollständiges 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 angezeigt wird.

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 in 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 tradefed.sh list configs erscheint. 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 als auch integrationsbasierter Tests, indem der Pfad zu ihrer Testdatei oder ihrem Verzeichnis entsprechend eingegeben wird. Es unterstützt auch das Ausführen einer einzelnen Klasse, indem der Pfad zur Java-Datei der Klasse angegeben wird. Sowohl relative als auch absolute Pfade werden unterstützt.

Führen Sie ein Modul aus

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

Von Android repo-root :

atest cts/tests/video

Von Android repo-root/cts/tests/video :

    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.

Von 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 von 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

Schritte angeben: 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
  • Installieren Sie apk und führen Sie Tests aus: atest -it test-to-run
  • Erstellen und ausführen, aber nicht installieren: atest -bt test-to-run

Atest kann einen Test zwingen, den Cleanup- oder Teardown-Schritt zu überspringen. Viele Tests, wie z. B. CTS, bereinigen das Gerät, nachdem der Test ausgeführt wurde, sodass der Versuch, Ihren Test mit -t erneut auszuführen, ohne den Parameter --disable-teardown wird. Verwenden Sie -d vor -t , um den Testbereinigungsschritt zu überspringen und iterativ zu testen.

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

Ausführen bestimmter Methoden

Atest unterstützt das Ausführen bestimmter Methoden innerhalb einer Testklasse. Obwohl das gesamte Modul erstellt werden muss, reduziert dies die Zeit, die zum Ausführen der Tests benötigt wird. Um bestimmte Methoden auszuführen, identifizieren Sie die Klasse mit einer der Methoden, die zum Identifizieren einer Klasse unterstützt werden (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 zwei Beispiele zeigen die bevorzugten Methoden zum Ausführen einer einzelnen Methode, testFlagChange . Diese Beispiele werden der reinen 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 Modul:Klasse:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Von 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 mehrerer Klassen

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 Klassen 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, die in diesem Beispiel armeabi-v7a (ARM 32-Bit) und arm64-v8a (ARM 64-Bit) sind.

Beispiel Eingangstest:

atest -a libinput_tests inputflinger_tests

Um eine bestimmte auszuführende GTest-Binärdatei auszuwählen, verwenden Sie einen Doppelpunkt (:), um den Testnamen anzugeben, und ein Hashtag (#), um eine einzelne Methode weiter anzugeben.

Beispielsweise 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 individuellen Test mit dem Folgenden durch:

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Führen Sie Tests in TEST_MAPPING

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 in aktuellen und übergeordneten Verzeichnissen aus:

atest

Führen Sie Presubmit-Tests in 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 in aktuellen und übergeordneten Verzeichnissen aus:

atest :postsubmit

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

atest :all

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

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

Führen Sie Mainline-Tests in 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 dem angegebenen Verzeichnis zu seinen übergeordneten Verzeichnissen). Wenn Sie auch Tests in TEST_MAPPING-Dateien in den Unterverzeichnissen ausführen möchten, verwenden --include-subdirs , um Atest zu zwingen, diese Tests ebenfalls einzuschließen:

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

Führen Sie Tests in Iteration aus

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

Beispiele:

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

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

Die folgenden Ansätze erleichtern das Erkennen flockiger Tests:

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

  • Beenden Sie, wenn ein Fehler auftritt oder die Iteration die 10. (standardmäßig) Runde erreicht.
    atest test-to-run --rerun-until-failure
    
  • Beenden 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 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 10 Mal aus (standardmäßig) oder bis der Test bestanden ist.
    atest test-to-run --retry-any-failure
    
  • Stoppen Sie die Ausführung des nicht bestandenen Tests, wenn er die 100. Runde besteht oder erreicht.
    atest test-to-run --retry-any-failure 100
    

Führen Sie Tests auf AVDs durch

Atest kann Tests auf einem neu erstellten AVD ausführen. Führen acloud create aus, um ein AVD zu erstellen und Artefakte zu erstellen, und verwenden Sie dann die folgenden Beispiele, um Ihre Tests auszuführen.

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

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

Starten Sie ein AVD im Rahmen eines Testlaufs:

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

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

Übergeben Sie Optionen an das Modul

Atest kann Optionen an Testmodule übergeben. Um TradeFed-Befehlszeilenoptionen zu Ihrem Testlauf hinzuzufügen, verwenden Sie die folgende Struktur und stellen Sie sicher, dass Ihre benutzerdefinierten Argumente dem TradeFed-Befehlszeilenoptionsformat entsprechen.

atest test-to-run -- [CUSTOM_ARGS]

Übergeben Sie Testmoduloptionen an Zielersteller 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

Pass-Optionen für einen Läufertyp oder eine 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 Übergabeoptionen an die Module .