CONCLUSION
Ce document permet de comprendre les principes d'une
architecture SOA et de mettre en évidence les points qui en font sa
particularité : tous les avantages apportés par cette
architecture en termes de souplesse et de facilité d'évolution
complexifient la méthodologie de test. On comprend alors qu'on ne peut
pas aborder les tests de la même manière qu'une application
classique. Pour créer un plan de tests, il faut donc avoir en tête
tous les problèmes évoqués précédemment mais
aussi comprendre ce qu'il y a d'unique dans l'architecture. Ainsi, s'ajoutent
en plus les spécificités du monde de la banque : multiplateforme,
multi environnement, multi technologie, ...
Le point important est bien sûr de d'impliquer
les équipes de tests dès la phase de conception de l'architecture
SOA : prévoir l'approche de tests lors de la définition des
besoins et ne pas avoir des surprises à la fin au niveau performance ou
sécurité. Il y a beaucoup d'éléments dans
l'architecture SOA et il n'est pas forcément possible de tout tester :
il faut ainsi savoir ce qui y est important et ainsi satisfaire tous les
engagements pris lors de la conception de l'entreprise.
Les applications basées sur SOA évoluent
constamment et il est nécessaire de pouvoir passer rapidement des
scripts de tests permettant de tester toutes les fonctionnalités. Il est
bien sûr important d'utiliser des outils, avec une interface Homme
Machine facilement utilisable, qui permettent de tester les aspects uniques des
applications SOA qui sont sans interfaces graphiques et où il y beaucoup
d'échanges de messages. Aucun outil ne peut satisfaire toutes les
applications, environnements et tests possibles : il faut donc se construire
une solution adaptée en n'hésitant pas à utiliser
différents logiciels.
Si la qualité est au coeur de l'architecture SOA,
toutes les possibilités offertes pourront être
utilisées.
ANNEXES
CICS - DÉTAILS
Comparaison entre les différentes couches de CICS et
J2EE :
COBOL - EXEMPLE DE
RÉUTILISATION EN TANT QUE WEB SERVICE AVEC LES LOGICIELS ACUCORP
Il est possible de transformer le programme Cobol en service
web. Ici, un exemple avec les logiciels de l'entreprise Acucorp (fournit
un moyen d'invoquer un programme Cobol, génération d'un fichier
WSDL à partir des spécifications, génération d'une
interface permettant d'appeler le service, outils donnant des informations
statistiques pendant l'exécution, ...).
LE MODÈLE DE TEST
« ONSITE - OFFSHORE »
Le modèle de test « Onsite -
Offshore », qui permet d'externaliser les procédures de tests,
est très utilisé. Le client est donc
« Onsite » (à gauche) et l'entreprise ou service
dédié aux tests est « Offshore » (à
droite).
On peut imaginer qu'une petite équipe travaillerait
chez le client alors qu'une plus grande serait à l'extérieur.
L'équipe chez le client fournit alors une interface avec le client et
coordonne le travail externe, et l'équipe externe peut exécuter
tous les cas de tests et rapporter tous les défauts.
| 
