La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "Chap 7 1 Chapitre 8 Principes de test des protocoles w3.uqo.ca/luigi."— Transcription de la présentation:

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

2 Chap 7 2 Première partie Théorie du test Utilisation de matériaux de J. Tretmans et P. Koopman Université de Nijmegen Vives remerciements!

3 INF6001 Chap 7 3 Définition Le test est le processus d exécuter un programme avec lintention dy 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

4 INF6001 Chap 7 4 Un dicton fameux Le test ne peut pas prouver labsence derreurs, mais seulement leur présence (E.W. Dijkstra) Mais en réalité nous ne connaissons aucune méthode pour prouver labsence derreurs … Problème indécidable Dans toute lingé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 labsence derreurs

5 INF6001 Chap 7 5 Rappel du 1 er cours… Spec dexigences (langue naturelle, notation logique) Spécification du comportement Spécification de limplantation (comportement utilisant des composantes données) Implantation Nous pouvons effectuer des V&V et du test entre tous les niveaux

6 INF6001 Chap 7 6 Types de Testing unit é int é gration syst è me performance robustesse comportem. fonctionnel bo î te blanchebo î te noire niveau de d é tail Accessibilit é Caract é ristiques utilisabilit é fiabilit é module securit é boîte grise passif actif Contrôlabilit é

7 INF6001 Chap 7 7 Terminologie: niveau de détail Unité, module: une unité ou un module est testé Intégration: linté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é

8 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 dimplantation Boîte noire: le testeur ne connaît pas la structure du code, mais seulement le comportement désiré Cest donc la spécification qui guide le procédé de test Normalement fait par un organisme extérieur à la boîte dimplantation Boîte grise: quelques informations de structure interne sont disponibles Dans ce cours, nous discuterons le test boîte noire

9 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é dun produit à une norme (un standard)

10 INF6001 Chap 7 10 Terminologie: test actif et passif Dans le test actif, le testeur interagit avec lentité 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 lentité 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 dobservations faites à un autre moment Dans ce cours, nous discuterons le test actif

11 INF6001 Chap 7 11 Implantation Spécification de limplantation Besoins Spécification du comportement Test du système Test dintegration Test de module Test dunité Le test dans le modèle de développement : Modèle V

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

13 INF6001 Chap 7 13 Tests de conformité en pratique Dans le cadre de la normalisation, nous avons besoin dun test objectif pour déterminer la correspondance dun produit à une norme P. ex. compagnie X produit une implémentation dun 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 dimplantation! Y devra donc envoyer des séquences de test à limplantation 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, limplantation de X obtiendra son timbre de conformité

14 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!

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

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 dune pièce de 25¢ 50 ¢? : entrée dune 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

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

18 INF6001 Chap 7 18 Tester avec modèle FSM Le FSM est la spécification La structure interne de limplantation nest pas connue Tester limplantation 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

19 INF6001 Chap 7 19 Tester tous les états Faire le tour des états, contrôler les sorties P.ex. 25¢? ; 25¢? ; café?

20 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é?

21 INF6001 Chap 7 21 Problèmes avec lapproche En général, le problème de construire un tour optimal dune 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 nest pas une garantie de bon fonctionnement! Donc au lieu dessayer toutes les transitions dans un tour, essayer une transition à la fois Quelle donne la sortie désirée et conduise à létat désiré

22 INF6001 Chap 7 22 Tester une transition à la fois Tester la transition: Aller à létat s x Exécuter lentrée a? Contrôler la sortie b! Contrôler que nous sommes à létat s y But du test: (test purpose) Vérifier que le système, quand il se trouve dans létat s x, répond à lentrée a? avec la sortie b! et exécute une transition à létat s y Comment faire tout ceci? sxsx sysy a? / b!

23 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 nimporte quel état Une telle séquence pourrait ne pas exister Mais dans plusieurs protocoles, nous avons des séquence de reset qui conduisent de nimporte 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 dun é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é

24 INF6001 Chap 7 24 Séquence de synch Séquence de synchronisation: 50¢? ; café? Contrôlez que cette séquence conduit de nimporte quel état à létat initial

25 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 ¢? /- Café ? /- 50¢ ? / 25¢! 25¢? /- 25¢? / 25¢!50¢? / 50¢! Café ? /- café? / café! 50¢ ? /-

26 INF6001 Chap 7 26 Séquences didentification détats Comment vérifier quune machine est dans un état spécifique? Un état pourrait être caractérisé par le fait que, étant donné une certaine séquence dentrée, il y aura une séquence de sorties différente par rapport à la séquence de sorties de nimporte quel autre état Ces séquences sont appelées UIO sequences Séquences dentrée/sortie uniques Elles pourraient ne pas exister!

27 INF6001 Chap 7 27 Méthode didentification détat 1 Séquences didentification détat UIO Pour état 0: 25¢?/ - ; café?/ - Pour état 25: 50¢?/25¢! Pour état 50:café?/café! Unique Input Output

