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