Chap 7 1 Chapitre 8 Principes de test des protocoles w3.uqo.ca/luigi.

Chap 7 1

Chapitre 8

Principes de test des protocoles

w3.uqo.ca/luigi

Chap 7 2

Première partie

Théorie du testUtilisation de matériaux de J. Tretmans et P. Koopman

Université de NijmegenVives remerciements!

INF6001 Chap 7 3

Définition

Le test est le processus d’exécuter un programme avec l’intention d’y trouver des erreurs [Myers]

Cependant le test est possible non seulement pour le programme ou produit final, mais aussi pour les spécifications, si elles sont exécutables

Donc nous pouvons tester une spécification SDL, LOTOS, Promela, CCS… car ces langages sont exécutables

INF6001 Chap 7 4

Un dicton fameux

Le test ne peut pas prouver l’absence d’erreurs, mais seulement leur présence (E.W. Dijkstra)

Mais en réalité nous ne connaissons aucune méthode pour prouver l’absence d’erreurs …

Problème indécidable

Dans toute l’ingénierie, Avant tout on produit une conception et une implantation utilisant

des techniques formalisées Et puis on teste le résultat car aucune technique de conception ne

peut assurer l’absence d’erreurs

INF6001 Chap 7 5

Rappel du 1er cours…

Spec d’exigences (langue naturelle, notation logique)

Spécification du comportement

Spécification de l’implantation

(comportement utilisant des composantes données)

Implantation

Nous pouvons effectuer des V&V et du test entre tous les niveaux

INF6001 Chap 7 6

Types de Testing

unité

intégration

système

performancerobustesse

comportem. fonctionnel

boîte blanche boîte noire

niveau de détail

Accessibilité

Caractéristiques

utilisabilité

fiabilité

module

securité

boîte grise

passifactif

Contrôlabilité

INF6001 Chap 7 7

Terminologie: niveau de détail

Unité, module: une unité ou un module est testéIntégration: l’intégration de plusieurs unités ou modules est

testée Nous parlerons aussi de tests d’interopérabilité

Système: le système dans sa totalité est testé

unité

intégration

système



boîte blanche boîte noireAccessibilité

Caractéristiques

utilisabilité

fiabilité

module

securité

boîte grise

passifactif

Contrôlabilité

INF6001 Chap 7 8

Terminologie: Accessibilité

Boîte blanche: le testeur connaît la structure du code Le testeur teste les différents chemins dans le code, etc. Normalement fait dans la même compagnie qui a produit le

code, comme partie du processus d’implantationBoîte noire: le testeur ne connaît pas la structure du

code, mais seulement le comportement désiré C’est donc la spécification qui guide le procédé de test Normalement fait par un organisme extérieur à la boîte

d’implantationBoîte grise: quelques informations de structure interne

sont disponiblesDans ce cours, nous discuterons le test boîte noire

unité

intégration

système




Caractéristiques

utilisabilité

fiabilité

module

securité

boîte grise

passifactif

Contrôlabilité

INF6001 Chap 7 9

Terminologie: robustesse, fiabilité

Robustesse: capacité de traiter des données normalement non-attendues

Fiabilité (reliability): bon fonctionnement dans le tempsComportement fonctionnel: correspondance avec le

comportement spécifiéDans ce cours, nous nous concentrerons sur le test à

boîte noire du comportement fonctionnelCes tests sont souvent appelés tests de conformité

car ils sont utilisés pour contrôler la conformité d’un produit à une norme (un standard)

unité

intégration

système




Caractéristiques

utilisabilité

fiabilité

module

securité

boîte grise

passifactif

Contrôlabilité

INF6001 Chap 7 10

Terminologie: test actif et passif

Dans le test actif, le testeur interagit avec l’entité testée, envoie des événements et contrôle les résultats Peut adapter son comportement aux résultats qui arrivent au

fur et à mesureDans le test passif, le testeur ne fait que analyser le

comportement de l’entité Nous avons des ‘observateurs’ qui prennent note du

comportement du système et produisent des rapports selon différents critères

Ceci peut être fait ‘offline’, cad sur la base d’observations faites à un autre moment

Dans ce cours, nous discuterons le test actifunité

intégration

système




Caractéristiques

utilisabilité

fiabilité

module

securité

boîte grise

passifactif

Contrôlabilité

INF6001 Chap 7 11

Implantation

Spécification de l’implantation

Besoins

Spécification du comportement

Test du système

Test d’integration

Test de module

Test d’unité

Le test dans le modèle de développement :

Modèle V

