Qu'est-ce qu'un test SOA ? Tutoriel avec exemple

Qu’est-ce que les tests SOA ?

SOA (Orienté Services Architest de structure) Il s'agit de tester le style architectural SOA, dans lequel les composants de l'application sont conçus pour communiquer via des protocoles de communication, généralement sur un réseau.

Qu'est-ce que SOA ?

SOA est une méthode d'intégration d'applications et de processus métier afin de répondre aux besoins de l'entreprise.

In Génie logicielL'architecture orientée services (SOA) offre agilité et flexibilité aux processus métier. Une modification apportée à un processus ou à une application peut cibler un composant particulier sans affecter l'ensemble du système.

Les développeurs de logiciels travaillant dans le domaine de l'architecture orientée services (SOA) développent ou achètent des modules de programmes appelés services.

Qu'est-ce que le service ?

Le schéma ci-dessous illustre une passerelle de paiement proposée comme un service que plusieurs sites de commerce électronique peuvent appeler.

• Un service peut être une unité fonctionnelle d'une application ou d'un processus métier, réutilisable par toute autre application ou tout autre processus. (Par exemple, dans l'image ci-dessus, la passerelle de paiement est un service réutilisable par tout site de commerce électronique. Lorsqu'un paiement doit être effectué, le site de commerce électronique appelle ou sollicite le service de passerelle de paiement. Une fois le paiement effectué sur la passerelle, une réponse est renvoyée au site de commerce électronique.)
• Les services sont faciles à assembler et les composants faciles à reconfigurer.
• Les services peuvent être comparés à des éléments de construction. Ils permettent de créer n'importe quelle application nécessaire, et il est facile de les ajouter ou de les supprimer de l'application ou du processus métier.
• Les services sont davantage définis par la fonction métier qu'ils remplissent que par des blocs de code.

Services Web

La plupart des services SOA sont exposés en tant que services web ; il est donc important de définir les mécanismes d’un appel de service web avant les couches de test.

Les services Web Ce sont des composants d'application indépendants disponibles sur le web.

Ces services peuvent être publiés, trouvés et utilisés sur le web, et communiquent via Internet. La séquence ci-dessous illustre l'interaction entre un fournisseur, un registre et un consommateur.

• Le fournisseur de services publie le service sur Internet.
• Le client recherche un service Web particulier dans le registre des services Web.
• A URL et la WSDLName Les données du service web requis sont renvoyées. En utilisant le WSDL et le URLLa communication entre le fournisseur de services et le demandeur s'effectue par le biais de messages SOAP.
• Lorsqu'un consommateur appelle un service web, une connexion HTTP est établie avec le fournisseur.
• Un message SOAP est créé pour indiquer au fournisseur d'invoquer la logique de service Web requise.
• La réponse reçue du fournisseur est un message SOAP intégré à la réponse HTTP. Cette réponse HTTP correspond au format de données compréhensible par l'application consommatrice.

Exemple

La capture d'écran ci-dessous montre un bulletin météorologique fourni par un service externe et intégré à la page d'accueil d'un moteur de recherche.

La page d'accueil d'un site web et un moteur de recherche affichent un bulletin météo quotidien. Plutôt que de développer cette section soi-même, il est possible d'acheter un service de bulletins météo auprès d'un fournisseur et de l'intégrer aux pages.

Couches de test SOA

L'architecture orientée services (SOA) comprend diverses technologies, et les applications construites avec la SOA comportent différents services faiblement couplés. Le diagramme ci-dessous illustre les trois couches qu'un plan de test doit couvrir.

Les tests SOA doivent se concentrer sur 3 couches système.

Couche de services

Cette couche est constituée des services exposés par un système, dérivés des fonctions métier.

Prenons par exemple un site web de bien-être composé de :

• Poids Tracker
• Blood Sugar Tracker
• Tension artérielle Tracker

TracLes fonctions `ker` affichent les données correspondantes et la date de leur saisie. La couche de services comprend les services qui récupèrent les données correspondantes de la base de données :

• Poids Tracservice ker
• Blood Sugar Tracservice ker
• Tension artérielle Tracservice ker
• Service de connexion

