Stratégie de test au sein du processus d'évolution d'architecture de Sodifrance

3.1.3 Test

3.1.3.1 Généralités

M. Félix donne une définition très claire de ce qu'est un test (FELIX 2011) : « Toute fabrication de produit suit les étapes suivantes : conception, réalisation et test. Avec le test, on s'assure que le produit final correspond à ce qui a été demandé... ».

Selon l'institut des ingénieurs électriciens et électroniciens (The Institute of Electrical and Electronics Ehgineers 345 East 47th Street, New York, NY 10017, USA s. d.), « le test est un processus manuel ou automatique, qui vise à établir qu'un système vérifie les propriétés exigées par sa spécification, ou à détecter des différences entre les résultats engendrés par le système et ceux qui sont attendus par la spécification ».

M. Gianas affirme que quels que soient les modèles de conception adoptés, en cascade, en Y ou en V comme le montre par exemple la Figure 12, on retrouve tout au long du processus de création du produit les principaux niveaux de tests (Régis-Gianas 2010):

· Test unitaire: le test de composants logiciels individuels.

· Tests d'intégration : tests effectués pour montrer des défauts dans les interfaces et interactions de composants ou systèmes intégrés.

· Test d'acceptation : test formel en rapport avec les besoins, exigences et processus métier, conduit pour déterminer si un système satisfait ou non aux critères d'acceptation et permettre aux utilisateurs, clients ou autres entités autorisées de déterminer l'acceptation ou non du système.

· Test de régression : tests d'un programme préalablement testé, après une modification, pour s'assurer que des défauts n'ont pas été introduits ou découverts dans des parties non modifiées du logiciel, comme suites des modifications effectuées. Ces tests sont effectués quand le logiciel ou son environnement est modifié.

CNAM de Nantes - 2010 / 2011 - Mémoire d'ingénieur

Figure 13 : Implémentation des tests avec NModel (Chinnapongse et al. 2009)

CNAM de Nantes - 2010 / 2011 - Mémoire d'ingénieur

3.1.3.2 Tests basés sur les modèles (Model Based Testing)

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

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

¹² NModel : est un outil de test basé sur les modèles et un cadre de développement écrit en C#. http://nmodel.codeplex.com/

CNAM de Nantes - 2010 / 2011 - Mémoire d'ingénieur

Figure 14 : Relations entre les sous modèles des tests basés sur les cas d'utilisation
(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¹³), les modèles annotés servent à la génération de suites de test exploitables par l'outil TCBeans¹⁴. Les cibles de cet outil sont des programmes qui possèdent des interfaces de programmation (Application Programming Interface, API).

¹³ 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

¹⁴ 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

CNAM de Nantes - 2010 / 2011 - Mémoire d'ingénieur

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.

CNAM de Nantes - 2010 / 2011 - Mémoire d'ingénieur

Figure 15 : Cas d'utilisation de la plate-forme de migration (« Migration Platform »)

Figure 16 : Vue d'ensemble des paquetages constituant le métamodèle « Migration Platform »
(Source Sodifrance, les parties que j'ai modélisées sont en vert)

CNAM de Nantes - 2010 / 2011 - Mémoire d'ingénieur