• Coût de la validation d'un système informatique : 50-75% du coût total de développement

• Test = vérification dynamique par activation du système implémenté

• De nombreuses avancées : test de conformité par rapport à une spécification

• Encore peu étudié : test de la robustesse d'un système soumis à des sollicitations quelconques, y compris erronées ou inopportunes

– Conception à base de composants réutilisables diversité des profils d’utilisation

– Systèmes embarqués autonomie face à des aléas

– Interconnexion et répartition caractère incertain – voire même malveillant – de l’environnement

• Animateurs : Richard Castanet (castanet@labri.u-bordeaux.fr)Hélène Waeselynck

(Helene.Waeselynck@laas.fr)

AS 23Techniques avancées de tests des systèmes complexes

AS 23Equipes Personnes impliquées

• Irisa, projets Triskell et Vertecs Claude Jard, Thierry Jéron, Yves Le Traon

• LaBRI, équipe MVTsi (Modélisation, vérification Richard Castanet, David Janinet Test de systèmes informatisés)

• LAAS-CNRS, groupe Tolérance aux fautes et Olfa Abdellatif-Kaddour, sûreté de fonctionnement informatique Jean Arlat, Hélène Waeselynck

• LRI, équipe Programmation et Génie Logiciel Marie-Claude Gaudel, Sandrine-Dominique Gouraud, Gregory Lestiennes

• VERIMAG, équipe Systèmes Asynchrones Jean-Claude Fernandez,Laurent Mounier, Cyril Pachon

AS 23Techniques avancées de tests des systèmes complexes

• objectif de prospective identifier et défricher un nouvel aspect de la production de tests pour les systèmes complexes

• thème multi-compétence : synthèse de tests formalisée, injection de fautes

• à court terme, production d'un document à destination de la communauté STIC

• perspective de susciter le lancement de projets autour de ce thème.

AS 23Techniques avancées de tests des systèmes complexes

Test de conformité (1)Vise à vérifier si un système satisfait ses spécifications

Notion de satisfaction entre une spécification S et une implantation I(utilisée comme base pour le jeu de tests et le verdict)Exemple : conf (Brinskma), ioco (Tretmans) : inclusion de traces

Restrictions sur la classe des implantations (hypothèses de test)restrictions « raisonnables » sur états, indéterminisme …

Jeu de tests « théorique » trop grand ou infini sélection des tests- critères de couverture (structurel …)- hypothèses : uniformité …- propos de test : certains comportements

Verdicts : réussite, échec, inconcluant

Test de conformité (2)Schéma général

ImplémentationSous test

Entréesde test

Sortiesde test

OracleVerdictcorrectes/incorrectes(vérification partielle)

}

• Spécification S du comportement attendu

• Relation de conformité I conf S

• Critères de sélectionHypothèses de sélection jeu de test finiObjectifs de test

Problèmes à étudier

• Positionnement du test de robustesse par rapport au test de conformité

• Domaine d’entrée du test

• Domaine de sortie et oracle

• Modélisation du comportement et sélection des tests

• Architectures de test, commandabilité et observabilité

Définitions de Robustesse : -IEEE : degré d’un système à fonctionner correctement en présence d’entrées invalides ou d’environnement stressant aptitude à exhiber un comportement acceptable en présence d’aléas

• Faute

– externe/interne

– Accidentelle/intentionnelle

• Variation profil utilisation et charge

– en vie opérationnelle / car réutilisation

aléa

correct ouacceptable

• Robustesse plus forte que correction …

• … ou orthogonale ?

• Parfois, pas de spécification a priori du comportementattendu par rapport à aléa

Différence avec la conformité : domaine d’entrée différent, Observation du comportement selon une perspective différente

Domaine d’entrée du test (1)• Extension du domaine pour prendre en compte les aléas

problème combinatoire difficile

• Classification des aléas selon deux points de vue– Situation par rapport aux frontières du système

– Représentable ou non au sein du modèle “nominal” du système

Combinatoire de 5 cas selon les 2 paramètres

systèmealéa

(a) aléa externe

(1) Aléa représentable :ex : classes d’entrée non valides (hors domaines)

(2) Aléa non représentable : ex : temps de réaction trop court entre éven.

Domaine d’entrée du test (2)

systèmealéa

système

??

aléa