Couche de processus

La couche processus est constituée des processus, c'est-à-dire l'ensemble des services qui font partie d'une fonctionnalité unique.

Ces processus peuvent faire partie d'une interface utilisateur (par exemple, un moteur de recherche) ou d'un outil ETL qui extrait des données de la base de données.

Cette couche se concentre principalement sur les interfaces utilisateur et les processus. L'interface utilisateur du poids tracL'objectif principal est le fonctionnement de ker et son intégration avec la base de données.

Les fonctions suivantes sont à prendre en considération :

• Ajout de nouvelles données
• Modification des données existantes
• Créer un nouveau tracker
• Supprimer des données

Couche consommateur

Cette couche comprend principalement les interfaces utilisateur, comme l'illustre la capture d'écran ci-dessous.

En fonction de ces couches, les tests d'une application SOA sont répartis en trois niveaux :

• Niveau de service
• Niveau de l'interface
• Niveau de bout en bout

Les deux approches diffèrent : une approche descendante est utilisée pour la conception des tests, tandis qu’une approche ascendante est utilisée pour leur exécution.

Stratégie pour les tests SOA

Approche de planification des tests

• Les testeurs SOA doivent comprendre l'architecture complète de l'application.
• L'application doit être décomposée en services indépendants (un service qui possède sa propre structure de requête et de réponse et qui ne dépend d'aucun autre service pour former une réponse).
• La structure de l'application doit être réorganisée en trois composantes : les données, les services et les applications frontales.
• Tous les éléments doivent être analysés avec soin et des scénarios d'affaires doivent être élaborés.
• Les scénarios métier doivent être classés en scénarios communs et en scénarios spécifiques à l'application.
• A Matrice de traçabilité doivent être préparés, et tous les cas de test doivent être tracadapté aux scénarios d'entreprise.

Approche d’exécution des tests

• Chaque composant de service doit être testé.
• Test d'intégration des composants de service doivent être effectués pour valider le flux de données à travers les services et l'intégrité des données.
• Test du système Une modélisation complète doit être réalisée afin de valider le flux de données entre l'application frontale et la base de données.
• Test de performance doit être effectué pour un réglage précis et des performances optimales.

Méthodes de test SOA

1) Tests basés sur les données et axés sur des scénarios d'entreprise

• Il convient d'analyser différents aspects commerciaux liés au système.
• Des scénarios doivent être élaborés en fonction de l'intégration des différents services web de l'application, et des services web avec l'application.
• La configuration des données doit être effectuée en fonction des scénarios ci-dessus.
• La configuration des données doit également couvrir les scénarios de bout en bout.

2) Talons

• Des interfaces factices sont créées pour tester les services.
• Diverses entrées peuvent être fournies via ces interfaces et les sorties peuvent être validées.
• Lorsqu'une application utilise une interface vers un service externe qui n'est pas testé (un service tiers), un stub peut être créé lors des tests d'intégration.

3) Tests de régression

• Les tests de régression Cette opération doit être effectuée lors de plusieurs mises à jour de l'application, afin de garantir la stabilité et la disponibilité des systèmes.
• Une suite complète de tests de régression sera créée couvrant les services qui constituent une partie importante de l'application.
• Cette suite de tests peut être réutilisée pour plusieurs versions du projet.

4) Tests de niveau de service

Les tests de niveau de service comprennent le contrôle des fonctionnalités, de la sécurité, des performances et de l'interopérabilité des composants. Chaque service doit être testé individuellement au préalable.

5) Tests fonctionnels

Essais fonctionnels devrait être fait à chaque intervention pour :

• Veillez à ce que le service apporte la réponse appropriée à chaque demande.
• S'assurer que les erreurs appropriées sont reçues pour les requêtes contenant des données invalides ou erronées.
• Vérifiez chaque requête et réponse pour chaque opération que le service doit effectuer lors de son exécution.
• Validez les messages d'erreur lorsqu'une erreur se produit au niveau du serveur, du client ou du réseau.
• Vérifiez que les réponses reçues sont dans le bon format.
• Vérifiez que les données reçues en réponse correspondent aux données demandées.

