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
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 Flex(23) 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
Page suivante : 4 LES TRAVAUX CONNEXES
Retour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance