Atest est un outil de ligne de commande qui permet aux utilisateurs de créer, d’installer et d’exécuter Les tests Android 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 obtenir des informations générales sur l'écriture de tests pour Android, consultez Test de la plate-forme Android
Pour en savoir plus sur la structure globale d'Atest, consultez le Guide du développeur Atest
Pour plus d'informations sur l'exécution de tests dans des fichiers TEST_MAPPING via Atest, consultez Exécutez 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 la suppression et le nettoyage du test. |
|
--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 au 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:Classe
- 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
de ce test
Android.mk
ou Android.bp
.
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 du
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 Tradefed
Pour exécuter des tests intégrés directement dans TradeFed (non-modules), saisissez la valeur
tel qu'il apparaît dans le résultat de la commande tradefed.sh list configs
. Exemple :
Pour exécuter la
Test reboot.xml
:
atest example/reboot
Pour exécuter la
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 y a aussi prend en charge l'exécution d'une classe unique en spécifiant le chemin d'accès au fichier Java de la classe. Les chemins d'accès 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
. Utiliser -d
avant
-t
pour ignorer l'étape de nettoyage du test et effectuer un test itératif.
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
recommandé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 l'exécution 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 comme 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 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 de pré-envoi dans TEST_MAPPING
fichiers 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
Pour 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 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 effectuez des tests dessus:
acloud create --local-instance --local-image && atest test-to-run
Démarrez un AVD lors 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 de test:
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.