Les fondamentaux¶
Le framework de test fournit un cadre permettant de normaliser la création des cas de tests.
- Les principales fonctionnalités sont:
- le support des cas de tests avec étapes
- le support des extensions permettant de communiquer avec le système à tester ou piloter
- la génération automatique des rapports de tests.
Cas de test¶
La création d’un cas de test dans la solution est normalisée.
- Un cas de test se découpe en 4 sections:
description
: description des différentes étapes du testprepare
: préparation des adaptateurs et librairies permettant de communiquer avec le système à tester ou piloterdefinition
: déroulement du testcleanup
: phase de nettoyage
Le résultat d’un cas de test est automatiquement calculé par le framework lorsque le test est terminé en fonction des différentes étapes définies.
- Il existe 3 résultats possibles:
PASS
: toutes les étapes du tests ont été exécutées avec succèsFAILED
: au moins une étape est en erreur après exécutionUNDEFINED
: au moins une étape du test n’a pas été exécutée
Note
La section cleanup
est systématiquement appelée, même en cas d’erreur.
Etapes de test¶
Un cas de test se découpe en sous-étapes.
- Une étape se définit par:
- un résumé de l’action à réaliser
- la description détaillée de l’action à réaliser
- la description du résultat attendu pour valider l’étape.
La définition des étapes du test doit être faite dans la section description
:
self.step1 = self.addStep(
expected="Logged in",
description="Login throught the rest api",
summary="Login throught the rest api",
enabled=True
)
Le résultat d’une étape est à préciser dans la section definition
Exemple pour mettre le résultat à PASS
ou FAILED
self.step1.setPassed(actual="step executed as expected")
self.step1.setFailed(actual="error to run the step")
Avertissement
Il ne faut pas oublier de démarrer une étape avec la fonction start
sinon il n’est pas possible de mettre le résultat.
Note
Il ne faut pas oublier de préciser le résultat d’une étape, sinon il sera considéré comme UNDEFINED
.
Important
Une étape positionnée à FAILED
ne pourra pas devenir PASS
par la suite dans un test.
Annulation d’un test¶
Il est possible de forcer l’exécution d’un cas de test en utilisant la fonction interrupt
dans la section description
de votre test.
Test(self).interrupt(err="aborted by tester")
Utiliser la fonction interrupt
permet d’arrêter le test et d’appeler automatiquement la section cleanup
du cas de test.
Dans ce cas précis, l’argument aborted
est mis à True par le framework pour indiquer l’annulation du test.
def definition(self):
Test(self).interrupt("bad response received")
def cleanup(self, aborted):
if aborted: self.step1.setFailed(actual="%s" % aborted)
Ajout de trace¶
Le framework met à disposition certaines fonctions pour ajouter des messages durant l’exécution d’un test.
Les niveaux suivants sont disponibles:
Exemple pour afficher un message de type
info
Trace(self).info(txt="hello world")Exemple pour afficher un message de type
warning
Trace(self).warning(txt="hello world")Exemple pour afficher un message de type
error
Trace(self).error(txt="hello world")
Note
Si un message de niveau error
est affiché alors le résultat sera automatiquement mis à FAILED
.
Note
Les messages apparaissent automatiquement dans le rapport basique.
Données¶
Public¶
Un espace public est disponible sur le serveur de test. Cet espace permet de mettre à disposition des fichiers qui sont nécessaire durant l’exécution d’un test.
Les fichiers sont stockés dans le répertoire /opt/xtc/current/Var/Public/
sur le serveur.
Avertissement
Cet espace est commun à l’ensemble des projets configurés sur le serveur.
Privé¶
L’espace de stockage privé n’existe que durant l’exécution d’un test. Il permet de sauvegarder des logs générés ou récupérés lors de l’exécution du test. Ces logs sont automatiquement mis à la disposition de l’utilisateur dans un fichier zip lorsque le test est terminé. Ils sont récupables depuis le client ou bien depuis l’API du serveur.
- Les logs sont organisés par répertoire:
- Répertoire TC-TESTCASE-#<id_tc>: contient les logs générés par le cas de test
- Répertoire ADP-#<id_adp>: contient les logs générés par les différents adaptateurs utilisés durant le test
Exemple pour sauvegarder le texte hello world dans un fichier my_logs depuis le cas de test
Private(self).saveFile(destname="my_logs", data="hello world")
Exemple pour ajouter du texte dans un fichier de log déjà existant
Private(self).appendFile(destname="my_logs", data="hello world2")
Note
Il est aussi possible de sauvegarder des fichiers depuis un adaptateur. Ils seront automatiquement stockés dans un répertoire portant le nom de l’adaptateur.
En cache¶
Le framework de test permet de stocker en cache des données sous la forme clé/valeur. Cette fonction peut être nécessaire pour partager des données entre tests lors de l’écriture d’un scénario par exemple.
Exemple pour sauvegarder une valeur dans le cache
Cache().set(name="my_data", data="hello")
Lire une valeur depuis le cache
my_data= Cache().get(name="my_data")
Trace(self).warning(my_data)
Exemple pour capturer une donnée avec une expression régulière et avec enregistrement dans le cache
my_data="March, 25 2017 07:38:58 AM"
Cache().capture(data=my_data, regexp=".* (?P<TIME>\d{2}:\d{2}:\d{2}) .*")
Trace(self).info( txt=Cache().get(name="TIME") )
Il est aussi possible de s’appuyer sur un paramètre de type custom
pour fournir l’expression régulière.
.*session_id=[!CAPTURE:SESSIONID:];expires.*
ou en mode greedy
.*session_id=[!CAPTURE:SESSIONID:.*?];.*
Important
Le cache n’existe que durant l’exécution d’un test.
Mettre en attente¶
Cette fonction permet de faire une pause durant l’exécution d’un test.
Exemple de mise en attente pendant 10 secondes:
Time(self).wait(timeout=10)
Exemple de mise en attente tant que la date et heure courante ne correspondent pas à la date indiquée:
Time(self).waitUntil(dt='2016-09-12 02:00:00', fmt='%Y-%m-%d %H:%M:%S', delta=0)
Interaction avec le testeur¶
Le framework permet d’écrire des tests semi-automatiques, c’est à dire en mode interaction. Cette fonction peut être intéressante pour faire un test en mode question/réponse (ex: configuration d’un équipement)
Exemple demandant le nom de la personne:
user_rsp = Interact(self).interact(ask="Your name?", timeout=30.0, default=None)
Depuis le client, l’onglet Interact
apparait automatiquement pour répondre à la question posée durant
l’exécution du test.
Cette fenêtre est disponible depuis le fenêtre d’analyse.
Note
Si aucune réponse n’est fournie dans le temps imparti, il est possible de fournir une valeur par défaut avec l’argument default
.
Paramètres d’un test¶
Paramètres¶
Les paramètres entrants (inputs) sont à utiliser pour ajouter des variables sur un test. Ils sont configurables depuis le client.
Les principaux types à utiliser sont:
Type | Description usage |
text | variable de type chaîne de caractères en mode avancé |
json | variable de type JSON en mode avancé |
global | les variables globales par projets |
Il existe plusieurs autres types de paramètres:
Type | Description usage |
str/pwd | chaîne de caractères |
list | liste de chaînes de caractères |
bool | valeur booléen |
hex | valeur hexadécimale |
none | valeur nulle |
alias | raccourci paramètre |
list-shared | liste de valeurs de variables projets |
cache | clé d’une valeur présente dans le cache |
int | entier |
float | décimal |
dataset | intègre un fichier de type dataset |
remote-image | intègre une image présente dans le dépôts de tests |
local-image | intègre une image présente en local sur un le poste |
snapshot-image | intègre une capture d’écran |
local-file | intègre un fichier présent en local sur le poste |
date | date |
time | heure |
date-time | date et heure |
self-ip | liste des adresses IP du serveur |
self-mac | liste des adresses MAC du serveur |
sef-eth | liste des interfaces réseau du serveur |
Les variables sont accessibles depuis un test avec la fonction input(...)
input('DEBUG')
Le paramètre custom
Le type custom
permet de construire des paramètres utilisants d’autre paramètre ou le cache.
Ils est donc possible d’utiliser des mots clés qui seront interprétés par le framework de test
au moment de l’exécution.
Liste des mots clés disponibles:
Mots clés | Description |
[!INPUT: :] |
Permet de récupérer la valeur d’un paramètre présent dans le test |
[!CACHE: :] |
Permet de récupérer une valeur présente dans le cache |
Note
Le nom d’un paramètre est unique et obligatoirement en majuscule.
Les agents¶
Il est possible d’accéder à la liste des agents depuis un test en utilisant le mode clé agent()
.
self.ADP_REST= SutAdapters.REST.Client(
parent=self,
destinationIp=input('HOST'),
destinationPort=input('PORT'),
debug=input('DEBUG'),
sslSupport=input('USE_SSL'),
agentSupport=input('SUPPORT_AGENT'),
agent=agent('AGENT_SOCKET')
)
Les probes¶
Import/export des paramètres¶
Les paramètres de tests peuvent être exportés dans un type de fichier dédié testconfig
(tcx).
Il est donc possible de travailler/préparer les paramètres sans avoir le test.
A l’inverse il est possible d’importer un fichier de configuration dans un test. L’import écrasera l’ensemble des paramètres si le nom est identique.