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

MÉTHODOLOGIE DE TEST

Pour créer un plan de test SOA, il est donc nécessaire de comprendre le fonctionnement de l'architecture à un méta-niveau puis de voir comment découper cette architecture en différents composants pouvant être testés individuellement. Ces parties doivent aussi pouvoir être testées en tant que composants liés entre eux. Enfin, l'architecture doit être testée de manière holistique. Il est donc nécessaire de créer des standards et des procédures qui permettent de tester jusqu'au niveau des projets.

SOA n'est qu'une théorie et il existe beaucoup d'implémentations différentes de cette théorie : les architectures ne sont pas toutes identiques et les solutions sont propres à chaque problème. En créant son propre plan de tests SOA, il faut comprendre cela car cela veut dire qu'il y aura des besoins spécifiques pour chaque architecture.

SOA assure une réduction des dépendances mais il existe une interdépendance entre les différents composants. On peut voir, dans le schéma suivant, comment ils sont reliés et nous allons comprendre comment ils fonctionnent indépendamment et collectivement.

On distingue ainsi plusieurs patrons de conceptions (design patterns) en fonction du type d'architecture. Les architectures de transactions sont celles où les services de transactions sont très utilisés : on peut prendre le cas des applications où il y a beaucoup de services de transactions en ligne et qui sont invoqués plus que les autres. Les architectures de données sont celles où les services les plus utilisés sont les services de données ou les services qui distribuent de l'information. Les architectures de processus sont celles où le coeur de l'architecture se trouve au niveau des processus : ce sont des architectures qui évoluent souvent et où les services principaux peuvent être changés facilement. Selon les besoins, on identifiera donc un certain type d'architecture et on testera différemment.

Pour pouvoir tester une architecture, on peut voir le problème de trois façons :

- « Bottom Up » (« de bas en haut ») : cette approche permet de tester l'architecture en commençant par les caractéristiques les plus simples puis de tester les plus sophistiquées. Si on regarde le schéma précédent, cela correspond à tester des données aux processus, puis la couche de données (services de données, abstraction de données), des couches de services de transaction vers les couches de processus et enfin les couches de contrôle et de gestion des évènements. Pour simplifier, cela revient à tester chaque composant en déplaçant des couches du bas vers les couches du haut.

- « Top Down » (« de haut en bas ») : cette approche inverse l'ordre des tests de l'approche « Bottom Up ». On teste chaque composant des couches les plus hautes vers les couches les plus basses.

- Système : l'approche Système permet de tester comme un tout. Ainsi, on regarde l'architecture comme une unité fonctionnelle en testant toutes les interfaces de toutes les couches en regardant ce qui rentre et ce qui sort en observant les différents comportements.

Ces trois approches sont distinctes et se complètent. Même si on peut n'utiliser qu'une des trois approches, les projets de tests SOA les plus réussis sont ceux qui utiliseront les trois approches. Le choix dépend bien sûr des besoins de l'architecture.

Pour créer un plan de tests, il ne faut pas oublier le domaine fonctionnel de l'architecture. Ainsi, il faut comprendre le domaine du problème avant de savoir comment le tester : au niveau sémantique, au niveau des services et au niveau des processus. L'approche va donc se décider au moment de la création de l'architecture.

Toutes les activités comme la conception, l'analyse, la planification et l'exécution doivent être testées tout au long de la vie du projet. Le fameux « modèle en V » est ainsi une bonne méthodologie qui permet de mettre en place une bonne discipline de tests durant toute la vie du projet. Le projet commence ainsi par une définition des besoins (« User Requirements ») puis les critères d'acceptation des tests (« Prepare User Acceptance Testing ») avant de commencer la phase de conception technique. De même, avant la phase suivante de design technique, le modèle en V demande de définir le niveau d'exigence technique et ainsi de suite. Ce modèle en V permet donc aux équipes projet de déterminer continuellement ce qu'il faut pour bien tester une application.

Ce modèle en V permet d'abord une approche « Top Down » en respectant la définition des exigences des processus, la conception technique fonctionnelle, ... Il encourage ensuite une approche « Bottom Up » en testant les fonctions à l'intérieur d'un service, puis les services eux-mêmes, les orchestrations de services et finalement le test du système complet. Le modèle en V incite donc à tester tout au long du développement de l'architecture. Nous reviendrons sur cette idée de tests continus, et non pas exclusivement à la fin du développement, par la suite.

