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.
Page suivante : 3.2.2.1 Vision statique et dynamique de la cartographie
Retour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance