Autres approches

Quelques prospectives concernant le test de robustesse ont été enregistrées dans le cadre de l’action scientifique n˚23 du CNRS, notons brièvement :

La prospective IRISA [33], fondée sur la disponibilité d’une spécification du système à tester et de ses propriétés de robustesse. Les auteurs emploient les techniques de synthèse de contrôleur pour empêcher la spécification d’atteindre des comportement non robustes. Ensuite, ils proposent d’exploiter des techniques déjà développées pour le test de conformité (par exemple TGV) pour générer les cas de test de robustesse.

Par ailleurs, la prospective proposée par le LaBRI [33] est fondée sur l’extension du test de conformité, plus précisément, un testeur de robustesse permet de vérifier que l’IUT d’une part a un comportement correct en accord avec la spécification et d’autre part il détecte des événements corrompus ou inconnus (provenant de l’environnement externe). A partir de ce testeur, il est possible de dériver des tests abstraits. Plusieurs étapes sont considérées pour la construction du testeur de robustesse : construction du graphe de refus de la spécification pour avoir l’ensemble des refus associés à chaque état (déterminisation des situations de blocages), complétion du graphe de refus avec des traces de fautes sur

chaque état et ajout d’un événement générique θ représentant les événements inconnus ou corrompus (le testeur passe dans un état de refus qui représente une situation dégradée et revient soit dans l’état de départ avec une transition non observable, soit dans un état de reprise identifié) et enfin prise en compte des actions du graphe de refus étendu afin de générer les tests abstraits.

4.3 Conclusion

Dans ce chapitre nous avons exposé quelques méthodes et outils développés pour trai-ter certains aspects du test de robustesse des systèmes. Toutefois, l’utilisation du trai-terme "robustesse" est souvent confondue avec les notions de conformité, de sécurité ou de sûreté de fonctionnement.

Les méthodes formelles, fondées sur un modèle de comportement, issues de l’AS23 ont défini les ingrédients de base pour formaliser le test de robustesse tels que la distinction entre "le comportement acceptable" et "le comportement correct", la classification des aléas vis-à-vis des frontières du systèmes et les notions "mode dégradé" et "mode nominal ". En revanche, la représentation formelle d’aléas et la méthodologie de construction d’un modèle de référence pour le test de robustesse (spécification dégradée ou augmentée) ne sont pas assez étudiées.

Nous pensons que le test de robustesse devrait s’appuyer sur un modèle de référence décrivant le comportement d’un système en présence d’aléas. En conséquence, les méthodes de génération des tests de robustesse doivent utiliser des critères de sélection visant à dériver uniquement des traces d’exécution produites par les aléas. Enfin, nous signalons l’absence d’une véritable étude de cas permettant de positionner proprement le test de robustesse par rapport aux autres types de test.

Un cadre formel pour le test de

robustesse

L’automatisation du test de robustesse impose la formalisation mathématique de cer-tains aspects du test. Tout d’abord, la spécification doit être formelle, afin que les compor-tements qu’elle décrit soient suffisamment précis et non ambigus. D’autres aspects doivent aussi être formalisés : les aléas, les comportements en présence d’aléas, la relation de robus-tesse entre l’IUT et sa spécification ainsi que les modèles de fautes issus de cette relation et, les interactions entre le testeur et l’IUT. Dans ce chapitre, nous proposons un cadre formel pour automatiser le test de robustesse appliqué aux protocoles de communication. Les résultats de ce chapitre sont publiés dans [166, 163, 167].

Le chapitre est organisé comme suit : La section 5.1 met l’accent sur la notion de robustesse. La section 5.2 expose les points de différence ainsi que les nouveaux enjeux comparés au test de conformité. La section 5.3 propose une définition, une classification et une représentation des aléas relative au domaine des protocoles. La section 5.4 donne le plan général de l’approche proposée, ainsi que les concepts formels utilisés par la suite. Les sections 5.5 et 5.6 détaillent les deux méthodes proposées. La section 5.7 propose une relation pour tester la robustesse d’une implémentation, ainsi que les modèles de fautes visés par cette relation. Enfin, la section 5.8 conclut le chapitre.

