Chapitre 2

Test d’interopérabilité de protocoles

Dans le domaine des réseaux des télécommunications, des normes sont définies,
décrivant les services devant être assurés par les protocoles formellement implémentés. Ces
implémentations doivent être testées de façon à vérifier leur capacité à s’interfonctionner avec
d’autres implémentations dans un contexte opérationnel. C’est pourquoi le test des
implémentations de protocoles est une étape importante de leur développement.
Il existe plusieurs méthodes de test pour vérifier qu’une implémentation sera capable
de fonctionner "convenablement". Parmi elles, on peut distinguer le test d’interopérabilité
dont le principe consiste à vérifier que plusieurs systèmes sont capables de communiquer tout
en fournissant les services décrits dans leur spécification.

2. 1. Éléments de base

L’activité de test d’interopérabilité fait intervenir un système sous test SUT (System
Under Test), un système de test TS (Test System) et l’environnement via lequel le SUT et le
TS communiquent. Selon le contexte de test, le SUT est composé de une ou plusieurs
implémentations à tester IUT (Implementation Under Test). L’objectif de l’activité de test est
alors de générer à partir des spécifications des systèmes testés les cas de test TC (Test Case)
exécutables sur le SUT. Généralement, cette génération de test est basée sur un objectif de test
TP (Test Purpose). Un objectif de test décrit une propriété à vérifier lors des tests. Un cas de
test est un test élémentaire destiné à tester cet objectif de test. Un ensemble de cas de test
compose une suite de test.

Le test d’interopérabilité met en relation plusieurs implémentations. La figure ci-

dessus décrit le contexte de test d’interopérabilité comportant deux implémentations appelé
one-to-one. Chacune de ces implémentations est une boîte noire. L’objectif de ce test est de
s’assurer à la fois que les implémentations interagissent correctement et qu’elles rendent les
services prévus dans leur spécification pendant leur interaction.

2. 2. Activité de test :

Dans cette partie, nous nous intéressons à l’activité de test. La spécification du

système (une ou plusieurs implémentations) et la description des objectifs de test sur le
système. Cette étape comprend la description des objets en présence avant l’activation de test,
c’est à-dire la spécification du ou des systèmes à tester, la configuration dans laquelle le ou les
systèmes seront testés, la description du ou des objectifs de la suite de tests, etc.

Objectif de test : Un objectif de test TP (Test Purpose) décrit de manière informelle quelle
est la propriété particulière ou le comportement spécifique à tester. Il sert à sélectionner un
cas de test afin de tester un aspect particulier du système sous test. Il décrit généralement un
enchaînement d’actions (non nécessairement consécutives) à observer durant l’exécution des
tests.

Cas de test : C’est un test facile destiné à tester une fonctionnalité particulière (l’objectif de
test). Il englobe généralement un préambule, un corps de test et un postambule. Le corps de
test correspond à l’ensemble des évènements utilisés pour atteindre l’objectif de test. Le
préambule est la séquence des évènements de test nécessaires pour atteindre l’état stable. Le
postambule est la séquence des évènements correspondant à la fin du cas de test élémentaire.

Verdicts : C’est le résultat de l’exécution d’un test sur le SUT (système à tester). Le verdict
peut prendre les valeurs "succès" (PASS), "échec" (FAIL) ou "non concluant" (INC ou
INCONCLUSIVE).

2. 3. Problématique du test d’interopérabilité :

Le test d’interopérabilité consiste à s’assurer que plusieurs implémentations

différentes interagissent correctement tout en rendant le service assuré. La plupart des cas de
test d’interopérabilité sont décrits à travers la définition des propriétés que les tests doivent
permettre de vérifier. Puis, grâce aux spécifications des protocoles à tester, les testeurs
décrivent les chemins possibles correspondant aux objectifs de test. Par exemple, lors de
sessions d’interopérabilité appelées Plugtests ou Interoperability Events, des constructeurs
font valider l’interopérabilité de leurs produits avec les autres produits du marché. Les
laboratoires de test participent à ces sessions d’interopérabilité en proposant les suites de test
permettant de valider les produits testés. Les Plugtests organisés par l’ETSI (European
Telecommunications Standards Institute) pour le test de différents protocoles comme l’IPv6,
le WiMAX et les applications mobiles sont des exemples de ces sessions d’interopérabilité.

2. 4. Architectures de test d’interopérabilité one-to-one :

Ces architectures de test d’interopérabilité sont définies dans le cadre de l’interaction

de deux implémentations appelée contexte one-to-one (Fig 2. 2).
 Le système sous test SUT (System Under Test) englobe deux implémentations sous
test IUT (Implementation Under Test) IUT1 et IUT2. Dans cette architecture, deux types
d’interfaces peuvent être citées :

- les interfaces inférieures LIi (Lower Interfaces) d’une implémentation sont les
interfaces utilisées pour l’interaction avec l’autre implémentation
- les interfaces supérieures UIi (Upper Interfaces) sont utilisées pour la communication
avec l’environnement ou les couches supérieures, c’est-à-dire pour fournir les services
prévus

Le système de test TS (Test System) est l’élément chargé d’observer et/ou de contrôler
le SUT. Il peut être composé de tout ou partie des éléments suivants :

- le testeur supérieur UTi (Upper Tester) est chargé du contrôle et de l’observation des
évènements sur l’interface UIi, via le PCO (Point of Control and Observation)
supérieur UPi.
- le testeur inférieur LTi (Lower Tester) est chargé de l’observation des évènements sur
l’interface LIi, via le PO (Point of Observation) inférieur LPi.
- le testeur Ti est la partie de TS chargée du contrôle et/ou de l’observation de
l’implémentation IUTi. Ce testeur est donc composé des testeurs UTi et/ou LTi.

Remarques :

Les interfaces inférieures ne sont pas contrôlables (un testeur est dans l’incapacité
d’envoyer de stimuli vers ces interfaces) mais seulement observables lors du test
d’interopérabilité. L’envoi de stimuli vers ces interfaces dévierait le test d’interopérabilité, de
tels messages n’étant pas des messages de l’interaction.
Le testeur LTi est ainsi chargé de l’observation des évènements sur les interfaces LIi.
Par contre, comme les interfaces supérieures ne sont pas utilisées pour l’interaction, le testeur
UTi peut à la fois observer et contrôler les évènements exécutés sur l’interface à laquelle il est
connecté.
 En fonction du type d’interfaces auxquelles les testeurs ont accès, on peut distinguer
les architectures suivantes.

1. Architecture de test inférieure :

L’architecture de test est dite inférieure si les testeurs ont accès uniquement aux
interfaces inférieures.
Cette situation est possible dans le cas où les interfaces supérieures sont encapsulées
dans le protocole de couche supérieure. Par exemple, dans le cas du test du protocole IP dans
une pile protocolaire TCP/IP opérationnelle, les testeurs n’ont pas accès aux interfaces
supérieures du protocole. Ces interfaces sont en effet encapsulées dans le protocole TCP
implémenté au-dessus d’IP (Fig 2. 3 (c)).

2. Architecture de test supérieure :

L’architecture de test est dite supérieure si les testeurs ont accès uniquement aux
interfaces supérieures (Fig 2. 3 (b)).
Cette situation est généralement rencontrée lorsque le protocole de couche inférieure
empêche la visualisation des messages qui lui sont transmis. Cette situation peut être
rencontrée lors du test de protocoles applicatifs au niveau service, par exemple, dans le cas du
test du protocole http auquel l’accès se fait via les primitives d’accès au service.

3. Architecture de test totale :

L’architecture de test est dite totale dans le cas où les testeurs peuvent observer et/ou
contrôler les deux types d’interfaces (Fig 2. 3 (a)).
Par rapport aux architectures de test supérieures et inférieures qui correspondent à des
cas particuliers où les testeurs n’ont pas accès à toutes les interfaces, l’architecture de test
totale correspond au cas général, à la situation la plus généralement rencontrée en pratique.

4. Architecture de test unilatérale :

L’architecture de test d’interopérabilité est dite unilatérale si les testeurs n’ont accès
qu’à une seule implémentation durant son interaction avec la deuxième implémentation .

Cette situation est possible par exemple dans des cas où l’une des deux
implémentations est encapsulée dans un autre système : les testeurs n’ont alors pas accès aux
interfaces de cette implémentation bien qu’elle interagisse avec l’autre implémentation (Fig 2.
4 (c)).

5. Architecture de test bilatérale :

L’architecture de test est dite bilatérale si les testeurs ont accès aux deux
implémentations, mais séparément (Fig 2. 4 (c)).

Dans cette architecture, il n’y a pas de connexion entre les testeurs T1 et T2, donc pas
de synchronisation entre ces testeurs.

6. Architecture de test globale :

L’architecture de test est dite globale si les testeurs ont accès aux deux
implémentations avec une vue globale lors des tests (Fig 2. 4 (a)).

Cette architecture est actuellement la plus utilisée en pratique. Ces deux dernières
architectures (globale et bilatérale) correspondent à une même observabilité des interfaces des
implémentations : la différence se situe au niveau des testeurs qui peuvent avoir soit une vue
globale du SUT (architecture globale) qui impose une synchronisation entre les testeurs, soit
une vue séparée de chacune des IUTs (architecture bilatérale) ce qui évite une synchronisation
entre testeurs souvent complexe.

Remarque:

Les architectures de test unilatérale, bilatérale et globale peuvent être combinées avec
les architectures de test totale, inférieure et supérieure. On obtient ainsi neuf architectures de
test d’interopérabilité : globale totale, unilatérale totale, bilatérale totale, globale supérieure,
unilatérale supérieure, bilatérale supérieure, globale inférieure, unilatérale inférieure,
bilatérale inférieure.