6) Tests de sécurité

Les tests de sécurité du service web constituent un aspect important des tests au niveau du service de l'application SOA, car ils garantissent la sécurité de l'application.

Les facteurs suivants doivent être pris en compte lors des tests :

• Le service web doit respecter la norme industrielle définie par WS-Security.
• Les mesures de sécurité doivent fonctionner parfaitement.
• Cryptage des données et signatures numériques sur les documents.
• Authentification et autorisation.
• Les injections SQL, les logiciels malveillants, les attaques XSS, CSRF et autres vulnérabilités seront testés sur le système. XML.
• Attaques par déni de service.

7) Tests de performances

Des tests de performance du service doivent être effectués car les services sont réutilisables et plusieurs applications peuvent utiliser le même service.

Les facteurs suivants sont pris en compte lors des tests :

• Les performances et les fonctionnalités du service doivent être testées sous une forte charge.
• Il convient de comparer les performances du service lorsqu'il fonctionne individuellement et lorsqu'il est intégré à l'application.
• Test de charge Des tests du service doivent être effectués pour vérifier le temps de réponse, détecter les goulots d'étranglement, vérifier l'utilisation du processeur et de la mémoire, et prévoir l'évolutivité.

8) Tests de niveau d'intégration

• Les tests de niveau de service garantissent le bon fonctionnement de chaque service individuellement ; ils ne garantissent pas le fonctionnement des composants couplés.
• Les tests d'intégration sont réalisés en se concentrant principalement sur interfaces.
• Cette phase couvre tous les scénarios commerciaux possibles.
• Il convient de procéder une nouvelle fois à des tests non fonctionnels de l'application au cours de cette phase. Les tests de sécurité, de conformité et de performance garantissent la disponibilité et la stabilité du système à tous les niveaux.
• Les protocoles de communication et de réseau doivent être testés pour valider la cohérence de la communication des données entre les services.

9) Tests de bout en bout

Cette phase garantit que l'application est conforme aux exigences métier, tant sur le plan fonctionnel que non fonctionnel.

Les éléments ci-dessous seront assurément testés pendant tests de bout en bout:

• Tous les services fonctionnent comme prévu après l'intégration
• Gestion des exceptions
• Interface utilisateur de l'application
• Flux de données approprié à travers tous les composants
• Processus d'affaires

Défis liés aux tests SOA

L'application de ces méthodes est rarement simple, et les difficultés décrites ci-dessous se retrouvent dans presque tous les programmes SOA.

• Absence d'interfaces pour les services.
• Le processus de test s'étend sur plusieurs systèmes, ce qui engendre des besoins complexes en matière de données.
• L'application étant un ensemble de composants variés qui ont tendance à évoluer, les tests de régression sont plus fréquents.
• Du fait de son architecture multicouche, il est difficile d'isoler les défauts.
• Puisqu'un service est utilisé par différentes interfaces, la charge est difficile à prévoir, ce qui rend la planification des tests de performance complexe.
• L'architecture orientée services (SOA) est un ensemble de technologies hétérogènes. Tester une application SOA requiert des personnes aux compétences variées, ce qui augmente les coûts de planification et d'exécution.
• L'application intégrant plusieurs services, les tests de sécurité présentent leur lot de difficultés. La validation de l'authentification et de l'autorisation s'avère complexe.

Outils de test SOA

De nombreux outils de test SOA sont disponibles sur le marché pour aider les testeurs à tester les applications SOA. Voici quelques-uns des outils de test SOA les plus populaires.

1) SoapUI

SoapUI est un outil de test fonctionnel open source pour les services et Test d'API.

• Application de bureau
• Prend en charge plusieurs protocoles : SOAP, REST, HTTP, JMS, AMF, JDBC
• Les services Web peuvent être développés, inspectés et invoqués.
• Peut également être utilisé pour les tests de charge, Tests d'automatisationet tests de sécurité
• Les talons peuvent être créés par MockServices
• Les requêtes et les tests de service Web peuvent être générés automatiquement via son client de service Web.
• Intègre des outils de reporting
• Développé par SmartBear, qui expédie à la fois le open-source SoapUI distribution et commercial ReadyAPI édition