28 INF6001 Chap 7 28 Méthode didentification détat 2 Distinguishing sequences (séquences de différenciation) Séquences dentrées qui donnent des sorties différentes pour chaque état Si japplique 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

29 INF6001 Chap 7 29 Méthode didentification 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 dexister pour toutes paires détats dans toute machine réduite, cad nayant pas détats redondants Je ne donnerai pas de détails

30 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) sxsx sysy a? / b!

31 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 ¢? /- café ? /- 50¢ ? / 25¢! 25¢? /- 25¢? / 25¢!50¢? / 50¢! café ? / - café? / café! 50¢ ? / ¢? /- - 50¢ ? / 25¢! 25¢? /- 25¢? / 25¢!50¢? / 50¢! café? / café! 50¢ ? /-

32 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 lordre des tests dans les suites P.ex. si létat de fin dun test est létat de début du prochain, il nest pas nécessaire dexécuter la séquence de synchronisation

33 INF6001 Chap 7 33 Organiser le tout en forme de tableau (exercice: remplir pour les 9 transitions) États initial et final PréambuleTransitionIdentif. état 0 -> 050¢ ; caféCafé? / -50¢! / -

34 INF6001 Chap 7 34 Pour trouver les préambules et les séquences didentification états Une méthode typique: au début nous pourrions être dans nimporte quel état, les transitions suivantes pourraient réduire lincertitude 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)

35 INF6001 Chap 7 35 Arbre de décision pour 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 didentification détats. Dans un cas plus complexe, il faudra probabl. essayer des séquences plus longues. Etc. (7 trans.) Etc.

36 INF6001 Chap 7 36 Résultat théorique Si nous faisons lhypothèse que Le nombre détats dans limplémentation nexcède pas le nombre détats dans la spécification Alors ce type de test est complet, cad si limplémentation passe le test, donc sa FSM est équivalente à celle de la spécification Malh. cette limitation fait que cette méthode nest pas vraiment boîte noire Pis, normalement le nombre détats dans limplémentation est beaucoup plus grand que le nombre détats dans la spéc!

37 INF6001 Chap 7 37 Exemple pratique dimpossibilité si lhypothèse est violée Spécification dexigence: Pour une entrée 1, doit sortir toujours 1 Besoin dun seul état pour cette machine Si limplantation 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 lexigence est toujours satisfaite Étant donné que le test est nécessairement un procédé fini, ce résultat montre limpossibilité théorique dun test à boîte noire de garantir le bon fonctionnement dun programme

38 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 lerreur dans limplémentation? Peut-elle être déterminée sur la base de la spécification seulement? ?1/!1

39 INF6001 Chap 7 39 Limitations importantes de cette théorie En plus de cette dernière limitation Dépend de lexistence 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

40 INF6001 Chap 7 40 Données Considérons une machine qui peut accepter un montant quelconque x Il faut avoir autant de transitions quil 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

41 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…

42 INF6001 Chap 7 42 Non-déterminisme Cette théorie de test présuppose aussi que lFSM et lentité testée soient déterministes Car sil y a non-déterminisme on peut ne pas savoir quel est létat qui résulte dune 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 quon teste des entités déterministe Qui peuvent être entièrement contrôlées par lenvironnement de test Ce qui rend cette théorie inutilisable pour le test dun système entier P.ex. dans le protocole du bit alterné, la perte des message ne peut pas être contrôlée par lenvironnement de test

43 INF6001 Chap 7 43 Utilisation pratique de cette méthode Pour les raisons mentionnées, cette méthode de test nest 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 ny a pas de formalisme largement accepté pour la spécification des exigences Il ny 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…

44 INF6001 Chap 7 44 Exemple de test dexigences 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

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

46 Conformance testing INF6001 Chap 7 46 Centre de test indépendant Cas de test Norme (standard) Implément ation par compagnie Client Certifie limplémentation ou signale des bogues Achète limplémentation seulement si elle a été certifiée par le centre de test

47 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

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

49 INF6001 Chap 7 49 Architecture de test conceptuelle Tester Larchitecture présupposée jusquà maintenant: Le testeur est directement connecté à lIUT et en contrôle le comportement Telle quelle décrite, seulement utilisable dans le cas où le test est fait localement par limplanteur: Capacité maximale de détection derreurs 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

50 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 Lupper tester est directement contrôlé par le testeur et son interface avec lIUT est un PCO Méthode distribuée Lupper tester est dans le système testé Il est directement contrôlé par le testeur et son interface avec lIUT est un PCO Méthode coordonnée Lupper tester est dans le système testé mais est implémenté par limplanteur du système testé Il est indirectement contrôlé par le testeur et son interface avec lIUT nest pas directement observable Méthode éloignée (remote) Pas de Upper Tester

51 INF6001 Chap 7 51 Méthode locale Upper Tester IUT ASPs PCO System Under Test (SUT) Test System (TS) Lower Tester ASPs PCO Lower level service provider Test Co-ordination Procedures (TCP) PDUs 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

