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 .