Tester vos Webservices : Pourquoi est-ce important ?

Toutes les activités du web sont conçues en se reposant sur ce que l’on appelle des webservices. Ils sont indépendants et permettent de faciliter l’intégration de services sur tous les canaux. C’est ce qui est généralement appelé une architecture SOA.

Ce choix d’architecture est dans l’air du temps car il permet une grande réutilisabilité de fonctionnalité. En contrepartie, il implique une grande interdépendance de fonctions qui sont essentielles au bon fonctionnement de plusieurs applications, voire toutes les applications d’un même domaine fonctionnel. Techniquement parlant, les choix réalisés sont le plus souvent des web services REST, voire SOAP.

A titre d’exemple, on pourrait citer les processus d’authentification sur les applications, permettant ainsi d’unifier les comptes des utilisateurs. Un bénéfice certain pour l’utilisateur mais aussi pour les annonceurs. En effet, cette approche permet une plus grande efficacité dans la gestion de la relation client.

Dysfonctionnement de webservices : quel impact pour votre site ?

La réponse est simple : c’est la catastrophe ! Tester directement ces  webservices est ainsi un moyen simple de réagir vite en cas d’incident. Cela évite de tester fonctionnellement l’ensemble des applications qui reposent sur ledit service.

Pour aller un peu plus loin dans la démarche, de nombreux processus métiers, sont construits sur la base d’enchaînements d’appels de ces webservices. Il devient alors possible de tester des processus complets et d’effectuer un large panel de vérifications garantissant la cohérence des informations de ces services.

Webservices : exemple des frais de port

On pourrait ainsi imaginer le cas suivant. Un site E-commerce, dont les calculs de frais dépendent du montant total du panier et éventuellement de différentes zones de livraison, sont gérés par un partenaire externe, via un web service. Il est alors indispensable de tester de manière régulière que le calcul est correct, afin de ne pas décevoir l’utilisateur.

Cet exemple est intéressant ! De plus en plus souvent, les applications sont construites pour déléguer ce type de traitement à un opérateur tiers, spécialisé en logistique et en livraison. Ces services sont donc fréquemment proposés par des partenaires et il est très important de vérifier la qualité du service rendu, notamment sur 3 critères :

• La disponibilité du service. On parle ici souvent de SLA (Service Level Agreement). L’objectif est de vérifier ici que le partenaire respecte ses engagements de bon fonctionnement du service.
• La fiabilité du service. Il s’agit ici plutôt d’une vérification fonctionnelle dont le but est de garantir que les données du service sont cohérentes. On pourrait presque parler ici de tests unitaires.
• Les performances. On s’attend à ce que le moteur de recherche externalisé ou le prestataire logistique propose des services dans des délais acceptables. Evidemment, l’expérience utilisateur ainsi que les performances ressenties sont en jeu. Par ailleurs, vérifier les performances en service régulier est un point, simuler de fortes hausses de trafic est un deuxième sujet. Pour traiter cet aspect, la planification des campagnes de tests de montée en charge est indispensable. En accord avec les différents partenaires, ces tests permettent de valider que toute la chaîne sera en mesure d’accueillir sans peine les pics de trafic inhérents à l’activité de l’annonceur.

Contrôles des webservices d’un processus d’authentification

Le test des web services dans une architecture SOA permet en outre une agilité accrue en termes de déboggage et de localisation d’erreurs.

Prenons un exemple simple. Un scénario utilisateur simule un achat sur un site Ecommerce. Ce scénario échoue lors de l’authentification. Imaginons que deux services sont appelés pendant le processus d’authentification. Le premier effectue le contrôle des login et mot de passe. Le second quant à lui, récupère le carnet d’adresse de l’internaute, afin de proposer une simulation de prix de livraison à l’étape suivante. En monitorant ces deux services de manière indépendante, il devient alors très simple d’identifier la cause de l’échec du scénario utilisateur. Vous pouvez ainsi identifier lequel des deux services n’a pas fonctionné conformément aux spécifications. Que ce service soit développé en interne ou soit délégué à un partenaire importe peu : seule la réactivité compte dans ce type de situation.

Cas des applications mobiles.

Netvigie intervient régulièrement dans le cadre de monitoring d’applications mobiles. Le test de ces applications via émulateurs ou même depuis le device lui-même est complexe et souvent source d’alertes erronées. La vérification du bon fonctionnement d’une application mobile est, à notre sens, un processus qui précède toute mise en exploitation de ladite application. Ce processus de recette est souvent assuré en interne ou par des partenaires spécialisés, comme Stardust, par exemple.

En revanche, ce qui ne peut être maîtrisé pendant le processus de recette d’une application mobile, c’est l’architecture de Web services sur laquelle elle repose. Le degré d’autonomie des applications mobiles dans un environnement ultra connecté est de plus en plus faible. Il est donc déterminant de vérifier de manière régulière la fiabilité des services qui assurent son bon fonctionnement.