52 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 lUpper Tester, communique directement avec lIUT Afin que cette méthode soit fidèle, la comm. entre lIUT et lUT 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 Cest à cause de ça quon 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

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

54 INF6001 Chap 7 54 Détails sur la méthode distribuée LUpper 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

55 INF6001 Chap 7 55 Exemple P. ex. supposons de tester un commutateur téléphonique Lupper tester pourrait simuler lusager (directement connecté) Le lower tester pourrait simuler le commutateur distant Peut donner des instructions à lupper tester, p.ex. décroche lappareil Et contrôler la bonne réponse sur le PCO auquel il est direct. connecté Upper Tester IUT ASPs PCO System Under Test (SUT)Test System (TS) Lower Tester ASPs PCO Lower level service provider Test Co-ordination Procedures (TCP) N-PDU décroche

56 INF6001 Chap 7 56 Méthode coordonnée La méthode distribuée a le désavantage que le site de lITU doit admettre lintrusion dans son système dun upper tester étranger qui est directement contrôlé par le testeur Dans la méthode coordonnée, lUpper Tester est directement connecté à lIUT et est normal. implanté par le fabricant de lIUT 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 System Under Test (SUT) Test System (TS) Lower Tester ASPs PCO Lower level service provider PDU TM-PDU Appropriée pour tester une couche intermédiaire

57 INF6001 Chap 7 57 Détails sur la méthode coordonnée Le Test Management Protocol doit être normalisé Car le testeur pourrait être nimporte 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

58 INF6001 Chap 7 58 Méthode éloignée (remote) Lupper tester nest 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 lIUT interprétera comme primitives à appliquer à son interface supérieure (ligne pointillée) Les possibilités de détection derreur sont limitées car il nest pas possible de contrôler ou observer directement linterface supérieure Cependant il sagit 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 linterface supérieure de lSUT est limité (p.ex. FTP, File Transfer Protocol) IUT System Under Test (SUT) Test System (TS) Lower Tester ASPs PCO Lower level service provider PDU Upper Tester ?

59 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é dune façon quelconque? Deux personnes qui communiquent par téléphone?

60 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 linterprétation de chaque méthode Chaque méthode a ses propres domaines dutilisation et ses propres capacités de détection derreurs Pour en savoir davantage:

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

62 INF6001 Chap 7 62 Les données de test pour les différentes architectures Les cas de test abstraits sont normalement indépendants de larchitecture Ils ont une nature globale Ils doivent être adaptés à larchitecture 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).

63 INF6001 Chap 7 63 Le processus de test de conformité System Under Test IUT System Under Test IUT Abstract test suite Executable test suite Tester Standard protocol specification test generation Protocol implementation Test selection and test implementation TTCN Test report

64 TTCN: TREE AND TABULAR COMBINED NOTATION Une notation pour spécifier les tests: INF6001 Chap 7 64

65 INF6001 Chap 7 65 Un test comme arbre dalternatives 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 lindentation = continuer la séquence Retourner à un niveau précédent = alternative

66 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

67 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 3 Line ! Digits Call Subscr2 4 Line ? CallTone 5 Line ? LineConnect ConnSubscr2 6 Line ! OnHookPass 7 Line ? BusyTone Busy B 8 Line ! DropHookInconclusive 9 Line ? NoToneFail LabelDynamic BehaviourConstraints refVerdict Comments Detailed Comments: This is a very simple case

68 INF6001 Chap 7 68 Test en MSC Test System: PhoneIUT: Phone Line OffHook DialTone Digits [CallSubscr] CallTone LineConnect [ConnSubscr] OnHook BusyTone OnHook NoTone alt PassInconc.Fail

69 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é quun appel téléphonique a été complété Fail: Le but du test na 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 na pas réussi Inconclusive: Le but du test na 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, lappel na pas pu être établi à cause du fait que lappelé était occupé

70 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 lexemple 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

71 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 dabstrait à 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

72 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 darbres 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

73 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

74 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

75 INF6001 Chap 7 75 Les méthodes de test dans le monde IP Malheureusement, il ny 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 quil 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é

76 Test dinteropérabilité Les tests dinteropérabilité évaluent linteropérabilité entre différentes implémentations Ils testent les capacités et le comportement dune 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

77 Une manière de voir les test dinterop INF6001 Chap 7 77 (thèse dAlexandra Desmoulins, 2007)

78 Architecture possible pour test dinterop INF6001 Chap 7 78 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 lIUT corresponde aussi à la norme. En pratique, il pourrait être difficile dimplémenter tout ceci

79 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 nimplémentent pas correctement la norme. Note: pourrait être redessinée dans la forme de larchitecture précédente, la différence essentielle est que nous navons pas de RI

80 Il y a beaucoup de recherche sur les tests dinteropérabilité mais une théorie ferme na 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 jai repris quelques figures et concepts Facilement répérable par recherche web INF6001 Chap 7 80


Télécharger ppt "Chap 7 1 Chapitre 8 Principes de test des protocoles w3.uqo.ca/luigi."

Présentations similaires


Annonces Google