(b) aléa interne

(1) Aléa représentable : faute d’un composant interne, propagation

(2) Aléa non représentable: faute d’un composant de base, bit-flip …

( c ) Aléa au-delà des frontières (environnement du système)

(1) Aléa non représentable : faute d’un équipement, radiations sur satellite….

Domaine de sortie et oracle (1)Extension du domaine d’entrée impact sur observation du comportement du système ?Combinatoire domaine d’entrée et oracle :4 cas à examiner

systèmeNouvelles sorties possibles

Augmentation observabilité(ex: déterminer si état interne erroné)

Lien avec modèle “nominal” ?

Domaine de sortie et oracle (2)

Différents cas-sortie identique et oracle inchangé : Pas d’impact (conservation de fonctionnalité en dépit des aléas : système tolérant et redondant)- sortie identique et oracle modifié : prise en compte de nouveaux comportements attendus, augmentation de l’observabilité, ex : effets de bord des fautes-Augmentation des sorties et oracle modifié : focalisation sur quelques propriétés de robustesse, exception nouvelle observation, problème de propagation d’erreurs-Augmentation des sorties et oracle flou : observations sans verdict (ex: collecte de données sur les modes de défaillance de composants sur étagères, analyse comparative a posteriori), appréciation humaine

Approches selon le degré de modélisation

• Modèle du système incluant la prise en compte d’aléas– Parfois identique à test de conformité(exemples)– De façon générale, question différente. Test de robustesse basée sur le modèle.

2 cas: aléas et leur traitement banalisés dans modèle --> critères de sélection ? (≠ conformité) ; Séparation des aspects “nominaux” et des aspects relatifs à la prise en compte d’aléas dans le modèle

• Pas de modèle du système incluant la prise en compte d’aléas (système complexe)– Test de robustesse basé sur un modèle des entrées

• Modélisation partielle– Approche mixte ?

Quelques modèles comportementaux pour la robustesse

• Modèle système à transitions étiquetées (LTS)• Modèle LTS étendu : modèle de communication (algèbre,

canaux …)• Modèle LTS enrichi : variables, actions, prédicats…• Modèle de jeu : 2 joueurs (système, environnement), stratégies

gagnantes• Modèle pour expression de critères de sélection : LTS avec

divers cas d’états distingués• Opérateurs et algorithmes : produit synchronisé, parcours et

traitement de graphes, algorithmes de résolution de jeux

Méthodes basées sur des modèles comportementaux (1)

S M//

produit

Propriété de robustesse

Différentes approches

P : S spécification, M modèle de fautes (ensemble des fautes potentielles et des événements non prévus), P propriété de robustesse : une implantation I est robuste ssi I satisfait P même en présence de fautes

S dégradéobservateur

Cas de test

Propos de test

Méthodes basées sur des modèles comportementaux (1)

Différentes approches

1. Modèle basé sur S spécification, M modèle de fautes (ensemble des fautes potentielles et des événements non prévus) et P propriété de robustesse sélection et synthèse de cas de test