Pour tester à un moment donné une application SOA, on distingue ainsi les catégories suivantes : test de gouvernance (Governance), test des données (Link Testing), test au niveau des composants du service (Component Testing), test des services (Service Testing), test d'intégration (Integration Testing), test au niveau des processus comme l'orchestration (Workflow Testing), test du système (System Testing) et test de sécurité (Security). On peut ainsi identifier à partir du schéma présenté précédemment, les couches impactées par ces catégories de test.

Le test de gouvernance. La gouvernance SOA correspond à l'assurance que les services existants (et les futurs services créés) soient conformes aux standards politiques et objectifs de l'entreprise. Elle permet par exemple de maintenir une qualité de service ou une flexibilité des processus car elle fournit une structure, un engagement et un support pour le développement, l'implémentation et la gestion de l'architecture SOA. Il s'agit donc ici de vérifier que les engagements soient respectés : la qualité de services en terme de performance ou transaction, les évènements qui doivent être notés et pendant combien de temps, ou les politiques sur l'infrastructure (droits d'accès, sauvegardes, plantages, ...). Ces tests interviennent à tout niveau.

Le test des données. Ces tests s'intéressent aux données liées aux services. Les données peuvent provenir des bases de données mais aussi de tous les systèmes utilisant des données. Il faut tester les données qui sont utilisées à l'intérieur des services : pas seulement la valeur de l'information mais son utilisation.

Le test au niveau des composants du service. Ces tests sont généralement exécutés par les développeurs pour vérifier le code compile, et que le fonctionnement de base des composants ainsi que les fonctions internes d'un service respectent les spécifications. Il est ainsi possible de tester ces petites parties de l'application en les isolant et voir si elles fonctionnent avant de les intégrer dans un ou plusieurs services.

Le test des services. Ce test est le plus important car beaucoup d'entreprises font, par exemple, des web services et il faut donc faire particulièrement attention aux tests unitaires. Ces tests doivent non seulement répondre aux engagements prévus pour le service mais aussi aux engagements des processus qui vont l'utiliser. Les services ne sont pas des applications ou des systèmes complets et ne doivent pas être traités de cette façon. Ils font partie de différentes applications et doivent être testés de façon indépendante : ils peuvent fonctionner seuls ou à l'intérieur d'un processus. La meilleure approche pour tester des services est de lister les cas d'utilisation pour chaque service. Toutes les configurations doivent être considérées : un service utilisé seul, un service qui est appelé par un autre qui est lui-même appelé par un autre service, ou des services appelés à distance par des systèmes non contrôlés. Les services doivent avoir un couplage cohérent avec leur utilisation pour maximiser les performances. Ainsi, un service avec un couplage trop faible va avoir tendance à baisser les performances car le nombre de communications va être trop important avec la multiplication de services.

Les tests d'intégration. Ces tests s'intéressent aux différentes interfaces des services et si elles respectent bien les spécifications. Tous les services livrés par une équipe de développement doivent bien correspondre à la définition des services en termes de standard, format et données. De plus, les tests se portent aussi sur les scénarios incluant les différentes couches de communication et les protocoles réseau. Les services externes à l'entreprise sont aussi testés. Les services doivent atteindre l'interopérabilité, qui permet à un système de travailler facilement avec d'autres, en respectant scrupuleusement les interfaces ou en utilisant des services capables de convertir les données d'une interface de service à la volée. Il faut donc avoir une interopérabilité au moment de la conception mais aussi en cours d'exécution pour pouvoir intégrer des éléments indépendamment des protocoles, du système d'exploitation ou langage de programmation. Le test de rétrocompatibilité permet aussi de savoir comment sont affectés les consommateurs d'un service dont on change l'interface. Si ces consommateurs sont affectés par ce changement, ce n'est pas rétrocompatible et il faudra donc mettre en place une stratégie, gérer l'impact de tels changements. Une interface de service évoluera forcément un jour et un tel changement doit être analysé.

Le test des processus. Ces tests permettent de s'assurer que les processus intégrant plusieurs services fonctionnent selon les spécifications. Cette phase de tests concerne donc la logique des processus, l'ordre d'utilisation des services, la gestion des erreurs et la réutilisation des processus. Les services sont orchestrés, assemblés pour former une solution cohérente et donc on peut ajouter, changer et enlever des services à volonté. Les processus peuvent évoluer rapidement et il faut donc vérifier que la conception permet ceci. Il y a beaucoup d'approches et de standards différents pour séquencer et manager des collections de services. Outre l'orchestration, on peut voir ainsi une chorégraphie de services (les services connaissent les autres services dont ils ont besoin contrairement à l'orchestration) ou encore les processus propriétaires : il faudra donc tester ces processus de manière adéquate.

