3.2.3 Objectif 2 : automatisation des tests
Les tests sur les applications cibles se font à l'aide
d'outils de rejeu de test, comme FlexMonkey22 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.
22 FlexMonkey : outil de rejeu de test
spécifique aux applications Flash :
http://www.gorillalogic.com/flexmonkey
CNAM de Nantes - 2010 / 2011 - Mémoire
d'ingénieur
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).
3.2.3.1 Génération des scripts de
test
La génération des scripts de test se fait alors
en parcourant les enregistrements de test, qui pointent sur des composants
sources, et pour chaque composant, en cherchant le composant cible qui lui est
associé. Pour chaque événement en base, on retrouvera
trois actions de génération :
· Positionner les propriétés qui
n'auront pas été changées de manière
événementielle. Par exemple, dans le scénario de test, on
coche une case, et il n'y a pas d'événement associé
à cette action. L'instrumentation du code source n'aura donc pas
ajouté de code pour suivre l'évolution de cette case à
cocher. En revanche, l'événement Click du bouton OK
déjà existant, aura été instrumenté.
L'instrumentation vérifiera l'ensemble des zones de l'écran et
informera que la valeur de la case à cocher a changé. Il restera
alors soit à modifier
CNAM de Nantes - 2010 / 2011 - Mémoire
d'ingénieur
|
|
|
la propriété, soit à déclencher un
événement afin de modifier la propriété. On peut
noter deux choses importantes :
o seules les propriétés modifiées depuis le
dernier appel sont remontées par l'instrumentation.
o il ne faut pas tenir compte des propriétés du
composant sur lequel porte l'événement en cours. Elles seront
modifiées par l'événement lui-même.
· Déclencher l'événement. Après
avoir positionné les propriétés des autres composants, on
peut déclencher l'événement enregistré. Dans notre
exemple, il s'agira du clic sur le bouton.
· Vérifier les propriétés
après l'événement. L'événement
Click du bouton OK aura déclenché des appels aux
services métier, et les données présentes à
l'écran auront pu être modifiées. L'instrumentation nous
fournit les valeurs des propriétés des composants de
l'écran à la fin de l'événement. Il reste donc
à vérifier que les données attendues ont bien
été mises à jour par l'appel à
l'événement Click et aux services métier.
Pour être précis, il y a bien quelques cas
particuliers à gérer, comme les événements ou
propriétés parasites qu'il y peu d'intérêt à
observer. Par exemple, toujours pour Visual Basic, le changement de ligne dans
une Combobox changera les propriétés Text et SelectedIndex. Seule
la propriété SelectedIndex sera à positionner, le texte de
la Combobox sera mis à jour implicitement.
Certaines propriétés ne font en fait
référence qu'à une seule action de l'utilisateur. Le clic
dans la cellule d'un tableau mettra à jour les propriétés
ColIndex puis RowIndex. Ceci est dû au fonctionnement de
l'instrumentation qui ne peut tester qu'une propriété à la
fois.
Au final sur la cible, il ne faudra générer qu'un
clic sur la grille dans la cellule correspondant aux coordonnées des
propriétés ColIndex et RowIndex.
Un événement utilisateur peut demander deux
événements sur la cible. Cliquer sur une ligne d'une ComboBox
peut obliger à effectuer auparavant un Scroll afin que la ligne à
cliquer soit visible. Cette limitation peut provenir de la technologie de
l'application cible. Pour Flex23 par exemple, on est bien dans ce
cas. On obtient donc un événement source qui doit en produire
deux sur la cible, le Scroll puis le Click.
23 Flex : Le logiciel est un outil Open Source de
développement d'applications web
CNAM de Nantes - 2010 / 2011 - Mémoire
d'ingénieur
Figure 29 : Vue de synthèse du plugin Eclipse (source
Sodifrance)
Figure 30 : Vue du suivi d'intégration du plugin Eclipse
(source Sodifrance)
CNAM de Nantes - 2010 / 2011 - Mémoire
d'ingénieur
|
|
|
| 
