Concrétisation des cas de tests

Les approches de génération des cas de tests doivent faire face au problème de l'explosion combinatoire du nombre de cas de test [59]. Comme il a été mentionné dans l'introduction, un test exhaustif du système est impossible, aussi bien en principe qu'en pratique. Ainsi, une spécification de test est obligatoirement nécessaire. Elle a deux objectifs : en premier lieu, elle permet de définir formellement les parties du système concernées par les tests et en second lieu, de réduire considérablement l’effort de test nécessaire. En d’autres termes, une spécification de test permet de définir parmi les traces potentielles, celles qui constitueront la batterie de test. Le type d'une spécification de test peut être classé en trois catégories : spécifications fonctionnelles, structurelles ou stochastiques. Dans la majorité des cas, la spécification fonctionnelle est utilisée en conjonction avec les spécifications structurelles ou stochastiques. Pour notre cas, nous n’allons considérer que la spécification de type fonctionnel. L'idée derrière une spécification fonctionnelle est de concevoir des scénarios de tests concernant certaines fonctionnalités du système à tester. Cet objectif est atteint en concentrant l’effort de test sur des parties « spéciales » de l’application, sur une vue particulière du système ou sur un cas d'utilisation bien spécifique et ce dans l’objectif de limiter le comportement du modèle de test à un nombre réduit de fonctionnalités. Les spécifications fonctionnelles couvrent, généralement, des relations d’entrée/sortie faisant référence soit à des scénarios dans les documents de spécifications, soit à des vues spécifiques résultants de l'expérience du testeur telles que les sections du code à forte intensité d’erreurs. Ainsi, le nombre de traces de tests possibles s’en trouve réduit (par cette définition de contraintes fonctionnelles supplémentaires concernant le système lui-même ou son

environnement).

En outre et dans l’objectif de produire des tests efficaces (tests permettant de ressortir un plus grand nombre de défauts), la technique de conception de cas de tests appelée « error-guessing » est également adoptée dans le cadre de cette approche. En réalité, cette stratégie n’est pas en soi une technique de test, mais plutôt une compétence qui peut être appliquée à toutes les autres techniques tests. Elle est basée sur l’aptitude du testeur de puiser dans ses expériences passées, ses connaissances et son intuition pour mieux détecter la localisation des défauts dissimulés dans un système sous test.

Test des interactions agents utilisant les réseaux de Petri récursifs colorés

83

Un chemin du graphe d’accessibilité généré étant abstrait (une combinaison de place en entrée, de transitions tirées et de places en sortie), plusieurs informations significatives y sont absentes pour considéré ce chemin comme étant directement exécutable. Ainsi, un tel cas de test abstrait doit être concrétisé en utilisant le graphe d’accessibilité généré avec la spécification de test et le fichier d’information agent. En d’autres termes cette étape agit comme un traducteur qui transforme les cas de tests abstraits en cas de tests concrets. Par la suite, ces cas de tests concrets peuvent être soumis à l’application sous test. Le translateur ayant pour but de réduire le gap entre le modèle abstrait et le système concret en ajoutant des informations manquantes et en transformant les entités abstraites en des structures du langage de la plateforme de test.

Comme beaucoup d’autres approches [62], on distingue différentes parties dans un cas de test concret. Ces parties sont : le prologue, le corps de test, le verdict et l’épilogue.

• Le prologue : au tout début, le prologue initialise le système sous test. Après l’avoir

exécuté on peut dire que le système a atteint l’état considéré comme point d’origine du cas de test actuel.

• Le corps de test : il contient les opérations et les stimuli correspondants à l’objectif du test

en cours

• Le verdict : définit des critères qui déterminent, en fonction des sorties ou des états

observés du système sous test, si les tests passent ou échouent.

• L’épilogue : à la fin, l’épilogue libère le système sous test dans un état final bien défini.

Plus précisément, l’épilogue prépare le système pour un nouveau cas de test ou, dans certain cas, libère le système sous test.

Pour vérifier l’exactitude d’une séquence d'exécution issue du graphe d’accessibilité, le translateur commencera par transformer les places en entrée de cette séquence en une série de messages codés selon la spécification de la structure de message FIPA ACL: <performatif,

