Exécution de tests (Atest)

Atest est un outil de ligne de commande qui permet aux utilisateurs de créer, d'installer et d'exécuter des tests Android localement, accélérant considérablement les réexécutions de test sans nécessiter de connaissance des options de ligne de commande du harnais de test de la Fédération commerciale . Cette page explique comment utiliser Atest pour exécuter des tests Android.

Pour obtenir des informations générales sur l'écriture de tests pour Android, consultez Test de la plate-forme Android .

Pour plus d'informations sur la structure globale d'Atest, reportez-vous au Guide du développeur Atest .

Pour plus d'informations sur l'exécution de tests dans les fichiers TEST_MAPPING via Atest, consultez Exécution de tests dans les fichiers TEST_MAPPING .

Pour ajouter une fonctionnalité à Atest, suivez le flux de travail du développeur Atest .

Configurez votre environnement

Pour configurer votre environnement Atest, suivez les instructions dans Configurer l'environnement , Choisir une cible et Générer le code .

Utilisation de base

Les commandes atest prennent la forme suivante :

atest test-to-run [optional-arguments]

Arguments facultatifs

Le tableau suivant répertorie les arguments les plus couramment utilisés. Une liste complète est disponible via atest --help .

Option	Version longue	Description
-b	--build	Construit des cibles de test. (défaut)
-i	--install	Installe les artefacts de test (APK) sur l'appareil. (défaut)
-t	--test	Exécute les tests. (défaut)
-s	--serial	Exécute les tests sur l'appareil spécifié. Un appareil peut être testé à la fois.
-d	--disable-teardown	Désactive le démontage et le nettoyage des tests.
	--info	Affiche les informations pertinentes sur les cibles spécifiées, puis quitte.
	--dry-run	Exécute Atest à blanc sans réellement créer, installer ou exécuter des tests.
