Qu'est-ce que le test SOA? Tutoriel avec exemple

Qu'est-ce que le test SOA?

Le test SOA (Service Oriented Architecture) est un test du 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.

Dans ce didacticiel, vous apprendrez-

• Qu'est-ce que SOA?
• Qu'est-ce que le service?
• Test SOA
• Stratégie pour les tests SOA
• Méthodes de test SOA
• Défis des tests SOA
• Outils de test SOA
• Cas d'utilisation des tests SOA

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 métier.

En génie logiciel, SOA offre agilité et flexibilité aux processus métier. Les modifications apportées au processus ou à l'application peuvent être dirigées vers un composant particulier sans affecter l'ensemble du système.

Les développeurs de logiciels de SOA développent ou achètent des morceaux de programmes appelés SERVICES.

Qu'est-ce que le service?

• Les services peuvent être une unité fonctionnelle d'application ou de processus métier, qui peut être réutilisée ou répétée par toute autre application ou processus.

  (Par exemple, dans l'image ci-dessus, la passerelle de paiement est un service qui peut être réutilisé par n'importe quel site de commerce électronique. Chaque fois qu'un paiement doit être effectué, le site de commerce électronique appelle / demande le service de passerelle de paiement. Une fois le paiement effectué le une passerelle, une réponse est envoyée sur le site e-commerce)
• Les services sont faciles à assembler et à reconfigurer les composants.
• Les services peuvent être comparés à des éléments constitutifs. Ils peuvent construire n'importe quelle application nécessaire. Les ajouter et les supprimer de l'application ou du processus métier est facile.
• Les services sont définis davantage par la fonction commerciale qu'ils exécutent que par des morceaux de code.

Services Web

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

Ils peuvent être publiés, trouvés et utilisés sur le Web. Ils peuvent communiquer via Internet.

1. Le fournisseur de services publie le service sur Internet.
2. Le client recherche un service Web particulier dans le registre des services Web
3. Une URL et le WSDL pour le service Web requis sont renvoyés.

   >> En utilisant le WSDL et l'URL, la communication entre le fournisseur de services et le demandeur se fait via des messages SOAP. <<

4. 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'appeler la logique de service Web requise.
5. La réponse reçue du fournisseur est un message SOAP qui sera intégré dans la réponse HTTP. Cette réponse HTTP est le format de données compréhensible par l'application grand public.

Exemple

Une page d'accueil d'un site Web et d'un moteur de recherche affiche le rapport météo quotidien. Au lieu de coder la section des bulletins météorologiques partout, un service de bulletin météorologique peut être acheté auprès d'un fournisseur et intégré dans les pages.

Test SOA

SOA se compose de diverses technologies. Les applications créées à l'aide de SOA ont divers services qui sont faiblement couplés.

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

Couche de services

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

Par exemple -

Considérez un site Web de bien-être qui se compose de

1. Suivi de poids
2. Suivi de la glycémie
3. Suivi de la pression artérielle

Les trackers affichent les données respectives et la date à laquelle elles sont entrées. La couche Services comprend les services qui récupèrent les données respectives de la base de données.

• Service de suivi du poids
• Service de suivi de la glycémie
• Service de suivi de la pression artérielle
• Service de connexion

Couche de processus

La couche de processus comprend les processus, la collection de services qui font partie d'une seule fonctionnalité.

Les processus peuvent faire partie de l'interface utilisateur (par exemple, un moteur de recherche), une partie d'un outil ETL (pour obtenir des données de la base de données).

L'objectif principal de cette couche sera les interfaces utilisateur et les processus.

L'interface utilisateur du tracker de poids et son intégration avec la base de données est l'objectif principal.

Les fonctions ci-dessous seront à prendre en considération

1. Ajouter de nouvelles données
2. Modifier les données existantes
3. Créer un nouveau tracker
4. Supprimer des données

Couche consommateur

Cette couche comprend principalement des interfaces utilisateur.

En fonction de la couche, le test d'une application SOA est réparti en trois niveaux.

1. Niveau de service
2. Niveau d'interface
3. Niveau de bout en bout

• L'approche descendante est utilisée pour la conception de tests.
• L'approche ascendante est utilisée pour l'exécution des tests.

Stratégie pour les tests SOA

Approche de planification des tests,

• L'architecture complète de l'application doit être comprise par les testeurs SOA.
• L'application doit être décomposée en services indépendants (service, qui a sa propre structure de demande et de réponse et ne dépend d'aucun autre service pour former la réponse).
• La structure de l'application doit être réorganisée en trois composants: les données, les services et les applications frontales.
• Tous les composants doivent être soigneusement analysés et les scénarios commerciaux doivent être mis à la craie.
• Les scénarios d'entreprise doivent être classés comme des scénarios courants et des scénarios spécifiques à l'application.
• Une matrice de traçabilité doit être préparée et tous les cas de test doivent être rattachés à des scénarios commerciaux.