INF6001 Chap 7 12

implementationImplantation

Spec formelle

Test et implantation basés sur les techniques formelles:une optique un peu différente: les tests de conformité

Construction de l’implantation

Test de l’implantation

Pourquoi donc tester si l’implantation est construite sur la base de la spécification? En théorie ceci ne serait pas nécessaire, en pratique des erreurs peuvent toujours se glisser…

INF6001 Chap 7 13

Tests de conformité en pratique

Dans le cadre de la normalisation, nous avons besoin d’un test objectif pour déterminer la correspondance d’un produit à une norme

P. ex. compagnie X produit une implémentation d’un protocole standard, veut la vendre Voudrait avoir un ‘timbre de conformité’ sur son produit, comme garantie aux

clients que son implémentation est conforme à la norme Fait appel à une compagnie Y, un centre de test accrédité

Mais X ne veut pas que Y voie sa méthode d’implantation! Y devra donc envoyer des séquences de test à l’implantation du protocole

existante chez X (test ‘boîte noire’ et à distance) Ces séquences de test pourraient avoir été produites par le même organisme

qui a produit la norme du protocole (ITU, IETF…) Si le protocole de X envoie à Y les réponses attendues, l’implantation de X

obtiendra son ‘timbre de conformité’

INF6001 Chap 7 14

Tests de conformité en théorie

Ce besoin pratique a motivé plus de 25 ans de recherches sur la théorie des tests des protocoles

Des congrès internationaux sont entièrement dédiés à ce sujet!

Exemple théorique

Principes pour tester exhaustivement un petit système

INF6001 Chap 7 15

Cas d’étude: exigences partielles

Machine à caféUn café coûte 50¢Entrées possibles:

Café? : demande de café qui est satisfaite seulement si on a entré 50¢

25¢? : entrée d’une pièce de 25¢ 50¢? : entrée d’une pièce de 50¢

Sorties possibles: Café! : donne un café 25¢! : retour de monnaie: pièce de 25¢ 50¢! : retour de monnaie: pièce de 50¢

INF6001 Chap 7 16

INF6001 Chap 7 17

Cas d’étude: Spécification du comportement

Un modèle souvent utilisé est celui de Mealy Entrée / Sortie

0 25

50

25¢? / -Café ? / -

50¢ ? / 25¢!

25¢? / -

25¢? / 25¢!50¢? / 50¢!

Café ? / -

café? / café!

50¢ ? / -

INF6001 Chap 7 18

Tester avec modèle FSM

Le FSM est la spécificationLa structure interne de l’implantation n’est pas connueTester l’implantation avec les chemins de la

spécificationStratégies différentes:

Tester chaque état couverture d’états dans la spec Tester chaque transition couverture des transitions

Tester la sortie de chaque transition Tester la sortie et l’état résultant de chaque transition

INF6001 Chap 7 19

Tester tous les états

Faire le tour des états, contrôler les sortiesP.ex. 25¢? ; 25¢? ; café?

0 25

50

25¢? / -Café ? / -

50¢ ? / 25¢!

25¢? / -

25¢? / 25¢!50¢? / 50¢!

Café ? / -

café? / café!

50¢ ? / -

INF6001 Chap 7 20

Tours des transitions (Sarikaya, Bochmann)

Essayer toutes les transitions, contrôler les sorties café? ; 25¢? ; café? ; 25¢? ; 25¢? ; 50¢?; café? ; 50¢? ; café? ; 25¢? ; 50¢? ; café?

0 25

50

25¢? / -Café ? / -

50¢ ? / 25¢!

25¢? / -

25¢? / 25¢!50¢? / 50¢!

Café ? / -

café? / café!

50¢ ? / -

INF6001 Chap 7 21

Problèmes avec l’approche

En général, le problème de construire un tour optimal d’une FSM est de complexité exponentielle Étudié en algorithmique sous le nom de

Problème du commis voyageur

Requiert que la FSM soit connectée et pourrait impliquer répéter des transitions et des états

Avoir exécuté chaque état une fois ou avoir exécuté chaque transition une fois n’est pas une garantie de bon fonctionnement!

Donc au lieu d’essayer toutes les transitions dans un tour, essayer une transition à la fois Qu’elle donne la sortie désirée et conduise à l’état désiré

INF6001 Chap 7 22

Tester une transition à la fois

Tester la transition: Aller à l’état sx Exécuter l’entrée a? Contrôler la sortie b! Contrôler que nous sommes à l’état sy

But du test: (test purpose) Vérifier que le système, quand il se trouve dans l’état sx, répond à

