Action Spécifique no. 23 Techniques avancées de tests des systèmes complexes

Test de robustesse : position du problème

La problématique du test de robustesse dépend du système considéré, de son architecture et de l'objectif qui sous-tend le test.

Tout système applicatif utilise les services d'un système opératoire, qu'il partage éventuellement avec d'autres systèmes applicatifs. Cet environnement opératoire est susceptible d'être source de défaillances qu'il faut prendre en compte.
De nombreux systèmes critiques intègrent des mécanismes et des architectures de tolérance aux fautes. La validation de ces mécanismes, avec leur observabilité et leur commandabilité dans une architecture donnée, est nécessaire.
Le troisième aspect concerne la conception et l'implantation du système applicatif à tester. La robustesse de ce système, et notamment son aptitude à satisfaire certaines propriétés critiques dans un environnement incertain, doit être testée en considérant des entrées erronées aussi bien dans la partie "données" que dans la partie "contrôle".
Le dernier aspect concerne le test d'un système selon ses profils d'utilisation et les services qu'il délivre. Les séquencements, les contraintes temporelles, le nombre et la fréquence des sollicitations (test de charge) sont dans ce cas à prendre en compte.
La figure suivante présente graphiquement l'ensemble de ces types de tests.

Les enjeux associés peuvent être détaillés comme suit :

• Caractérisation des modes de défaillance de systèmes opératoires. Il s'agit d'analyser finement le comportement d'un système opératoire (middleware, système d'exploitation, réseau...) en présence de fautes. Cette analyse fait appel à des méthodes expérimentales basées sur le test et l'injection de fautes, et peut permettre la conception de parades architecturales aux défaillances identifiées.
  
  
• Test de mécanismes de tolérance aux fautes. La capacité d'un système à traiter les fautes et les erreurs est assurée par la mise en úuvre de mécanismes de tolérance aux fautes. La vérification expérimentale de tels mécanismes procède par injection de fautes : dans ce cas, l'injection de fautes peut être vue comme une méthode de test, le domaine d'entrée relatif à l'activité fonctionnelle du système étant élargi pour prendre en compte l'occurrence de fautes. Un axe de recherche actuel concerne donc la définition de méthodes de sélection d'entrées de test (= entrées fonctionnelles et fautes) inspirées de méthodes existant dans le cadre du test du logiciel et du test de systèmes réactifs ou embarqués (par exemple les protocoles de communication et les systèmes complexes industriels).
  
  
• Test ciblant la vérification de propriétés de sûreté. Il s'agit de proposer des méthodes de sélection de scénarios de test susceptibles de mettre en défaut des propriétés de sûreté d'un système critique. Ces scénarios doivent considérer des entrées (données ou séquences d'événements) invalides, c'est-à-dire des entrées syntaxiquement ou sémantiquement incorrectes, conséquences de fautes survenant dans l'environnement du système. On s'intéressera plus particulièrement à la recherche de scénarios "stressants" vis à vis d'une propriété cible.
  
  
• Test selon différents profils d'utilisation. Pour vérifier le comportement d'un système interagissant avec un environnement non contraint, une solution possible est la définition de plusieurs profils d'utilisation, faisant varier la probabilité des types de sollicitations, leur séquencement, ou encore le délai entre deux sollicitations (profil de charge ou contraint temporellement). Tout système fournit des services. Il semble intéressant de vérifier dans quel cas un service ne peut être rendu et avec quelles données d'entrée. La même question se pose au niveau des composants du système, notamment dans le cas de composants réutilisables issus d'une conception orientée-objet, pour lesquels des modèles d'interface doivent être définis.

Par delà la diversité des types de test mentionnés, des problèmes communs peuvent être identifiés :

• L'élargissement du domaine d'entrée de test (aussi bien pour les données que pour les événements), pour prendre en compte non seulement les aspects fonctionnels des interactions avec l'environnement, mais encore les aspects temporels de ces interactions, ainsi que la possible occurrence de fautes(*). Une conséquence de cet élargissement est la difficulté de modéliser le domaine d'entrée ainsi obtenu.
  
  
• La détermination de trajectoires pertinentes dans ce domaine d'entrée, qui devient un problème d'autant plus complexe que la taille du domaine a été élargie. Le comportement testé peut dépendre de combinaisons subtiles de l'état interne du système, et des sollicitations de son environnement.
  
  
• Les limites relatives à la commandabilité et à l'observabilité des systèmes considérés, qui posent des problèmes complexes d'implémentation de scénarios de test abstraits.

L'action spécifique étudiera comment ces différentes facettes du problème du test de robustesse se déclinent selon le type de système considéré. Il s'agira également de déterminer le champ d'application des solutions existantes, ainsi que les points durs nécessitant le développement de nouvelles approches. Les résultats issus de cette action donneront lieu à la préparation d'un article de synthèse.