Qu'est-ce qu'un test SOA ? Tutoriel avec exemple
Qu’est-ce que les tests SOA ?
SOA (Orienté Services ArchiLes tests de technologie sont des tests de style architectural SOA dans lesquels 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.
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 SOA développent ou achètent des morceaux de programmes appelés PRESTATIONS DE SERVICE.
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, Payment Gateway 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é sur une passerelle, une réponse est envoyé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 base. Ils peuvent créer n’importe quelle application nécessaire. Les ajouter et les supprimer de l’application ou du processus métier est simple.
- Les services sont davantage définis par la fonction métier qu’ils exécutent plutôt 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.
- Le fournisseur de services publie le service sur Internet.
- Le client recherche un service Web particulier dans le registre des services Web.
- Une URL et le WSDL du service Web requis sont renvoyés. À l'aide du WSDL et de l'URL, la communication entre le fournisseur de services et le demandeur s'effectue via des messages SOAP.
- Lorsqu'un consommateur appelle un service Web, une connexion HTTP sera établie avec le fournisseur.
Un message SOAP est créé pour demander au fournisseur d'appeler la logique de service Web requise. - La réponse reçue du fournisseur est un message SOAP qui sera intégré à la réponse HTTP. Cette réponse HTTP est le format de données compréhensible par l'application consommateur.
Exemple
Une page d'accueil d'un site Web et d'un moteur de recherche affiche un bulletin météo quotidien. Au lieu de coder entièrement la section des bulletins météorologiques, un service de bulletin météo peut être acheté auprès d'un fournisseur et intégré dans les pages.
Tests SOA
SOA se compose de diverses technologies. Les applications créées à l’aide de SOA disposent de divers services 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étiers.
Par exemple -
Considérez un site Web de bien-être composé de
- Suivi du poids
- Suivi de la glycémie
- Traqueur de tension artérielle
Les trackers affichent les données respectives et la date à laquelle elles sont saisies. La couche Services comprend les services qui obtiennent 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 tension artérielle
- Service de connexion
Couche de processus
La couche de processus comprend les processus, ensemble de services qui font partie d'une fonctionnalité unique.
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'accent principal de cette couche sera mis sur les interfaces utilisateur et les processus.
L'interface utilisateur du suivi de poids et son intégration avec la base de données sont l'objectif principal.
Les fonctions ci-dessous seront à prendre en considération
- Ajout de nouvelles données
- Modification des données existantes
- Création d'un nouveau tracker
- Supprimer des données
Couche consommateur
Cette couche comprend principalement les interfaces utilisateur.
Basé sur la couche, le test d'une application SOA est réparti en trois niveaux.
- Niveau de service
- Niveau de l'interface
- 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 possède sa propre structure de requête et de réponse et ne dépend d'aucun autre service pour former une réponse).
- La structure des applications doit être réorganisée en trois composants : données, services et applications frontales.
- Tous les composants doivent être soigneusement analysés et des scénarios commerciaux doivent être élaborés.
- Les scénarios commerciaux doivent être classés en scénarios courants 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 rattachés à des scénarios commerciaux.
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 du modèle complet doit être effectué pour 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 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 développés sur la base de l’intégration de
- Divers Les services Web de l'application
- Services et applications Web.
- 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) Talons
- Des interfaces factices seront 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é (service tiers), un stub peut être créé lors des tests d'intégration.
3) Tests de régression
- Les tests de régression sur l'application doit être effectuée lorsqu'il existe 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) Tests de niveau de service
Les tests de niveau de service comprennent 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) Tests fonctionnels
Des tests fonctionnels doivent être effectués sur chaque service pour
- Assurez-vous que le service fournit la bonne réponse à chaque demande.
- Des erreurs correctes sont reçues pour les demandes contenant des données invalides, 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.
- Valider que les données reçues sur la réponse correspondent aux données demandées.
6) Tests 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 pris en compte lors des tests :
- La norme industrielle 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 Digisignatures réelles sur les documents
- Authentification et autorisation
- Injection SQL, Malware, XSS, CSRF, autres vulnérabilités sont à tester sur le XML.
- Attaques par déni de service
7) Tests de performances
Des tests de performances 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.
- Les performances du service doivent être comparées en travaillant individuellement et au sein de l'application avec laquelle il est couplé.
- Des tests de charge du service doivent être effectués
- 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
- prédire l'évolutivité
8) Tests de niveau d'intégration
- Les tests de niveau de service garantissent le bon fonctionnement uniquement des services individuellement, ils ne garantissent pas le fonctionnement des composants couplés.
- Les tests d'intégration sont effectués en se concentrant principalement sur les interfaces.
- Cette phase couvre tous les scénarios commerciaux possibles.
- Les tests non fonctionnels de l'application doivent être effectués une nouvelle fois au cours de cette phase. Les tests de sécurité, de conformité et de performances 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 des données entre les services.
9) Tests de bout en bout
Cette phase garantit que l'application répond aux exigences métier à la fois fonctionnellement et non fonctionnellement.
Il est garanti que les éléments ci-dessous seront 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 approprié à 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 à évoluer. 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édire la charge, ce qui rend la planification des tests de performances fastidieuse.
- SOA est un ensemble de technologies hétérogènes. Les tests d'une application SOA nécessitent 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é comportent leur lot 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 plus populaires Outils de test SOA:
1) Interface utilisateur SAVON
« SOAP UI » 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 demandes et les tests du 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 performances.
- 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 performances 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 clients JEE, AXIS et DotNet.
- Développé par HP.
4) Test SOA Parasoft
SOA Test est une suite d'outils de test et d'analyse développée pour les tests d'API et d'applications API.
- Prend en charge les technologies Web Services, REST, JSON, MQ, JMS, TIBCO, HTTP, 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 l'interface utilisateur SOAP.
- Développé par ParaSoft
Cas d'utilisation des tests SOA
Considérons un site Web de commerce électronique, qui contient les fonctions et sous-fonctions ci-dessous :
Traitement de la commande
PHASE 1
Dans la première phase des tests 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 le statut du client
- Modifier le statut de la commande
- Vérifier le statut de la commande
- Vérifier l'inventaire
Les fonctions commerciales étant les mêmes que les fonctions du Site Internet.
Remarque : Le document de stratégie de test contiendrait la liste du service et des fonctions qui doivent être testées.
PHASE 2
Phase de planification des tests. Des cas de tests sont rédigés pour chaque niveau.
- Niveau de bout en bout. Les cas de test sont rédigés pour chaque cas d'utilisation et flux métier. Ci-dessous l'exemple de cas de tests
- 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é commandée < quantité disponible.
- Créez une commande avec le produit disponible avec quantité commandée > quantité disponible.
- Créer une commande avec plusieurs articles
- Annulez complètement une commande.
- Annuler la commande partiellement.
- 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. 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 inférieure au montant de la commande.
- Vérifiez que le statut de la commande affiché sur l'interface utilisateur est le même que celui sur 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 du premier paiement, vérifiez que les informations de paiement saisies sur l'interface utilisateur sont 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é pour toutes les conditions de données.
Voici quelques exemples.
No. | 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é sur commande < Quantité sur base de données. |
3 | Créer une commande n° 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, c'est-à-dire que les tests de niveau de service sont effectués en premier, puis au niveau d'intégration et enfin. Tests de bout en bout.
1) Niveau de service
Considérons que Soapui L'outil est pris en compte pour tester l'application.
Le WSDLName et l'URL sont parcourus dans la fenêtre de test de SOAP.
La demande pour chaque service sera affichée sur la fenêtre de demande.
En modifiant les données selon les scénarios de test de niveau de service, des demandes sont créées pour chaque scénario de test.
Cas de test | Requêter | Réponse attendue |
---|---|---|
Créer une commande. Nombre d'articles = 1Quantité sur commande < Quantité sur base de données | x2 2 | o3251 Réussi |
Créer un numéro de commande. d'articles > 1 quantité sur commande < quantité sur base de données | y1 1 y2 3 | o3251 Réussi |
Créer un numéro de commande. d'articles = 1Quantité sur commande > Quantité sur base de données | x23 200 | nul Infructueux |
Vérifier le statut de la commande sur la base de données = Actif | o9876 | Actif Réussi |
Vérifiez le statut de la commande sur la base de données = Expédié | o9656 | Expédié Réussi |
Vérifier le statut de la commandeID de commande = Invalide | y5686 | nul Infructueux |
Vérifier la disponibilité du produitQuantité du produit >0 | d34 | 34 Oui Réussi |
Vérifier la disponibilité du produitQuantité du produit =0 | y34 | 0 Non Réussi |
Vérifier la disponibilité du produitID produit = invalide | sder | Infructueux |
2) Niveau d'intégration
Les cas de tests de niveau 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 devrait ê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 Web.
3) Niveau de bout en bout
Les flux métiers 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.
- Les demandes concernant un produit valide et la quantité les ajoutent 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 l'ensemble du flux est effectué sans distorsion des données.
Conclusion
En esquissant la bonne stratégie en matière de tests, de ressources, d'outils et de conformité pour fournir un bon service, les tests SOA peuvent fournir une application entièrement et parfaitement testée.