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 test
  • prepare: préparation des adaptateurs et librairies permettant de communiquer avec le système à tester ou piloter
  • definition: déroulement du test
  • cleanup: 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ès
  • FAILED: au moins une étape est en erreur après exécution
  • UNDEFINED: 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.

../_images/espace_public.png

Les fichiers sont stockés dans le répertoire [...]/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.

../_images/private_storage.png
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
../_images/private_storage_zip.png

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.

../_images/adapter_private.png

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.

../_images/client_cache.png

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") )
../_images/client_cache_capture.png

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.

../_images/client_interact.png

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

../_images/client_properties_agent.png ../_images/client_agent_support.png

Il est possible d’accéder à la liste des agents depuis un test en utilisant le mode clé input().

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=input('AGENT_SOCKET')
                                         )

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.

../_images/client_testconfig_export.png

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.

../_images/client_testconfig_import.png