l’entrée a? avec la sortie b! et exécute une transition à l’état sy

Comment faire tout ceci?

sx sya? / b!

sx sya? / b!

INF6001 Chap 7 23

Comment aller à l’état Sx

Un préambule peut être utilisé pour aller à un état donné, disons l’état initial, à partir de n’importe quel état Une telle séquence pourrait ne pas exister Mais dans plusieurs protocoles, nous avons des séquence

de reset qui conduisent de n’importe quel état à l’état initialPour un état quelconque, ce travail peut être divisé en

deux: Trouver une séquence de synch qui amène d’un état

quelconque à l’état initial Si le FSM est déterministe et complet, nous pouvons trouver

une séquence qui conduit de l’état initial à l’état désiré

INF6001 Chap 7 24

Séquence de synch

Séquence de synchronisation: 50¢? ; café? Contrôlez que cette séquence conduit de n’importe quel état à l’état initial

0 25

50

25¢? / -Café ? / -

50¢ ? / 25¢!

25¢? / -

25¢? / 25¢!50¢? / 50¢!

Café ? / -

café? / café!

50¢ ? / -

INF6001 Chap 7 25

Pour tester une transition… Nous voulons tester la transition (25 50¢? 50) Pour aller à l’état 0, utiliser 50¢? ; café? Puis pour aller à l’état 25, utiliser 25¢ Faire 50¢? Contrôler sortie 25¢! Vérifier que la machine est en état 50

0 25

50

25¢? / -Café ? / -

50¢ ? / 25¢!

25¢? / -

25¢? / 25¢!50¢? / 50¢!

Café ? / -

café? / café!

50¢ ? / -

INF6001 Chap 7 26

Séquences d’identification d’états

Comment vérifier qu’une machine est dans un état spécifique?

Un état pourrait être caractérisé par le fait que, étant donné une certaine séquence d’entrée, il y aura une séquence de sorties différente par rapport à la séquence de sorties de n’importe quel autre état

Ces séquences sont appelées UIO sequences Séquences d’entrée/sortie uniques Elles pourraient ne pas exister!

INF6001 Chap 7 27

Méthode d’identification d’état 1

Séquences d’identification d’état UIO

Pour état 0: 25¢?/ - ; café?/ - Pour état 25: 50¢?/25¢! Pour état 50: café?/café!

0 25

50

25¢? / -Café ? / -

50¢ ? / 25¢!

25¢? / -

25¢? / 25¢!50¢? / 50¢!

Café ? / -

café? / café!

50¢ ? / -

UniqueInputOutput

INF6001 Chap 7 28


Distinguishing sequences (séquences de différenciation)

Séquences d’entrées qui donnent des sorties différentes pour chaque état Si j’applique 50¢?

Et je suis en état 0: - Et je suis en état 25: 25¢! Et je suis en état 50: 50¢!

Donc pour cette machine il existe une séquence de différenciation de longueur 1: 50¢? Les séquences de différentiation aussi pourraient ne pas exister

0 25

50

25¢? / -Café ? / -

50¢ ? / 25¢!

25¢? / -

25¢? / 25¢!50¢? / 50¢!

Café ? / -

café? / café!

50¢ ? / -

INF6001 Chap 7 29


Méthode W (au cas que les méthodes précédentes ne fonctionnent pas)

Séquences W: peuvent distinguer tout paire d’états Pas une seule séquence, mais une séquence pour chaque

paireGaranties d’exister pour toutes paires d’états dans

toute machine réduite, cad n’ayant pas d’états redondants Je ne donnerai pas de détails

INF6001 Chap 7 30

Une suite de test complète

Donc dans cette méthode un test complet pour une transition consiste en trois parties: Préambule pour conduire à l’état de début de la transition Tester la transition: une entrée et une sortie Séquence pour déterminer que nous sommes dans le bon

état (postamble)

sx sya? / b!

INF6001 Chap 7 31

Exemple complet

Pour tester la transition (25 50, cas où on donne 50¢) Voici les trois séquences qui forment le cas de test:

50¢? ; café? sans besoin de contrôler la sortie pour se rendre à l’état 0 25¢? sans besoin de contrôler les sorties pour se rendre à l’état 25 Donner entrée 50¢? Contrôler sortie 25¢! pour tester la transition Donner café? Contrôler café! pour contrôler que nous sommes en état 50

0 25

50

25¢? / -café ? / -

50¢ ? / 25¢!

25¢? / -

25¢? / 25¢!50¢? / 50¢!

café ? / -

