Concrétisation des cas de tests abstraits

C’est l’étape la plus délicate dans le processus de test basé sur les modèles. Elle tire sa minutie de son emploi pour réduire le gap entre le modèle abstrait (ensemble de place en entrée, de transitions tirées et de place en sortie) et le système concret (structures de données du langage d’implémentation). De ce fait et avant qu’elle ne soit déclenchée, un travail de fond doit être réalisé en premier, notamment une compréhension de la structuration de l’application à tester. Un analyseur statique se chargera de ce travail de synthèse.

6.5.2.1 Analyse statique

L’analyseur statique a comme principale fonction la collecte d’un certain nombre d’informations à partir de la représentation « non active » du programme. Les types d’information captée après cette analyse statique peuvent être structurés sous forme d’une table de symbole (similaire à celle construite par un compilateur) ou d’un fichier d’informations agent regroupant les identifications des agents, le nombre et la dénomination de leurs différents plans, les noms des différentes classes avec les noms de leurs méthodes ainsi que leurs paramètres et le type de chacun d’eux. Ces informations seront par la suite utilisées tout au long de la génération d’un cas de test concret.

Par cas de test concret on sous entend une structure de donnée composée des éléments suivants : le prologue, le corps de test, le verdict et l’épilogue (voir chapitre précédent). La génération de chacune de ces parties d’un cas de test abstrait est détaillée dans ce qui suit.

6.5.2.2 Génération de la partie prologue

Quelque soit le scénario imaginé et simulé par le testeur, les premières lignes du fichier de la trace de simulation (numérotés par le chiffre 1) seront toujours considérées comme étant la partie prologue du cas de test abstrait. Ainsi, une analyse textuelle de ces lignes permettra de déterminer les principales caractéristiques de notre système : la taille du packet world (nombre de places initialisées), le nombre d’agents (nombre de transitions ayant un constructeur new), le nombre de paquets (nombre de places dont l’état est égal à packet), le nombre de paquets différents (nombre d’occurrences différentes de la valeur packet) et finalement, la portée de vue de l’agent (définie dans la place ag). Le résultat de cette analyse est une série de message FIPA ACL contenant chacun un ensemble d’actions dont l’exécution mènera le système au point origine de l’actuel cas de test. Un de ces messages est le suivant :

