Principes de test des protocoles

Présentation au sujet: "Principes de test des protocoles"— Transcription de la présentation:

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

2 Première partie Théorie du test
Utilisation de matériaux de J. Tretmans et P. Koopman Université de Nijmegen Vives remerciements! 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 niveau de détail système intégration module
actif passif module Contrôlabilité unité boîte grise Accessibilité securité robustesse boîte blanche boîte noire performance utilisabilité fiabilité comportem. fonctionnel Caractéristiques 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é 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’implantation Boî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’implantation Boîte grise: quelques informations de structure interne sont disponibles Dans ce cours, nous discuterons le test boîte noire INF6001 Chap 7

9 Terminologie: robustesse, fiabilité
Robustesse: capacité de traiter des données normalement non-attendues Fiabilité (reliability): bon fonctionnement dans le temps Comportement fonctionnel: correspondance avec le comportement spécifié Dans ce cours, nous nous concentrerons sur le test à boîte noire du comportement fonctionnel Ces 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) 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 à mesure Dans 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 actif INF6001 Chap 7

11 Le test dans le modèle de développement : Modèle V
Besoins Test du système Spécification du comportement Test d’integration Spécification de l’implantation Test de module Implantation Test d’unité INF6001 Chap 7

12 Test et implantation basés sur les techniques formelles: une optique un peu différente: les tests de conformité Spec formelle Construction de l’implantation Test de l’implantation Implantation implementation 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! INF6001 Chap 7

15 Principes pour tester exhaustivement un petit système
Exemple théorique Principes pour tester exhaustivement un petit système INF6001 Chap 7

16 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

17 Cas d’étude: Spécification du comportement
Un modèle souvent utilisé est celui de Mealy Entrée / Sortie 25¢? / - Café ? / - Café ? / - 25 25¢? / - 50¢ ? / - café? / café! 50¢ ? / 25¢! 50 50¢? / 50¢! 25¢? / 25¢! INF6001 Chap 7

18 Tester avec modèle FSM Le FSM est la spécification
La structure interne de l’implantation n’est pas connue Tester l’implantation avec les chemins de la spécification Straté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 sorties
P.ex. 25¢? ; 25¢? ; café? 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é? 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 sy a? / 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 initial Pour 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 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 25 50 25¢? / - Café ? / 50¢ ? / 25¢! 25¢? / 25¢! 50¢? / 50¢! 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
Unique Input Output Pour état 0: 25¢?/ - ; café?/ - Pour état 25: 50¢?/25¢! Pour état 50: café?/café! INF6001 Chap 7

28 Méthode d’identification d’état 2 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 INF6001 Chap 7

29 Séquences W: peuvent distinguer tout paire d’états
Méthode d’identification d’état 3 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 paire Garanties 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 sy a? / 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 25¢? / 25¢? / - - café ? / - café ? / - - 25 25 25¢? / 25¢? / - - 50¢ ? / 50¢ ? / - - café? / café! café? / café! 50¢ ? / 25¢! 50¢ ? / 25¢! 50 50 INF6001 Chap 7 50¢? / 50¢! 50¢? / 50¢! 25¢? / 25¢! 25¢? / 25¢!

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
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écision pour identifier l’état
{0, 25, 50} Etc. (7 trans.) 25¢?/- 25¢?/25¢! 50¢?/- 50¢?/25¢! {0, 25} {50} {0} {25} Etc. 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. 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 INF6001 Chap 7

38 Dans un diagramme… 100 fois ?1/!1 ?1/!1 Implem. Spec. ?1/!0 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? 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’états On 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 INF6001 Chap 7

45 Langages et architectures de test (norme ISO 9646)
Deuxième partie Langages et architectures de test (norme ISO 9646) Utilisation d’une présentation trouvée dans Mars 2004 (auteur inconnu) Chap 7

46 Conformance testing Cas de test Norme (standard) Client INF6001 Chap 7
Implémentation par compagnie Centre de test indépendant 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 Client INF6001 Chap 7

47 Système testé (IUT) et système testeur
System Under Test (SUT) Test System (TS) Implementation Under Test (IUT) tester Les tests de conformité sont normalement ‘à distance’ INF6001 Chap 7

