Interface 2 : Génération des cas de test de robustesse

Cette interface permet de générer les cas de test de robustesse à partir de la spécification

augmentée S_Aet un objectif de test de robustesse RTP. D’abord, l’utilisateur est interrogé

pour insérer deux fichiers, l’un de la spécification augmentée S_Aet l’autre de la spécification

nominale S. RTCG procède à l’ajout de traces de suspension, puis à la déterminisation de la spécification nominale. Ensuite, il compare, au fur et à mesure, les transitions de

la spécification augmentée à celles de ∆(Sδ). Pendant cette comparaison, RTCG attribue

une couleur à l’ensemble de transitions de ∆(Sδ) et une autre couleur à l’ensemble de

transitions hors de ∆(Sδ). La coloration de transitions sera utilisée comme un critère de

sélection des cas de test de robustesse.

Formats : SDL, DOT Automate suspendu Déterminisation Coloriage Objectif de Test de robustesse Format DOT Produit Synchrone

Graphe Réduit du Test de robustesse Sélection

Cas de Test de Robustesse Spécification Formats : SDL, DOT Formats : TTCN−3, XML, DOT Spécification augmentée Coloriée Formats : SDL, DOT Augmentée Spécification

Fig. 50: Architecture de l’interface 2

L’utilisateur est ensuite interrogé pour insérer un autre fichier décrivant l’objectif du test de robustesse et fixer les états initiaux de chaque IOLTS, ainsi que l’état Accept de RTP. Les objectifs utilisés dans la version actuelle de RTCG utilisent seulement les deux étiquettes Accept et other (Reject n’est pas encore utilisée). Les différents algorithmes de cette interface sont donnés ci-dessous :

Interprétation de l’objectif du test de robustesse

D’abord, RTCG procède à l’interprétation de l’objectif de test de robustesse. Celle-ci consiste à remplacer chaque transition étiquetée par other par l’ensemble de transitions

correspondant. Ceci est calculé par l’algorithme 7. Algorithme 7 Interprétation de RTP

Entrées: RT P abstrait Sorties: IOLT S de RTP

pour tout état q dans RT P tel que q−−−−→^otherRT P q
faire pour tout action a dans ΣSA− IO(q) faire

Ajouter une transition q−→^a RT P q
; fin pour

Supprimer q−−−−→^other RT P q
; fin pour

Pour toute transition T de RTP étiquetée par other. Pour chaque action a non spécifiée dans l’état source de T , on ajoute une transition étiquetée par a.

Construction des graphes du test de robustesse

Afin de calculer toutes les traces, de la spécification augmentée, satisfaisant l’objectif de test de robustesse, nous avons besoin de calculer leur produit synchrone. Partant de la définition 27, nous proposons l’algorithme suivant :

Algorithme 8 Le produit synchrone

Entrées: Deux IOLTSs, SA= (QSA, q₀^SA, ΣSA, →SA) et RT P = (QRT P, qRT P

0 , ΣRT P, →RT P) Sorties: IOLTS SA⊗ RT P = (QSA⊗RT P, q₀^{SA⊗RT P}, ΣSA⊗RT P, →SA⊗RT P) Q^SA⊗RT P := ∅ ; q^S₀^{A⊗RT P} = (qSA 0 , qRT P 0 ) ; QSA⊗RT P := {qSA⊗RT P 0 } ; pour tout qSA⊗RT P = (qSA j , qRT P k ) ∈ QSA⊗RT P _faire

pour tout a ∈ IO(q^S_j^A) ∪ IO(qRT P k ) faire si (q, q
) ∈ QSA⊗RT P, q
= Accept, q a −→SAq1, q
^a−→RT P q
₁alors Ajouter la transition(q, q
) a −→SA⊗RT P (q1, q₁
) ; finsi si(q, q
) ∈ QSA⊗RT P, q
= Accept, q a −→SAq1, q
a −→RT P alors Ajouter la transition(q, q
) a −→SA⊗RT P (q1, q
) ; finsi si(q, q
) ∈ QSA⊗RT P, q
= Accept, q a −→SA, q
^a−→RT P q
₁ alors Ajouter la transition(q, q
) a −→SA⊗RT P (q, q
1) ; finsi fin pour fin pour

L’algorithme 8 utilise une liste d’états pour enregistrer les états créés de S_A⊗ RT P et

une table dynamique pour stocker les transitions de S_A⊗ RT P . IO(q) décrit l’ensemble

d’actions (entrées et sorties) tirables dans l’état q. c’est à dire IO(q) = In(q) ∪ Out(q).

Nous rappelons que les règles de synchronisation ne sont pas applicables sur l’état Accept.

Le graphe du test de robustesse RTG est l’image miroir du produit synchrone S_A⊗RT P

(les entrées deviennent sorties et inversement). Pour ce faire, il suffit de parcourir toutes

Algorithme 9 Réduction du graphe de test de robustesse RT C

Entrées: Le graphe de test de robustesse RT G Sorties: Le graphe réduit de test de robustesse RRT G

Étape 1 : récupération de l’ensemble d’état depuis lesquels Accept est accessible. {V isitedStates est la liste d’états à visiter}

V isitedStates := ∅ ;

