WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

SOA : Définition, Utilisation dans le monde de la banque et méthodologie de test

( Télécharger le fichier original )
par Cédric MORA
IFIPS - Maison de l'ingénieur - Spécialité informatique 2008
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

LES BASES DE LA MÉTHODOLOGIE DE TEST

On peut identifier certains points importants lorsque l'on teste un service d'une architecture SOA : la distribution, les données, le comportement, l'intégrité, la conception et le niveau de performance des services. Les services sont distribués au sein de l'entreprise dans des environnements hétérogènes et peuvent être découverts en cours d'exécution. Une architecture SOA n'est pas figée et la découverte dynamique de service implique une phase de tests couvrant cette possibilité. Le test des données est critique car il faut contrôler les données utilisées par le service et vérifier la cohérence entre les données entrantes et sortantes. Les messages qui circulent contiennent beaucoup de champs (les services sont appelés de façon indépendante et n'ont pas d'état prédéfini donc pas de contexte) et les possibilités de permutations des champs sont importantes. Le comportement d'un service est bien sûr ce qu'il y a de plus important : est-ce qu'il répond correctement à ce pour quoi il a été créé ? Et si le service a plusieurs fonctionnalités, il faut le surveiller pendant tous les traitements. L'intégrité permet de savoir jusqu'à quel point un service est capable de continuer à jouer son rôle pendant une longue période. Ces tests doivent bien sûr refléter des cas d'utilisations possibles en production. Tester la conception d'un service permet de savoir si pour un service particulier et sa fonctionnalité intrinsèque, le bon patron de conception (design pattern) est utilisé. Cette phase demande une attention particulière car elle demande une interaction entre les architectes, les designers et les développeurs. Enfin, le dernier point correspond au niveau de performance spécifique que peut fournir un service et mesurer ce niveau en condition réelle pour voir s'il respecte bien le niveau prévu. Un mauvais niveau de performance d'un service peut faire baisser la performance globale de l'architecture SOA : un processus d'orchestration qui utiliserait un service avec un faible niveau de performance aurait, lui, un mauvais niveau de performance, ...

De plus, les données échangées dans une requête et dans une réponse sont figées : les services sont accessibles par des interfaces connues (WSDL). Ceci implique donc une prédictibilité entre les services qui interagissent. Les données et les fonctionnalités évoluent constamment ce qui implique une évolution permanente de l'application et ces évolutions amènent donc de plus en plus d'interactions entre les différents systèmes. Aussi, les services sont souvent pensés synchrones mais il existe aussi des services qui fonctionnent de manière asynchrone et on peut donc voir des interfaces qui ne correspondent pas au traditionnel questions/réponses avec les standards SOAP des web services. Chaque protocole (qui utilise par exemple des queues de message Java Message Services) ajoute de la complexité aux tests. Il est impossible de réellement tester l'architecture SOA comme une boite noire classique (vérification que l'implémentation fournit bien le résultat attendu par la spécification sans savoir comment cela a été réalisé ; à différencier la boite blanche où on a accès à la structure du code et où on peut donc faire des tests au plus bas niveau possible). En effet, les données pouvant être modifiées dans différents systèmes, il est nécessaire de vérifier que les systèmes impactés ont bien pris en compte cette évolution au niveau données (il n'y a que très rarement des impacts sur la fonctionnalité du service).

Enfin, SOA étant une architecture, il est important de tester l'architecture de manière holistique : considérée comme un tout et non comme une composition d'éléments (services, processus, ...). On peut ainsi voir si l'architecture dans sa globalité réussit à atteindre les objectifs de réutilisation et flexibilité et étudier les composants principaux de l'architecture comme la persistance de l'information (qui correspond aux données qui sont sauvegardées une fois une opération terminée).

On peut donc voir différents problèmes outre ceux de l'application elle-même : l'environnement et les besoins logiciels que l'on va avoir. L'environnement est complexe car on peut intégrer différentes technologies et il faut pouvoir gérer ces technologies comme points d'intégration : plus les technologies sont différentes, plus la complexité des tests sera grande. Ce qui fait la force de SOA alourdit ainsi la complexité de la phase de tests. Les outils dont a besoin doivent répondre ainsi aux problèmes soulevés :

Problèmes

Besoins

L'application n'a pas d'interface graphique.

Les testeurs ont besoin d'une interface de test facile à utiliser et permettant de générer des requêtes à partir d'un fichier WSDL.

Messages contenant beaucoup de données.

Outil permettant l'automatisation de la permutation des données.

L'application a des interfaces précises (WSDL).

Outil permettant de vérifier que la réponse correspond au service.

L'application évolue rapidement et constamment.

Outil permettant de générer des types de tests modulaires et de les exécuter rapidement.

L'application peut supporter différents protocoles.

Outil gérant les divers protocoles existants (Ex : HTTP/HTTPS, MQ, JMS, ...)

Impossible de tester en tant que boîte noire classique.

Outil pour automatiser la validation des fichiers et des bases de données, et permettant d'automatiser des scénarios de tests qui soient paramétrables.

Les dépendances de l'environnement ne peuvent être contrôlées.

Outil pour gérer les données sur différents systèmes.

La maintenance des données est coûteuse.

Outil permettant de réutiliser les données sur les différents cas de test.

précédent sommaire suivant