Katalon, le côté lumineux de la force

Malgré des avantages indéniables : gain de temps, efficacité, nombre de cas de tests traités… les tests automatiques sont encore trop souvent mis de côté.

Pour cause, on y associe régulièrement une certaine complexité de développement et la nécessité d’avoir une ressource spécialisée possédant des connaissances avancées, notamment dans le cas d’outils tels que Selenium.

Néanmoins, il existe certains frameworks, comme 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 destinée à simplifier l’automatisation des tests, qu’ils visent les APIs, les IHMs ou encore les applications mobiles ou desktop.

Afin de créer un premier projet simple, nous allons utiliser SWAPI, une API permettant de récupérer beaucoup d’informations sur l’univers Star Wars. Vous pourrez trouver la documentation ici.

Après avoir créé notre premier projet vierge, nous allons commencer à créer nos éléments dont, en premier lieu, nos profils. Ils sont destinés à contenir des variables globales, nous verrons 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, cliquez-droit sur Profiles puis New >> Exécution Profile. Ouvrez ce profil et vous pouvez désormais ajouter des variables à ce dernier. Ajoutons l’adresse de notre serveur d’API.

Petite astuce : n’hésitez pas à créer une variable contenant le nom de votre environnement, pour conditionner l’exécution de certaines fonctions si besoin.

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. On peut très vite se retrouver submergé 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, mais 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 suffit d’indiquer :

• le nom en clair
• l’adresse (on utilise notre variable de profil avec la syntaxe ${GlobalVariable.nom_de_la_variable})
• un descriptif succinct de l’API

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 également 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). Évidemment, 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. On ajoute une nouvelle variable en précisant son nom, son type et une valeur par défaut si besoin. Cela nous permet de tester l’API indépendamment d’un cas de test.

Cette variable, locale à l’objet, peut être appelée par la syntaxe ${nom_de_la_variable} comme dans cet exemple, dans l’URL ou dans le body de l’appel.

On peut déjà utiliser notre API en l’exécutant avec le premier bouton à droite de l’URL. Le bouton ‘+’ permet de créer directement un cas de test avec cet objet ou 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.). Ce retour nous permet de lancer des vérifications post-exécution, dans l’onglet Verification. Il s’agit d’un script Groovy que l’on peut modifier à volonté. Il sera lancé, si demandé, après le retour de l’API.

Pas besoin 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. Un clic sur le snippet correspondant et le code est automatiquement ajouté.

Une fois nos endpoints paramétrés, nous pouvons créer 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. Il est vide pour l’instant, nous allons donc ajouter 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 allons choisir 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 allons tester le personnage 1 et surchargeons donc la valeur de la variable avec 1. Le résultat sera un objet que nous allons appeler « personne », il suffit de l’indiquer dans la colonne Output.

Nous allons tester le contenu de cet objet. Ajoutons donc un mot-clé qui se nomme « Verify Element Property Value » permettant 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 nom du champ et enfin la valeur recherchée : « personne », « name » et « Luke Skywalker ».

Nous pouvons exécuter ce cas de test et le résultat est OK. Si le test est KO, c’est rouge.

Si nous allions un peu plus loin ? Par exemple, si on vérifiait que tous les personnages de l’univers Star Wars étaient bien à leur place dans la base de SWAPI ?

Première chose à faire, nous allons variabiliser le nom et l’id du personnage recherché dans notre cas de test.

1. Créons une copie de notre cas de test « Luke Skywalker » et appelons la « Recherche personnage par ID ». Nous allons utiliser l’ongletVariableset créer deux éléments :

• idPersonnage qui sera un nombre
• nomPersonnage qui sera une chaîne de caractères

Nous pouvons, comme dans l’objet, donner des valeurs par défaut, nous reprenons ici « 1 » et « Luke Skywalker ». Maintenant, nous allons utiliser ces variables dans notre script.

Retournons dans l’onglet Manual et dans l’objet People où nous allons remplacer 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 chose, nous remplaçons la chaîne de caractères par une variable, « nomPersonne ».

Maintenant, à 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 contiendra 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 », vous comprendrez très vite pourquoi.

Afin de l’utiliser dans Katalon, nous allons créer un Data File et nous l’appellerons « Données tests personnages ». Nous chargeons le fichier et… nos données de test sont prêtes. Rien de plus à faire, nous sommes prêts à lancer une campagne de tests en masse.

On y va ? En premier lieu, créons une suite de tests dans laquelle nous pouvons ajouter notre cas de test de recherche de personnages par ID. Le bouton Show Data Binding va nous permettre de lier notre fichier de données à notre cas de test. Nous ajoutons donc notre fichier de données.

Quelques minutes plus tard, c’est fait. Très rapidement, et sans aucune ligne de code à taper, nous avons pu construire 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 que d’une première incursion dans le monde de Katalon et de l’automatisation. Beaucoup 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.