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 FrameworksServicesTestsatest 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:VideoEncoderDecoderTestatest FrameworksServicesTests:ScreenDecorWindowTestsatest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
Klassenname
Um eine einzelne Klasse auszuführen, ohne explizit einen Modulnamen anzugeben, verwenden Sie den Klassennamen.
Beispiele:
atest ScreenDecorWindowTestsatest 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-runatest -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#testMultipleDecorsatest 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/projectFü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 --iterationsatest 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-runhat 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-valueatest 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-valueatest 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 .