Approche d'exécution des tests

• Chaque composant de service doit être testé.
• Intégration Des tests 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.
• Le test du système du modèle complet doit être effectué pour valider le flux de données entre l'application frontale et la base de données.
• Les tests de performance doivent être effectués pour un réglage fin et des performances optimales.

Méthodes de test SOA

1) Tests basés sur des données basés sur des scénarios commerciaux,

• Divers aspects commerciaux liés au système doivent être analysés.
• Les scénarios doivent être élaborés sur la base de l'intégration de
  • Différents services Web de l'application
  • Services Web et application.
• La configuration des données doit être effectuée sur la base des scénarios ci-dessus.
• La configuration des données doit être effectuée de manière à couvrir également les scénarios de bout en bout.

2) Bouts

• Des interfaces factices seront créées pour tester les services.
• Différentes 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 en cours de test (service tiers), un stub peut être créé pendant le test d'intégration.

3) Test de régression

• Des tests de régression sur l'application doivent être effectués lorsqu'il y a plusieurs versions 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 dans plusieurs versions du projet.

4) Test de niveau de service

Le test de niveau de service comprend le test du composant pour la fonctionnalité, la sécurité, les performances et l'interopérabilité.

Chaque service doit d'abord être testé indépendamment.

5) Test fonctionnel

Des tests fonctionnels doivent être effectués sur chaque service pour

• Assurez-vous que le service fournit la bonne réponse à chaque demande.
• Les bonnes erreurs sont reçues pour les demandes avec des données non valides, des données incorrectes, etc.
• Vérifiez chaque demande et réponse pour chaque opération que le service doit effectuer au moment de l'exécution.
• Validez les messages d'erreur lorsqu'une erreur survient au niveau du serveur, du client ou du réseau.
• Vérifiez que les réponses reçues sont dans le bon format.
• Validez que les données reçues sur la réponse correspondent aux données demandées.

6) Test de sécurité

Les tests de sécurité du service Web sont un aspect important lors des tests de niveau de service de l'application SOA; cela garantit la sécurité de l'application.

Les facteurs suivants doivent être couverts lors des tests:

• La norme de l'industrie définie par les tests WS-Security doit être respectée par le service Web.
• Les mesures de sécurité doivent fonctionner parfaitement.
• Cryptage des données et signatures numériques sur les documents
• Authentification et autorisation
• Injection SQL, Malware, XSS, CSRF, d'autres vulnérabilités sont à tester sur le XML.
• Attaques par déni de service

7) Test de performance

Le test des performances du service doit être effectué 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:

• 8) Les performances et la fonctionnalité du service doivent être testées sous une charge importante.
• Les performances du service doivent être comparées tout en travaillant individuellement et au sein de l'application avec laquelle il est couplé.
• Le test de charge du service doit être effectué
  • pour vérifier le temps de réponse
  • pour vérifier les goulots d'étranglement
  • pour vérifier l'utilisation du processeur et de la mémoire
  • pour prédire l'évolutivité

9) Test de niveau d'intégration

