Configurer des tests ACTS

Obsolète :ACTS, y compris SL4A, l'application d'assistance côté appareil pour les tests ACTS, a été abandonnée en octobre 2022 et n'est plus gérée. Pour éviter les problèmes de maintenance et de prise en charge des fonctionnalités, nous vous recommandons de migrer votre couverture de test vers le framework de test Mobly.

Cette page explique comment configurer les tests ACTS.

Sources de configuration

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

• 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 concernant 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 ACTS pour éviter toute pollution de l'environnement.

Variables de configuration requises

Chaque test ACTS nécessite de définir les variables suivantes.

Parcours de test ACTS

ACTS s'exécute à partir d'un seul emplacement d'entrée principal. Par conséquent, l'emplacement du chemin de test est inconnu pour le 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.

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'indicateur -tc/--test_class dans la ligne de commande. Notez que cet indicateur accepte également une liste de noms de classe. Les noms de classe doivent correspondre à leurs noms de fichiers correspondants. Par exemple, SampleTest doit se trouver dans SampleTest.py.

Chemin d'accès au journal ACTS

Les ACTS doivent disposer d'un emplacement pour écrire des journaux dans un environnement 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 d'accès aux journaux, utilisez la variable d'environnement ACTS_LOGPATH ou l'indicateur -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 plusieurs plates-formes de test sont définies dans la configuration, ACTS exécute les tests pour chacune d'elles. Pour exécuter le test sur un seul banc d'essais 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 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

Configurer vos plates-formes 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 de banc d'essais est créé avec une seule valeur de banc d'essais. 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 (qui ne sont pas des valeurs spéciales mentionnées dans la section ci-dessus) sont stockées dans self.user_params sous forme de dictionnaire. Il s'agit d'un bon emplacement pour stocker des informations sur l'environnement ou les tests, par exemple si les téléphones se trouvent dans un environnement de données limité ou pendant combien de temps les données doivent être collecté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"}]

Dans le script de test, vous pouvez ensuite utiliser une fonction de filtrage pour récupérer l'appareil approprié 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

Voici 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 remplace la commande par adb logcat -v threadtime -b radio.