• Aucun résultat trouvé

Simulation et génération des cas de tests abstraits

Dans le document Test des systèmes multi-agents (Page 101-104)

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

6.5 L’approche de test basé sur le modèle

6.5.1 Simulation et génération des cas de tests abstraits

Nous pensons que la première étape (construction du modèle) a été pleinement discutée dans la section 6.4. Néanmoins, il est utile de rappeler que contrairement aux techniques de test classiques où l’ensemble des activités de test sont réalisés en fin de projet, la production des cas de tests à partir d’un modèle commence dès les phases de spécifications terminées, voire en amont avec les aspects stratégie de test et identification des exigences. Cela permet de détecter au plus tôt les ambiguïtés ou les contradictions au sein des spécifications, avec un bénéfice immédiat pour le projet grâce à leur consolidation, figure 6.11.

1. Est une description partielle de

3. Sont la version abstraite de 2. Sont dérivées de 4. Peuvent être exécutés sur Système Modèle Tests Concrets Tests Abstraits

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

Figure 6.11: Première phase : Simulation et génération des cas de tests abstraits.

Plus qu’un outil d’édition des réseaux de référence, Renew est également un simulateur très puissant. Ainsi, l’ingénieur de test (chargé de la modélisation) peut de manière dynamique et interactive explorer les états du modèle qu’il a mis au point. Il peut, par exemple, imaginer différents scénarios d’exécution en agissant sur le nombre d’agents, la portée de leur vue, le nombre de paquets, leurs couleurs différentes ainsi que sur leur disposition dans l’environnement. Tout en simulant le comportement du modèle pour chacun des scénarios d’exécution imaginés, l’ingénieur de test pourra, en fonction des résultats obtenus, corriger et/ou raffiner progressivement le model abstrait de test. Ce qui est important pour nous (en tant que testeur), c’est qu’il est possible de récupérer toute la trace de simulation sous forme d’un fichier texte. En réalité, chaque fois qu’une transition est tirée, son nom tel qu’il a été utilisé dans le réseau, est écrit dans la trace de simulation. Les noms des places sont également écrits dans cette trace de simulation à chaque fois qu’un jeton est retiré ou déposé dans la dite place. On obtient très vite une suite d’étapes de simulation dont chacune est composée des noms des places en entrée avec leurs marquages, de la liste des transitions tirées et de la liste des places en sortie avec leurs marquages courant. Cette combinaison (place en entrée, transitions tirées et places en sortie) telle qu’elle est écrite dans la trace de simulation est considérée comme étant le cas de test abstrait et doit être (après concrétisation) soumis au système sous test.

En plus des noms des places, des noms des transitions spécifiées dans le réseau et du numéro de l’étape de simulation (un nombre séquentiel), les autres termes sont ceux communément utilisés dans la terminologie des réseaux de Petri : initializing, putting, firing,

removing, …etc. Ainsi, si l’on charge les réseaux world, agent, implémentation interne et les

réseaux de protocoles décrits précédemment et que l’on déclenche la simulation du réseau

world, on obtiendra la trace de simulation de la figure 6.12.

Spécifications systèmes L’outil RENEW Modèle de test abstrait Raffinements Simulation et génération des cas de test Feedback Trace de Simulation Ingénieur de test (Modeleur)

Utilisateur final Notations de conception Composants d’interface Deviner erreurs Spécification de test

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

103

Figure 6.12: La trace de simulation.

Les premières lignes de cette trace de simulation indiquent que le simulateur Renew commence par la création d’une instance du réseau world. Il initialise, par la suite, le nombre d’agent chargés de la collecte des paquets et pour chacun d’eux, la valeur de sa vue. Enfin, chaque position du packet world sera définie par ses coordonnées et par son état (free, dest,

packet, idleAg, busyAg).

Ceci fait, le simulateur retire un jeton agent (il s’agit en réalité du réseau de Petri de la figure 6.6) de la place d’entrée (ag) et modifie l’état de la place destination. Le tirage de la transition d’entrée provoque l’exécution du constructeur du réseau agent et par conséquent son instanciation ainsi que l’initialisation des différents protocoles comportementaux dans la place protocoles. L’effet de chaîne continue par l’exécution du constructeur du réseau

implémentation interne. Comme conséquence, ce dernier est instancié et les paramètres lui

sont passés via la transition start. Finalement, l’état de la place destination est mis à jour et notre agent est désormais dans son environnement.

Dans l’optique de réduire le nombre de cas de tests générés, nous comptons énormément (comme dans l’approche de test décrite dans le chapitre précédent) sur l’expérience et les intuitions du testeur pour la construction des spécifications fonctionnelles de test. Ce faisant, le nombre des traces de tests nécessaires est réduit en définissant d’autres contraintes fonctionnelles concernant le système et son environnement. Plusieurs sources d’information seront nécessaires : les diagrammes d’activité et/ou les machines d’états finis, les diagrammes de séquence et/ou les spécifications des protocoles régulant les interactions entre agents ou enfin, l’utilisateur final et/ou les interfaces de composants.

(1) Setting time to 0.0

(1) New net instance world[0] created //the world net is created

(1) Initializing [2] into world[0].ag //an agent token is putted in the entrance place (the //viewSize=2)

(1) Initializing [free,0,0] into world[0].P0 //initializing each position in the world net (free //position) (1) Initializing [packet1,0,3] into world[0].P3 //position containing a packet

(1) Initializing [dest,1,3] into world[0].P8 //destination position ...

(2)---Synchronously---

(2) Removing [2] in world[0].ag //the agent leaves the entrance place (2) Removing [free,0,0] in world[0].P0 //the position status will be modified (2) Firing world[0].new agt //the agent constructor

(2) New net instance agent[0] created //the agent net is created (2) Initializing [] into agent[0].protocols //all protocols lie in this place (2) Firing agent[0].new impl //the impl. constructor (2) New net instance implmt[0] created //the implmt net is created

(2) Firing implmt[0].start //the entrance transition of this net is fired

(2) Putting [0,0,2,free] into implmt[0].entry //parameters are passed (coordinate, view and status) (2) Putting [IdleAg,0,0] into world[0].P0 //the new position status

(2) Putting agent [0] into world[0].P0 //the agent enter the world (3) ---Synchronously---

(3) ...

(10) ---Synchronously---

(10) Removing agent[0] in world[0].P3 //the agent leaves P3 place (10) Firing world[0].move //firing the move transition (10) Putting agent[0] into world[0].P4 //the agent enter P4 place

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

Dans le document Test des systèmes multi-agents (Page 101-104)