café? / café!

50¢ ? / -

0 25

50

25¢? / --

50¢ ? / 25¢!

25¢? / -

25¢? / 25¢!50¢? / 50¢!

café? / café!

50¢ ? / -

sx sya? / b!

INF6001 Chap 7 32

Pour tester toute la machine

Il y a 9 transitions, donc il faut une suite de test de 9 tests

Il y a des techniques pour optimiser l’ordre des tests dans les suites P.ex. si l’état de fin d’un test est l’état de début du prochain, il

n’est pas nécessaire d’exécuter la séquence de synchronisation

INF6001 Chap 7 33

Organiser le tout en forme de tableau(exercice: remplir pour les 9 transitions)

États initial et final

Préambule Transition Identif. état

0 -> 0 50¢ ; café Café? / - 50¢! / -

INF6001 Chap 7 34

Pour trouver les préambules et les séquences d’identification états

Une méthode typique: au début nous pourrions être dans n’importe quel état, les transitions suivantes pourraient réduire l’incertitude Construire un arbre de décision de l’état de départ

P.ex. pour trouver les UIO dans le cas précédent, nous procéderons comme suit (prenant en considération toutes les transitions possibles)

INF6001 Chap 7 35

Arbre de décisionpour identifier l’état

{0, 25, 50}

25¢?/-

{0, 25}

25¢?/25¢!

{50}

50¢?/-

{0}

50¢?/25¢!

{25}

Dans ce cas élémentaire, nous avons déjà trouvé toutes les séquences d’identification d’états. Dans un cas plus complexe, il faudra probabl. essayer des séquences plus longues.

Etc. (7 trans.)

Etc.

0 25

50

25¢? / -Café ? / -

50¢ ? / 25¢!

25¢? / -

25¢? / 25¢!50¢? / 50¢!

Café ? / -

café? / café!

50¢ ? / -

INF6001 Chap 7 36

Résultat théorique

Si nous faisons l’hypothèse que Le nombre d’états dans l’implémentation n’excède pas le

nombre d’états dans la spécification Alors ce type de test est complet, cad si l’implémentation

passe le test, donc sa FSM est équivalente à celle de la spécification

Malh. cette limitation fait que cette méthode n’est pas vraiment ‘boîte noire’

Pis, normalement le nombre d’états dans l’implémentation est beaucoup plus grand que le nombre d’états dans la spéc!

INF6001 Chap 7 37

Exemple pratique d’impossibilité si l’hypothèse est violée

Spécification d’exigence: Pour une entrée 1, doit sortir toujours 1 Besoin d’un seul état pour cette machine

Si l’implantation peut avoir plus d’états que la spec, nous pouvons facilement créer des implantations qui donnent le mauvais résultat après 10, 100, ….1000… transitions

Donc aucun nombre de test fini ne pourra assurer que l’exigence est toujours satisfaite Étant donné que le test est nécessairement un procédé fini,

ce résultat montre l’impossibilité théorique d’un test ‘à boîte noire’ de garantir le bon fonctionnement d’un programme

?1/!1?1/!1?1/!1?1/!1

INF6001 Chap 7 38

Dans un diagramme…

?1/!1

100 fois

?1/!0

Spec.

Implem.

• Quelle est la longueur de la séquence de test nécessaire pour découvrir l’erreur dans l’implémentation?• Peut-elle être déterminée sur la base de la spécification seulement?

?1/!1?1/!1?1/!1?1/!1

INF6001 Chap 7 39

Limitations importantes de cette théorie

En plus de cette dernière limitation Dépend de l’existence de séquences de synchronisation et

identification d’état Ne considère pas vraiment les données Ne teste pas la robustesse Pas pratique dans le cas de non-déterminisme

INF6001 Chap 7 40

Données

Considérons une machine qui peut accepter un montant quelconque x

Il faut avoir autant de transitions qu’il y a de valeurs possibles pour x

Explosion de transitions, explosion d’étatsOn peut limiter cette explosion en créant des classes

de valeurs mais la théorie et son application deviennent plus difficiles

INF6001 Chap 7 41

Robustesse…

Cette méthode ne teste pas la robustesse! P.ex. quel sera le comportement de la machine

Si 1$ est inséré Si une pièce finlandaise est insérée Si on frappe la machine…

INF6001 Chap 7 42

Non-déterminisme

Cette théorie de test présuppose aussi que l’FSM et l’entité testée soient déterministes

Car s’il y a non-déterminisme on peut ne pas savoir quel est l’état qui résulte d’une transition!