5.1 Notion de robustesse

Le test de robustesse constitue un domaine d’étude relativement récent aussi sa défini-tion est-elle encore imprécise et sujette à interprétadéfini-tion. Dans la littérature, la nodéfini-tion de robustesse est quelquefois confondue avec celle de sûreté de fonctionnement ou avec celle de conformité. En particulier, si on considère que le test de robustesse ne peut s’appliquer qu’à un système qui fonctionne correctement, dans les conditions nominales, il est alors un sur-ensemble du test de conformité. En revanche, si on considère que la robustesse est

définie par rapport à la réalisation d’une propriété, il peut être nécessaire de modifier la spécification afin d’assurer cette propriété, par exemple en ajoutant des comportements dégradés, ce qui peut être orthogonal à la conformité. Dans ce dernier cas, le test de ro-bustesse et le test de conformité sont deux domaines bien distincts. Ces constatations ont conduit à deux principales définitions de la robustesse ; elles sont rappelées ci-dessous. Définition 12 (La robustesse selon l’IEEE) est le degré selon lequel un système, ou

un composant, peut fonctionner correctement en présence d’entrées invalides ou de condi-tions environnementales stressantes [88].

Cette définition est très vague parce que, dans la plupart des cas, le comportement du système en présence de fautes ou de conditions de stress n’est pas assez spécifié ou en-tièrement omis de la spécification. Ceci est justifié par l’impossibilité de prévoir toutes les fautes et les conditions de stress provenant d’un environnement préalablement inconnu. Par conséquent, si le système montre un comportement différent du comportement attendu alors ceci pose un problème pour l’acceptation ou le refus de ce comportement (absence de référence). Un exemple illustratif de cette ambiguïté est un distributeur d’argent implanté à partir de la spécification suivante : "un utilisateur identifié retire l’argent après avoir

saisi son code secret et choisi un montant autorisé". Si le distributeur rejette la carte

ban-caire après l’épuisement de l’argent, ce comportement est alors orthogonal avec celui de la spécification nominale. Naturellement, ce comportement est peut être acceptable même s’il est orthogonal avec la spécification.

Dans la définition précédente, la spécification incomplète pose un véritable problème pour l’évaluation du comportement correct du système dans les situations imprévues. Par-tant de cette problématique, les auteurs de l’action scientifique N˚23 du CNRS [33] ont proposé la définition suivante :

Définition 13 (La robustesse selon l’AS 23) Le test de robustesse vise à vérifier la

capacité d’un système, ou d’un composant, à fonctionner de façon acceptable, en dépit d’aléas.

Dans cette définition, l’utilisation du terme générique "aléa" désigne à la fois les entrées invalides et les conditions environnementales stressantes. L’expression "fonctionner de

fa-çon acceptable" indique que les comportements attendus par le test de robustesse peuvent

être incorrects, c’est à dire non conformes à ceux qui sont attendus dans la spécification nominale. En conséquence de cette contradiction, nous avons décidé de définir la robustesse de la manière suivante :

Définition 14 Un système est considéré comme robuste s’il est d’abord conforme à sa

spé-cification nominale et, qui prouve un comportement acceptable en dehors de ses conditions nominales (en présence d’aléas).

Nous pensons d’abord que le test de robustesse devrait s’appliquer à des systèmes conformes à leur spécification nominale, c’est à dire la description du service attendu du

système dans les conditions normales. Le comportement acceptable désigne tout compor-tement qui peut être toléré par les concepteurs et les utilisateurs du système. Pour éviter toutes sortes d’ambiguïté, ce comportement devrait être spécifié ou défini par les concep-teurs du système. Nous proposons par la suite un formalisme permettant de faciliter cette tâche.