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.
| 