La plus longue est une séquence de transitions, le moins certain est l’état où nous sommes

Des théories de test ont été bâties sur cette incertitude, cependant elles sont difficiles à utiliser en pratique Il y a en effet 2 théories pour les tests des systèmes non-déterministes: une par

rapport aux modèles FSM, et une par rapport aux modèles algébriques (CCS, LOTOS)

Donc une hypothèse courante est qu’on teste des entités déterministe Qui peuvent être entièrement contrôlées par l’environnement de test

Ce qui rend cette théorie inutilisable pour le test d’un système entier P.ex. dans le protocole du bit alterné, la perte des message ne peut pas être

contrôlée par l’environnement de test

INF6001 Chap 7 43

Utilisation pratique de cette méthode

Pour les raisons mentionnées, cette méthode de test n’est pas beaucoup utilisée en pratique Elle a encore des mérites comme guide méthodologique

Plus utilisés sont les tests fonctionnels basés sur les exigences Que le protocole correspond aux exigences

Malheureusement, Il n’y a pas de formalisme largement accepté pour la

spécification des exigences Il n’y a pas de théorie largement acceptée sur comment

dériver des tests de conformité sur la base des exigences Donc ce type de test ne garantit absolument rien…

INF6001 Chap 7 44

Exemple de test d’exigences

Pour un système téléphonique, quand on décroche on doit entendre la tonalité après avoir composé, on doit entendre ou bien libre ou bien

occupé voici deux tests qui ne dépendent pas de la théorie que nous

avons présentée

Chap 7 45

Deuxième partie

Langages et architectures de test

(norme ISO 9646)

Utilisation d’une présentation trouvée danshttp://www.item.ntnu.no/fag/ttm4160/Testing/, Mars 2004(auteur inconnu)

http://www.item.ntnu.no/fag/ttm4160/Testing/

Conformance testing

INF6001 Chap 7 46

Centre de test indépendant

Cas de test

Norme (standard)

Implémentation par compagnie

Client

Certifie l’implémentation ou signale des bogues

Achète l’implémentation seulement si elle a été certifiée par le centre de test

INF6001 Chap 7 47

Système testé (IUT) et système testeur

Test System (TS)Implementation

Under Test (IUT)

System Under Test (SUT)

tester

Les tests de conformité sont normalement ‘à distance’

INF6001 Chap 7 48

IUT, ASP, PCO

N-IUT: Implementation under Test de couche N

PCO: Point of Control and ObservASP: Abstract Service PrimitivePDU: Protocol Data Unit

L’hypothèse est que l’IUT est une couche de protocole et a des interfaces avec les couches supérieure et inférieure.

N-ASP

PCO

PCO

N-IUT

(N-1) ASP ou N-PDU

PCO

PCO

INF6001 Chap 7 49

Architecture de test conceptuelle

Tester

• L’architecture présupposée jusqu’à maintenant:• Le testeur est directement connecté à l’IUT et en contrôle le comportement• Telle quelle décrite, seulement utilisable dans le cas où le test est fait localement par l’implanteur: Capacité maximale de détection d’erreurs• Pas utilisable directement pour les tests de conformité, car la communication entre upper et lower tester doit se faire à travers le milieu (couches inférieures)

Upper Tester

Lower Tester

Implantation de couche

N-ASP

PCO

PCO

N-IUT

(N-1) ASP or N-PDU

PCO

PCO

N-ASP

PCO

PCO

N-IUT

(N-1) ASP or N-PDU

PCO

PCO

INF6001 Chap 7 50

Méthodes de test abstraites pour les tests de conformité

Nous sommes intéressés à des méthodes utilisables pour les tests de conformité qui sont exécutés par un testeur indépendant

Il y a une norme à ce sujet: ISO 9646. Elle décrit les méthodes suivantes: Méthode locale

Upper tester et lower tester sont dans le système de test L’upper tester est directement contrôlé par le testeur et son interface avec l’IUT est un PCO

Méthode distribuée L’upper tester est dans le système testé Il est directement contrôlé par le testeur et son interface avec l’IUT est un PCO

Méthode coordonnée L’upper tester est dans le système testé mais est implémenté par l’implanteur du système testé Il est indirectement contrôlé par le testeur et son interface avec l’IUT n’est pas directement

observable Méthode éloignée (remote)

Pas de Upper Tester

INF6001 Chap 7 51

Méthode locale

Upper Tester

IUT

ASPsPCO

System Under Test (SUT) Test System (TS)

Lower Tester

ASPs

PCO

Lower level service provider

