Variabiliser vos scénarios de tests sans coder
Lorsque l’on créé un parcours fonctionnel dans le cadre de l’élaboration d’un test de non-régression, la réelle première difficulté arrive avec la volonté de variabiliser le parcours.
En effet, si le parcours a été enregistré en mode « live recorder » (Ex : Recorder SELENIUM IDE), le parcours est linéaire et toujours identique. L’objectif du testeur est de l’adapter pour, par exemple, le faire jouer sur des appareils différents (Chrome, Firefox, Edge), avec différents identifiants de connexion et une navigation aléatoire…
Bien sûr, les développeurs diront qu’il suffit de coder cela avec le langage de programmation (Java, C#, Python, …), mais justement le testeur n’est pas un développeur… Nous allons voir comment variabilisé sans coder avec CloudNetCare.
La variabilisation des appareils et navigateurs
Une des premières déclinaisons d’un parcours fonctionnel est de s’assurer qu’il s’exécute correctement sur différents appareils, que ce soient des navigateurs, des téléphones ou des tablettes. Dans CloudNetCare, il suffit de sélectionner les « devices cibles » dans la liste disponible et le parcours sera jouer autant de fois que de « Devices ».
Dans certain cas, il peut être nécessaire d’adapter certaines étapes spécifiquement pour un appareil ou un navigateur web. L’étape du scénario est alors conditionnée pour un ou plusieurs « Devices ».
Le scénario reste unique et peut s’adapter à des spécificités particulières d’un « Device » (ex : taille d’écran, …)
La variabilisation du login et mot de passe
La variabilisation prédictible permet de répondre à la problématique des couples (login/mot de passe) qui doivent être connus à l’avance, dans un ordre prédéfini.
Pour faire cela, dans CloudNetCare, il suffit d’importer une liste (login/mot de passes) à partir d’un fichier .csv et de sélectionner les champs de saisie à remplacer dans le scénario en cliquant sur les icônes correspondantes :
Pendant l’exécution du test, les champs paramétrés seront remplacés successivement dans l’ordre au fur et à mesure de l’instanciation des tests. Une option spécifique permet de garantir l’unicité du couple (login/mot de passe) pour s’assurer qu’il ne sera utilisé qu’une seule fois.
Cela est utile dans les tests de formulaires de création de compte ou l’unicité de l’email est obligatoire. Ce type de variabilisation est aussi particulièrement utile dans le cadre de tests de charges ou de performance.
Les variables de scénarios (locales, globales)
Avec l’utilisation de SELENIUM la création de scénarios est basée sur une succession d’étapes toutes identifiées par 3 paramètres (Command, Target, Value). Un scénario peut être sauvegardé dans un fichier au format JSON ou visualisé graphiquement dans CloudNetCare.
Dans le contexte d’un scénario, il peut être utile de stocker des valeurs dans des variables. On peut vouloir par exemple stocker une valeur lue sur l’interface pour la ré-utiliser sur une étape ultérieure.
Avec SELENIUM IDE, une variable peut être stockée avec les commandes de type « Store », puis ré-utilisée avec la syntaxe suivante : ${nom_variable}
Exemples avec un script JSON :
Stocker Bonjour dans variable1 :
{
« command »: « store »,
« target »: « variable1 »,
« value »: « Bonjour »
},
Utilisation de variable1 pour cliquer sur le bouton identifié par name=Bonjour:
{
« command »: « click »,
« target »: « name=${variable1} »,
},
Stocker le texte pointé par target dans la variable priceToPay
{
« command »: « storeText »,
« target »: « css=section>dl>dd:nth-child(2) »,
« value »: « priceToPay »
},
Comme les scripts SELENIUM sont intégrés en import/export dans CloudNetCare, toute la gestion des variables est entièrement fonctionnelle dans CloudNetCare.
Par défaut dans SELENIUM les variables ont une portée qui reste au sein du scénario.
Dans certain cas, il est souhaitable que les variables puissent être utilisées entre plusieurs scénarios.
Dans CloudNetCare, il suffit que le nom de la variable soit préfixé par « global » pour que sa portée soit automatiquement globalisée. Elle est donc persistée dans le temps, pour toutes les exécutions de tous les scénarios du compte utilisateur.
Exemple : ${globalVariable1}
La variabilisation aléatoire des parcours utilisateurs
Lorsque l’on souhaite rendre des parcours utilisateurs plus réalistes, principalement lors d’un test de charge, il est souhaitable que les utilisateurs prennent des chemins différents, tout en effectuant le même parcours. Par exemple le parcours d’achat avec une sélection de produits aléatoires.
Pour réaliser simplement cela, on peut utiliser les variables de scénario. En effet, il est possible de définir la valeur d’une variable avec une fonction javascript, puis d’utiliser cette valeur dans le parcours.
Exemple :
Exécuter un Javascript pour stocker un résultat aléatoire dans productNb (exemple: ‘product153’) :
{
« command »: « store »,
« target »: » javascript{‘product’+Math.floor((Math.random()*1000))} »,
« value »: « productNb »
},
Exemple de génération d’email aléatoire (exemple: ‘prefix56165@yopmail.com) :
{
« command »: « store »,
« target »: » javascript{‘prefix’+Math.floor((Math.random()*10000000000))+’@yopmail.com’} »,
« value »: « randomEmail »
},
Grâce à cette technique, toute valeur dans un parcours peut être variabilisée très simplement. Grâce au Javascript et l’utilisation de variables, il est également possible de récupérer des collections de valeurs depuis l’interface et de « piocher » aléatoirement dedans pour effectuer une action ultérieure.
Exemple : récupérer la liste des tailles de produits présente sur une page et sélectionner une taille aléatoirement dans cette liste)
La variabilisation avec des jeux de données
Dans le cadre des tests fonctionnels, l’utilisation des jeux de données est la technique la plus efficiente de variabilisation. En effet, elle conjugue l’utilisation de variables SELENIUM et de valeurs définis (ou calculés), tout cela à partir d’un simple fichier Excel.
La première étape consiste à préparer son scénario avec les variables à « injecter » en utilisant la syntaxe SELENIUM suivante : ${in_NomVariable, ValeurParDéfaut}.
Le « _in » permet d’indiquer que la variable sera remplacée par un jeu de donnée en « entrée » (sinon la valeur par défaut sera utilisée).
Exemple 1 : Click sur une barre de menu définie en « DataSet »
Exemple 2 : Vérification d’un texte via « DataSet »
Toutes les variables de types « _in » sont disponibles être remplacées par une valeur en provenance d’un jeu de données.
Un jeu de données est tout simplement une suite de valeurs dans un fichier Excel.
Chaque cellule Excel est évaluée et la valeur d’un jeu de donnée peut être une expression.
Il est également possible de récupérer des valeurs depuis l’interface avec les commandes de type Store de SELENIUM et des variables préfixées par « _out ». Par exemple, il est possible de lire une valeur sur l’écran d’un site web et de l’utiliser dans une expression pour « calculer » une valeur qui remplira une variable « _in ».
En utilisant cette fonctionnalité, il est possible de « coder » une logique de test dans Excel avec des expressions évaluées dans les cellules. Toute la logique de test est alors entièrement décorréler de la partie « scripting » SELENIUM.
Sur un gros projet d’automatisation, la séparation des compétences et des responsabilités et un facteur de succès dans le temps.
L’automaticien reste concentré sur la maintenance des scripts SELENIUM et le testeur fonctionnel fait évoluer ses cas de tests avec un fichier Excel, tout simplement.
La variabilisation des scénarios de test dans CloudNetCare
La puissance d’un outil de test en mode SaaS comme CloudNetCare est la versatilité des usages. Un même et unique scénario peut être utilisé très simplement dans différents contextes pour valider la non-régression fonctionnelle.
Les différents types de variabilisation permettent de répondre à différents usages, d’un test de charge variabilisé à un test fonctionnel agrémenté de jeux de données évalués, tout cela sur plusieurs appareils en parallèle et sans aucune connaissance en programmation.
L’approche de séparation de la logique de test de l’implémentation des scripts permet de minimiser la maintenance tout en maximisant la couverture testée.
UX Functional testing
UX Functional testing
UX Functional testing