De même que les modèles tendent à s’imposer dans le monde du développement, la part que
représentent les tests basés sur les modèles commence à se faire de plus en plus visible. Assez
longtemps délaissée, cette discipline fait désormais l’objet d’études sérieuses et approfondies. Bien
que de nombreux documents traitent de ce sujet, ils sont souvent ciblés sur une technologie, un
langage ou un environnement.
Dans leur article, MM. Hernandez et al. (Hernandez et al. s. d.) ciblent le contexte des applications
web et des différentes technologies qui les entoure (HTML, JavaScript, Flash, ActionScript, etc.).
Dans l’objectif de diminuer les coûts de maintenance des scripts de test, le principe
d’automatisation des tests est acquis, et l’utilisation d’un métamodèle UML vise à ne pas avoir à
réécrire l’ensemble des tests pour chaque environnement cible (utilisation des principes MDE de
transformation des PIM en PSM). Cependant, tout en utilisant la notion de PIM, le métamodèle
proposé est exclusivement à destination des environnements web.
Pour MM. Chinnapongse et al. (Chinnapongse et al. 2009), la cible adressée concerne les appareils
portables (Smartphone, etc.). Globalement, le processus décrit consiste à
· définir un modèle comportemental de l’application (créé manuellement à partir de la
documentation de l’appareil) avec l’interface de programmation (Application Programming
Interface, API) NModel(12).
· le transformer en machine à états finis (cf. Figure 13, branche model programmer view, mpv)
· générer une suite de tests (cf. Figure 13, branche offline test generator, otg)
· exécuter les tests (cf. Figure 13, branche conformance tester, ct)
Ici aussi, le contexte adressé est restreint puisqu’il se limite aux appareils portables, et aux
applications développées en .Net, qui peuvent être testée avec NModel.
(Use Case Base Testing, UCBT) (Williams 2001)
M. Williams (Williams 2001) se sert des cas d’utilisation UML pour décrire le modèle de test et
produire des suites de test. « De même que les classes et leurs concepts associés nécessitent un
métamodèle bien défini afin de produire du code source, les cas d’utilisation ont besoin d’un
métamodèle précis pour produire des cas de test valides et robustes. ». Lors des phases de
modélisation, les annotations portées sur les cas d’utilisation déterminent le sous-modèle cible :
modèle système, modèle de données, modèle des cas d’utilisation ou modèle utilisateur (cf. Figure
14). Avec cette technique de tests basés sur les cas d’utilisation (Use Case Based Testing, UCBT(13)),
les modèles annotés servent à la génération de suites de test exploitables par l’outil TCBeans(14). Les
cibles de cet outil sont des programmes qui possèdent des interfaces de programmation (Application
Programming Interface, API).
Une idée forte qui se dégage de ces différentes approches des tests basés sur les modèles, est la
réponse à la question suivante : pourquoi faut-il mettre en oeuvre des tests basés sur les modèles ?
La réponse est très simple : le coût ! (Strohmeier 1996, p.2)
De manière générale, plus une anomalie est découverte tard, plus elle coûte cher à résoudre. Sans
parler de la constitution des jeux de tests, la façon la plus efficace de tester une application est
d’utiliser un outil de rejeu de test. On évite ainsi le passage fastidieux des étapes de test à la main.
Ensuite vient le problème de maintenance de ces tests. C’est là que les tests basés sur les modèles
prennent tout leur sens. On rejoint là encore les avantages du MDE dans le monde du
développement. On retrouve entre autres l’indépendance entre la logique métier et la plate-forme
technologique ciblée, une meilleure qualité de codage grâce à la génération du code à partir des
modèles, et cela « force » les concepteurs à formaliser les spécifications.
Contrairement aux recherches présentées ci-dessus, nous avons essayé de ne pas limiter notre
processus à certaines technologies ou langages. En effet, nos clients viennent d’horizons très larges
et ont le plus souvent des parcs applicatifs hétérogènes. Dans la mesure du possible, ils attendent
que nous prenions en compte l’ensemble de leur patrimoine.
(Source Sodifrance, les parties que j’ai modélisées sont en vert)
12 NModel : est un outil de test basé sur les modèles et un cadre de développement écrit en C#.
http://nmodel.codeplex.com/
13 UCBT : technique d’IBM pour générer des cas de test à partir de cas d’utilisations.
http://www.research.ibm.com/softeng/TESTING/ucbt.htm
14 TCBeans : logiciel de test conçu pour élaborer, exécuter et organiser des tests fonctionnels.
https://www.research.ibm.com/haifa/projects/verification/gtcb/index.html
Page suivante : 3.2 Plate-forme de migration (« Migration Platform »)
Retour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance