UMR 5157 SAMOVAR

1
UMR 5157 SAMOVAR

• Equipe AVERSE

2
Test de systèmes de télécommunicationsProblématiq
ue et perspectives

• Ana Cavalli
• Institut National des Télécommunications
• 26 janvier 2004

3
Plan de la présentation

• Importance du test
• Les protocoles de communication
• Techniques de test
• Domaines dapplication
• Activités de recherche sur le test

4
Importance du test

• Le test, activité qui consiste à vérifier quun
  système possède les comportements et les
  propriétés attendus
• Contribue à réduire le risque derreur et à
  garantir la qualité des logiciels
• Elle est une partie intégrante de linnovation,
  de la production et de lopération des systèmes
• Cest une technique de validation très répandue
  dans le milieu industriel
• Elle est présente dans toutes les étapes du
  développement du logiciel

5
Différentes communautés

• Deux communautés
• test du logiciel
• test des systèmes de communication
• Utilisation de méthodes différentes
• nécessité dunifier les efforts de recherche pour
  définir un cadre commun

6
Les protocoles de communication
7
Les protocoles de communication

• Qu'est-ce qu'un protocole de communication?
• Un ensemble de règles régissant les communication
  entre les entités d'un système distribué
• Service fourni par le protocole
• Les contraintes de lenvironnement dans lequel le
  protocole sera exécuté (par ex. larchitecture)
• Vocabulaire des messages utilisés pour mettre en
  uvre le protocole
• Le codage des messages dans le vocabulaire
  (format)
• Règles de communication
• Le problème de la conception de protocoles
  efficaces et non ambigus est très ancien
  (Agamenon, Eschyle, 458 A.C.)
• transmission rapide de linformation sur de
  longues distances

8
Les protocoles de communication

• Protocoles basés sur le modèle de référence Open
  System Interconnexion (OSI)
• Pour linterconnexion de systèmes hétérogènes
• 7 couches
• Chaque couche définit un service précis et
  implante un protocole différent (normes ISO et
  ITU)
• Protocoles liés à lInternet (Internet Protocol
  Test Suite)
• Protocoles IEEE (réseaux locaux IEEE 802)
• Protocoles réseaux des télécommunications (ITU,
  ETSI)

9
Techniques de test
10
Test de conformité

• Il s'agit de tester les nouveaux produits afin de
  s'assurer qu ils ont les mêmes fonctionnalités
  que leur spécification. Cette procédure est
  appelée test de conformité.

Spécification dun protocole (norme)

• Constructeur B
• Conception
• Développement
• Test de fonctionnement
• test unitaire
• test d intégration

Test de Conformité
Produit A
Produit B
Test dinteropérabilité
11
Structure dun test

• Préambule Mettre limplantation sous test sur
  un état donné (en partant de létat initial)
• Corps du test Tester la transition concernée
  (appliquer l input, observer l output).
  Vérifier létat darrivée de limplantation
• Postambule Remettre limplantation dans un état
  stable (normalement létat initial)

12
Problèmes

• Définition dune méthode de génération de test
  efficace pour un protocole donné
• Test boîte noire tester le comportement externe
  visible à travers les points de contrôle et
  dobservation (PCOs)
• Problème du contrôle et de lobservabilité de
  limplantation à tester
• contrôle limité
• observabilité limitée
• Définition dune méthode d exécution des tests
  sur limplantation
• Architecture de test (environnement matériel et
  logiciel permettant la communication entre le
  système de test et l'implantation testée)

13
Architecture de test

• Interfaces accessibles de l'implantation sous
  test les points de contrôle et d'observation
  (PCO)
• Utilisation d'un système de test
• testeur supérieur,
• testeur inférieur
• coordinateur des séquences à envoyer par les
  testeurs

Testeur supérieur
Coordination des procédures de test (TCP)
(N)-ASPs
PCO
Implantation de protocole (N)
PCO
(N)-PDUs (N-1)-ASPs
Testeur inférieur
14
Test d'interopérabilité

• Test dinteropérabilité
• Linteropérabilité consiste à vérifier par le
  test que deux implantations qui sont conformes à
  la même norme peuvent coopérer
• Mêmes problèmes que pour le test de conformité
• Génération des tests
• Architecture de test
• Normes
• ISO 9646
• ISO / ITU FMCT

15
Méthodes formelles pour la génération de tests

• Objectifs
• Optimiser la production de tests en réduisant le
  temps et les coûts.
• Un ingénieur produit manuellement trois tests par
  jour
• Une suite de tests d'un protocole réel se compose
  en moyenne de 800 tests
• Améliorer la couverture des erreurs
• Produire des séquences de tests finies et
  garantissant une couverture complète de certains
  types d'erreurs (par exemple, des erreurs de
  transfert et de sortie)
• Automatiser la production de tests
• Développer des algorithmes pour la génération des
  tests

16
Etapes de la Génération des Tests

• 1. Obtenir une spécification formelle
• Éliminer les ambiguïtés
• Obtenir une interprétation commune du protocole
• Prendre en compte les données spécifiques au test
  (architecture, PCOs, POs, etc.).
• 2. Sélectionner les tests pertinents
• Il s'agit de sélectionner les tests, en se
  basant sur divers critères objectifs de test,
  couverture, types derreurs, coût acceptable du
  test, etc.
• 3. Générer la séquence de test
• Il s'agit de générer la séquence d'interactions
  qui, appliquée à l'implantation sous test, va
  vérifier un objectif de test.
• 4. Mettre en forme le test final
• Produire les suites de tests exploitables dans
  un formalisme reconnu et adapté à cela. Dans le
  domaine des protocoles ou systèmes de
  communications, TTCN s'impose.

17
Autres techniques

• Méthodes de test classiques fortement liées à la
  contrôlabilité de lIUT
• Elles sont basées sur lhabilité dun testeur que
  stimule limplantation sous test et évalue la
  correction des réponses produites par
  limplantation
• Parfois, une activité difficile
• le testeur na pas une interface directe avec
  limplantation
• limplantation est construite à partir de
  composants qui doivent être exécutés dans son
  environnement et ne peuvent pas être arrêtés ou
  interrompus (pour long temps) afin de les tester

18
Test Passif (Monitoring basé sur des méthodes
formelles)

• Pourquoi utiliser le test passif ?
• Dans le test passif, il nest pas nécessaire que
  limplantation sous test interagisse avec le
  testeur
• Les traces dexécution sont observées sans
  interférences sur lexécution du protocole
• Le test passif a des applications multiples
• Il peut être utilisé comme une technique de
  monitoring pour la détection et le report des
  erreurs
• Aussi, pour le management des réseaux afin de
  détecter des problèmes de configuration,
  identification des erreurs ou disponibilité des
  ressources

19
Test Passif (Monitoring basé sur des méthodes
formelles)

• Les techniques de test passif ne sont pas
  nouvelles
• Activité de recherche très active ces dernières
  années
• Dhabitude, les traces dexécution de
  limplantation sont comparées avec la
  spécification pour détecter des erreurs dans
  limplantation
• La spécification a la forme dune machine détats
  finis (FSM) et le test passif consiste à vérifier
  que la trace exécutée est acceptée par la
  spécification
• Architecture basée sur les POs

20
Test Passif (Monitoring basé sur des méthodes
formelles)

• Nous proposons une approche plus active
• Nous partons dun ensemble dinvariantes qui
  représentent les propriétés les plus relevantes
  de limplantation sous test
• De manière informelle, une invariante exprime le
  fait que chaque fois que limplantation sous test
  réalise une séquence dentrées/sorties elle doit
  exhiber un comportement exprimé par linvariante

21
Test Passif (Monitoring basé sur des méthodes
formelles)

• Les invariantes doivent être fournies par
  lexpert connaissant le protocole à tester
• Première étape vérifier que linvariante est
  correcte par rapport à la spécification
• Deuxième étape vérifier que les traces produites
  par limplantation sous test respectent les
  invariantes

22
Exemples dinvariante

•  Chaque fois quun utilisateur demande une
  connexion et que la connexion est assurée, si
  après avoir réalisé quelques opérations,
  lutilisateur demande à être déconnecté, alors il
  est déconnecté. 
•  Chaque fois quun utilisateur demande une
  ressource (par exemple une page web) alors la
  ressource est obtenue ou on a un message
  derreur. 

23
Domaines dapplication
24
Application au protocole Wireless Application
Protocol (WAP)

• Mise en place d une pile protocolaire WAP Kannel
• Nous avons trouvé quil était possible de mettre
  des POs dans la pile WAP Kannel
• Permet plus dobservabilité et une meilleure
  analyse du résultat du test
• Nous avons aussi des PCOs dans la pile, qui
  permettent un contrôle complet de la passerelle
  WAP et permettent quelle puisse devenir un
  testeur inférieur dans une architecture de test à
  distance.

25
Architecture de test

• Test de couches WAP

WAE
Apps on Other Servers
WAE
WSP
HTTP
WSP
Points dobservation (PO)
WTP
UDP
WTP/T
TCP
WDP
UDP
Bearer
IP
IP
Sub-network
Sub- network
PPP
PSTN Circuit
CSD- RF
PSTN Circuit
Kannel WAP Gateway
IWF
Mobile Phone
RAS
(Remote Access Server)
26
Loutil TESTInv

• Réalisation dun outil logiciel
• Récupération et filtre des traces dexécution des
  couches protocolaires (information obtenue à
  travers les POs)
• Vérification que les invariantes sont correctes
  par rapport à la spécification du protocole de la
  couche WAP
• Vérification que les traces produites par
  limplantation de la pile protocolaire respectent
  les invariantes de chaque couche.

27
Test Architectures (suite)

• Un PCO et un PO (dans
• WAP)
• Objectifs
• - améliorer lobservabilité
• - améliorer lanalyse des résultats du test
• - test dintéroperabilité
• Contrôle limité

Terminal
HTTP
WAP
Simulator
Server
Gateway
/Terminal
PCO
PO
Tester

• Deux PCOs la passerelle WAP devient un testeur
  actif Objectifs
• - Test de conformité
• - Test dinteropérabilité
• Contrôle total

Terminal
HTTP
WAP
Simulator
Server
Gateway
/Terminal
PCO
Tester
PCO

• Un PCO et un PO(coté serveur par analyse des
  fichiers log)
• Objectifs
• - test de services WAP, test dinteroperabilité
  end-to-
• end entre client et serveur
• Contrôle limité

Terminal
HTTP
WAP
Simulator
Server
Gateway
/Terminal
PCO
PO
Tester
28
Activité de recherche sur le test des systèmes
de communication
29
Equipes travaillant sur le test

• France (INT, IRISA, LSR, LAAS, LABRI, LAMI, LRI,
  FT RD, CEA)
• Angleterre(NPL, Stirling, Cambridge, Oxford)
• USA (Bell Labs, Univ.Maryland, Univ.New York,
  Univ. Columbia)
• Canada (Montréal, Ottawa,British Columbia)
• Allemagne (Univ. Humboldt, GMD Berlin, Univ.
  Gottinguen)
• Pays Bas (Twente Univ.)
• Japon (Osaka Univ., Tokyo Univ.)
• Corée (ICU-Taejon, ETRI-Taejon, Pusan Univ.,
  Univ. de Séoul)
• Russia

30
Industriels

• ATT, Alcatel, Bouygues, Cegetel, Ericsson,
  France Télécom, IBM, Motorola, Nortel, Cisco,
  Siemens, Lucent, Microsoft, Docomo-Japon,
  NTT-Japon, Korea Telecom
• PME Telelogic, Esterel Technologies, I-Logix

31
Notre activité CNRS

• Participation au RTP Réseaux de Communication
  (CP) et au RTP Sûreté de Fonctionnement
• AS Specs et Test (leader GET/INT)
• Laboratoires de recherche
• SAMOVAR (leader), LABRI, LAMI, ENSICA, LSR-IMAG ,
  LAAS, LRI
• Industriels
• FT RD, CEA

32
Activité européenne

• Réseau TAROT-Training and Research on Testing
  (Programme Marie Curie)
• GET/INT leader
• 11 partenaires
• Durée 4 ans
• 1.500.000 euros