Tests ausführen (Atest)

Atest ist ein Befehlszeilentool, mit dem Nutzer Android testet lokal, wodurch sich die erneute Ausführung von Tests erheblich beschleunigt, ohne dass Wissen über das Trade Federation Test-Harnisch Befehlszeilenoptionen. Auf dieser Seite wird erläutert, wie Android mit Atest ausgeführt wird. Tests durchführen.

Allgemeine Informationen zum Schreiben von Tests für Android finden Sie unter Android-Plattformtests.

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

Um Atest eine Funktion hinzuzufügen, folgen Sie der Atest-Entwickler-Workflow

Umgebung einrichten

Folgen Sie zum Einrichten Ihrer Atest-Umgebung der Anleitung unter Einrichtung der Umgebung, Ziel auswählen und Code erstellen.

Grundlegende Nutzung

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 finden Sie unter atest --help.

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 Führt einen Probelauf für Atest aus, ohne tatsächlich Tests zu erstellen, zu installieren oder auszuführen.
-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 die Protokollierung auf DEBUG-Ebene an.
--iterations Tests werden in einer Schleife ausgeführt, bis die maximale Wiederholung erreicht ist. (Standardwert 10)
--rerun-until-failure [COUNT=10] Alle Tests werden wiederholt, bis ein Fehler auftritt oder die maximale Iteration erreicht ist. (Standardwert 10)
--retry-any-failure [COUNT=10] Fehlgeschlagene Tests werden so lange wiederholt, bis sie bestanden wurden oder die maximale Wiederholung erreicht ist. (10 standardmäßig)
--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 Test-Runner an.
-a --all-abi Führt die Tests für alle verfügbaren Gerätearchitekturen aus.
--host Der Test wird vollständig auf dem Host ohne Gerät ausgeführt.
Hinweis: Hosttest ausführen, für den ein Gerät mit --host erforderlich ist schlägt fehl.
--history Testergebnisse in chronologischer Reihenfolge anzeigen.
--latest-result Druckt das letzte Testergebnis aus.

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

Tests angeben

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

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

Trennen Sie Verweise auf mehrere Tests durch Leerzeichen. Beispiel:

atest test-identifier-1 test-identifier-2

Modulname

Wenn du ein ganzes Testmodul ausführen möchtest, verwende den Modulnamen. Geben Sie den Namen so ein, wie er angezeigt wird. die Variablen LOCAL_MODULE oder LOCAL_PACKAGE_NAME in diesem Test Android.mk- oder Android.bp-Datei.

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. Class ist der Name der Klasse Testklasse in der Datei .java und kann der voll qualifizierte Klassenname oder die grundlegenden Namen verwenden.

Beispiele:

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

Kursname

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

Beispiele:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Tradefed-Integrationstest

Um Tests durchzuführen, die direkt in TradeFed (nicht Module) integriert sind, geben Sie die wie er in der Ausgabe des Befehls tradefed.sh list configs angezeigt wird. Für Beispiel:

Um den reboot.xml-Test:

atest example/reboot

Um den native-benchmark.xml-Test:

atest native-benchmark

Dateipfad

Atest unterstützt die Ausführung von modul- und integrationsbasierten Tests durch und geben den Pfad zu ihrer Testdatei bzw. zum Testverzeichnis nach Bedarf ein. Außerdem unterstützt die Ausführung 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

Die folgenden Beispiele zeigen zwei Möglichkeiten, das Modul CtsVideoTestCases mit einen Dateipfad.

Unter Android repo-root ausführen:

atest cts/tests/video

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

    atest .

Testklasse ausführen

Das folgende Beispiel zeigt, wie Sie eine bestimmte Klasse innerhalb der CtsVideoTestCases-Modul mithilfe eines Dateipfads.

