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

Configuration des tests ACTS

Cette page décrit comment configurer les tests ACTS.

Sources de configuration

La suite de tests Android Comms (ACTS) dispose de trois sources principales de configuration :

L'interface de ligne de commande (CLI)
Le fichier de configuration ACTS
Variables d'environnement

Les valeurs de ces sources sont combinées en une seule configuration utilisée pour exécuter un test ACTS. Si des valeurs sont spécifiées à plusieurs emplacements, les valeurs sont écrasées en fonction de l'ordre ci-dessus (où la CLI est prioritaire).

Une note sur les variables d'environnement

Soyez prudent lorsque vous utilisez des variables d'environnement pour les tests ACTS. Ces valeurs sont les moins visibles pour l'utilisateur et il n'est pas recommandé de les utiliser en dehors du poste de travail d'un développeur. Les variables d'environnement sont désactivées lors des tests automatisés ACTS pour éviter l'empoisonnement de l'environnement.

Variables de configuration requises

Chaque test ACTS nécessite la définition des variables suivantes.

Parcours de test ACTS

ACTS fonctionne à partir d’un seul emplacement d’entrée principal. En conséquence, l’emplacement du chemin de test est inconnu du coureur.

Définissez l'emplacement du chemin de test à l'aide de la variable d'environnement ACTS_TESTPATH ou avec l'indicateur -tp / --testpaths dans la ligne de commande. La valeur peut être une liste de répertoires.

Cours de tests ACTS

ACTS doit savoir quelles classes de test exécuter. Il peut s'agir d'une expression régulière ou d'une liste de noms de classes de test.

Pour définir cette valeur, utilisez l'indicateur -tc / --test_class dans la ligne de commande. Notez que cet indicateur accepte également une liste de noms de classes. Les noms de classe doivent correspondre à leurs noms de fichiers correspondants, par exemple, SampleTest doit être trouvé dans SampleTest.py .

Chemin du journal ACTS

ACTS doit disposer d'un emplacement dans lequel écrire les journaux autre que STDOUT. ACTS écrit des journaux de débogage complets contenant des données qui peuvent aider à déterminer pourquoi certains tests échouent. Pour éviter tout encombrement, ACTS n'écrit pas ces journaux dans STDOUT.

Pour définir le chemin du journal, utilisez la variable d'environnement ACTS_LOGPATH ou l'indicateur -lp / --logpath dans la ligne de commande.

Chemin de configuration ACTS

Pour exécuter le test, ACTS doit savoir quel banc de test existe. La configuration ACTS contient tous les appareils du banc de test, ainsi que tous les paramètres de test ou d'environnement spéciaux qui pourraient être nécessaires. Définissez cette valeur sur la ligne de commande en utilisant -c / --config .

S'il existe plusieurs bancs de test dans la configuration, ACTS exécute les tests pour chaque banc de test. Pour exécuter le test uniquement pour un seul banc d'essai de la liste, utilisez l'argument de ligne de commande -tb/--testbed <NAME> .

Un exemple de poste de travail local

La plupart des utilisateurs d'ACTS développent sur une seule branche de dépôt Android et ont une configuration similaire à celle-ci :

# in ~/.bashrc
ACTS_LOGPATH='/tmp/acts_logpath'
ACTS_TESTPATH='~/android/<REPO_BRANCH>/tools/test/connectivity/acts_tests/'

# On cmdline
$ act.py -c ~/acts_configs/local_config.json -tc SampleTest -tb marlin

Si les utilisateurs d'ACTS s'exécutent sur plusieurs branches, ils exécutent souvent ACTS à partir du répertoire acts/framework et utilisent un chemin relatif pour ACTS_TESTPATH :

# in ~/.bashrc
ACTS_LOGPATH='/tmp/acts_logpath'
ACTS_TESTPATH='../acts_tests/'

# On cmdline
$ cd ~/android/main/tools/test/connectivity/acts_tests/acts_contrib/
$ act.py -c ~/acts_configs/local_config.json -tc SampleTest -tb marlin

Configuration de vos bancs d'essai

Le fichier de configuration ACTS fournit toutes les informations nécessaires pour exécuter des tests sur les périphériques matériels :

{
  "testbed": {
    "my_testbed": {
      "my_testbed_value": "value"
    },
    "another_testbed": {
      "AndroidDevice": [
        "53R147"
      ]
    }
  },
  "user_parameter_1": "special environment value",
  "user_parameter_2": "other special value"
}

L'unité de base de cette configuration est le banc d'essai. Dans l'exemple de configuration ci-dessus, le testbed my_testbed est créé avec une seule valeur de testbed. Le deuxième banc de test, another_testbed , possède une configuration de contrôleur spéciale qui contient les informations d'une liste d'appareils Android. Ces appareils sont stockés dans une liste d'appareils sous self.android_devices . Notez que si un banc de test ne spécifie pas d'objet AndroidDevice , une classe de test qui attend un objet AndroidDevice lève une exception. Pour une liste complète des configurations de contrôleur prises en charge fournies avec ACTS, consultez la liste à l' /acts/framework/acts/controllers/ .

Toutes les autres valeurs (qui ne sont pas des valeurs spéciales mentionnées dans la section ci-dessus) sont stockées dans self.user_params en tant que dictionnaire. C'est un bon endroit pour conserver des informations sur l'environnement ou les tests, telles que si les téléphones se trouvent dans un environnement de données mesurées ou combien de temps il faut collecter des données pour un test.

Cas particuliers pour les appareils Android

Pour faciliter le développement lorsque vous souhaitez disposer de plusieurs appareils avec des propriétés différentes, AndroidDevice présente des cas particuliers.

Format de configuration JSON

Toutes les paires clé/valeur du JSON ci-dessous sont définies sur l'objet AndroidDevice correspondant. Si la configuration tente d'écraser un paramètre défini dans l'attribut AndroidDevice , ControllerError est renvoyé.

  "AndroidDevice": [{"serial": "XXXXXX", "label": "publisher"},
                    {"serial": "YYYYYY", "label": "subscriber", "user_parameter_1": "anything"}]

Ensuite, dans le script de test, vous pouvez utiliser une fonction de filtre pour récupérer le périphérique correct et accéder à des paramètres supplémentaires à partir de l'objet périphérique :

  def setup_class(self):
      self.pub = next(filter(lambda ad: ad.label == 'publisher',
                             self.android_devices))
      self.sub = next(filter(lambda ad: ad.label == 'user_parameter_1',
                             self.android_devices))

Paramètre facultatif

Ce qui suit est un paramètre facultatif :

adb_logcat_param : chaîne ajoutée à la commande adb logcat pour collecter les journaux adb. Par défaut, adb logcat -v threadtime -b all est utilisé. Si adb_logcat_param est défini, la section -b all est écrasée. Par exemple, définir adb_logcat_param sur -b radio modifie la commande en adb logcat -v threadtime -b radio .