COMMENT TESTER
SOA ?
POURQUOI EST-CE SI PARTICULIER
DE TESTER SOA ?
Tester l'intergiciel d'une entreprise (middleware - sert
d'intermédiaire de communication entre plusieurs applications) qui
utilise une architecture orientée services est compliqué.
L'architecture SOA fait évoluer le système d'information
où les applications étaient au centre vers un monde où ce
sont les processus qui sont au centre. Comme évoqué
précédemment, l'intégration des mécanismes de SOA
permet une intégration avec un couplage faible et on peut ainsi changer
les applications sans impacter les autres applications.
SOA, pouvant être implémenté de multiples
façons, sera donc testé de façon
particulière : il existe peu de méthodologies conçues
spécifiquement pour les applications SOA et des nouvelles approches et
méthodologies ont dû être créées pour
vérifier et valider de telles applications. On peut se poser la
question : Pourquoi est-ce si différent de tester SOA ? La
réponse est complexe mais elle peut se résumer à
« agilité » et
« flexibilité ». Ce qui fait tout
l'intérêt d'une architecture SOA est aussi ce qui demande une
approche différente au niveau des tests. Il faut ainsi tester les
interfaces et les services qui peuvent rapprocher différents
systèmes et plateformes mais aussi s'intéresser aux dimensions de
sécurité et de performance. Un autre point important de la
méthodologie de test pour SOA est la disponibilité de
l'environnement. Derrière cette notion, est présent
l'essence même de SOA où interviennent les différents
services ou applications dans l'environnement : la disponibilité de
ces services internes autonomes, qui composent les Business
Process (BPEL - Orchestration de Services), est très importante
pendant les différentes phases de tests d'intégration. Il faut
ainsi pouvoir tester ces processus d'orchestration comme un tout complet mais
aussi tester chacune des parties qui le composent.
Les applications intergicielles basées sur SOA sont
donc plus complexes que les applications que l'on rencontre habituellement qui
sont liées à l'interface graphique (GUI). Ici, l'interface
machine n'est pas intuitive pour une personne humaine qui voudrait interagir
avec : les messages qui sont échangés, par exemple, sont
conçus conformément aux données de l'entreprise mais ne
sont pas forcément compréhensibles humainement. Il faut bien
sûr des outils pour pouvoir déchiffrer des messages mais aussi des
outils de génération de tests qui ne peuvent pas tous être
écrits spécifiquement pour chaque cas, ...
De plus, en ajoutant plus de complexité pour atteindre
un état flexible et réutilisable, l'architecture SOA devient
d'autant plus stratégique pour l'entreprise. Le retour
sur investissement d'une telle architecture peut être important si cette
architecture est bien testée. Une architecture SOA non testée
peut se transformer en échec et faire perdre de l'argent.
| 
