Model-checking et génération de tests avec Object Geode et TestComposer

Transcription

1 Paris-Sud ISI M2PRO IICI année Année Model-checking et génération de tests avec Object Geode et TestComposer Figure 1 Spécification SDL du Simple Connection Protocol 1

2 1 Model-checking 1.1 GOAL observers Un observer est une machine à états qui est exécutée en parallèle d un modèle SDL et qui permet d observer un ensemble de comportements choisis. Un observer est donc associé à un modèle SDL particulier. La syntaxe des observers diffère du langage SDL utilisé pour construire les spécifications. Il faut déclarer un ensemble de probes(sondes) qui définissent des chemins d accès aux parties du modèle SDL à observer (système, bloc, processus). Ensuite, un observer est une machine à états dont les INPUT sont remplacés par des WHEN qui réagissent aux événements qui se produisent dans le modèle. Enfin, certains états de l observer sont étiquetés par error ou success pour la vérification de propriétés. Création d un observer. On crée un observer grâce à File > New GOAL observer. Il doit porter le même nom que le modèle auquel il est associé. Un observer est composé de deux parties : la déclaration des probes PR declaration et l observer lui-même. On déclare un probe en donnant un nom au chemin menant à l élément du système SDL qu on veut observer. Ici, on nomme pr scp le probe menant un processus SCP du bloc Protocol du système SimpleConnexionProtocol. Pour définir un observer, on déclare ses états de succès et d erreur et on construit une machine à états correspondant à la propriété que l on veut observer sur le système. Ici, on cherche à montrer que si la connexion est acceptée (ConnexionOK), elle finira par prendre fin (FinConnexion). Observations. Un observer permet de suivre les événements qui se produisent dans le modèle en se synchronisant sur les événements communs. Il est possible d observer des envois 2

3 ou des réceptions de signaux comme dans l exemple précédent, grâce aux mots clés input et output (il est possible de préciser to ou from suivi du nom du probe). On peut également observer la valeur d une variable du modèle ou le nom d un état. Il faut pour cela déclarer une variable dans l observer, qui permettra de stocker la valeur de la variable ou de l état au moment voulu puis de vérifier l adéquation entre la valeur observée et la valeur attendue. Dans cet exemple, on cherche à observer l état atteint après la réception du signal Accepte. On déclare une variable particulière etat de type nom probe!state sort dans laquelle on stocke le nom de l état nom probe!state. On vérifie ensuite que le nom de l état atteint est bien connexionok : si c est le cas, on atteint l état de succès s ok, sinon on atteint l état d erreur 3

4 s erreur. 1.2 Model-checking Pour effectuer la vérification de la propriété décrite par l observer sur le modèle SDL, il faut charger dans l éditeur le modèle et l observer correspondant puis lancer le simulateur. Après avoir chargé les feed du modèle (source scp.feed) et déclaré l environnement raisonnable (define reasonable feed true), la vérification se lance avec Execute > Verify. Les différents paramètres permettent de contrôler le nombre de scénarios de succès et d erreur qu on veut que l outil génère en cas de succès ou d erreur. Lorsque des succès ou des erreurs sont trouvés, les scénarios correspondant sont stockés dans des fichiers dont le nom termine par e*.scn pour les erreurs et par s*.scn pour les succès. Il est possible de jouer ces scénarios en chargeant un de ces fichiers (ne pas oublier de remettre le modèle dans l état initial et de démarrer la visualisation du MSC) : source scp.connexiondata.s1.scn. 2 TestComposer TestComposer est un outil de génération de tests de conformité. Il est conçu pour produire, automatiquement ou interactivement, des suites de tests complètes à partir d une spécification donnée et de son environnement de test. TestComposer prend en entrée une spécification SDL, un environnement de test donné par l ensemble des messages provenant de l environnement (feed) et un ensemble d objectifs de test. Ceux-ci peuvent être décrits par des MSC ou des GOAL observers. Le moteur de génération de tests produit ensuite une suite de tests, composée des tests générés pour chaque objectif de test. 2.1 Description des objectifs de test MSC Un objectif de test sous la forme d un MSC décrit les échanges de messages principaux que l on doit observer pour conclure au succès du test. Il doit décrire les interactions attendues entre le système et l environnement, où le système est considéré comme une boîte noire. Les interactions internes au système ne sont pas décrites. Concrètement, le MSC sera constitué uniquement d une instance du système, comme dans les exemples de la figure 2. Cette instance doit nommer l objet SDL qu elle représente, c est-à-dire ici le système Simple- ConnexionProtocol. Elle doit de plus porter un nom, ici inst scp. Les messages du MSC sont les signaux portés par les canaux entre le système et l environnement, dont les paramètres doivent être instanciés. Différents niveaux d abstraction sont possibles. Un objectif de test est complet s il décrit exactement tous les échanges de messages vers et depuis le système sous test (Fig. 2(a)). Il est complet en entrées s il décrit toutes les entrées à envoyer au système mais pas forcément toutes les sorties du système attendues (Fig. 2(b)). 4

5 (a) (b) Figure 2 Exemples d objectifs de test MSC (a) complet (b) complet en entrées Pour chaque objectif de test, il faut préciser à l outil l abstraction choisie pour sa description. Dans l éditeur, il est possible de préciser que l objectif de test est complet ou complet en entrée dans le menu Edit > MSC simulation properties. Préciser également que le temps est global. GOAL Observers Un objectif de test sous la forme d un observer est une machine à états finis munie d états particuliers étiquetés accept et reject. Un état est étiqueté par accept s il correspond à la fin d une séquence d actions visée par l objectif de test. L étiquette reject est donnée aux états qui correspondent à des déviations d une séquence visée et qui ne font pas partie de l objectif. Les états étiquetés par accept ou reject sont des états puits (pas de transition sortante). Figure 3 Exemple d objectif de test décrit par un GOAL observer Lorsqu on déclare un observer, il faut préciser sur quels objets du système SDL portent 5

6 les observations. Ce sont les probe (sondes) qui sont déclarées dans PR declaration. Dans la figure 3, on appelle scp la sonde qui permet d observer le processus SCP du bloc Protocol du système SimpleConnexionProtocol. 2.2 Génération des cas de test Pour générer des cas de tests à partir d un objectif de test (MSC ou observer), il faut tout d abord ouvrir dans l éditeur le système SDL et l objectif de test, puis lancer TestComposer (dans le menu Tools). Une fenêtre s ouvre, il faut alors lancer la vérification des fichiers chargés avec Check, puis lancer Build, puis Execute. Le simulateur s affiche avec des menus propres à TestComposer. Il faut commencer par charger le fichier feed pour que l outil connaissent les entrées possibles de l environnement: source scp.feed. Ensuite, la génération des tests pour l objectif de test choisi s effectue dans le menu Test Suite : Generate > Generate current, puis Publish pour que l outil écrive les tests générés dans le fichier contenant la suite de tests, et enfin Visualize pour ouvrir ce fichier. Reset sert à réinitialiser la suite de tests. 6