3.2.2 Objectif 1 : cartographie des tests
L'instrumentation du code source, détaillé au
§ 4.2, doit fournir, à la suite du passage des tests de
références, deux types de flux XML. Dans le premier, on va
chercher à ajouter du code pour chaque méthode, juste
après l'entrée et juste avant chaque instruction de sortie. On
obtient ainsi une arborescence des appels de méthodes. Le second flux
permet de connaître pour les méthodes de type «
événement utilisateur » l'état de l'ensemble des
éléments graphiques d'un écran à un instant
donné. Il est alimenté, comme le précédent, lors de
entrée et de la (ou des) sortie(s) de la méthode.
Un service Java permet de lire ces flux et de les
intégrer à la base « Migration Platform ».
Cela revient à insérer les tests de référence en
base. Ils sont vus comme des cas de test, composés
d'éléments, qui sont soit des appels de méthode simple :
« testExecutionNode » (cf. Figure 20), soit des appels de
méthodes événementielles : « testUserEvent
».
Ces derniers ont alors un état d'entrée et de
sortie de l'écran : « UIState » (cf. Figure 21). Il
est luimême composé d'un ensemble de paires clé / valeur
permettant de représenter les propriétés de chaque
composant de l'écran.
En Visual Basic 6, langage de programmation sur lequel a
été réalisé une grande partie des maquettes,
l'introspection n'est pas totalement implémentée.
C'est-à-dire qu'on ne peut pas connaitre dynamiquement l'ensemble des
propriétés d'un composant graphique par exemple. En revanche, si
on connaît le nom des propriétés pour lesquelles on veut la
valeur, la commande « CallByName » permet d'interroger dynamiquement
la propriété du composant et d'obtenir sa valeur. Il a donc fallu
définir par le biais d'un fichier de configuration les composants
graphiques et les propriétés faisant l'objet d'une «
surveillance » de la part de l'instrumentation.
CNAM de Nantes - 2010 / 2011 - Mémoire
d'ingénieur
|
|
|
Figure 22 : Exploitation de la cartographie pour produire un
diagramme de classe
CNAM de Nantes - 2010 / 2011 - Mémoire
d'ingénieur
|
|
|
3.2.2.1 Vision statique et dynamique de la
cartographie
Avant l'insertion des tests, la base de donnée ne
contient que ce que l'analyseur syntaxique a pu lui fournir. Pour garder le
langage Visual Basic en exemple, l'instruction :
Public Function getCustomer() as clsCustomer
sera interprétée comme une fonction renvoyant
une instance de la classe « clsCustomer ». Dans le modèle, il
en résulte la création d'un lien entre cette fonction et la
classe « clsCustomer ». En revanche, l'instruction suivante ne
donnera pas les mêmes résultats :
Public Function getCustomer() as Object
En effet, même si dans le corps de la méthode,
les instructions font que le type renvoyé sera effectivement une
instance de la classe « clsCustomer », l'analyseur syntaxique ne
réussira pas à résoudre cette relation. On arrive alors
aux limites de l'analyse statique du code. Grâce à
l'instrumentation de toutes les méthodes du code source, la trace XML
permettra de mettre en évidence, à l'intérieur de la
fonction « getCustomer » l'accès au constructeur de la classe
« clsCustomer » ou à des méthodes liées à
cette classe. On obtient donc une vision dynamique de l'application. On pourra
donc ajouter la liaison non résolu par l'analyseur syntaxique entre la
fonction et la classe
Au niveau de la base « Migration Platform
», on ajoute à la vision statique de l'analyseur la vision
dynamique fournie par les tests de références. Au passage, on
peut noter qu'on répond à une des exigences initiales : le point
d'entrée étant un cas de test, on connait l'exhaustivité
des composants utilisés par ce cas de test.
Concernant le langage Visual Basic, il peut être
utilisé de manière assez libre et devenir très peu
typé. Cette vision dynamique est indispensable afin d'obtenir une
idée claire de l'ensemble des relations entre les composants de
l'application.
| 
