Les tests sur les applications cibles se font à l’aide d’outils de rejeu de test, comme FlexMonkey(22)
pour une application Flash par exemple. Habituellement, il faut jouer les scénarios de test sur
l’application à tester afin que l’outil enregistre les actions qui sont effectuées sur l’interface
graphique. L’idée de l’automatisation des tests, c’est de mettre en place un processus dont la finalité
permettra d’alimenter automatiquement les outils de rejeu de test. Or, l’ensemble du processus mis
en place vise à atteindre cet objectif. L’instrumentation du code source remplace la phase
d’enregistrement des actions sur l’application cible.
L’outil de test doit être en mesure d’identifier chaque composant de l’application cible afin de
pouvoir tester les valeurs de ses propriétés ou d’effectuer des actions dessus. On commence à
percevoir le problème de l’automatisation lorsqu’on sait que le processus d’évolution d’architecture
intègre les conventions de nommage du langage cible, ou encore les spécifications propres à chaque
client.
Au cours de la migration, il faut donc avoir une solution pour établir un lien entre les composants de
la source et ceux de la cible. Ceci est rendu possible en intégrant trois actions dans le processus de
migration industrielle.
Une première action, en tout début de processus, consiste à « attacher » une clé à chaque composant
avant que ceux-ci n’aient été renommés ou modifiés. Cette clé est construite selon le même format
que celui décrit au § 3.2.1.
La deuxième action se situe quant à elle en toute fin de processus. A ce niveau, les composants ont
pu être renommés, déplacés, ou même avoir changés de type. En effet un client peut demander à
changer tous les boutons « OK » en liens hypertexte « Valider ». On reconstruit une nouvelle clé, en
suivant les mêmes règles qu’avec la clé d’origine et encore une fois, on l’« attache » au composant.
Chaque composant se retrouve donc « agrémenté » de deux clés, celle de la source et celle de la
cible.
Figure 28 : Les classes du paquetage traçabilité (« Traceability )
du métamodèle « Migration Platform »
L’action finale se résume à insérer dans la base de données Migration Platform, les nouveaux
composants cibles mais aussi leurs relations avec les composants issus de la cartographie statique
par le biais du paquetage de traçabilité (« TraceDependency », cf. Figure 28).
22 FlexMonkey : outil de rejeu de test spécifique aux applications Flash : http://www.gorillalogic.com/flexmonkey
Page suivante : 3.2.3.1 Génération des scripts de test
Retour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance