Nous rappelons que le test consiste à exécuter le système à tester, celui-ci prenant un ensemble d’entrées et fournissant un ensemble de sorties comme résultats. La justesse du système est alors déterminée en comparant les résultats obtenus aux résultats décrits dans la spécification (cahier de charge, standard du protocole, etc). Deux approches sont envisageables pour la construction des tests : l’approche "boîte noire" ou l’approche "boîte
blanche". Dans l’approche boîte noire, la spécification joue un rôle central pour la sélection
des entrées du test et aussi pour l’évaluation des résultats obtenus.
La spécification du système décrit habituellement la fonction ou le service attendu du système dans les conditions normales (règles de communication, format de messages, etc). Lorsque l’on considère des systèmes critiques ou de sécurité, la spécification est généralement complétée par l’énoncé de ce qui ne devrait pas arriver (par exemple, les états dangereux pouvant mener à une catastrophe, ou à la divulgation d’informations sensibles). Cette spécification conduit à définir un ensemble de fonctions additionnelles pour éviter les défaillances (par exemple identification d’un utilisateur et vérification de ses droits). Par ailleurs, la spécification peut être exprimée selon divers points de vue ou degrés de détail. Elle peut être aussi décomposée selon la présence ou l’absence de défaillance (mode dégradé, mode nominal). Ces constatations peuvent conduire à distinguer plusieurs types de test dependant du degré de détail dans la spécification et de contraintes environnementales d’exécution.
Dans le domaine des protocoles de communication, la spécification est en général une description rédigée en langue naturelle (spécification CCITT par exemple) ou en langage spécialisé (SDL, Lotos, etc). Elle décrit souvent les règles de communications distantes dans les conditions normales. En d’autres termes, elle définit un certain nombre de messages permettant au système de dialoguer avec son environnement. Ces messages sont souvent présentés sous une forme structurée, regroupant des champs, eux-mêmes subdivisés en d’autres champs et ainsi de suite, de longueurs fixes ou variables, obligatoires ou optionnels. Dans certains cas, la spécification décrit aussi quelques règles additionnelles pour éviter certaines défaillances (par exemple, messages d’erreur).
A partir de cette spécification, le testeur peut se concentrer uniquement sur les fonctions
de base (les fonctions attendues sans aucune considération de fautes). Dans ce cas, le testeur
Éxigences de robustesse Aléas Spécification de base + mecanismes de sureté de fonctionnement
TEST DE CONFORMITÉ TEST DE SURETÉ DE FONCTIONNEMENT TEST DE ROBUSTESSE
Spécification du test de robustesse augmentée Spécification Spécification du test de sureté de fonctionnement de sureté de Spécification Spécification de base seulement fonctionnement conformité du test de Spécification tester ce qu’on veutQu’est
tester ce qu’on veutQu’est Standard du
protocole
Spécification nominale
Fig. 22: Le degré de détail dans la spécification permet de distinguer plusieurs types de test
Parallèlement, la considération des fautes spécifiées conduit à dériver une spécification de base enrichie par les fonctions décrivant les mécanismes de sûreté de fonctionnement (voir Fig.22). Le test basé sur cette dernière spécification est appelé test de sûreté de
fonctionnement. Ce terme est peu utilisé dans le domaine du test de protocoles et, on parle
souvent du test de conformité pour décrire l’ensemble des tests qui peuvent être dégagés directement à partir de la spécification du protocole.
Par la suite, nous appellerons une "spécification nominale" la description de tout ce qui est spécifié préalablement par les concepteurs du système. Notons aussi que la spécification parfaite ou exhaustive est impossible. Naturellement, la spécification est initialisée dès les premières phases du cycle de vie d’un système et elle se poursuit généralement tout au long de la vie du système, en raison de la difficulté à identifier ce qui est attendu d’un système et notamment dans un environnement inconnu.
Pour ce qui concerne le test de robustesse, nous avons choisi de le considérer comme une extension (sur-ensemble) du test de conformité. Ce type de test vise à vérifier la capacité d’un système à fonctionner de façon acceptable en présence d’aléas. La spécification utilisée comme une référence pour ce test est appelée "la spécification augmentée". Elle est obtenue par l’intégration d’aléas représentables (les entrées et les sorties qui exhibent les aléas) dans la spécification nominale. Toutefois, si on considère les aléas non représentables (voir la section 5.3), la spécification nominale peut être utilisée, dans certains cas, comme une référence pour le test de robustesse (si on cherche à vérifier l’exécution de quelques fonctions nominales en présence d’aléas), la seule différence dans ce cas se trouve au niveau de
l’exécution de l’implémentation sous test. Plus précisément, dans le test de conformité, l’environnement est supposé normal et sûr ; par opposition, dans le test de robustesse on vise à soumettre le système à des situations critiques ou inattendues, et à vérifier s’il est capable de réaliser les fonctions qu’on attend de lui.
Dans la littérature, on peut trouver d’autres classifications de la "robustesse" et du "test de robustesse". Nous rappelons particulièrement certains travaux menés au LAAS définissent la robustesse comme un attribut secondaire de sûreté de fonctionnement : "la
robustesse est un exemple d’un attribut secondaire spécialisé de la sûreté de fonctionnement, c’est à dire la sûreté de fonctionnement en présence de fautes externes caractérisant les réactions du système face à certaines classes spécifiques des fautes" [10]. Par ailleurs, les
auteurs de [123] proposent un modèle globale des principales activités nécessaires pour le développement d’un système sûr de fonctionnement. Trois processus ont été proposés : processus de création, processus d’élimination de fautes et processus de prévision de fautes. Dans ce modèle, le test de robustesse est considéré comme un moyen réalisation durant le processus d’élimination de fautes.
5.2.1 Les nouveaux enjeux comparés au test de conformité
Pour mieux comprendre les spécificités du test de robustesse, nous fondons sa définition par rapport à celle du test de conformité utilisant un modèle ne prenant pas en compte les aléas (voir Fig.23), et nous analysons les écarts induits par la considération de ces derniers. En conséquence, les aléas et la définition du comportement acceptable font deux points de différenciation possibles : 1) le domaine d’entrées n’est pas nécessairement le même et, 2) le comportement de l’implémentation sous test peut être observé et évalué selon un point de vue différent.
Ensemble fini de tests
Entrées
du test Implémentation sous test Sortiesdu test Oracle Verdict ou objectifs de test
ou hypothèses de sélection Critères de sélection Spécification du comportement Relation de conformité
Fig. 23: Architecture du test de conformité
En conclusion de cette comparaison, une série de questions nécessite des réponses claires afin de définir proprement le test de robustesse :
– Comment spécifier le comportement du système en présence d’aléas ? – Comment élargir le domaine d’entrées ?
– Comment modifier le domaine de sorties ? – Comment définir la relation de robustesse ?
– Comment définir les critères de sélection, les hypothèses de sélection ou les objectifs de test de robustesse ?
– Comment évaluer les résultats du tests (les verdicts) ?
Dans ce document, nous proposons des réponses à toutes ces questions. Nos réponses sont fondées sur notre définition de la robustesse.