Test fonctionnel de webservices sur un bureau multi écran

Le test de web services avec Agilitest

31 janvier 2020

L’objectif de cet article est de présenter la création de tests fonctionnels de webservices avec Agilitest. Nous ne reviendrons pas sur ce qu’est un services web (en anglais web services) ni son rôle dans une Architecture Orientée Services car la littérature est déjà abondante sur le sujet.

Pourquoi des tests de web services dans Agilitest

Il suffit de savoir que généralement ces services sont très étroitement liés avec les processus métiers pour comprendre tout l’intérêt qu’il y a d’automatiser les tests dans le cadre d’une campagne de tests fonctionnels ou tests d’acceptance. Les possibilités sont multiples mais nous pouvons notamment citer :

  • Les tests sur plusieurs canaux qui permettent de réaliser une transaction sur un terminal donné (Web sur PC, App sur Android…), et ensuite de vérifier le résultat de l’opération en utilisant un web service dédié.
  • L’inverse est aussi possible : permettre de visualiser dans une application que les données insérées en utilisant un web service sont bien visibles et utilisables.
  • Les tests de web services de type « annuaire » qui doivent délivrer une information nécessaire à un processus global : réaliser des tests de type sanity-checks de ces services en amont de tests plus globaux permet de rapidement identifier les causes d’échecs.
  • On peut citer aussi les sanity-checks de web services en production qui permettent de réagir rapidement si le service venait à ne plus répondre dans les conditions prévues.

C’est dans cette optique que nous avons considéré qu’il était nécessaire d’intégrer la gestion des tests de web services dans Agilitest.

Le test web service en multicanal

Ouverture d’un canal web services avec Agilitest

Agilitest permet de tester des web services sur les deux technologies dominantes : SOAP, très structuré ayant un flux de retour en XML et REST, plus récent et très souple, ayant un flux de retour en JSON.

L’ouverture du canal se fait de la même façon que tout type de canal ouvert dans Agilitest, par l’action « Démarrer un canal ». L’utilisateur sélectionne l’adresse de son web service et éventuellement l’authentification désirée en HTTP.

Evidemment, il est possible d’avoir des canaux ouverts sur d’autres applications en même temps permettant de récupérer des informations et de réaliser des contrôles : les canaux de test web service sous Agilitest sont complètement intégrés avec les canaux sur les autres technologies.

Le test de web service graphique

L’ensemble des informations renvoyées par le web services sont visibles dans un « viewer » de web services interne à Agilitest.

SOAP : Visualisation des services disponibles

L’appel d’un service se fait en utilisant l’action de navigation web service REST ou web service SOAP.

Définition de la méthode d’appel du web service : SOAP ou JSON

L’appel d’un web service REST permet de définir quelle « method » est utilisée pour récupérer les informations. Il est ensuite possible d’ajouter un en-tête.

Navigation vers un Webservice SOAP en utilisant Agilitest
Navigation vers un web service SOAP

Le retour de l’appel du web service est affiché dans notre viewer, et le mode capture d’Agilitest est automatiquement activé.

Cela permet d’aller sélectionner directement les éléments de réponses que nous souhaitons récupérer. Le fonctionnement du locator Agilitest est identique à ce qui est déja mis en oeuvre sur les autres technologies : complétement graphique, bénéficiant de la puissance des expressions régulières, l’utilisation des éléments sélectionnés pour générer des actions se fait ensuite en drag-droppant le locator dans l’éditeur.

Affichage et capture du résultat d'un webservice SOAP en utilisant Agilitest
Affichage et capture du résultat

La gestion des certificats

Agilitest supporte la gestion des certificats clients pour la réalisation des tests de web services, il suffit de recopier les certificats au format « .pfx » sous l’arborescence « assets/certs ».

Selon les chemin du certificat dans le répertoire « assets/certs » le certificat sera appliqué aux scripts ATS situés selon la même organisation hiérarchique, par ex. un certificat à la racine de « assets/certs » sera appliqué pour tous les script ATS, un certificat situé dans « assets/certs/ws/functional/domain » sera appliqué pour tous les scripts ATS situés à partir du répertoire « src/ats/ws/functional/domain »

Une intégration parfaite

Au final, l’intégration du tests de web services dans Agilitest a été rendu parfaitement identique aux autres technologies que nous supportons : très graphique et bénéficiant de l’ensemble des fonctionnalités d’Agilitest : gestion des canaux, gestion des variables, les sous-scripts et le data-driven-testing, etc.

Un ensemble de fonctions techniques plus complexes comme la gestion des certificats pour les connexions sécurisées était nécessaire et a aussi été implémenté : cela fait d’Agilitest un concurrent sérieux des solutions les plus performantes du marché, la simplicité en plus.

Questions courantes sur Agilitest et le test de webservices

Notre webinaire du 26 Septembre « Test de webservices avec Agilitest » s’est terminé et vous avez été nombreux à y participer et à poser des questions, nous vous en remercions.

Dans le test SOAP présenté (villes) il y a 3 tests, est-il possible de factoriser notamment un bloc qui est appelé 3 fois ?

L’exemple montré commence par une ouverture de canal, et ensuite plusieurs requêtes sont réalisées en effet successivement.

Il n’y avait là pas de réel scénario mais vous pouvez faire entre 1 et n appels webservices selon vos besoins en factorisant le code dans des sous-scripts

L’utilisation des sous-scripts peut même est soumise à variabilisation : le nom des sous-scripts et le nom des fichiers csv peuvent contenir des variables.

Dans un contexte DevOps, à quel moment devrait-on jouer une campagne de tests auto de webservices ?

Il est conseillé en effet d’adopter une méthode TestOps qui est au DevOps ce que le test en continu est au développement en continu.

Votre pipeline de releases sera donc constitué de Sprint de développement -> Test auto -> Mise en prod (si OK) et Ticket de suivi (si KO).

Si vos processus internes automatisent l’étape de tests, il est certain que cela se fait avant (et conditionne) toute mise en production.

Si vous souhaitez aller plus vie pour la mise en production, vous pouvez rejouer un subset de vos tests, représentatif de vos tests de non régression et les nouveautés, mais auparavant il faut que vous ayez une politique de test de non régressions complet plus régulière.

Sur des tests de performances, peut-on avoir un rapport hebdomadaire ?

Agilitest peut s’utiliser conjointement avec Neoload pour réaliser des tests de performances. Les rapports sont alors générés par Neoload et non pas par Agilitest.

Cela dit il est possible de générer un rapport personnalisé avec Agilitest au format attendu (PDF, XLS, etc) à partir des données brutes XML. Une feuille de style XSLT permet notamment la production d’un PDF.