• Les tests de niveau de service garantissent le bon fonctionnement des seuls services individuellement, ils ne garantissent pas le fonctionnement des composants couplés.
• Les tests d'intégration sont effectués principalement sur les interfaces.
• Cette phase couvre tous les scénarios commerciaux possibles.
• Le test non fonctionnel de l'application doit être effectué une fois de plus au cours de cette phase. La sécurité, la conformité et les tests de performance garantissent la disponibilité et la stabilité du système sous tous ses aspects.
• Les protocoles de communication et de réseau doivent être testés pour valider la cohérence de la communication de données entre les services.

10) Test de bout en bout

Cette phase garantit que l'application répond aux exigences de l'entreprise à la fois fonctionnellement et non fonctionnellement.

Les éléments ci-dessous sont garantis pour être testés pendant les 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 correct à travers tous les composants
• Processus d'affaires

Défis des tests SOA

• Manque d'interfaces pour les services
• Le processus de test s'étend sur plusieurs systèmes, créant ainsi des besoins de données complexes
• L'application est un ensemble de divers composants qui ont tendance à changer. Le besoin de tests de régression est plus fréquent.
• En raison de l'architecture multicouche, il est difficile d'isoler les défauts.
• Étant donné que le service sera utilisé dans différentes interfaces, il est difficile de prévoir la charge, ce qui complique la planification des tests de performances.
• SOA est un ensemble de technologies hétérogènes. Le test d'une application SOA nécessite des personnes possédant des compétences différentes, ce qui augmente les coûts de planification et d'exécution.
• Étant donné que l'application est une intégration de plusieurs services, les tests de sécurité ont leur propre part de problèmes. La validation de l'authentification et de l'autorisation est assez difficile.

Outils de test SOA

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

1) Interface utilisateur SOAP

"SOAP UI" est un outil de test fonctionnel open source pour les services et les tests 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 appelés.
• Peut également être utilisé pour les tests de charge, les tests d'automatisation et les tests de sécurité
• Les stubs peuvent être créés par MockServices
• Les demandes et tests de service Web peuvent être générés automatiquement via son client de service Web.
• Avoir des outils de reporting intégrés
• Développé par SmartBear

2) iTKO LISA

"LISA" est une suite de produits qui fournit une solution de test fonctionnel pour les systèmes distribués comme SOA.

• Peut également être utilisé pour les tests de régression, d'intégration, de charge et de performance.
• Développé par iTKO (CA Technologies)
• Peut être utilisé pour concevoir et exécuter des tests.

3) Test de service HP

"Service Test" est un outil de test fonctionnel, qui prend en charge les tests d'interface utilisateur et de services partagés

• Les tests fonctionnels et de performance des services peuvent être effectués par un seul script.
• Intégré à HP QC.
• La 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 client JEE, AXIS et DotNet.
• Développé par HP.

4) Test Parasoft SOA

SOA Test est une suite d'outils de test et d'analyse développée pour les tests d'applications API et API.

• Prend en charge les services Web, REST, JSON, MQ, JMS, TIBCO, HTTP, 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.
• Les stubs peuvent être créés à l'aide de Parasoft Virtualize, qui sont plus intelligents que SOAP UI.
• Développé par ParaSoft

Cas d'utilisation des tests SOA

Considérez un site Web de commerce électronique, qui contient les fonctions et sous-fonctions ci-dessous:

commande en cours de traitement

LA PHASE 1

Dans la première phase de test SOA, c'est-à-dire la phase de stratégie de test, l'application est divisée en services et fonctions métier.

Considérons ci-dessous les services de l'application.

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

Les fonctions commerciales sont les mêmes que les fonctions du site Web.

Remarque: Le document de stratégie de test contiendrait la liste du service et des fonctions à tester.

PHASE 2

Phase de planification des tests. Les cas de test sont écrits pour chaque niveau.