Le test du système. Cette phase permet de vérifier que la solution technique de l'architecture SOA correspond bien aux engagements et satisfait les critères d'acceptation. Les tests ciblent les scénarios clés de la solution et interviennent après les tests précédents.

Le test de sécurité. Plus l'architecture SOA deviendra grande au sein de l'entreprise, plus ces tests seront importants. Il faut donc planifier dès la création de l'architecture et ne pas attendre la fin du développement de l'architecture. En effet, il faut se demander si les données qui parcourent ce réseau interne et externe sont protégées. Si jamais les tests de sécurité sont exécutés seulement à la fin, il y a un risque de trouver des problèmes de sécurité sévères mais, plus important, de voir que le système n'a pas eu une conception adéquate pour une architecture sécurisée.

Nous avons pu voir que tous ces tests ne doivent pas être effectués seulement à la fin du développement si l'on ne veut pas avoir de surprise concernant les performances ou la sécurité. Tester tôt dans la réalisation de l'architecture peut sembler compliqué mais c'est nécessaire si l'on veut éviter les échecs. Tester un service rapidement permet de se rendre compte de ses erreurs plus rapidement et donc de réagir plus vite et éviter une perte de temps et d'argent. Il faut donc tester dès le début et en continu. Un service qu'on ne pensait pas stratégique peut devenir important dans le futur. Et la qualité et les performances des services peuvent être altérées par les configurations de l'ESB, les règles de transformations ou la politique de sécurité. Tester en continu permet à l'architecture SOA de changer facilement - l'empêchant de devenir statique et rigide. Les bénéfices sont importants : on peut tester et valider quotidiennement tôt dans le cycle de développement quand c'est facile (et donc moins cher) de réparer les problèmes.

Une des conséquences de la correction d'un défaut est la possibilité d'introduire des nouvelles erreurs. En introduisant de nouveaux éléments, on ne peut être certains que tous les tests qui ont été passés correctement se passeront bien à nouveau. La stratégie de régression permet de ne tester à nouveau qu'une sélection de services tout en s'assurant qu'aucun autre service précédemment testé ne sera compromis par les changements effectués. Cette stratégie ne s'intéresse pas à tester la correction du défaut mais plutôt que le système et les services qui le composent n'aient pas été affectés. Ces tests ne peuvent rendus possibles que par l'utilisation d'outils automatisant la vérification des tests : nous allons voir les produits pouvant être utilisés.

Beaucoup d'entreprises adoptent l'approche de tests basée sur les risques : les cas et scripts de tests exécutés selon un ordre justifié par les implications financières des tests qui ne passeraient pas et sur la possibilité d'échec de ces tests.

L'analyse de tous ces tests nous permet de comprendre la complexité de l'architecture SOA. Cela se complique lorsque l'on multiplie les différentes technologies, applications protocoles, processus, les systèmes hétérogènes et distribués. On peut comprendre qu'il est difficile de trouver un outil miracle permettant de réaliser tous ces tests. Le but n'était pas ici de décrire toutes les solutions mais bien de définir une méthodologie de tests et de bonnes pratiques et amenant à une réflexion continue lorsque l'on développe une architecture SOA. On peut tout de même identifier plusieurs produits offrant une palette d'outils : les outils de la société Green Hat qui sont parmi les plus utilisés ou ceux de la société IBM (Rational), peut-être moins complets mais offrant plus de maintenance, ou encore les produits « Open Source » mais plus simplistes comme SOAP UI.

précédent sommaire suivant