Sender, Receiver, Reply-to, content, language, ontologie> [16], destiné aux agents concernés

les invitant à effectuer une série d'opérations pour diriger le système à un état initial. Les paramètres Sender, Receveir et Reply-to informent sur l'identité des agents impliqués dans l'acte de communication. Le paramètre Performative indique le type de ce dernier (Inform,

Request, Propagate, Confirm, etc.). Etant donné que le paramètre ontologie dans une telle

situation est le même pour la communauté des agents, il peut être omis. Enfin, le paramètre

language désigne le langage dans lequel le paramètre content est exprimé. Pour notre cas,

nous allons utiliser le langage de spécification FIPA SL [18]. Ainsi, l'agent testeur (en utilisant le fichier d’informations agent) tentera, dans la partie prologue du cas de test concret, de définir les caractéristiques principales du système sous test à savoir : les agents cibles concernés, l’acte de communication et un ensemble de conditions supplémentaires tel le nombre maximum d'agents pour lesquels le message doit être transmis. Un exemple d'un tel message est le suivant:

Test des interactions agents utilisant les réseaux de Petri récursifs colorés

(inform

:sender (:name TesterAgent) :receiver (:name InitiatorAgent)

:content ( = (? BrokerAgent) (Tourismagent@whitestein.com:8080); = (? NbAgent) (1);

= (? Service) (book-hotel); :language FIPA-SL

:reply-with query1)

Par ailleurs, connaissant les noms des différentes transitions apparaissant dans la séquence de test sélectionnée: proxy, accepter, refuser, échec, ... etc, et les noms d’objets leurs correspondants (contenus dans les fichiers d'information agent) avec les valeurs des variables contenues dans les places d'entrée et l'identification de l'agent impliqué dans chaque séquence de test, le traducteur peut formater ces informations, en respectant la spécification de la structure de message FIPA ACL, pour générer des performatives de type Request destinées aux agents sous test. Le paramètre content du message FIPA ACL dépend de l'action à exécuter par l'agent(s). Dans cet exemple simple l’agent testeur demande à l'agent initiateur d’adresser un proxy à l'agent courtier pour réserver une chambre d’hôtel:

(request

:sender (:name TesterAgent) :receiver (: name InitiatorAgent) :language FIPA-SL

: protocol fipa-proxy

:content(action (:name BrokerAgent) (book-hotel

(:arrival 05/11/2008) (:departure 05/12/2008) (:infos (…)) )

:reply-with query1))

Le résultat attendu après l'exécution du corps de test en cours par un des agents sous test est également dérivé de la séquence d’exécution et ce en prospectant les places de sortie ainsi que les valeurs des variables correspondantes. Plusieurs scénarios sont possibles : le succès ou l'échec des tests peut être vérifié selon la réponse de l'agent suite à une demande explicite de l'agent testeur (le test échoue si la réponse de l'agent est de type failure). Par exemple, dans le message précédent l'expéditeur a utilisé le paramètre reply_with. Un tel paramètre introduit une expression qui sera utilisée par l'agent répondant afin d’identifier ce message. Ainsi, l'agent testeur peut, une fois la réponse reçue, confronter les deux messages pour décider si le test passe ou échoue. L'agent testeur peut aussi décider que les tests échouent si les valeurs des variables contenues dans la réponse de l'agent sont différentes de celles contenues dans les places de sortie de l’actuelle séquence de test. L'exactitude de l'exécution du système peut enfin être vérifiée après plusieurs d'interactions complexes entre l'agent testeur et les agents sous test. Il est à noter que dans la technique « error-guessing » adoptée, les ingénieurs de test peuvent énumérer une liste des situations à fort risque d’erreurs. L’agent testeur devra alors être en mesure de vérifier le comportement des agents face à ces situations.

Test des interactions agents utilisant les réseaux de Petri récursifs colorés

85

La partie épilogue du cas de test est également préparée à ce stade. Ainsi, tant que la fin de la séquence de test n'a pas encore été atteinte, le traducteur va générer le corps de test suivant et le placer dans la partie épilogue du cas de test courant. Sinon, cette partie contiendra l’ensemble des messages nécessaires à la libération et à la destruction des agents testés ainsi que l’ensemble de messages nécessaires à l’arrêt du processus de test.