2) Virtualisation des services Broadcom (anciennement iTKO LISA)

LISA est une suite logicielle offrant une solution de test fonctionnel pour les systèmes distribués tels que l'architecture orientée services (SOA). Ce produit, initialement développé par iTKO, a été repris par CA Technologies et est aujourd'hui commercialisé sous le nom de Broadcom Service Virtualization.

• Peut également être utilisé pour les tests de régression, d'intégration, de charge et de performance.
• Peut être utilisé pour concevoir et exécuter des tests.

3) UFT Un (anciennement HP Service Test)

Service Test est un outil de test fonctionnel qui prend en charge les tests d'interface utilisateur et de services partagés. Ses fonctionnalités de test d'API ont été intégrées à Unified Functional Testing, désormais commercialisé par OpenText as UFT One.

• Un seul script permet de réaliser à la fois les tests fonctionnels et de performance des services.
• Intégré à Quality Center, maintenant vendu sous le nom de OpenText ALM / Centre de qualité.
• Une quantité massive de services et de données peut être gérée.
• Prend en charge les tests d'interopérabilité en simulant les environnements clients JEE, AXIS et DotNet.

4) Parasoft SOAtest

Parasoft SOAtest est une suite d'outils de test et d'analyse développée pour les tests d'API et d'applications pilotées par API.

• Prend en charge les services Web, REST, JSON, MQ, JMS, TIBCO, HTTP et les technologies XML.
• Des tests fonctionnels, unitaires, d'intégration, de régression, de sécurité, d'interopérabilité, de conformité et de performance sont possibles.
• Des ébauches peuvent être créées à l'aide de Parasoft Virtualiser, qui sont plus capables que SoapUI Services fictifs.

Cas d'utilisation des tests SOA

L'exemple pratique ci-dessous applique la stratégie, les méthodes et les outils décrits ci-dessus à un seul site de commerce électronique, phase par phase.

Prenons l'exemple d'un site web de commerce électronique qui contient les fonctions et sous-fonctions ci-dessous.

Traitement de la commande

Le schéma ci-dessous décompose le traitement des commandes en sous-fonctions qui deviennent des services.

PHASE 1

Dans la première phase des tests SOA, la phase de stratégie de test, l'application est décomposée en services et en fonctions métier.

Examinons ci-dessous les services proposés dans l'application.

• Créer une commande
• Vérifier le statut du client
• Modifier le statut de la commande
• Vérifier le statut de la commande
• Vérifier l'inventaire

Les fonctions métier sont identiques aux fonctions du site web.

Remarque : Le document de stratégie de test contiendra la liste des services et des fonctions qui doivent être testés.

PHASE 2

Il s'agit de la phase de planification des tests. Cas de test Des textes sont rédigés pour chaque niveau.

Niveau de bout en bout. Des cas de test sont rédigés pour chaque cas d'utilisation et flux métier. Vous trouverez ci-dessous des exemples de cas de test.

• Créer une commande avec un utilisateur actif.
• Créez une commande avec un utilisateur inactif.
• Créez une commande avec un produit disponible dont la quantité commandée est inférieure à la quantité disponible.
• Créez une commande avec un produit disponible dont la quantité commandée est supérieure à la quantité disponible.
• Créez une commande avec plusieurs articles.
• Annulez complètement une commande.
• Annulation partielle d'une commande.

Niveau d'intégration. Des cas de test sont rédigés pour l'intégration de la base de données et de l'interface utilisateur. Vous trouverez ci-dessous des exemples de cas de test.

• Créez une nouvelle commande avec un seul article. Vérifiez que la commande est créée sur la base de données.
• Créez une nouvelle commande avec un seul article. Vérifiez que le prix calculé pour la commande est correct.
• Créez une nouvelle commande avec un seul article. Vérifiez que la quantité du produit disponible est bien réduite du montant de la commande.
• Vérifiez que le statut de la commande affiché dans l'interface utilisateur correspond à celui enregistré dans la base de données.
• Annulez la commande et vérifiez que le statut de la commande est modifié dans la base de données.
• Lors d'un premier paiement, vérifiez que les informations de paiement saisies dans l'interface utilisateur sont bien enregistrées dans la base de données.
• Pour renvoyer des paiements, vérifiez que les détails du paiement dans la base de données sont affichés sur l'interface utilisateur.

