Cette page a été traduite par l'API Cloud Translation.

Exécuter des tests (Atest)

Atest est un outil de ligne de commande qui permet aux utilisateurs de créer, d’installer et d’exécuter Android effectue des tests en local, ce qui accélère considérablement les réexécutions de tests des connaissances sur l'outil de test de la Fédération commerciale ; options de ligne de commande. Cette page explique comment utiliser Atest pour exécuter Android tests.

Pour en savoir plus sur l'écriture de tests pour Android, consultez Tester la plate-forme Android.

Pour en savoir plus sur la structure globale d'Atest, consultez le Guide du développeur Atest

Pour en savoir plus sur l'exécution de tests dans des fichiers TEST_MAPPING via Atest, consultez la section Exécuter des tests dans des fichiers TEST_MAPPING.

Pour ajouter un élément géographique à Atest, suivez les Atest des processus du développeur

Configurer votre environnement

Pour configurer votre environnement Atest, suivez les instructions de la section Configurer le environnement, Choisir une cible et Compiler le code.

Utilisation de base

Les commandes Atest se présentent sous la forme suivante :

atest test-to-run [optional-arguments]

Arguments facultatifs

Le tableau suivant répertorie les arguments les plus couramment utilisés. Voici une liste complète : disponible jusqu'au atest --help.

Option	Option longue	Description
`-b`	`--build`	Crée des cibles de test. (par défaut)
`-i`	`--install`	Installe les artefacts de test (APK) sur l'appareil. (par défaut)
`-t`	`--test`	Exécute les tests. (par défaut)
`-s`	`--serial`	Exécute les tests sur l'appareil spécifié. Vous ne pouvez tester qu'un seul appareil à la fois.
`-d`	`--disable-teardown`	Désactive le démontage et le nettoyage des tests.
	`--dry-run`	Effectue un test à blanc sans compiler, installer ou exécuter des tests.
`-m`	`--rebuild-module-info`	Force la recompilation du fichier `module-info.json`.
`-w`	`--wait-for-debugger`	Attend la fin de l'exécution du débogueur avant de s'exécuter.
`-v`	`--verbose`	Affiche la journalisation de niveau DEBUG.
	`--iterations`	Les tests sont exécutés en boucle jusqu'à ce que le nombre maximal d'itérations soit atteint. (10 par défaut)
	`--rerun-until-failure [COUNT=10]`	Réexécute tous les tests jusqu'à ce qu'un échec se produise ou que l'itération maximale soit atteint. (10 par défaut)
	`--retry-any-failure [COUNT=10]`	Réexécute les tests ayant échoué jusqu'à ce qu'ils soient réussis ou que le nombre maximal d'itérations soit atteint. (10 par défaut)
	`--start-avd`	Crée automatiquement un AVD et exécute des tests sur l'appareil virtuel.
	`--acloud-create`	Crée un AVD à l'aide de la commande `acloud`.
	`--[CUSTOM_ARGS]`	Spécifie des arguments personnalisés pour les exécuteurs de test.
`-a`	`--all-abi`	Exécute les tests pour toutes les architectures d'appareils disponibles.
	`--host`	Exécute complètement le test sur l'hôte, sans appareil. Remarque: Exécution d'un test hôte qui nécessite un appareil avec `--host` échouera.
	`--history`	Affiche les résultats du test dans l'ordre chronologique.
	`--latest-result`	Imprime le dernier résultat de test.

Pour en savoir plus sur -b, -i et -t, consultez les Spécifier les étapes: compilation, installation ou exécution.

Spécifier des tests

Pour exécuter des tests, spécifiez un ou plusieurs tests en utilisant l'un des éléments suivants identifiants:

Nom du module
Module:Class
Nom de classe.
Test d'intégration Tradefed
Chemin d'accès au fichier
Nom du package

Séparez les références à plusieurs tests à l'aide d'espaces, comme ceci:

atest test-identifier-1 test-identifier-2

Nom du module

Pour exécuter un module de test complet, utilisez son nom. Saisissez le nom tel qu'il apparaît dans les variables LOCAL_MODULE ou LOCAL_PACKAGE_NAME du fichier Android.mk ou Android.bp de ce test.

Exemples :

atest FrameworksServicesTests
atest CtsVideoTestCases

Module:Classe

Pour exécuter une classe unique dans un module, utilisez Module:Class. Module : identique à celui décrit dans la section Nom du module. Class (Classe) est le nom de la classe dans le fichier .java. Il peut s'agir du nom complet de la classe ou du nom de base.