Test Co-ordinationProcedures (TCP)

PDUs

IUT: Implementation under TestPCO: Point of Control and ObservationASP: Abstract Service PrimitivePDU: Protocol Data Units

Cette méthode est considérée pratique seul. pour tester le matériel

INF6001 Chap 7 52

Contrôlabilité dans la méthode locale

Dans un système réel, la couche supérieure, ici représentée par l’Upper Tester, communique directement avec l’IUT

Afin que cette méthode soit fidèle, la comm. entre l’IUT et l’UT doit donc être synchrone – les deux entités doivent fonctionner comme si elles étaient directement connectées Le cercle jaune dans la figure représente cette synchronisation

C’est à cause de ça qu’on dit que la méthode locale est pratique seulement pour tester le matériel SUT, TS, PCO seront donc du matériel

Pour les tests de conformité du logiciel, il faut utiliser des méthodes asynchrones, comme les suivantes

Upper Tester

IUT

ASPsPCO


Lower Tester

ASPs

PCO



PDUs

INF6001 Chap 7 53

Méthode distribuée

Upper Tester

IUT

ASPs

PCO


Lower Tester

ASPs

PCO



PDUs

IUT: Implementation under TestPCO: Point of Control and ObservationASP: Abstract Service PrimitivePDU: Protocol Data Units

Appropriée pour le test d’une pile complète de protocoles

Les TCP peuvent être manuelles (par opérateur) ou automatisées

INF6001 Chap 7 54

Détails sur la méthode distribuée

L’Upper Tester est un produit de la compagnie qui fait les tests La coordination entre Lower Tester et Upper Tester est un protocole de

cette compagnie Pourrait être exécutée par un opérateur Les suites de test seront semblables à celles de la méthode locale

Upper Tester

IUT

ASPs

PCO


Lower Tester

ASPs

PCO



PDUs

INF6001 Chap 7 55

Exemple

P. ex. supposons de tester un commutateur téléphonique L’upper tester pourrait simuler l’usager (directement connecté) Le lower tester pourrait ‘simuler’ le commutateur distant Peut donner des instructions à l’upper tester, p.ex. décroche l’appareil Et contrôler la bonne réponse sur le PCO auquel il est direct. connecté

Upper Tester

IUT

ASPs

PCO


Lower Tester

ASPs

PCOLower level service provider


N-PDU

décroche

INF6001 Chap 7 56

Méthode coordonnée La méthode distribuée a le désavantage que le site de l’ITU doit admettre l’intrusion dans son système

d’un upper tester ‘étranger’ qui est directement contrôlé par le testeur Dans la méthode coordonnée, l’Upper Tester est directement connecté à l’IUT et est normal. implanté

par le fabricant de l’IUT Il communique avec le testeur par un Test Management Protocol qui échange des TM-PDUs Pas de PCO du côté SUT!

Upper Tester

IUT


Test System (TS)

Lower Tester

ASPs

PCO


PDU

TM-PDU

Appropriée pour tester une couche intermédiaire

INF6001 Chap 7 57

Détails sur la méthode coordonnée

Le Test Management Protocol doit être normalisé Car le testeur pourrait être n’importe quelle entité

La coordination entre LT et UT (TM-PDUs) doivent aussi être partie de la suite de test Les messages détaillant cette coordination

pourraient être inclus dans la partie données des N-PDU Donc passer par le ‘lower-level SP’

ou pourraient être transmis à travers une connexion séparée

Upper Tester

IUT


Test System (TS)

Lower Tester

ASPs

PCO


PDU

TM-PDU

INF6001 Chap 7 58

Méthode éloignée (remote) L’upper tester n’est pas requis, son travail peut être effectué par un opérateur qui suit des instructions informelles Ou le lower tester peut envoyer des PDUs qui contiennent des données que l’IUT interprétera comme primitives à

appliquer à son interface supérieure (ligne pointillée) Les possibilités de détection d’erreur sont limitées car il n’est pas possible de contrôler ou observer directement

l’interface supérieure Cependant il s’agit de la méthode la plus souvent utilisée, car son architecture est la plus simple

Adéquate pour tester des protocoles où le rôle de l’interface supérieure de l’SUT est limité (p.ex. FTP, File Transfer Protocol)

IUT

System Under Test (SUT)Test System (TS)

Lower Tester

ASPs

PCO


PDU

Upper Tester?

INF6001 Chap 7 59

Liaison entre Upper Tester et Test System

Toutes les architectures (moins celle éloignée) prévoient une liaison entre UT et TS