48 IUT, ASP, PCO N-IUT N-ASP PCO (N-1) ASP ou N-PDU
PCO: Point of Control and Observ ASP: Abstract Service Primitive PDU: Protocol Data Unit N-ASP PCO N-IUT (N-1) ASP ou N-PDU N-IUT: Implementation under Test de couche N L’hypothèse est que l’IUT est une couche de protocole et a des interfaces avec les couches supérieure et inférieure. INF6001 Chap 7

49 Architecture de test conceptuelle
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 Implantation de couche Tester Lower Tester 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 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 Test System (TS) Upper Tester PDUs IUT Lower Tester
System Under Test (SUT) Test System (TS) PCO ASPs Upper Tester Test Co-ordination Procedures (TCP) PDUs IUT Lower Tester ASPs PCO Lower level service provider IUT: Implementation under Test PCO: Point of Control and Observation ASP: Abstract Service Primitive PDU: 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 INF6001 Chap 7

53 Méthode distribuée Les TCP peuvent être manuelles (par opérateur) ou automatisées System Under Test (SUT) Test System (TS) Test Co-ordination Procedures (TCP) Upper Tester Lower Tester ASPs PCO IUT PDUs ASPs PCO Lower level service provider IUT: Implementation under Test PCO: Point of Control and Observation ASP: Abstract Service Primitive PDU: Protocol Data Units Appropriée pour le test d’une pile complète de protocoles 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 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é System Under Test (SUT) Test System (TS) Test Co-ordination Procedures (TCP) Upper Tester Lower Tester décroche ASPs PCO IUT N-PDU ASPs PCO Lower level service provider INF6001 Chap 7

56 Méthode coordonnée Appropriée pour tester une couche intermédiaire
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! Test System (TS) System Under Test (SUT) TM-PDU Upper Tester Lower Tester IUT PDU ASPs PCO Lower level service provider 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 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) System Under Test (SUT) Test System (TS) ? Lower Tester Upper Tester IUT PDU ASPs PCO Lower level service provider 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: INF6001 Chap 7

61 Locale Coordonnée Distribuée Éloignée INF6001 Chap 7

62 Les données de test pour les différentes architectures
Les 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 ( ) TTCN-3: Testing and Test Control Notation ( ) 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é
Standard protocol specification test generation Abstract test suite TTCN Test selection and test implementation Protocol implementation Executable test suite System Under Test IUT Tester Test report INF6001 Chap 7

64 TTCN: Tree and Tabular Combined Notation
Une notation pour spécifier les tests: TTCN: Tree and Tabular Combined Notation INF6001 Chap 7

65 Un test comme arbre d’alternatives
Incrémenter l’indentation = continuer la séquence Retourner à un niveau précédent = alternative 1 Line ! OffHook 2 Line ? DialTone Line ! Digits {signalisation} Line ? CallTone Line ? LineConnect {connexion} Line ! OnHook Line ? BusyTone {appelé occupé} Line ! DropHook 9 Line ? NoTone {problème?} INF6001 Chap 7

66 Un test comme arborescence de choix
1 Line ! OffHook 2 Line ? DialTone Line ! Digits Line ? CallTone Line ? LineConnect Line ! OnHook Line ? BusyTone Line ! DropHook 9 Line ? NoTone OffHook NoTone DialTone Digits CallTone Busy Drop Connect Onhook INF6001 Chap 7

67 TTCN-2: TABULAR notation
Test Case Dynamic Behaviour Test Case Name: Basic_Connect Group: Basic Telephone Calls Purpose: Check that a normal Basic Call Connection can be established Configuration: Default: Comments: Simple case Nr 1 Line ! OffHook 2 Line ? DialTone Line ! Digits Call Subscr2 Line ? CallTone Line ? LineConnect ConnSubscr2 Line ! OnHook Pass Line ? BusyTone Busy B 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 INF6001 Chap 7 Test System: Phone IUT: Phone Line OffHook
alt DialTone Digits [CallSubscr] alt CallTone LineConnect [ConnSubscr] Pass OnHook BusyTone Inconc. OnHook NoTone 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éussi Inconclusive: 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 TTCN Les 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 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-3 Pas 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 services Donc 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é INF6001 Chap 7

76 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

77 Une manière de voir les test d’interop
(thèse d’Alexandra Desmoulins, 2007) 77 INF6001 Chap 7

78 Architecture possible pour test d’interop
IUT: Implementation Under Test UT: Upper Tester RI: Reference Implementation TCP: 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 INF6001 Chap 7

79 Architecture simplifiée
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 INF6001 Chap 7

80 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