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