1. Niveau de bout en bout. Les cas de test sont écrits pour chaque cas d'utilisation métier et chaque flux.

   Voici l'exemple de cas de test

   • Créez une commande avec l'utilisateur actif.
   • Créez une commande avec un utilisateur inactif.
   • Créez une commande avec le produit disponible avec la quantité de commande
   • Créez une commande avec le produit disponible avec quantité de commande> quantité disponible.
   • Créer une commande avec plusieurs articles
   • Annulez complètement une commande.
   • Annuler partiellement la commande.
2. Niveau d'intégration. Les cas de test sont écrits pour l'intégration de la base de données et de l'interface utilisateur.

   Voici 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é de produit disponible est inférieure au montant de la commande.
   • Vérifiez que l'état de la commande affiché sur l'interface utilisateur est le même que celui de 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.
   • Pour le premier paiement, vérifiez que les détails de paiement saisis sur l'interface utilisateur sont enregistrés dans la base de données.
   • Pour retourner des paiements, vérifiez que les détails du paiement dans la base de données sont affichés sur l'interface utilisateur.
3. Niveau de service. Chaque service est testé pour toutes les conditions de données.

Voici quelques exemples.

Non.	détails de la commande	Condition de commande
1	Créer une commande. Nombre d'articles = 1	Quantité sur commande
2	Créer une commande. Nombre d'articles> 1	Quantité sur commande
3	Créer un numéro de commande 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
dix	Vérifier la disponibilité des produits	ID de produit = invalide

PHASE 3 - Exécution des tests

L'exécution des tests utilise une approche ascendante, c'est-à-dire que les tests de niveau de service sont effectués en premier, puis au niveau d'intégration et enfin de bout en bout.

1) Niveau de service

Considérons que l'outil Soapui est considéré pour tester l'application.

Le WSDL et l'URL sont parcourus dans la fenêtre de test de SOAP.

La demande pour chaque service sera affichée dans la fenêtre de demande.

En modifiant les données selon les cas de test de niveau de service, des demandes sont créées pour chaque cas de test.

Cas de test	Demander	Réponse attendue
Créer une commande. Nombre d'articles = 1Quantité sur commande	x2 2	o3251 Réussi
Créer une commande. des articles> 1Quantité sur commande	y11 y2 3	o3251 Réussi
Créer OrderNo. d'articles = 1Quantité sur commande> Quantité sur db	x23 200	null Échec
Vérifier l'état de la commande Statut sur la base de données = Actif	o9876	Active Réussi
Vérifier l'état de la commande Statut sur la base de données = Expédié	o9656	Expédié Réussi
Vérifier l'état de la commandeOrder id = Invalid	y5686	null Échec
Vérifier la disponibilité du produit Quantité de produit> 0	d34	34 oui Successful
Vérifier la disponibilité du produit Quantité de produit = 0	y34	0no Successful
Vérifier la disponibilité du produit ID de produit = invalide	sder	Échec

2) Niveau d'intégration

Les cas de test de niveau d'intégration sont exécutés sur l'interface utilisateur et la base de données.

• Créer une commande avec un seul article -
• Un utilisateur ouvre le site Web.
• Va passer une commande.
• Sélectionne un produit et une quantité valides et enregistre la commande.
• Un message indiquant que la commande a été passée avec succès doit être affiché.
• Un utilisateur ouvre la base de données et vérifie si les détails de la commande sont les mêmes que ceux saisis sur le site.

3) Niveau de bout en bout

Les flux commerciaux et les cas d'utilisation sont exécutés sur l'interface utilisateur.

• Créer une commande avec plusieurs articles -
• Un utilisateur ouvre un site Web.
• Va passer une commande.
• Renseigne sur un produit valide et la quantité les ajoute au panier.
• D'autres produits valides sont ajoutés avec des quantités valides et la commande est enregistrée. Le paiement s'effectue via un nouveau mode de paiement et la commande est passée.
• Un message indiquant "Commande passée avec succès" devrait s'afficher.
• Un testeur doit valider que tout le flux est effectué sans biais des données.

Conclusion:

En esquissant la bonne stratégie pour les tests, les ressources, les outils et la conformité pour fournir un bon service, les tests SOA peuvent fournir une application complètement et parfaitement testée.