Un examen

Atest est un outil de ligne de commande qui permet aux utilisateurs de construire, installer et exécuter des tests Android localement, ce qui accélère grandement tests réexécutions sans exiger la connaissance de la Fédération du Commerce essai harnais options de ligne de commande. Cette page explique comment utiliser Atest pour exécuter des tests Android.

Pour des informations générales sur les tests d' écriture pour Android, voir la plate - forme Android Testing .

Pour plus d' informations sur la structure globale de Atest, voir Atest Guide du développeur .

Pour plus d' informations sur les tests en cours d' exécution dans les fichiers TEST_MAPPING par Atest, voir Exécuter des tests dans des fichiers TEST_MAPPING .

Et pour ajouter une fonctionnalité à Atest, suivez Atest Developer Flux de travail .

Configuration de votre environnement

Pour exécuter Atest, suivez les étapes décrites dans les sections ci-dessous pour configurer votre environnement.

Définir la variable d'environnement

Set test_suite pour Soong ou LOCAL_COMPATIBILITY_SUITE Make par emballage règles de script de construction .

Exécutez envsetup.sh

À partir de la racine de la vérification des sources Android, exécutez :

source build/envsetup.sh

Courir le déjeuner

Exécutez le lunch commande pour afficher un menu des périphériques pris en charge. Trouvez l'appareil et exécutez cette commande.

Par exemple, si vous avez un appareil ARM connecté, exécutez la commande suivante :

lunch aosp_arm64-eng

Ceci définit diverses variables d'environnement nécessaires à l' exécution Atest et ajoute la commande Atest à votre $PATH .

Utilisation de base

Les commandes de test prennent la forme suivante :

atest test-to-run [optional-arguments]

Arguments facultatifs

Vous trouverez ci-dessous les arguments les plus couramment utilisés. Une liste complète est disponible via atest --help .

