Google s'est engagé à promouvoir l'équité raciale pour les communautés noires. Regarde comment.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Configuration de test complexe

Certains modules de test peuvent nécessiter une configuration personnalisée et des étapes de suppression qui ne peuvent pas être effectuées dans le cas de test lui-même. Des exemples typiques peuvent inclure:

  • installer d'autres apks (en plus de l'apk de test)
  • pousser certains fichiers sur l'appareil
  • exécuter des commandes (par exemple adb shell pm ...)

Dans le passé, les équipes de composants ont généralement recours à la rédaction d'un test côté hôte pour effectuer de telles tâches, ce qui nécessite une compréhension du harnais de la fédération commerciale et augmente généralement la complexité d'un module de test.

Empruntant à CTS, nous avons introduit le concept de configuration du module de test pour prendre en charge de telles tâches, la liste des tâches courantes ci-dessus peut être réalisée en quelques lignes de configuration. 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é au dossier source du module de niveau supérieur, nommé «AndroidTest.xml». Le XML suit le format d'un fichier de configuration utilisé par le harnais 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 de cibles

Une balise «target_preparer», comme son nom l'indique, définit un préparateur de cible (voir ITargetPreparer ) qui offre une méthode de configuration, qui est appelée avant que le module de test ne soit exécuté pour le test; et si la classe référencée dans la balise «target_preparer» implémente également ITargetCleaner , sa méthode de démontage sera appelée une fois le module de test terminé.

Pour utiliser la configuration du module commun intégré, ajoutez un nouveau fichier 'AndroidTest.xml' dans le dossier de niveau supérieur de votre module de test et remplissez-le avec le contenu suivant:

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

À titre d'exemple, nous pouvons ajouter les balises d'option suivantes (au niveau du commentaire «insérer» 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 configureront le faisceau de test pour:

  1. avant que le module de test ne soit appelé, exécutez la commande shell «settings put secure availability_enabled 1» sur l'appareil
  2. une fois le module de test terminé, exécutez la commande shell "settings put secure availability_enabled 0"

Dans cet exemple particulier, l'accessibilité est activée / désactivée avant / après l'exécution du module de test, respectivement. Avec un exemple simple démontré, il est nécessaire de couvrir plus de détails sur la façon dont la balise «option» est utilisée. Comme indiqué ci-dessus, la balise peut avoir deux attributs: nom, valeur. L'attribut name indiquait le nom de l'option et se décompose en deux parties séparées par deux-points: le nom court du préparateur et le nom de l'option réelle proposé par le préparateur.

Le but exact du champ de valeur dépend de la manière dont le préparateur a défini l'option: il peut s'agir d'une chaîne, d'un nombre, d'un booléen ou même d'un chemin de fichier, etc. Dans l'exemple ci-dessus, le nom «run-command: run-command» signifie que nous définissons la valeur de l'option «run-command» définie par un préparateur cible avec le nom court «run-command»; et le nom «run-command: teardown-command» signifie que nous définissons la valeur de l'option «teardown-command» également définie par le même préparateur de cible avec le nom court «run-command». Voici un résumé des trois préparateurs d'objectifs courants:

  • nom de la classe: PushFilePreparer

    • nom court : fichier push
    • fonction : pousse les fichiers arbitraires sous le dossier de cas de test vers la destination sur l'appareil
    • remarques :
      • ce préparateur peut pousser de dossier en dossier ou de fichier en fichier; en d'autres termes, vous ne pouvez pas pousser un fichier sous un dossier sur l'appareil: vous devez également spécifier le nom du fichier de destination sous ce dossier
    • options :
      • push: Une spécification push, 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 peut être relatif au répertoire du module de test ou au répertoire out lui-même.
      • ** post-push: ** Une commande à exécuter sur l'appareil (avec ` adb shell <your command> `) après que toutes les poussées ont été tentées. Un cas d'utilisation typique serait l'utilisation de chmod pour les autorisations
  • nom de la classe: InstallApkSetup

    • nom court: install-apk
    • fonction: pousse les fichiers apk arbitraires sous dans la destination sur l'appareil
    • options:
      • test-file-name: le nom de l'apk à installer sur l'appareil.
      • install-arg: arguments supplémentaires à transmettre à la commande pm install, y compris le tiret au début, par exemple «-d». Peut être répété
  • nom de la classe: RunCommandTargetPreparer

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

Classe d'essai

Une classe de test est la classe de la fédération commerciale à 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: Un test qui exécute un package de test natif sur un appareil donné.
    • options:
      • native-test-device-path: chemin sur le périphérique où se trouvent les tests natifs.
  • nom de la classe: InstrumentationTest

    • nom court: instrumentation
    • fonction: Un test qui exécute un package de test d'instrumentation sur un périphérique donné
    • options:
      • package: le nom du package manifeste de l'application de test Android à exécuter.
      • class: le nom de la classe de test à exécuter.
      • method: nom de la méthode de test à exécuter.
  • nom de la classe: AndroidJUnitTest

    • function: Un test qui exécute un package de test d'instrumentation sur un appareil donné à l'aide de android.support.test.runner.AndroidJUnitRunner C'est la principale façon d'exécuter un test d'instrumentation.