2. Modèle basé sur S spécification (modes nominal, dégradé), P propriété de robustesse, SR sous-spécification permissive = S X C (C : le superviseur synthétisé t.q. C X S sat P contrôle de la robustesse et génération de test de robustesse

3. Modèle basé sur le graphe de refus de S, avec ajout de traces d’erreur testeur de robustesse propos de tests de robustesse

4. Modèle basé sur S (style Lotos) enrichie et des mécanismes de tolérance aux fautes (exemple du Two-Phase Commit Protocol) et des hypothèses d’équivalence de classes de données composition S+processus de test +injecteur de fautes

Approche 1(1)

S M//

produit

Propriété de robustesse

-Génération d’une spécification dégradée S d à partir de S et de M (S d et M simplifiés par P)-Génération d’un observateur O (expression de la propriété de non robustesse) test robustesse de S d et extraction de séquences incorrectes respectant P- Synthèse de cas de test (de S d , O, propos de test pour raffiner la sélection), cas de test exécutables (en accord avec le contrôle donné et les critères d’observation) verdicts de robustesse

S dégradéobservateur

Cas de test

Propos de test

Approche 1 (2)Méthodes utilisées

• Combinaison de S et M (modèle de fautes)– Méthode de mutation de code : entrées non prévues extension de transitions et de

domaine de données, non fiabilité d’un canal, fautes internes transitions pour « bypass » formalisme général ?

• P, observateur (O) et critères de robustesse– Construction de O (complété) reconnaissant séquences de non P détection

séquences incorrectes d’exécution de Sd et génération de tests pour IUT. O : automate de Rabin (séquences finies et infinies) un IUT est robuste ssi aucune séquence n’est reconnue par O : L(IUT) L(O)=

• Génération de tests– Produit synchrone (étendu aux séquences non spécifiées de IUT) de O et Sd

observateur pour l ’IUT– Sélection et synthèse de cas de tests : construction d’un graphe de test et verdicts

« robuste » ou « non robustesse » selon le type du nœud final d’exécution de la séquence d’exécution du test

Approche 2 (1)

nominalaléa

réparation

Propriété de robustesse

•synthèse du plus grand sous-système satisfaisant la propriété (synthèse de contrôleurs)

• stratégies gagnantes (2 joueurs : environnement, système) pour revenir à l’état nominal

Dégradé(s)

Modèle utilisé pour le test

-Entrées : S (comportements normaux et dégradés), P (prop. Robustesse: comment une fonctionnalité est préservée dans chaque mode en dépit d’un environnement hostile)-Synthèse d’un contrôleur C t.q. C x S sat P, SR nouvelle spécification robuste en respectant P : la plus permissive sous-spécification (on coupe le plus petit ensemble d’événements contrôlables dans chaque état)-Hypothèse IUT implanté selon SR : test de la conformité de IUT par rapport à soit P soit SR

Approche 2 (2) Méthodes utilisées

• Modèle de spécification : LTS– Modes nominal et dégradé, actions (input, output, interne, contrôlable ou non, nominal ou

non prévu),

• Propriété de robustesse– S sat f(P) pour une transformation f qui tient compte d’hypothèses sur l’environnement et

le système et restreint la satisfaction de P aux arbres de calcul qui satisfont les 2 hypothèses. Plusieurs niveaux de modes dégradés possibles. choix de logique temporelle pour exprimer les propriétés ?

• Contrôle de la robustesse– Synthèse d’un contrôleur C t.q. S x C sat P : coupe des événements contrôlables qui donne

la possibilité à l’environnement de gagner. SR = S x C

• Génération de tests de robustesse– Choix de relation entre SR et IUT : Ioco :    I ioco S if STraces(S), out(I after ) out(S after ), where STraces are

suspension traces. . nombreuses pistes de réflexion pour robustesse et pour des modèles plus riches (limite de décidabilité)

Approche 3 (1)-spécification S : LTS, extension avec évènement inconnu ou incorrect-Construction du graphe de refus de S (ensemble de refus sur chaque état)-Ajout des traces de fautes (séquence d’actions alternée avec ensemble de refus)-Construction du testeur de robustesse : graphe de refus + traces de fautes, ajout d’action non observable pour retourner dans l’état nominal- sélection des tests et calcul de couverture

S Graphe de refus Ajout de traces de fautes

Testeur de robustessePropos de test sélectionnés

Approche 3 (2)Méthodes utilisées

Construction du graphe de refus

1

32

a a

b c

4

5

aRef : {{b, c}}

Ref : {{a, b};{a, c}}

b cRef = {{a, b, c}}

Traces de fautes : séquences alternées d’actions et d’ensemble de refus

4

5 r

r

ab

({b, c}, , )

({a, c}, {a, b}, , )

Construction du testeur de robustesse

Approche 4 (1)-Spécification (type Lotos)-Test de mécanismes de tolérance aux fautes-Exemple du « Two-Phase Commit Protocol » : diffusion atomique avec erreurs transitoires (fail silent)

GPE

AP user

Réseau fiable

GPE : protocole , transmission, livraison de messages, stockageLiaisons avec l’utilisateur, le réseau et l’unité de stockage

fromNet?OK

FromNet ?OK

Autre action

Rien faire(faute)

Prendremessagecasnominal

GPE

Approche 4 (2)Méthodes utilisées

• Modélisation du processus d’erreur : interruption à tout moment possible du traitement nominal, l’erreur peut persister, ou faire silence ou terminer. Le processus de recouvrement peut aussi être interrompu

• Utilisation de techniques de test de conformité pour tolérance aux fautes– Problème de fréquence de fautes : couverture de toutes les transitions menant à une

faute (trop redondant, pas de test de fautes successives avec essai de recouvrement)– Problème du comportement incontrôlable et non équilibré : en test de conformité,

hypothèses d’équité. Ici erreur très indéterministe avec faible probabilité

• Solutions envisageables– Nouvelle définition d’uniformité (sur les états et non les données), inclusion d’erreurs

entre les messages dépendants– Enrichissement du processus de test avec des actions correspondant à des occurrences

d’erreurs. IUT et testeur doivent contrôler l’injection de fautes environnement de test avec système et testeur synchronisés avec un injecteur de fautes

Approches basées sur un modèle des entrées (1)

• Problème des expériences non significatives– Ex: injection d’une faute qui restera non activée dans le système

analyse en-ligne de l’activité du système, analyse boîte grise

• Sélection pertinente dans un objectif de vérification(≠ évaluation)– Ex: heuristiques d’optimisation pour guider la recherche des scénarios de

test les plus “dangereux” (≠ les plus représentatifs)

•Profil opérationnel•Classes d’équivalence d’entrées•…

Souvent, modèle activité nominale + modèle aléas

Superposition activité nominale x aléas ?

Approches basées sur un modèle des entrées (2)

• Décomposition du domaine en 2 dimensions : activité de base (workload), fautes (faultload) . Production combinée d’erreurs à l’interface ou dans le système

• Approche basée sur l’activité ; utilisation de benchmarks, test de performances et de charge, tests de propriétés non fonctionnelles (ex : intégrité de transactions). Très long benchmark (test OS)

• Approche basée sur les fautes– Injection de fautes dans l’exécution (à différents moments), possibilité de reset– Injection de fautes pour mécanismes de tolérance, problème de couverture de test– Types de fautes

• Fautes physiques• Fautes logicielles• Fautes humaines

Approches basées sur un modèle des entrées (3)

• Type de fautes physiques– Faute externe venant de l’environnement ( radiations bit flip). Méthode de

corruption de mémoire. Technique d’injection de fautes SWIFI.– Faute interne d’un composant

• Type de fautes logicielles– Nombreux exemples de test de robustesse d’OS ou micro-noyaux, importance des

composants sur étagère à tester, des ORB et des systèmes embarqués croissante. Technique de corruption (paramètres d’appel, code, données)

– Niveaux de fautes : catastrophique, niveau application, fin anormale, silence, code de retour erroné. Traitements automatiques ou humains (interprétation)

• Type de fautes humaines– Erreurs intentionnelles (intrusion …) ou non. Test statistique pour définir le

« faultload » (type de faute, fréquence, gravité)

Approches basées sur un modèle des entrées (4)

• Approche basée sur activité et fautes– Inconvénient des approches sur un seul mode (ex test de robustesse d’un

OS , 30% des injections de fautes n’ont pas d’effets visibles)– Objectifs : tests + effectifs, durée moindre des tests, focus sur critère de

test spécifique, augmenter l’observabilité– Technique de test « boîte grise » : « boîte blanche » + « boîte noire »– Contrôlabilité (tests + effectifs)

• Injection de fautes sur un chemin d’exécution• Injection de charges (monitoring du système à tester)

– Regroupement de tests, nécessité de connaissance du système– Propagation d’erreurs (système multi-composants)– Prédiction de la couverture de détection d’erreurs (test d’activité de

chaque bloc d’un système, plus un composant est activé, plus son comportement en présence de fautes va être important)

Vers des approches mixtes?

• Modélisation partielle avec plusieurs niveaux d’abstraction– Raffinements pour faire des “zooms” sur certaines parties du

système

– Prise en compte d’informations structurelles

– Prise en compte d’informations issues de l’analyse en ligne du comportement du système

• Combinaison avec modèles des entrées– Approche combinée entre modèle des entrées et modèle du

système

Conclusion et perspectives

• Domaine de recherche riche, susceptible de fédérer plusieurs communautés

• Nouvelles méthodes de test à définir• Problèmes difficiles (complexité, modélisation,

observabilité, commandabilité)• Thème explicitement inséré dans une EoI du 6ième

PCRD (TESTNET)• Besoins industriels évidents et importants