-m	--rebuild-module-info	Force une reconstruction du fichier module-info.json .
-w	--wait-for-debugger	Attend que le débogueur se termine avant de s'exécuter.
-v	--verbose	Affiche la journalisation de niveau DEBUG.
	--iterations	Boucle-exécute des tests jusqu'à ce que l'itération maximale soit atteinte. (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 atteinte. (10 par défaut)
	--retry-any-failure [COUNT=10]	Réexécute les tests échoués jusqu'à ce qu'ils soient réussis ou que l'itération maximale soit atteinte. (10 par défaut)
	--start-avd	Crée automatiquement un AVD et exécute des tests sur le périphérique virtuel.
	--acloud-create	Crée un AVD à l'aide de la commande acloud .
	--[CUSTOM_ARGS]	Spécifie des arguments personnalisés pour les testeurs.
-a	--all-abi	Exécute les tests pour toutes les architectures de périphériques disponibles.
	--host	Exécute complètement le test sur l'hôte sans périphérique. Remarque : L'exécution d'un test d'hôte qui nécessite un périphérique avec --host échouera.
	--history	Affiche les résultats des tests dans l'ordre chronologique.
	--latest-result	Imprime le dernier résultat de test.

Pour plus d'informations sur -b , -i et -t , consultez la section Spécifier les étapes : construire, installer ou exécuter .

Spécifier les tests

Pour exécuter des tests, spécifiez un ou plusieurs tests à l'aide de l'un des identifiants suivants :

• Nom du module
• Module :Classe
• Nom du cours
• Test d'intégration Tradefed
• Chemin du fichier
• Nom du paquet

Séparez les références à plusieurs tests avec des espaces, comme ceci :

atest test-identifier-1 test-identifier-2

Nom du module

Pour exécuter un module de test entier, utilisez son nom de module. 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 seule classe dans un module, utilisez Module:Class . Le module est identique à celui décrit dans Nom du module . Classe est le nom de la classe de test dans le fichier .java et peut être le nom de classe complet ou le nom de base.

Exemples:

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

Nom du cours

Pour exécuter une seule classe sans indiquer explicitement un nom de module, utilisez le nom de la classe.

Exemples:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Test d'intégration Tradefed

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

Pour exécuter le test reboot.xml :

atest example/reboot

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

atest native-benchmark

Chemin du fichier

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

Exécuter un module

Les exemples suivants montrent deux manières d'exécuter le module CtsVideoTestCases à l'aide d'un chemin de fichier.

Exécuter à partir repo-root Android :

atest cts/tests/video

Exécutez depuis 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 de fichier.

À partir repo-root Android :

    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 de fichier depuis Android repo-root :

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

Nom du paquet

Atest prend en charge la recherche de tests par nom de package.

Exemples:

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

Spécifiez les étapes : créer, 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, toutes les étapes s'exécutent.

• Cibles de génération uniquement : atest -b test-to-run
• Exécuter les tests uniquement : atest -t test-to-run
• Installez apk et exécutez les tests : atest -it test-to-run
• Construisez et exécutez, mais n'installez pas : atest -bt test-to-run

Atest peut forcer un test à ignorer l'étape de nettoyage ou de démontage. De nombreux tests, tels que CTS, nettoient le périphérique après l'exécution du test, donc essayer de réexécuter votre test avec -t échouera sans le paramètre --disable-teardown . Utilisez -d avant -t pour ignorer l'étape de nettoyage du test et tester de manière itérative.

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

Exécution de méthodes spécifiques

Atest prend en charge l'exécution de méthodes spécifiques dans une classe de test. Bien que l'ensemble du module doive être construit, cela réduit le temps nécessaire pour exécuter les tests. Pour exécuter des méthodes spécifiques, identifiez la classe à l'aide de l'une des méthodes prises en charge pour identifier une classe (module : classe, chemin de fichier, etc.) et ajoutez le nom de la 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 préférées pour exécuter une seule méthode, testFlagChange . Ces exemples sont préférables à l'utilisation uniquement du nom de la classe car la spécification du module ou de l'emplacement du fichier Java permet à Atest de trouver le test beaucoup plus rapidement.

Utilisation de Module : Classe :

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

À partir repo-root Android :

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 modules :

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors

Exécution de plusieurs classes

Pour exécuter plusieurs classes, séparez-les par des espaces de la même manière que pour exécuter plusieurs tests. Atest construit et exécute les classes de manière efficace, donc la spécification d'un sous-ensemble de classes dans un module améliore les performances par rapport à l'exécution de l'ensemble du module.

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

atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests

Pour exécuter deux cours dans des modules différents :

atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest

Exécuter les binaires GTest

Atest peut exécuter des binaires GTest. Utilisez -a pour exécuter ces tests pour toutes les architectures de périphériques disponibles, qui dans cet exemple 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 deux-points (:) pour spécifier le nom du test et un hashtag (#) pour spécifier davantage une méthode individuelle.

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

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Exécutez ce qui suit pour spécifier l'intégralité du test :

atest inputflinger_tests:InputDispatcherTest

Ou exécutez un test individuel en utilisant ce qui suit :

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Exécuter des tests dans TEST_MAPPING

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

Exécuter implicitement des tests de pré-soumission

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

atest

Exécutez des tests de pré-soumission 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 : presubmit (par défaut), postsubmit , mainline-presubmit et all .

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

atest :postsubmit

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

atest :all

Exécutez des tests post-soumission dans les fichiers TEST_MAPPING dans /path/to/project et ses répertoires parents :

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

Exécutez les tests principaux dans les 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 recherche uniquement les tests dans les fichiers TEST_MAPPING vers le haut (du répertoire courant 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 également ces tests :

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

Exécuter des tests en itération

Exécutez les tests en itération en passant l'argument --iterations . Qu'il réussisse ou échoue, Atest répétera le test jusqu'à ce que l'itération maximale soit atteinte.

Exemples:

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

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

Les approches suivantes facilitent la détection des tests floconneux :

Approche 1 : exécutez tous les tests jusqu'à ce qu'un échec se produise ou que l'itération maximale soit atteinte.

• Arrêtez-vous lorsqu'un échec se produit ou que l'itération atteint le 10e tour (par défaut).

  atest test-to-run --rerun-until-failure
  

• Arrêtez-vous lorsqu'un échec se produit ou que l'itération atteint le 100e tour.

  atest test-to-run --rerun-until-failure 100
  

Approche 2 : exécuter uniquement les tests ayant échoué jusqu'à ce qu'ils soient réussis ou que l'itération maximale soit atteinte.

• Supposons que test-to-run comporte plusieurs cas de test et que l'un des tests échoue. Exécutez uniquement le test ayant échoué 10 fois (par défaut) ou jusqu'à ce que le test réussisse.

  atest test-to-run --retry-any-failure
  

• Arrêtez d'exécuter le test échoué lorsqu'il réussit ou atteint le 100e tour.

  atest test-to-run --retry-any-failure 100
  

Exécuter des tests sur les AVD

Atest est capable d'exécuter des tests sur un AVD nouvellement créé. Exécutez acloud create pour créer un AVD et générer 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 plus d'informations, exécutez acloud create --help .

Passer les options au module

Atest est capable de passer des options pour tester les modules. Pour ajouter des options de ligne de commande TradeFed à votre exécution de test, utilisez la structure suivante et assurez-vous que vos arguments personnalisés suivent le format d'option de ligne de commande Tradefed.

atest test-to-run -- [CUSTOM_ARGS]

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

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

Passer les options à un type ou une classe de coureur :

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 plus d'informations sur les options de test uniquement, consultez Transmettre les options aux modules .