{CurrentState est l’état actuel} CurrentState := Accept ; répéter

V isitedStates := V isitedStates ∪ P redecessors(CurrentState) ; Passer à l’état suivant dans la liste V isitedStates ;

jusqu’à ce qu’il n’y a aucun état à ajouté ; Étape 2 : Construction de RRT G. RRT G := ∅ ;

pour tout transition q−→ q^a
dans RT G faire si(q ∈ V isitedStates) ∧ (q
∈ V isitedStates) alors

Ajouter la transition q−→ q^a
dans RRT G ; finsi

si(q ∈ V isitedStates) ∧ (q
∈ V isitedStates) ∧ (∃a ∈ ΣRT G I |q a

−→ q
) alors Ajouter la transition q−→ Inconc dans RRT G ;^a

finsi fin pour

Le graphe du test de robustesse RTG contient certaines traces de la spécification aug-mentée qui ne satisfont pas l’objectif RTP. En conséquence, il est nécessaire de réduire ce graphe en se concentrant uniquement sur l’ensemble d’états/transitions depuis lesquels l’état Accept est accessible, ainsi que toute réception partant de cet ensemble. L’algorithme 9 assure cette réduction. Cet algorithme collecte d’abord une liste d’états (V isitedStates) depuis lesquels l’état Accept est accessible. Pour ce faire, il enregistre l’ensemble de

pré-décesseurs (predecessors(q)) de chaque état q dans la liste V isitedStates. Ensuite,

l’algo-rithme parcourt RTG et ajoute toute transition dont la source et la cible font partie de

V isitedStates, ainsi que toute transition sortant de V isitedStates par une réception.

Sélection d’un cas de test de robustesse

Pour dériver un cas de test de robustesse RTC, nous avons implémenté un algorithme de génération à la volée (on-the fly) avec quelques règles supplémentaires privilégiant les entrées invalides et les entrées inopportunes. Pour ce faire, nous avons implémenté l’algo-rithme 1 présenté dans le chapitre 6. Cet algol’algo-rithme parcourt le graphe du test de robustesse RTG à partir de son état initial. Dans chaque état visité, s’il s’agit d’un :

1. État de réception, on prend alors toutes les réceptions spécifiées dans cet état ; 2. État d’émission et réception, on fait un choix aléatoire entre l’une ou l’autre. Selon

le choix, s’il s’agit d’un état de.

(a) Émission, on choisit uniquement une seule transition (on donne l’avantage aux émissions coloriées différemment de celles de la spécification nominale) ;

(b) Réception, on prend alors toutes les réceptions spécifiées dans cet état ;

Dans chaque état de réception, on ajoute une transition, etiquetée par " ?other ", vers un état sans successeur représentant le verdict Fail.

Description des cas de test en langage TTCN-3

TTCN (Tree and Tabular Combined Notation) est un langage normalisé dans les re-commandations Z.140-146 de ITU-T [38] et ISO 9646-3 [91]. Ce langage est un moyen pour représenter les séquences de test en distinguant les symboles que le testeur doit émettre et recevoir. TTCN (versions 1 et 2) permet de décrire des séquences de test abstraites en deux formats : TTCN.GR (Graphic) qui modélise les séquences de test par des tableaux, et TTCN.MP (Machine Processable) qui traduit les séquences de test en format supporté par les testeurs automatiques. La représentation tabulaire (TTCN.GR) d’une suite de test comporte deux parties :

1. une partie statique ou déclarative décrivant les points de contrôle et d’observation (PCOs), les unités de données du protocole (PDUs) ainsi que les horloges ;

2. une partie dynamique décrivant la séquence du test, c’est à dire les émissions et les réceptions, l’interrogation et la réinitialisation d’horloges ainsi que les verdicts. TTCN-3 (Testing and Test Control Notation) [58] est la version actuelle de TTCN. Le but de TTCN-3 est d’élargir le domaine d’utilisation aux autres types du test. La norme TTCN-3 inclut plusieurs formats (facultatifs) de présentation : format textuel avec une syntaxe proche de celle des langages de programmation, format tabulaire (TFT) qui est bien connu aux utilisateurs des versions plus anciennes de TTCN, et un format graphique (GFT) qui exprime les séquences de test sous une forme graphique.

Dans notre outil RTCG, nous utilisons le format textuel pour décrire les cas de test de robustesse. Dans TTCN-3, un cas de test comporte trois parties :

1. partie interface (runs on) qui décrit le type de MTC (Main Test Component) ; 2. partie système (system) décrit le type de l’interface du système ;

3. partie comportement (behaviour part) décrivant le comportement du MTC. En général, un cas de test possède la syntaxe suivante :

testcase <nom de cas de test> runs on <partie interface> system <partie système>

timer ReponseTimer := temps de réponse; // partie préambule L1.send(Message0) ... // test L1.send(Message1) ReponseTimer.start alt { [contrainte 1] L1.receive(Message1) {faire quelque chose }

[contrainte 2] L1.receive(Message2) {...} [contrainte 3] L1.receive(Mesage3)

{...}

[else] {faire quelque chose} }

...

après la réception d’un message, le testeur exécute une affectation d’un verdict

(ReponseT imer.start, ReponseT imer.stop) ou un appel à une fonction particulière.