Von 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 ausgeführt wird von Android repo-root:

    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 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. Viele Tests, wie z. B. CTS, bereinigen Sie das Gerät nach Abschluss des Tests, versuchen Sie also, den Test noch einmal auszuführen. mit -t schlägt ohne den Parameter --disable-teardown fehl. Verwende -d vor dem -t, um den Schritt zur Testbereinigung zu überspringen und einen iterativen Test 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 die gesamte -Modul erstellt werden muss, reduziert sich die Zeit, die zum Ausführen der Tests benötigt wird. Zum Ausführen Methoden finden, identifizieren Sie die Klasse mithilfe einer der Methoden, die für eine Klasse identifizieren (Modul:Klasse, Dateipfad usw.) und fügen Sie den Namen der :

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 zur Ausführung einer einzelnen Methode. testFlagChange Diese Beispiele werden gegenüber der ausschließlichen Verwendung des Klassennamens bevorzugt. da Atest das Modul oder den Speicherort der Java-Datei angeben kann, viel schneller testen können.

Verwendung 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

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 Kurse ausführen möchten, trennen Sie sie wie beim Ausführen durch Leerzeichen. mehrere Tests durchführen. Atest erstellt und führt Klassen effizient aus. eine Untergruppe von Klassen in einem Modul verbessert die Leistung gegenüber der Ausführung des gesamten -Modul.

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ärprogramme ausführen

Atest kann GTest-Binärdateien ausführen. Verwenden Sie -a, um diese Tests für alle verfügbaren Gerätearchitekturen, in diesem Beispiel 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

Oder führen Sie einen individuellen Test mit folgendem Code durch: 

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ühre Tests zum Vorabsenden 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 postsubmit-Tests in TEST_MAPPING-Dateien im aktuellen und übergeordneten Verzeichnis aus:

atest :postsubmit

Führen Sie Tests für alle Gruppen in TEST_MAPPING-Dateien aus:

atest :all

Nach dem Senden durchgeführte Tests in TEST_MAPPING-Dateien in /path/to/project und zugehörigen übergeordneten Verzeichnissen:

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 nach Tests in TEST_MAPPING-Dateien ab der das aktuelle oder das angegebene Verzeichnis in seine übergeordneten Verzeichnisse). Wenn Sie auch Um Tests in TEST_MAPPING-Dateien in den Unterverzeichnissen auszuführen, verwenden Sie --include-subdirs. um zu erzwingen, dass Atest diese Tests ebenfalls berücksichtigt:

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

Tests in Iterationen ausführen

Führen Sie Tests in Iterationen durch, indem Sie das Argument --iterations übergeben. Bestanden oder schlägt er fehl, wiederholt Atest den Test, bis die maximale Iteration erreicht ist.

Beispiele:

Standardmäßig wird Atest zehnmal iteriert. Die Anzahl der Iterationen muss positiv sein Integer

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

Die folgenden Ansätze erleichtern die Erkennung instabiler Tests:

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

  • Beenden Sie die Iteration, wenn ein Fehler auftritt oder die 10. Runde (standardmäßig) erreicht wird. 
    atest test-to-run --rerun-until-failure
  • Sie wird beendet, wenn ein Fehler auftritt oder die Iteration die 100. Runde erreicht. 
    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 Testläufe und einen der folgenden: die Tests scheitern. Führen Sie standardmäßig nur den fehlgeschlagenen Test 10 Mal bzw. bis zum bestanden werden. 
    atest test-to-run --retry-any-failure
  • Beenden Sie die Ausführung des nicht bestandenen Tests, wenn er bestanden wird oder die 100. Runde erreicht ist. 
    atest test-to-run --retry-any-failure 100

AVDs testen

Atest kann Tests für eine neu erstellte AVD ausführen. Zum Erstellen acloud create ausführen und Build-Artefakte erstellen, dann führen Sie Ihre Tests anhand der folgenden Beispiele aus.

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

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"

Weitere Informationen erhalten Sie, wenn Sie acloud create --help ausführen.

Optionen an Modul weitergeben

Atest kann Optionen an Testmodule übergeben. TradeFed-Befehlszeile hinzufügen Optionen hinzufügen möchten, verwenden Sie die folgende Struktur und stellen Sie sicher, dass Ihre benutzerdefinierten -Argumenten folgen dem Format für Tradefed-Befehlszeilenoptionen.

atest test-to-run -- [CUSTOM_ARGS]

die Optionen für Testmodul, die auf Vorbereitungen oder Testläufer ausgerichtet sind, wie in den Testkonfigurationsdatei:

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