Cette page a été traduite par l'API Cloud Translation.

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 test) ;
transférer des fichiers vers l'appareil ;
Exécuter des commandes (par exemple, adb shell pm ...)

Auparavant, les équipes de composants avaient généralement recours à l'écriture d'un test côté hôte pour pour réaliser ces tâches, ce qui nécessite de savoir comment exploiter et augmente généralement la complexité d'un module de test .

En empruntant à CTS, nous avons présenté le concept de configuration de module de test de telles tâches, la liste de tâches courantes ci-dessus peut être réalisée en seulement quelques lignes configuration. Pour une flexibilité maximale, vous pouvez même implémenter votre propre cible preparer, 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 principales balises gérées via les configurations du module de test sont "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 "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 permettent de configurer l'harnais de test de manière à:

Avant l'appel du module de test, exécutez la commande shell "settings put secure accessibility_enabled 1" sur l'appareil.
Une fois le module de test terminé, exécutez la commande shell "settings put secure accessibilité_enabled 0"

Dans cet exemple, l'accessibilité est activée/désactivée avant/après l'exécution du module de test, respectivement. En voici un exemple simple : Voyons plus en détail comment le tag "option" est utilisé. Comme indiqué ci-dessus, une 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 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: <ph type="x-smartling-placeholder">
  - 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: <ph type="x-smartling-placeholder">
  - push-file : spécification de transfert, qui indique le fichier local au chemin d'accès où il doit être transféré 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, le dernier sera transféré.
  - 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>) une fois toutes les tentatives de transfert effectuées. Utilisation habituelle utiliserait chmod pour les autorisations
nom de la classe: InstallApkSetup
- short name:install-apk
- function:transfère les fichiers APK arbitraires vers la destination lorsque appareil
- Options: <ph type="x-smartling-placeholder">
  - test-file-name:nom de l'APK sur lequel installer 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
- short name:run-command
- function:exécute des commandes shell arbitraires avant ou après le test exécution du module
- Options: <ph type="x-smartling-placeholder">
  - run-command:adb shell à exécuter. Peut être répété
  - teardown-command : commande shell adb à exécuter pendant la phase de démontage. Peut être répété

Classe de test

Une classe de test est la classe de 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
- short name:gtest
- function:test qui exécute un package de test natif sur un appareil donné.
- Options: <ph type="x-smartling-placeholder">
  - native-test-device-path:chemin d'accès sur l'appareil où se trouvent les tests natifs.
nom de la classe: InstrumentationTest
- short name (nom court) : instrumentation
- function:un test qui exécute un package de test d'instrumentation sur un appareil donné.
- Options: <ph type="x-smartling-placeholder">
  - package:nom du package du fichier 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:un test qui exécute un package de test d'instrumentation sur une appareil à l'aide d'android.support.test.runner.AndroidJUnitRunner Il s'agit du principal moyen d'exécuter un test d'instrumentation.