Exemples :

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

Nom de classe.

Pour exécuter une classe unique sans indiquer explicitement le nom d'un module, utilisez la classe son nom.

Exemples :

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Test d'intégration de Tradefed

Pour exécuter des tests intégrés directement à TradeFed (non-modules), saisissez le nom tel qu'il apparaît dans la sortie de la commande tradefed.sh list configs. Exemple :

Pour exécuter la Test reboot.xml:

atest example/reboot

Pour exécuter le test native-benchmark.xml :

atest native-benchmark

Chemin d'accès au fichier

Atest permet d'exécuter des tests basés sur des modules et des tests basés sur l'intégration en en saisissant le chemin d'accès à leur fichier de test ou à leur répertoire, le cas échéant. Il permet également d'exécuter une seule classe en spécifiant le chemin d'accès au fichier Java de la classe. Les chemins relatifs et absolus sont acceptés.

Exécuter un module

Les exemples suivants montrent deux façons d'exécuter le module CtsVideoTestCases avec un chemin d'accès à un fichier.

Exécutez à partir d'Android repo-root:

atest cts/tests/video

Exécutez à partir d'Android repo-root/cts/tests/video:

    atest .

Exécuter une classe de test

L'exemple suivant montre comment exécuter une classe spécifique dans le Module CtsVideoTestCases à l'aide d'un chemin d'accès à un fichier.

Depuis Android repo-root :

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

Exécuter un test d'intégration

L'exemple suivant montre comment exécuter un test d'intégration à l'aide d'un chemin d'accès à un fichier à partir d'Android repo-root:

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

Nom du package

Atest permet de rechercher des tests par nom de package.

Exemples :

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

Spécifier les étapes: compiler, installer ou exécuter

Utilisez les options -b, -i et -t pour spécifier les étapes à exécuter. Si vous ne spécifiez pas d'option, puis toutes les étapes s'exécutent.

Cibles de compilation uniquement : atest -b test-to-run
Exécuter des tests uniquement: atest -t test-to-run
Installez l'APK et exécutez des tests: atest -it test-to-run
Compilez et exécutez, mais ne l'installez pas: atest -bt test-to-run

La fonction Atest peut forcer un test à ignorer l'étape de nettoyage ou de suppression. De nombreux tests, comme CTS, nettoyez l'appareil après l'exécution du test. Essayez donc d'exécuter à nouveau votre test. avec -t échouent sans le paramètre --disable-teardown. Utilisez -d avant -t pour ignorer l'étape de nettoyage des tests et effectuer des tests itératifs.

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

Exécuter des méthodes spécifiques