Cette liaison est réelle et doit être implantée séparément du fournisseur de service inférieur

Possibilités: Un lien indépendant et fiable implanté d’une façon

quelconque? Deux personnes qui communiquent par téléphone?

INF6001 Chap 7 60

Conclusions sur les architectures de test

Ces possibilités ont été proposées en théorie et quelques unes pourraient avoir resté dans la théorie…

Il y a de la liberté dans l’interprétation de chaque méthode

Chaque méthode a ses propres domaines d’utilisation et ses propres capacités de détection d’erreurs

Pour en savoir davantage: http://portal.etsi.org/edithelp/pdf/021__r1.pdf http://www.mailmeanywhere.org/sw.free/neda/leap/esro/ESROS-MulPub/doc/esroSrcDesc-tty/split/node34.html

http://portal.etsi.org/edithelp/pdf/021__r1.pdf

INF6001 Chap 7 61

Upper Tester

IUT

ASPsPCO


Lower Tester

ASPs

PCO



PDUs

Upper Tester

IUT

ASPs

PCO


Lower Tester

ASPs

PCO



PDUs

Upper Tester

IUT


Test System (TS)

Lower Tester

ASPs

PCO


PDU

TM-PDU

IUT

System Under Test (SUT)Test System (TS)

Lower Tester

ASPs

PCO


PDU

Upper Tester?

Locale Coordonnée

DistribuéeÉloignée

INF6001 Chap 7 62

Les données de test pour les différentes architecturesLes cas de test abstraits sont normalement

indépendants de l’architecture Ils ont une nature ‘globale’

Ils doivent être adaptés à l’architecture choisie TTCN est un langage normalisé pour la définition de

séquences de test abstraites TTCN-1 et TTCN-2: Tree and Tabular Combined Notation (1984-1997) TTCN-3: Testing and Test Control Notation (1998-2001)

Notre discussion sera focalisée sur TTCN-2(TTCN-3 est beaucoup plus compliqué et général).

INF6001 Chap 7 63

Le processus de test de conformité

System Under Test

IUT

System Under Test

IUT

Abstract test suite

Executable test suite

TesterTester

Standard protocol

specification

test generation

Protocol implementation

Test selection and test implementation

TTCN

Test report

TTCN:TREE AND TABULAR COMBINED NOTATION

Une notation pour spécifier les tests:

INF6001 Chap 7 64

INF6001 Chap 7 65

Un test comme arbre d’alternatives

1 Line ! OffHook

2 Line ? DialTone

3 Line ! Digits {signalisation}

4 Line ? CallTone

5 Line ? LineConnect {connexion}

6 Line ! OnHook

7 Line ? BusyTone {appelé occupé}

8 Line ! DropHook

9 Line ? NoTone {problème?}

Incrémenter l’indentation = continuer la séquenceRetourner à un niveau précédent = alternative

INF6001 Chap 7 66

Un test comme arborescence de choix

OffHook

DialTone

Digits

CallTone

Connect

Onhook

Busy

Drop

NoTone

1 Line ! OffHook

2 Line ? DialTone

3 Line ! Digits

4 Line ? CallTone

5 Line ? LineConnect

6 Line ! OnHook

7 Line ? BusyTone

8 Line ! DropHook

9 Line ? NoTone

INF6001 Chap 7 67

TTCN-2: TABULAR notationTest Case Dynamic Behaviour

Test Case Name: Basic_ConnectGroup: Basic Telephone CallsPurpose: Check that a normal Basic Call Connection can be establishedConfiguration:Default:Comments: Simple case

Nr

1 Line ! OffHook

2 Line ? DialTone

3 Line ! Digits Call Subscr2

4 Line ? CallTone

5 Line ? LineConnect ConnSubscr2

6 Line ! OnHook Pass

7 Line ? BusyTone Busy B

8 Line ! DropHook Inconclusive

9 Line ? NoTone Fail

Label Dynamic Behaviour Constraints ref Verdict Comments

Detailed Comments: This is a very simple case

INF6001 Chap 7 68

Test en MSC

Test System: Phone IUT: Phone Line

OffHook

DialTone

Digits [CallSubscr]

CallTone

LineConnect [ConnSubscr]

OnHook

BusyTone

OnHook

NoTone

alt

alt

Pass

Inconc.

Fail

INF6001 Chap 7 69

Verdicts: Pass, Fail, Inconclusive

Pass: le but du test a été vérifié Dans le cas précédent: il a été vérifié qu’un appel

téléphonique a été complétéFail: Le but du test n’a pas été vérifié, montrant que le

