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 commandeadb logcat
pour collecter les journaux adb. Par défaut,adb logcat -v threadtime -b all
est utilisé. Siadb_logcat_param
est défini, la section-b all
est écrasée. Par exemple, définiradb_logcat_param
sur-b radio
modifie la commande enadb logcat -v threadtime -b radio
.