Atest permet d'exécuter des méthodes spécifiques dans une classe de test. Bien que l'ensemble un module spécifique doit être compilé, ce qui réduit le temps nécessaire à l'exécution des tests. À exécuter méthodes spécifiques, identifiez la classe en utilisant l'une des méthodes prises en charge pour identifiant une classe (Module:Class, chemin d'accès au fichier, etc.), puis ajoutez le nom du méthode:

atest reference-to-class#method1

Lorsque vous spécifiez plusieurs méthodes, séparez-les par des virgules:

atest reference-to-class#method1,method2,method3

Exemples :

atest com.android.server.wm.ScreenDecorWindowTests#testMultipleDecors
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval

Les deux exemples suivants montrent les méthodes privilégiées pour exécuter une seule méthode, testFlagChange. Il est préférable d'utiliser ces exemples plutôt que d'utiliser uniquement le nom de la classe. car spécifier le module ou l’emplacement du fichier Java permet à Atest de trouver effectuer des tests beaucoup plus rapidement.

Utilisation de Module:Class :

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Depuis Android repo-root:

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

Plusieurs méthodes peuvent être exécutées à partir de différentes classes et de différents modules:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors

Exécuter plusieurs classes

Pour exécuter plusieurs classes, séparez-les par des espaces, comme pour exécuter plusieurs tests. Atest crée et exécute les classes de manière efficace, donc spécifier un un sous-ensemble de classes d'un module améliore les performances par rapport à l'exécution de l'ensemble de ce module.

Pour exécuter deux classes dans le même module:

atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests

Pour exécuter deux classes dans différents modules:

atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest

Exécuter des binaires GTest

Atest peut exécuter des binaires GTest. Utilisez -a pour exécuter ces tests pour tous les tests architectures d'appareils. Dans cet exemple, elles sont armeabi-v7a (ARM 32 bits) et arm64-v8a (ARM 64 bits).

Exemple de test d'entrée:

atest -a libinput_tests inputflinger_tests

Pour sélectionner un binaire GTest spécifique à exécuter, utilisez le signe deux-points (:) pour indiquer le test et un hashtag (#) pour spécifier une méthode individuelle.

Par exemple, pour la définition de test suivante:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Exécutez la commande suivante pour spécifier le test dans son intégralité:

atest inputflinger_tests:InputDispatcherTest

Vous pouvez également exécuter un test individuel à l'aide de la commande suivante :

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Exécuter des tests dans TEST_MAPPING

Atest peut exécuter des tests dans des fichiers TEST_MAPPING.

Exécuter des tests avant l'envoi implicitement

Exécutez des tests de pré-envoi dans les fichiers TEST_MAPPING des répertoires actuel et parent:

atest

Exécutez des tests avant l'envoi dans les fichiers TEST_MAPPING dans /path/to/project et ses répertoires parents :

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

Exécuter un groupe de test spécifié

Les groupes de test disponibles sont les suivants: presubmit(par défaut), postsubmit, mainline-presubmit et all.

Exécutez les tests post-envoi dans les fichiers TEST_MAPPING des répertoires actuel et parent:

atest :postsubmit

Exécutez les tests à partir de tous les groupes dans les fichiers TEST_MAPPING:

atest :all

Exécuter les tests post-envoi dans les fichiers TEST_MAPPING dans /path/to/project et ses répertoires parents:

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

Exécuter des tests principaux dans des fichiers TEST_MAPPING dans /path/to/project et ses répertoires parents:

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

Exécuter des tests dans des sous-répertoires

Par défaut, Atest ne recherche que les tests dans les fichiers TEST_MAPPING supérieurs (à partir de le répertoire actuel ou donné vers ses répertoires parents). Si vous souhaitez également exécuter des tests dans les fichiers TEST_MAPPING des sous-répertoires, utilisez --include-subdirs pour forcer Atest à inclure ces tests également :

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

Exécuter des tests dans l'itération

Exécutez des tests lors de l'itération en transmettant l'argument --iterations. Réussite ou échoue, Atest répète le test jusqu'à atteindre le nombre maximal d'itérations.

Exemples :

Par défaut, Atest effectue 10 itérations. Le nombre d'itérations doit être un nombre positif entier.

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

Les approches suivantes facilitent la détection des tests irréguliers:

Méthode 1: exécuter tous les tests jusqu'à ce qu'un échec se produise ou que le nombre maximal d'itérations soit atteint

s'arrête lorsqu'un échec se produit ou que l'itération atteint le 10e cycle (par défaut).
```
atest test-to-run --rerun-until-failure
```
s'arrête lorsqu'un échec se produit ou que l'itération atteint le 100e cycle.
```
atest test-to-run --rerun-until-failure 100
```

Méthode 2: exécuter uniquement les tests ayant échoué jusqu'à ce que les tests soient réussis ou que le nombre maximal d'itérations soit atteint.

Supposons que test-to-run comporte plusieurs scénarios de test et un des les tests échouent. Exécutez uniquement le test ayant échoué 10 fois (par défaut) ou jusqu'à ce que le des cartes de test.
```
atest test-to-run --retry-any-failure
```
Arrêtez d'exécuter le test ayant échoué lorsqu'il réussit ou atteint le 100e cycle.
```
atest test-to-run --retry-any-failure 100
```

Exécuter des tests sur des AVD

Atest peut exécuter des tests sur un AVD nouvellement créé. Exécuter acloud create pour créer un AVD et compiler des artefacts, puis utilisez les exemples suivants pour exécuter vos tests.

Démarrez un AVD et exécutez des tests dessus :

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

Démarrez un AVD dans le cadre d'un test:

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

Pour en savoir plus, exécutez acloud create --help.

Transmettre des options au module

Atest peut transmettre des options aux modules de test. Ajouter la ligne de commande TradeFed options à votre exécution de test, utilisez la structure suivante et assurez-vous que votre au format de ligne de commande Tradefed.

atest test-to-run -- [CUSTOM_ARGS]

Transmettez les options du module de test aux préparateurs ou aux exécuteurs de test cibles définis dans le fichier de configuration des tests :

atest test-to-run -- --module-arg module-name:option-name:option-value
atest GtsPermissionTestCases -- --module-arg GtsPermissionTestCases:ignore-business-logic-failure:true

Transmettez des options à un type ou à une classe d'exécuteur:

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

Pour en savoir plus sur les options réservées aux tests, consultez Transmettre des options aux modules.