Option Option longue La 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 le périphérique spécifié. Un seul appareil peut être testé à la fois.
-d --disable-teardown Désactive le démontage et le nettoyage des tests.
--info Affiche les informations pertinentes des cibles et sorties spécifiées.
--dry-run Essais à sec sans construire, installer et exécuter des tests dans la réalité
-m --rebuild-module-info Forces Une recréation du module-info.json fichier.
-w --wait-for-debugger Attend le débogueur avant l'exécution. Uniquement pour les tests d'instrumentation.
-v --verbose Affiche la journalisation de niveau DEBUG.
--iterations Les tests en boucle sont exécutés 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 ayant échoué 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 AVDS à l' aide de la acloud command.
--[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 de périphériques disponibles.
--host Exécute le test complètement sur l'hôte sans périphérique.
(Remarque: L' exécution d' un test d'hôte qui a besoin d' un appareil avec --host échouera.)
--flakes-info Affiche le résultat du test avec des informations sur les flocons.
--history Affiche le résultat du test par ordre chronologique.
--latest-result Imprime le dernier résultat du test.

Pour plus d' informations sur -b , -i et -t , voir Spécification étapes: construire, installer ou exécuter.

Tests à exécuter

Vous pouvez exécuter un ou plusieurs tests à l' aide de test-to-run . Pour exécuter plusieurs tests, séparez les références de test par des espaces. Par exemple:

atest test-to-run-1 test-to-run-2

Voici quelques exemples:

atest FrameworksServicesTests
atest example/reboot
atest FrameworksServicesTests CtsVideoTestCases
atest FrameworksServicesTests:ScreenDecorWindowTests

Pour plus d' informations sur la façon de faire référence à un test, voir Identification des tests.

Tests d'identification

Vous pouvez spécifier le test-to-run dispute avec le nom du module de test, Module: classe, nom de classe, test d'intégration de TF, chemin du fichier ou le nom du package.

Nom du module

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

Exemples:

atest FrameworksServicesTests
atest CtsVideoTestCases

Module : Classe

Pour exécuter une seule classe dans un module, utilisez le module: classe. Module est le même que celui décrit dans le nom du module . Classe est le nom de la classe de test dans le .java fichier et peut être le nom complet de la classe ou le nom de base.

Exemples:

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

Nom du cours

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

Exemples:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Utilisation du module: référence de classe est recommandée chaque fois que possible , car Atest nécessite plus de temps pour chercher l'arbre source complète pour les correspondances possibles si aucun module est indiqué.

Exemples (classés du plus rapide au plus lent) :

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

Test d'intégration TF

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

Pour exécuter le reboot.xml essai :

atest example/reboot

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

atest native-benchmark

Chemin du fichier

Vous pouvez exécuter à la fois des tests basés sur des modules et des 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. Vous pouvez également 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 pris en charge.

Exemple: Deux façons d'exécuter le CtsVideoTestCases module via chemin

  1. Module d' exécution d'Android repo-root :

    atest cts/tests/video
    
  2. De Android repo-root / cts / tests / vidéo:

    atest .
    

Exemple: Exécuter une classe spécifique dans CtsVideoTestCases module via chemin. De Android repo-root :

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

Exemple : Exécutez un test d'intégration via path. De 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écification des étapes : générer, installer ou exécuter

Vous pouvez spécifier les étapes à exécuter en utilisant le -b , -i et -t options. Si vous ne spécifiez pas d'option, toutes les étapes s'exécutent.

  • Cibles de génération seulement: atest -b test-to-run
  • Exécuter des tests uniquement: atest -t test-to-run
  • Installer apk et exécuter des tests: atest -it test-to-run
  • Construire et exécuter, mais ne pas installer: atest -bt test-to-run

Atest peut forcer un test à sauter l'étape de nettoyage/démontage. De nombreux tests, tels que CTS, nettoyez l'appareil après le test est exécuté, afin d' essayer de relancer votre test avec -t échouera sans --disable-teardown paramètre. Utilisez -d avant -t pour passer le test propre étape et test itérativement.

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

Exécuter des méthodes spécifiques

Vous pouvez exécuter des 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'un des moyens pris 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

Vous pouvez spécifier plusieurs méthodes avec 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 moyens préférés 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 :

  1. Utilisation du module : classe

    atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange
    
  2. De 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 modules :

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors

Exécuter plusieurs cours

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 des classes de manière efficace. Par conséquent, la spécification d'un sous-ensemble de classes dans un module améliore les performances par rapport à l'exécution du module entier.

Exemples:

  • Deux cours dans le même module :

    atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests
    
  • Deux cours dans des modules différents :

    atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest
    

Exécuter des tests natifs

Atest peut exécuter des tests natifs. Utilisez -a pour exécuter les tests pour toutes les architectures de dispositifs disponibles, ce qui dans cet exemple sont armeabi-V7A (ARM 32 bits) et arm64-v8a (ARM 64 bits).

Exemples:

  • Tests d'entrée :

    atest -a libinput_tests inputflinger_tests
    

Pour sélectionner un test natif spécifique à exécuter, utilisez deux points (:) pour spécifier le nom du test et le hashtag (#) pour spécifier davantage une méthode individuelle. Par exemple, pour la définition de test suivant:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Vous pouvez exécuter le test entier à l' aide

atest inputflinger_tests:InputDispatcherTest

ou une méthode de test individuel en utilisant

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Exécution de tests dans TEST_MAPPING

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

  1. Exécutez des tests de pré-soumission implicitement dans les fichiers TEST_MAPPING dans les répertoires actuels, parents ou spécifiques.

    Exécuter les tests de preSubmit dans les fichiers TEST_MAPPING dans les répertoires actuels et parents:

    atest
    

    Exécuter les tests de preSubmit dans les fichiers TEST_MAPPING dans /path/to/project et ses répertoires parents:

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

  2. Exécutez un groupe test spécifié dans les fichiers TEST_MAPPING; groupes d'essai sont disponibles: presubmit (par défaut), postsubmit , mainline-presubmit et all .

    • Exécuter les tests de postSubmit dans les fichiers TEST_MAPPING dans les répertoires actuels et parents:

      atest :postsubmit
      

    • Exécuter des tests de tous les groupes dans les fichiers TEST_MAPPING:

      atest :all
      

    • Exécuter les tests de postSubmit dans les fichiers TEST_MAPPING dans /path/to/project et ses répertoires parents

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

    • Exécuter les tests dans les fichiers de la canalisation principale TEST_MAPPING dans /path/to/project et ses répertoires parents

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

  3. Exécutez des tests dans les fichiers TEST_MAPPING, y compris les sous-répertoires.

Par défaut, atest ne recherche que les tests dans les fichiers TEST_MAPPING vers le haut (à partir du répertoire courant ou donné à ses répertoires parents). Si vous souhaitez également exécuter des tests dans des fichiers TEST_MAPPING dans les sous-répertoires, vous pouvez utiliser l' option --include-subdirs pour forcer atest d'inclure ces tests aussi bien.

Exécuter les tests de preSubmit dans les fichiers TEST_MAPPING dans le courant, parent et sous-répertoires:

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

Exécuter des tests en itération

Pour exécuter des tests dans l' itération, il suffit de passer le --iterations argument. Qu'il réussisse ou échoue, atest n'arrêtera pas le test jusqu'à ce que l'itération maximale soit atteinte.

Exemples:

Par défaut, atest itère 10 fois, donnant un entier pour changer le cycle d'itération.

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

Deux approches qui aident les utilisateurs à détecter les 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 (par défaut) tour.
    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écutez uniquement les tests ayant échoué jusqu'à ce qu'ils soient réussis ou que l'itération maximale soit atteinte.

  • Supposons test-to-run a cinq cas de test et l' un des tests échoue. Exécutez uniquement le test ayant échoué 10 fois ou jusqu'à ce que le test réussisse.
    atest test-to-run --retry-any-failure
    
  • Arrêtez d'exécuter le test qui a échoué lorsqu'il réussit ou atteint le 100e tour.
    atest test-to-run --retry-any-failure 100
    

Exécution de tests sur les AVD

Atest est capable d'exécuter des tests avec l'AVD nouvellement créé. Atest peut construire des artefacts ainsi que l' exécution de acloud create et exécuter des tests après l'AVD a été créé avec succès.

Exemples:

  • Démarrer une AVD avant l' exécution des tests sur ce dispositif nouvellement créé:

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

  • Commencez AVDS par specifing acloud create arguments et exécuter des tests sur ce dispositif nouvellement créé.

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

Pour obtenir les détails d'utilisation de l'argument, exécutez acloud create --help .

Passer les options au module

Atest est capable de passer des options aux modules. Le format bref dans la ligne de commande Atest ajouter l' option de ligne de commande TradeFed est

atest test-to-run -- [CUSTOM_ARGS]
Les [CUSTOM_ARGS] doivent suivre les formats d'options de ligne de commande Tradefed.

Exemples de transmission d'options de module de test aux préparateurs cibles ou aux exécuteurs de test 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

Exemples d'options de passage au type ou à la 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 le test que les options, voir les options Pass pour les modules