système ne correspond pas aux spécs: Dans le cas précédent: on a cherché a établir un appel mais

on n’a pas réussiInconclusive: Le but du test n’a pas été vérifié, à cause

de non-déterminisme dans le système qui a conduit à un autre résultat Dans le cas précédent, l’appel n’a pas pu être établi à cause

du fait que l’appelé était occupé

INF6001 Chap 7 70

Points of Control and Observation en TTCN

Les PCOs sont des ‘portes’ dans la notation TTCNLes actions dans une suite TTCN ont la forme

PCO_nom ! ASP_PDU[options] PCO_nom ? ASP_PDU [options]

P.ex. dans l’exemple précédent le seul PCO est Line, Mais dans une architecture de test réelle ces différents

événements se produiront à interfaces différentes

INF6001 Chap 7 71

Séquences de tests abstraites et concrètes

Une séquence de test abstraite doit être rendue concrète en considérant: l ’architecture de test choisie la représentation des données pour l’équipement spécifique

P.ex. digits doit être traduit dans une séquence de signalisation 819-765-5500

Codage des PDUs (séquences de bits, etc)Donc il faut aussi prévoir un mécanisme de traduction

d’abstrait à concret (v. PIXIT plus tard)

Il y a en production industrielle plusieurs engins de test qui peuvent être programmés en TTCN et produire des tests concrets

INF6001 Chap 7 72

Concernant TTCN-3

TTCN-2 est adéquat pour spécifier des stratégies de test simples: essentiellement des arborescences

Quand la stratégie de test devient complexe, il est difficile de relier ensemble un grand nombre de tableaux et d’arbres de test

TTCN-3 est comparable à un langage de programmation les architectures de test et des stratégies de tests complexes

peuvent être programmés en TTCN-3Pas limité aux protocoles

INF6001 Chap 7 73

PICS : Protocol Implementation Conformance Statements

Options implémentées Pas toute la norme est nécessairement implémentée

Rangées de valeurs de paramètres supportées

INF6001 Chap 7 74

PIXIT: Protocol Implementation Extra Information for Testing

Information nécessaire pour traduire les suites de test abstraites en suites concrètes

Codage des données, adresses possibles, etc etc

Implantation supposée du système de test, etc etc

INF6001 Chap 7 75

Les méthodes de test dans le monde IP

Malheureusement, il n’y a pas de specs formelles dans le monde IP Pas de specs formelles de protocoles, pas de specs formelles de

servicesDonc les méthodes de test formelles ne sont pas facilement

applicables Mais encore il y a eu des excellents résultats dans cette direction

Il faut avant tout établir ce qu’il faut tester, etc.Cependant le problème de la certification du comportement

correct de services web est en train de se proposer Surtout pour les aspects sécurité

Test d’interopérabilité

Les tests d’interopérabilité évaluent l’interopérabilité entre différentes implémentations

Ils testent les capacités et le comportement d’une implémentation dans

un environnement de réseau Si une implémentation peut communiquer avec une autre

implémentation du même type ou de type différent

INF6001 Chap 7 76

Une manière de voir les test d’interop

INF6001 Chap 7 77

77

(thèse d’Alexandra Desmoulins, 2007)

Architecture possible pour test d’interop

INF6001 Chap 7 78

IUT: Implementation Under TestUT: Upper TesterRI: Reference ImplementationTCP: Test control procedures

La ‘Reference Implementation’ est supposée implémenter correctement la norme et donc assure que l’IUT corresponde aussi à la norme.

En pratique, il pourrait être difficile d’implémenter tout ceci

Architecture simplifiée

INF6001 Chap 7 79

Cette architecture est plus pratique (implémentation plus simple) mais ne détecte pas le cas où les deux entités communiquent mais n’implémentent pas correctement la norme.

Note: pourrait être redessinée dans la forme de l’architecture précédente, la différence essentielle est que nous n’avons pas de RI

Il y a beaucoup de recherche sur les tests d’interopérabilité mais une théorie ferme n’a pas encore été établie

V. Article: T. Walter, I. Schieferdecker, J. Grabowski: Test Architectures for DistributedSystems - State of the Art and Beyond (1998) Article duquel j’ai repris quelques figures et concepts Facilement répérable par recherche web

INF6001 Chap 7 80

Chap 7 1 Chapitre 8 Principes de test des protocoles w3.uqo.ca/luigi.

Documents

Transcript of Chap 7 1 Chapitre 8 Principes de test des protocoles w3.uqo.ca/luigi.