Configuration de test complexe

Certains modules de test peuvent nécessiter une configuration et des étapes de suppression personnalisées dans le scénario de test lui-même. Voici quelques exemples typiques:

  • installer d'autres APK (en plus de l'APK de test) ;
  • transférer certains fichiers sur l'appareil
  • Exécuter des commandes (par exemple, adb shell pm ...)

Auparavant, les équipes de composants recouraient généralement à l'écriture d'un test côté hôte pour effectuer ces tâches, ce qui nécessite une compréhension du harnais Trade Federation et augmente généralement la complexité d'un module de test.

En nous inspirant de CTS, nous avons introduit le concept de configuration de module de test pour prendre en charge ces tâches. La liste des tâches courantes ci-dessus peut être réalisée en quelques lignes de configuration seulement. Pour une flexibilité maximale, vous pouvez même implémenter votre propre préparateur de cible, tel que défini par ITargetPreparer ou ITargetCleaner, et les configurer pour les utiliser dans votre propre configuration de module de test.

Une configuration de module de test pour un module de test est un fichier XML requis ajouté en haut de la page du module "AndroidTest.xml". Le fichier XML respecte le format d'un fichier de configuration utilisé par l'outil d'automatisation des tests de la Fédération commerciale. Actuellement, les balises principales gérées via les configurations du module de test sont les balises "target_preparer" et "test".

Préparateurs des cibles

La balise "target_preparer", comme son nom l'indique, définit un "préparateur cible". (voir ITargetPreparer). qui propose une méthode de configuration, qui est appelée avant l'exécution du module de test à des fins de test. Si la classe référencée dans le tag "target_preparer" est également met en œuvre ITargetCleaner sa méthode de suppression sera appelée une fois le module de test terminé.

Pour utiliser la configuration de module commune intégrée, ajoutez un nouveau fichier "AndroidTest.xml" à l'adresse dans le dossier racine de votre module de test, et remplissez-le avec le code ci-dessous : contenu:

<?xml version="1.0" encoding="utf-8"?>
<!-- [insert standard AOSP copyright here] -->
<configuration description="Test module config for Foo">
<!-- insert options here -->
</configuration>

Par exemple, nous pouvons ajouter les balises d'option suivantes (au niveau du commentaire "insert" ci-dessus) :

    <target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
        <option name="run-command" value="settings put secure accessibility_enabled 1" />
        <option name="teardown-command" value="settings put secure accessibility_enabled 0" />
    </target_preparer>

Les options permettent de configurer l'harnais de test de manière à:

  1. avant d'appeler le module de test, exécutez la commande shell "settings put secure Accessibility_enabled 1 pouce sur l'appareil
  2. Une fois le module de test terminé, exécutez la commande shell "settings put secure accessibilité_enabled 0"

Dans cet exemple particulier, l'accessibilité est activée/désactivée respectivement avant/après l'exécution du module de test. En voici un exemple simple : Voyons plus en détail comment le tag "option" est utilisé. Comme indiqué ci-dessus, la balise peut avoir deux attributs : nom et valeur. L'attribut "name" doit faire référence à l'une des options proposées par le préparateur.

L'objectif exact du champ de valeur dépend de la façon dont le préparateur a défini l'option : il peut s'agir d'une chaîne, d'un nombre, d'une valeur booléenne ou même d'un chemin d'accès de fichier. Voici un récapitulatif des trois principaux acteurs de la préparation des cibles:

  • Nom de la classe : PushFilePreparer

    • short name (nom court) : push-file
    • function : envoie des fichiers arbitraires dans le dossier du scénario de test vers la destination sur l'appareil
    • remarques:
      • ce préparateur peut le transférer de dossier à dossier, ou de fichier à fichier ; que vous ne pouvez pas transférer un fichier dans un dossier de l'appareil: vous devez spécifier également le nom de fichier de destination sous ce dossier
    • options:
      • push-file:spécification push spécifiant le fichier local sur le chemin d'accès là où il doit être poussé sur l'appareil. Peut être répété. Si plusieurs fichiers sont configurés pour être transférés vers le même chemin d'accès distant, la dernière sera transmise.
      • push : (obsolète) spécification de transfert, au format /path/to/srcfile.txt->/path/to/destfile.txt ou /path/to/srcfile.txt->/path/to/destdir/. Peut être répété. Ce chemin d'accès peut être relatif au répertoire du module de test ou au répertoire de sortie lui-même.
      • post-push:commande à exécuter sur l'appareil (avec adb shell <your command>) après toutes les tentatives d'envoi. Utilisation habituelle utiliserait chmod pour les autorisations

  • Nom de la classe : InstallApkSetup

    • nom court : install-apk
    • function:transfère les fichiers .apk arbitraires vers la destination lorsque appareil
    • options:
      • nom-fichier-test : nom de l'APK à installer sur l'appareil.
      • install-arg:arguments supplémentaires à transmettre à la commande pm install , y compris le tiret de début, par exemple "-d". Peut être répété

  • Nom de la classe : RunCommandTargetPreparer

    • Nom court : run-command
    • function : exécute des commandes shell arbitraires avant ou après l'exécution du module de test
    • options:
      • run-command:adb shell à exécuter. Peut être répété
      • teardown-command:commande shell adb à exécuter pendant la phase de suppression. Peut être répété

Classe de test

Une classe de test est la classe Trade Federation à utiliser pour exécuter le test.

<test class="com.android.tradefed.testtype.AndroidJUnitTest">
  <option name="package" value="android.test.example.helloworld"/>
  <option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>

Voici trois classes de test courantes :

  • nom de la classe: GTest

    • Nom court : gtest
    • function : test qui exécute un package de test natif sur un appareil donné.
    • options:
      • native-test-device-path:chemin d'accès sur l'appareil où se trouvent les tests natifs.

  • Nom de la classe : InstrumentationTest

    • nom court : instrumentation
    • function:un test qui exécute un package de test d'instrumentation sur un appareil donné.
    • Options:
      • package : nom du package manifeste de l'application de test Android à exécuter.
      • class : nom de la classe de test à exécuter.
      • method:nom de la méthode de test à exécuter.

  • nom de la classe: AndroidJUnitTest

    • function : test qui exécute un package de test d'instrumentation sur un appareil donné à l'aide d'android.support.test.runner.AndroidJUnitRunner. Il s'agit du principal moyen d'exécuter un test d'instrumentation.