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

Configurer des tests ACTS

Cette page explique comment configurer les tests ACTS.

Sources de la configuration

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

Interface de ligne de commande (CLI)
Fichier de configuration ACTS
Variables d'environnement

Les valeurs provenant 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, elles sont écrasées dans l'ordre ci-dessus (où la CLI prévaut).

Remarque 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 ne sont pas recommandées en dehors du poste de travail d'un développeur. Les variables d'environnement sont désactivées lors des tests automatisés de l'ACTS afin d'éviter toute intoxication à l'environnement.

Variables de configuration requises

Pour chaque test ACTS, les variables suivantes doivent être définies.

Chemins de test ACTS

Le système ACTS s'exécute à partir d'un emplacement d'entrée principale unique. Par conséquent, l'emplacement du chemin de test est inconnu de l'exécuteur.

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

Classes de test ACTS

Les ACTS doivent 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'option -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 aux noms de fichiers correspondants. Par exemple, SampleTest doit se trouver dans SampleTest.py.

Chemin d'accès au journal ACTS

Les ACTS doivent avoir un emplacement pour écrire des journaux dans d'autres sources que STDOUT. Le système ACTS écrit des journaux de débogage complets contenant des données qui peuvent aider à déterminer la raison de l'échec de certains tests. Pour éviter d'encombrer le système, ACTS n'écrit pas ces journaux dans STDOUT.

Pour définir le chemin d'accès au journal, utilisez la variable d'environnement ACTS_LOGPATH ou l'option -lp/--logpath dans la ligne de commande.

Chemin d'accès à la configuration ACTS

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

Si la configuration comporte plusieurs tests, le système ACTS exécute les tests pour chacun d'eux. Pour n'exécuter le test que pour un seul test de la liste, utilisez l'argument de ligne de commande -tb/--testbed <NAME>.

Exemple de station de travail locale

La plupart des utilisateurs ACTS développent une seule branche de dépôt Android et ont une configuration semblable à 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 ACTS s'exécutent sur plusieurs branches, ils exécutent souvent ce type d'outil à partir du répertoire acts/framework et utilisent un chemin d'accès 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

Configurer vos outils de test

Le fichier de configuration ACTS fournit toutes les informations nécessaires pour exécuter des tests sur des 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 testbed. Dans l'exemple de configuration ci-dessus, le my_testbed testbed est créé avec une seule valeur testbed. Le deuxième testbed, another_testbed, dispose d'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 objet testbed ne spécifie pas d'objet AndroidDevice, une classe de test qui attend un objet AndroidDevice génère une exception. Pour obtenir la liste complète des configurations de manette compatibles fournies avec les outils ACTS, consultez la liste sur /acts/framework/acts/controllers/.

Toutes les autres valeurs (autres que les 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 stocker des informations sur l'environnement ou les tests, par exemple pour savoir si les téléphones se trouvent dans un environnement de données facturé à l'usage ou sur la durée de collecte des données pour un test.

Cas particuliers pour AndroidDevice

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

Format de configuration JSON

Toutes les paires clé/valeur de l'exemple JSON suivant 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 généré.

  "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 bon appareil et accéder à des paramètres supplémentaires à partir de l'objet de l'appareil:

  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

Le paramètre suivant est facultatif:

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