(inform

:sender (agent-identifier :name TesterAgent) :receiver (agent-identifier :name AgentWorld) :content (=(any ?x (is-world ?x))

(world : worldSize 8 : nbPacket 4 : perKind 2 : nbAgent 1 : viewSize 2 :language FIPA-SL :reply-with query1)

Test basé modèle des agents mobiles utilisant le paradigme des réseaux dans les réseaux

105

6.5.2.3 Instrumentation

Pour permettre aux agents sous test de communiquer avec notre agent testeur, le module d’instrumentation a comme tâche l’adjonction dans le code source initial d’un certain ensemble de routines déterminées (primitives d’instrumentation), lesquelles en s’exécutant et sans modifier le comportement initial du programme (sauf en ce qui concerne les aspects occupation mémoire et temps d’exécution), sont capables de produire un certain nombre d’informations pertinentes. Ces informations seront par la suite recueillies et traitées par l’agent testeur. Elles peuvent concerner les parties du code exécutées, les valeurs successives des variables impliquées, la succession d’appels des différentes méthodes, le changement d’état d’une donnée, etc.

6.5.2.4 Génération de la partie corps de test et du verdict

Après que la partie prologue ait été générée, le translateur est désormais prêt pour la construction des parties corps de test et du verdict. En fait, le corps de test consiste en liste ordonnée de séquences de test, qui sont à leur tour des actes de communication FIPA ACL. A chaque acte de communication (séquence de test) correspond une séquence verdict permettant de statuer sur la validité les données observées et qui seront stockées dans la partie verdict de l’actuel cas de test.

Excepté les premières lignes de la trace de simulation qui sont vouées à l’initialisation du système et à l’instanciation automatique des réseaux de Petri de départ, la grammaire de toutes les autres traces de simulation respectent le digramme d’états fini décrit par la figure 6.13 (l’astérisque signifie zéro ou plusieurs répétitions du mot clé)

Figure 6.13: Diagramme d’états finis pour les termes de simulation.

Pour chacun de ces mots clés, un ensemble d’actions sont entreprises. Elles sont définies dans ce qui suit :

- Removing: définition des données en entrée qui doivent être satisfaites avant le tirage des transitions en sortie de la place actuelle.

- Firing (Constructor): appel au constructeur du réseau définissant soit un agent soit un objet. - Firing (Transition): relative à une action à exécuter ou à un appel explicite d’une méthode. - New net instance: informe sur la création avec succès d’une instance réseau.

- Initializing: définition des valeurs de variables au niveau d’une place quelconque.

- Putting: définition des données en sortie qui doivent, encore une fois, être satisfaites après le tirage des transitions précédant la place actuelle.

Removing* Firing^* (Transition) Firing (Constructor) Putting* New net instance ^Initializing *

Test basé modèle des agents mobiles utilisant le paradigme des réseaux dans les réseaux

De telles indications de translations peuvent être ajustées pour différentes plateformes de test et être stockées dans un fichier de configuration ou dans une table de translation. Appliquant un tel principe à notre cas d’étude (pour la trace de simulation numéro 2 de la figure 6.12), on obtient la table suivante qui définit les actions à entreprendre pour chacun des mots clés ainsi que les résultats attendus correspondants, table 6.2.

Mots clés Actions Résultats attendus

Removing Définition des données en entrée NULL

Firing (constructor) Création d’une instance du réseau agent

Instance créée

Initializing Définition des valeurs de variables NULL

Firing (constructor)

Création d’une instance du réseau implémentation interne

instance créée

Firing (transition) Passage de paramètres Paramètres passés

Putting Résultats attendus Comme définies dans la trace de simulation Tableau 6.2: Table de correspondance.

Ainsi, connaissant les noms des différentes transitions décrites dans le fichier trace de simulation qui succèdent aux mots clés précédemment décrits : déplacer, saisir, poser,

composer, envoyer, … etc, les noms d’objets (méthodes) leurs correspondants (contenus dans

le fichier d’information agent) ainsi que les valeurs des variables contenues dans les places en entrée et l’identification des agents impliqués dans chacune des traces de simulation, le translateur (utilisant la précédente table et assisté par le testeur humain) peut formater ces informations, respectant la structure d’un message FIPA ACL, pour générer des performatives de type Request qui seront envoyées aux agents sous test. Le paramètre content dépendra de l’action à exécuter par l’agent invoqué. Dans l’exemple suivant, l’agent testeur demande à un des agents de se déplacer vers la position (3,3).

(request

:sender (agent-identifier :name TesterAgent) :receiver (agent-identifier :name Agent1) :content(action (agent-identifier :name Agent1) (move :x 3 :y 3)

:language FIPA-SL :reply-with query1))

Le résultat attendu après l’exécution de la séquence de test en cours par l’agent sous test est aussi dérivé à partir de la précédente table de translation. Plusieurs scénarios sont possibles. Le succès ou l’échec du cas de test peut être vérifié en fonction de la réponse de l’agent suite à une requête explicite de l’agent testeur (le test échoue si la réponse est de type

failure). Par exemple, dans le précédent message, l’émetteur a utilisé le paramètre reply-with.

Un tel paramètre définit une expression qui sera utilisée par l’agent auquel le message est destiné afin d’identifier ce message. L’agent testeur pourra ainsi comparer les deux messages pour statuer sur le succès ou sur l’échec du test. L’agent testeur peut également, décider de l’échec d’un test si les valeurs de variables contenues dans la réponse de l’agent diffèrent de

Test basé modèle des agents mobiles utilisant le paradigme des réseaux dans les réseaux

107

celles contenues dans les places en sortie de l’actuelle séquence de test. Finalement, le succès d’un test peut être décidé après une série interactions entre l’agent testeur et l’agent sous test.

6.5.2.5 Génération de la partie épilogue

La partie épilogue est également préparée lors de cette étape. En effet, tant que la fin de fichier de simulation n’a pas encore été atteinte, le translateur va générer le prochain corps de test et le stocker dans la partie épilogue de l’actuel cas de test. Sinon cette partie contiendra des messages pour la libération du système et pour la destruction des agents testés ainsi que les messages nécessaires pour l’arrêt du processus de test.