Tests ausführen (Atest)

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

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

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 Ihre Atest-Umgebung einzurichten.

Grundlegende Nutzung

Atest-Befehle haben folgendes 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.

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 Beenden und Bereinigen von Tests.
--dry-run Probeläufe von Atest, ohne Tests tatsächlich zu erstellen, zu installieren oder auszuführen.
-m --rebuild-module-info Erzwingt die Neuerstellung der Datei module-info.json.
-w --wait-for-debugger Wartet vor der Ausführung auf den Abschluss des Debuggers.
-v --verbose Zeigt Protokollierung auf DEBUG-Ebene an.
--iterations Bei Schleifen werden Tests so lange ausgeführt, bis die maximale Iteration erreicht ist. (Standardwert: 10)
--rerun-until-failure [COUNT=10] Führt alle Tests noch einmal aus, bis ein Fehler auftritt oder die maximale Anzahl von Wiederholungen erreicht ist. (Standardwert: 10)
--retry-any-failure [COUNT=10] Wiederholt fehlgeschlagene Tests, bis sie bestanden sind oder die maximale Anzahl von Iterationen erreicht ist. (standardmäßig 10)
--start-avd Erstellt automatisch ein AVD und führt Tests auf dem virtuellen Gerät aus.
--acloud-create Erstellt ein 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 Führt den Test vollständig auf dem Host ohne Gerät aus.
Hinweis: Das Ausführen eines Hosttests, für den ein Gerät mit --host erforderlich ist, schlägt fehl.
--history Zeigt Testergebnisse in chronologischer Reihenfolge an.
--latest-result Gibt das letzte Testergebnis aus.

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

Tests angeben

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

  • Modulname
  • Modul:Class
  • Klassenname
  • Tradefed-Integrationstest
  • Dateipfad
  • Paketname

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

atest test-identifier-1 test-identifier-2

Modulname

Wenn Sie ein ganzes 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:Class

Wenn Sie eine einzelne Klasse innerhalb eines Moduls ausführen möchten, verwenden Sie Module:Class. Modul entspricht dem unter Modulname beschriebenen. Class ist der Name der Testklasse in der Datei .java. Das 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

Klassenname

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 Test reboot.xml aus:

atest example/reboot

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

atest native-benchmark

Dateipfad

Atest unterstützt das Ausführen von modulbasierten und integrationsbasierten Tests, indem der Pfad zur Testdatei oder zum Testverzeichnis eingegeben wird. Außerdem wird das Ausführen einer einzelnen Klasse unterstützt, 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 CtsVideoTestCases-Modul über einen Dateipfad auszuführen.

Über 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 im Modul CtsVideoTestCases über einen Dateipfad ausführen.

Von einem Android-Gerät 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, Installation oder Ausführung

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

Mit „atest“ kann ein Test gezwungen werden, den Bereinigungs- oder Teardown-Schritt zu überspringen. Bei vielen Tests, z. B. beim CTS, wird das Gerät nach dem Ausführen des Tests bereinigt. Wenn Sie versuchen, Ihren Test mit -t noch einmal auszuführen, schlägt dies ohne den Parameter --disable-teardown fehl. Verwenden Sie -d vor -t, um den Bereinigungsschritt zu überspringen und iterativ zu testen.

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

Bestimmte Methoden ausführen

Mit Atest können bestimmte Methoden innerhalb einer Testklasse ausgeführt werden. Obwohl das gesamte Modul erstellt werden muss, wird dadurch die Zeit verkürzt, die zum Ausführen der Tests benötigt wird. 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 werden gegenüber der reinen Verwendung des Klassennamens bevorzugt, da Atest den Test viel schneller finden kann, wenn das Modul oder der Speicherort der Java-Datei angegeben wird.

Mit „Modul:Klasse“:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Von einem Android-Gerät 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 durchführen

Wenn Sie mehrere Klassen ausführen möchten, trennen Sie sie durch Leerzeichen, genau wie bei der Ausführung mehrerer Tests. Atest erstellt und führt Klassen effizient aus. Wenn Sie also eine Teilmenge von Klassen in einem Modul angeben, wird die Leistung im Vergleich zur 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

GTest-Binärdateien ausführen

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

Beispiel für Eingabetest:

atest -a libinput_tests inputflinger_tests

Wenn Sie ein bestimmtes GTest-Binärprogramm auswählen möchten, das ausgeführt werden soll, geben Sie den Testnamen mit einem Doppelpunkt (:) und eine einzelne Methode mit einem Hashtag (#) an.

Beispiel: 

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

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

atest inputflinger_tests:InputDispatcherTest

Oder führen Sie einen einzelnen Test mit dem folgenden Befehl aus: 

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

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

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

Bestimmte Testgruppe ausführen

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

Führen Sie Post-Submit-Tests in TEST_MAPPING-Dateien im aktuellen und in übergeordneten Verzeichnissen 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 Mainline-Tests 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 aufwärts (vom aktuellen oder angegebenen Verzeichnis 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 einzubeziehen:

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

Tests in Iteration ausführen

Führen Sie Tests in der Iteration aus, indem Sie das Argument --iterations übergeben. Unabhängig davon, ob der Test bestanden oder fehlgeschlagen ist, wird er von Atest wiederholt, bis die maximale Anzahl von Wiederholungen erreicht ist.

Beispiele:

Standardmäßig wird Atest zehnmal durchlaufen. 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 von instabilen Tests:

Ansatz 1: Alle Tests werden ausgeführt, bis ein Fehler auftritt oder die maximale Anzahl von Iterationen erreicht ist.

  • Der Vorgang wird beendet, wenn ein Fehler auftritt oder die Iteration die 10. Runde (Standard) erreicht. 
    atest test-to-run --rerun-until-failure
  • Beenden Sie den Vorgang, 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 Anzahl von Wiederholungen erreicht ist.

  • Angenommen, test-to-run hat mehrere Testläufe und einer der Tests schlägt fehl. Führen Sie den fehlgeschlagenen Test standardmäßig 10-mal oder so lange aus, bis er bestanden wird. 
    atest test-to-run --retry-any-failure
  • Der fehlgeschlagene Test wird beendet, 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 einem neu erstellten AVD ausgeführt werden. Führen Sie acloud create aus, um ein AVD und Build-Artefakte zu erstellen. Verwenden Sie dann die folgenden Beispiele, um Ihre Tests auszuführen.

AVD starten und Tests darauf ausführen:

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

AVD im Rahmen eines Testlaufs starten:

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

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

Optionen an Modul übergeben

Mit Atest können Optionen an Testmodule übergeben werden. Wenn Sie Ihrem Testlauf TradeFed-Befehlszeilenoptionen hinzufügen möchten, verwenden Sie die folgende Struktur und achten Sie darauf, dass Ihre benutzerdefinierten Argumente dem Tradefed-Befehlszeilenoptionsformat entsprechen.

atest test-to-run -- [CUSTOM_ARGS]

Übergeben Sie Testmoduloptionen an Zielvorbereiter oder Test-Runner, 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 Runner-Typ oder eine Runner-Klasse ü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 Testoptionen finden Sie unter Optionen an die Module übergeben.