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.
Page suivante : 3.2.2.2 Représentation graphique de la cartographie des tests
Retour au menu : Stratégie de test au sein du processus d’évolution d’architecture de Sodifrance