Niveau de service. Chaque service est testé dans toutes les conditions de données. Voici quelques exemples.

Non.	Détails des commandes	État de la commande
1	Créer une commande. Nombre d'articles = 1	Quantité en commande < Quantité sur base de données
2	Créer une commande. Nombre d'articles > 1	Quantité commandée < Quantité enregistrée dans la base de données
3	Créer une commande. Nombre d'articles = 1	Quantité sur commande > Quantité sur base de données
4	Vérifier l'état des commandes	Statut sur la base de données = Actif
5	Vérifier l'état des commandes	Statut sur la base de données = Expédié
6	Vérifier l'état des commandes	Statut sur la base de données = Annulé
7	Vérifier l'état des commandes	ID de commande = invalide
8	Vérifier la disponibilité des produits	Quantité de produit >0
9	Vérifier la disponibilité des produits	Quantité de produit =0
10	Vérifier la disponibilité des produits	Identifiant du produit = invalide

PHASE 3 — Exécution des tests

L'exécution des tests utilise une approche ascendante : les tests au niveau du service sont effectués en premier, puis ceux au niveau de l'intégration, et enfin les tests de bout en bout.

1) Niveau de service

Considérons que le SoapUI Cet outil est utilisé pour tester l'application. Le WSDL et URL sont affichés dans la fenêtre de test de SoapUILa requête pour chaque service s'affiche dans la fenêtre de requête. En modifiant les données conformément aux cas de test du niveau de service, des requêtes sont créées pour chaque cas de test.

Cas de test	Demander	Réponse attendue
Créer une commande. Nombre d'articles = 1, quantité commandée < quantité en base de données	x2 2	o3251 Réussi
Créer une commande. Nombre d'articles > 1, quantité commandée < quantité enregistrée dans la base de données	y1 1 y2 3	o3251 Réussi
Créer une commande. Nombre d'articles = 1, quantité commandée > quantité dans la base de données	x23 200	nul Infructueux
Vérifier le statut de la commande. Statut dans la base de données : Active	o9876	Actif Réussi
Vérifier le statut de la commande. Statut dans la base de données : Expédiée	o9656	Expédié Réussi
Vérifier le statut de la commande. Numéro de commande = Invalide	y5686	nul Infructueux
Vérifier la disponibilité du produit. Quantité de produit > 0	d34	34 Oui Réussi
Vérifier la disponibilité du produit. Quantité de produit = 0	y34	0 Non Réussi
Vérifier la disponibilité du produit. L'identifiant du produit est invalide.	sder	Infructueux

2) Niveau d'intégration

Les tests d'intégration sont exécutés sur l'interface utilisateur et la base de données. Créez une commande avec un seul article :

• Un utilisateur ouvre le site Web.
• L'utilisateur va passer une commande.
• L'utilisateur sélectionne un produit et une quantité valides, puis enregistre sa commande.
• Un message confirmant la bonne réception de la commande devrait s'afficher.
• L'utilisateur ouvre la base de données et vérifie si les détails de la commande correspondent à ceux saisis sur le site web.

3) Niveau de bout en bout

Les flux métier et les cas d'utilisation sont exécutés sur l'interface utilisateur. Créer une commande avec plusieurs articles :

• Un utilisateur ouvre le site Web.
• L'utilisateur va passer une commande.
• L'utilisateur se renseigne sur un produit valide et sa quantité, puis l'ajoute à son panier.
• D'autres produits valides sont ajoutés avec les quantités souhaitées et la commande est enregistrée. Le paiement est effectué via un nouveau mode de paiement et la commande est validée.
• Un message indiquant « Commande passée avec succès » devrait s'afficher.
• Un testeur doit vérifier que le flux complet s'exécute sans distorsion des données.

FAQ