katalon studio
Malgré leurs atouts indéniables, gain de temps, efficacité, nombre de cas de tests traités… les tests automatiques sont souvent ignorés. Certains frameworks simplifient la création et la maintenance de ces tests.
Pour cause, nous y associons régulièrement une certaine complexité de développement et la nécessité d’avoir une ressource spécialisée possédant des connaissances élevées, notamment lors de l’utilisation d’outils tels que Selenium.
Néanmoins, il existe certains frameworks, tel Katalon Studio, permettant de simplifier ces tests :
Développé par la société du même nom, Katalon Studio s’inscrit dans une suite logicielle simplifiant l’automatisation des tests, qu’ils visent les APIs, les IHMs ou encore les applications mobiles ou desktop.
Une multitude de ces fonctionnalités grandit sans cesse et la communauté active qui l’accompagne permet d’étendre le champ des possibles via un store. Dans cet article, j’utilise la version gratuite de Katalon Studio, disponible au téléchargement sur cette page.
Afin de créer un premier projet simple, nous utilisons SWAPI, une API permettant de récupérer un grand nombre d’informations sur l’univers Star Wars. Je vous mets à disposition la documentation ici.
Une fois notre premier projet vierge créé, nous commençons à créer nos éléments en débutant par nos profils. Ces derniers sont destinés à contenir des variables globales, je vous expliquerai un petit peu plus tard comment les utiliser. Il peut s’agir de l’adresse du serveur d’API, d’une clé, d’un ID d’application, du nom d’une base de données, etc.
Pour créer un nouveau profil, faites un clic-droit sur Profiles >> New >> Exécution Profile. Ouvrez ce profil, il vous est désormais possible d’ajouter des variables à ce dernier. Ajoutons l’adresse de notre serveur d’API.
Notre environnement étant prêt, nous allons créer notre premier objet. Au sens de Katalon, un objet peut décrire un endpoint d’API, tout comme un élément d’une page web ou d’une application mobile. Nous pouvons très vite nous retrouver submergés par ces objets donc n’hésitez pas à les hiérarchiser de manière stricte pour ne pas vous y perdre.
Ici, nous allons créer un endpoint manuellement. Vous pouvez également importer des collections via SOAPUI, Swagger, ou encore OpenAPI.
Dans l’Object Repository, donc, un nouveau clic-droit afin de créer notre objet Web Service. Ici, rien de compliqué, il vous suffit d’indiquer :
En cas de besoin, il est possible d’ajouter une authentification via l’onglet Authorization ou simplement en adaptant le HTTP Header à vos besoins. Vous pouvez aussi utiliser les variables de profil.
Certaines API utilisent des paramètres, dans ce cas, il suffit d’ajouter au tableau Query Parameters le couple nom/valeur. Ici, l’URL est automatiquement adaptée pour utiliser ce ou ces paramètre(s). Bien entendu, la valeur peut être variabilisée comme nous allons pouvoir le constater.
L’onglet variable permet de gérer toutes les variables utilisées en interne par l’objet, qu’il s’agisse de paramètres de la requête ou de valeurs utilisées dans le body de la requête. Cela nous permettra, par la suite, d’utiliser cet endpoint avec les données souhaitées lors de l’utilisation dans des cas de tests, ou même de suites de tests. Nous ajoutons une nouvelle variable en précisant son nom, son type et si besoin, une valeur par défaut. Cela permet de tester l’API indépendamment d’un cas de test.
Cette variable, locale à l’objet, peut être nommée par la syntaxe ${nom_de_la_variable} comme dans cet exemple, dans l’URL ou dans le body de l’appel.
Nous pouvons déjà utiliser notre API en l’exécutant avec le premier bouton à droite de l’URL. Le bouton ‘+’ vous permet de créer directement un cas de test avec cet objet, ou bien, de l’ajouter à un cas de test existant.
À droite, nous avons le retour de l’API (code retour HTTP, corps de la réponse, header, etc.). Il nous permet de lancer des vérifications post-exécution, dans l’onglet Verification. Il s’agit d’un script Groovy, modifiable à volonté. Et sera lancé, si demandé, après le retour de l’API.
Il n’est pas indispensable de savoir coder pour ajouter quelques contrôles ici, puisque des snippets prédéfinis sont intégrés. Nous allons juste tester le code retour HTTP 200. Nous cliquons sur le snippet correspondant et le code est automatiquement ajouté.
Une fois nos endpoints paramétrés, nous créons un premier cas de test simple, le tout sans avoir à coder. Puisque nous sommes dans l’univers Star Wars, notre cas sera le suivant : nous allons vérifier que la personne dont l’identifiant est 1 est bien Luke Skywalker.
Nous créons donc cette fois un Test Case, nous l’appellerons Luke Skywalker. Pour l’instant vidé, nous lui ajoutons un Web Service Keyword. Par défaut, c’est le Send Request qui est sélectionné, mais nous allons choisir Send Request And Verify. La différence entre les deux est subtile car nous allons utiliser le script de vérification de l’objet plutôt que de refaire le nôtre dans le cas de test.
Dans la colonne Objet, nous choisissons notre objet People, l’API permettant de récupérer les données des personnages par ID. Vous voyez qu’ici, nous avons une variable avec la valeur par défaut de l’objet, soit 5. Nous testons le personnage 1 et surchargeons donc la valeur de la variable avec 1. Le résultat sera un objet que nous allons appeler « personne », à indiquer dans la colonne Output.
Passons à l’exécution du cas en testant le contenu de cet objet. Pour cela, nous ajoutons un mot-clé qui se nomme « Verify Element Property Value ». Il permet de contrôler le contenu d’un champ dans le JSON de sortie de l’API. En cliquant sur le contenu de la colonne Input, nous pouvons définir l’objet en entrée, le champ et la valeur recherchée : « personne », « name » et « Luke Skywalker ».
Nous exécutons ce cas de test, notre résultat est OK. Si le test est KO, c’est rouge.
Allons un peu plus loin ! Par exemple, vérifions que tous les personnages de l’univers Star Wars sont bien à leur place dans la base de SWAPI.
La première chose à faire est de variabiliser le nom et l’id du personnage recherché dans notre cas de test.
Créons une copie de notre cas de test « Luke Skywalker » et appelons la « Recherche personnage par ID ». Nous allons utiliser l’ongletVariables et créer deux éléments :
Nous pouvons, comme dans l’objet, donner des valeurs par défaut en reprenant ici « 1 » et « Luke Skywalker ». Maintenant, nous allons utiliser ces variables dans notre script.
Retournons dans l’onglet Manual et dans l’objet People. Nous remplaçons le nombre par une variable. Le type de la donnée est donc maintenant une variable et nous allons utiliser notre « idPersonne ». Dans l’action de vérification, même manip, nous remplaçons la chaîne de caractères par une variable, « nomPersonne ».
Désormais, à l’aide d’un fichier contenant nos données de tests, nous allons pouvoir tester tous les personnages. Le fichier est simple, au format Excel, et contient 2 colonnes : une pour le nom et une pour l’identifiant. Nommons-les de la même manière que nos variables du cas de test « idPersonnage » et « nomPersonnage », très vite, vous allez comprendre pourquoi.
Afin de l’utiliser dans Katalon, nous créons un Data File et l’appelons « Données tests personnages ». Nous chargeons le fichier et… nos données de test sont prêtes. Rien de plus à faire, tout est prêt pour lancer une campagne de tests en masse.
On y va ? Tout d’abord, créons une suite de tests dans laquelle nous ajouton notre cas de test de recherche de personnages par ID. Le bouton Show Data Binding permet de lier notre fichier de données à notre cas de test. Nous l’ajoutons donc.
Ensuite, en cliquant sur Map All, Katalon va automatiquement lier les colonnes de notre fichier aux variables du cas de test. Voilà pourquoi le nommage des colonnes du fichier Excel a son importance. En effet, lorsque vous avez un fichier contenant 60 données différentes, le nommage est fort utile. Sinon, nous aurions pu lier les données aux colonnes manuellement, évidemment. Voilà, notre objet fonctionne, notre cas de test également, nos données sont créées, notre suite de test également, il ne nous reste plus qu’à lancer tout ça !
Quelques minutes votre automatisation de tests est faite. Très rapidement, et sans aucune ligne de code à taper, nous avons construit une suite de tests, certes simples, mais reproductibles à plus grande échelle et utilisables rapidement, quelle que soit la taille du jeu de données en entrée.
Il ne s’agit ici que d’une première incursion dans le monde de Katalon et de l’automatisation. Une multitude d’autres outils sont disponibles, permettant de travailler avec des bases de données, des fichiers PDF, des images, etc. L’intégration dans un outil tel que Jenkins est également possible afin de lancer des tests de non-régression à chaque déploiement sans effort.
Pour peu que l’on structure bien ses projets, il sera très simple de réutiliser les composants créés afin de générer simplement des cas de tests et des suites de tests complets, proposant une couverture très large.
Alain,
Expert tests logiciels
Néo-Soft Groupe : retrouvez nos offres d’emploi sur notre page entreprise ou au sein de l’espace carrière de notre site internet. Découvrez nos articles technophiles, rédigés par nos collaborateurs, sur notre page Lab.go.
Les maladies inflammatoires chroniques de l’intestin ou "MICI" sont invisibles, mais leurs impacts sur la…
Depuis l'été, j'ai un Pixel qui intègre à la fois un TPU (Tensor Processing Unit)…
On se retrouve dans un nouvel article avec toutes les infos sur cette nouvelle saison…
Pourquoi l’inclusion numérique est essentielle : le point avec Mathieu Froidure. Dans un monde de…
Elles sont passées où les femmes dans la tech ? Entre le manque de représentation…