La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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é

Présentations similaires


Présentation au sujet: "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é"— Transcription de la présentation:

1 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 dutilisation –Systèmes embarqués autonomie face à des aléas –Interconnexion et répartition caractère incertain – voire même malveillant – de lenvironnement Animateurs :Richard Castanet Hélène Waeselynck AS 23 Techniques avancées de tests des systèmes complexes

2 AS 23 EquipesPersonnes impliquées Irisa, projets Triskell et VertecsClaude Jard, Thierry Jéron, Yves Le Traon LaBRI, équipe MVTsi (Modélisation, vérification Richard Castanet, David Janin et Test de systèmes informatisés) LAAS-CNRS, groupe Tolérance aux fautes et Olfa Abdellatif-Kaddour, sûreté de fonctionnement informatiqueJean Arlat, Hélène Waeselynck LRI, équipe Programmation et Génie LogicielMarie-Claude Gaudel, Sandrine-Dominique Gouraud, Gregory Lestiennes VERIMAG, équipe Systèmes AsynchronesJean-Claude Fernandez, Laurent Mounier, Cyril Pachon AS 23 Techniques avancées de tests des systèmes complexes

3 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 23 Techniques avancées de tests des systèmes complexes

4 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

5 Test de conformité (2) Schéma général Implémentation Sous test Entrées de test Sorties de test Oracle Verdict correctes/incorrectes (vérification partielle) } Spécification S du comportement attendu Relation de conformité I conf S Critères de sélection Hypothèses de sélection jeu de test fini Objectifs de test

6 Problèmes à étudier Positionnement du test de robustesse par rapport au test de conformité Domaine dentrée du test Domaine de sortie et oracle Modélisation du comportement et sélection des tests Architectures de test, commandabilité et observabilité

7 Définitions de Robustesse : -IEEE : degré dun système à fonctionner correctement en présence dentrées invalides ou denvironnement stressant aptitude à exhiber un comportement acceptable en présence daléas Faute – externe/interne – Accidentelle/intentionnelle Variation profil utilisation et charge – en vie opérationnelle / car réutilisation aléa correct ou acceptable Robustesse plus forte que correction … … ou orthogonale ? Parfois, pas de spécification a priori du comportement attendu par rapport à aléa Différence avec la conformité : domaine dentrée différent, Observation du comportement selon une perspective différente

8 Domaine dentré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ème aléa (a) aléa externe (1)Aléa représentable :ex : classes dentrée non valides (hors domaines) (2)Aléa non représentable : ex : temps de réaction trop court entre éven.

9 Domaine dentrée du test (2) système aléa système ?? aléa (b) aléa interne (1)Aléa représentable : faute dun composant interne, propagation (2) Aléa non représentable: faute dun composant de base, bit-flip … ( c ) Aléa au-delà des frontières (environnement du système) (1)Aléa non représentable : faute dun équipement, radiations sur satellite….

10 Domaine de sortie et oracle (1) Extension du domaine dentrée impact sur observation du comportement du système ? Combinatoire domaine dentrée et oracle : 4 cas à examiner système Nouvelles sorties possibles Augmentation observabilité (ex: déterminer si état interne erroné) Lien avec modèle nominal ?

11 Domaine de sortie et oracle (2) Différents cas -sortie identique et oracle inchangé : Pas dimpact (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 lobservabilité, 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 derreurs -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

12 Approches selon le degré de modélisation Modèle du système incluant la prise en compte dalé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 daléas dans le modèle Pas de modèle du système incluant la prise en compte daléas (système complexe) –Test de robustesse basé sur un modèle des entrées Modélisation partielle –Approche mixte ?

13 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

14 Méthodes basées sur des modèles comportementaux (1) SM // 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

15 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, S R 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 derreur 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

16 Approche 1(1) SM // produit Propriété de robustesse -Génération dune spécification dégradée S d à partir de S et de M (S d et M simplifiés par P) -Génération dun 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 dobservation) verdicts de robustesse S dégradé observateur Cas de test Propos de test

17 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é dun 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 dexécution de S d 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 nest 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 S d observateur pour l IUT –Sélection et synthèse de cas de tests : construction dun graphe de test et verdicts « robuste » ou « non robustesse » selon le type du nœud final dexécution de la séquence dexécution du test

18 Approche 2 (1) nominal alé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 dun environnement hostile) -Synthèse dun contrôleur C t.q. C x S sat P, S R 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 S R : test de la conformité de IUT par rapport à soit P soit S R

19 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 dhypothèses sur lenvironnement 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 dun contrôleur C t.q. S x C sat P : coupe des événements contrôlables qui donne la possibilité à lenvironnement de gagner. S R = S x C Génération de tests de robustesse –Choix de relation entre S R 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é)

20 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 dactions alternée avec ensemble de refus) -Construction du testeur de robustesse : graphe de refus + traces de fautes, ajout daction 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 robustesse Propos de test sélectionnés

21 Approche 3 (2) Méthodes utilisées Construction du graphe de refus 1 32 a a bc 4 5 a Ref : {{b, c}} Ref : {{a, b};{a, c}} bc Ref = {{a, b, c}} Traces de fautes : séquences alternées dactions et densemble de refus 4 5 r r a b ({b, c},, ) ({a, c}, {a, b},, ) Construction du testeur de robustesse

22 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, stockage Liaisons avec lutilisateur, le réseau et lunité de stockage fromNet?OK FromNet ?OK Autre action Rien faire (faute) Prendre message cas nominal GPE

23 Approche 4 (2) Méthodes utilisées Modélisation du processus derreur : interruption à tout moment possible du traitement nominal, lerreur 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 duniformité (sur les états et non les données), inclusion derreurs entre les messages dépendants –Enrichissement du processus de test avec des actions correspondant à des occurrences derreurs. IUT et testeur doivent contrôler linjection de fautes environnement de test avec système et testeur synchronisés avec un injecteur de fautes

24 Approches basées sur un modèle des entrées (1) Problème des expériences non significatives –Ex: injection dune faute qui restera non activée dans le système analyse en-ligne de lactivité du système, analyse boîte grise Sélection pertinente dans un objectif de vérification ( évaluation) –Ex: heuristiques doptimisation pour guider la recherche des scénarios de test les plus dangereux ( les plus représentatifs) Profil opérationnel Classes déquivalence dentrées … Souvent, modèle activité nominale + modèle aléas Superposition activité nominale x aléas ?

25 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 derreurs à linterface ou dans le système Approche basée sur lactivité ; 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 lexé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

26 Approches basées sur un modèle des entrées (3) Type de fautes physiques –Faute externe venant de lenvironnement ( radiations bit flip). Méthode de corruption de mémoire. Technique dinjection de fautes SWIFI. –Faute interne dun composant Type de fautes logicielles –Nombreux exemples de test de robustesse dOS ou micro-noyaux, importance des composants sur étagère à tester, des ORB et des systèmes embarqués croissante. Technique de corruption (paramètres dappel, 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é)

27 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 dun OS, 30% des injections de fautes nont pas deffets visibles) –Objectifs : tests + effectifs, durée moindre des tests, focus sur critère de test spécifique, augmenter lobservabilité –Technique de test « boîte grise » : « boîte blanche » + « boîte noire » –Contrôlabilité (tests + effectifs) Injection de fautes sur un chemin dexécution Injection de charges (monitoring du système à tester) –Regroupement de tests, nécessité de connaissance du système –Propagation derreurs (système multi-composants) –Prédiction de la couverture de détection derreurs (test dactivité de chaque bloc dun système, plus un composant est activé, plus son comportement en présence de fautes va être important)

28 Vers des approches mixtes? Modélisation partielle avec plusieurs niveaux dabstraction –Raffinements pour faire des zooms sur certaines parties du système –Prise en compte dinformations structurelles –Prise en compte dinformations issues de lanalyse 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

29 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


Télécharger ppt "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é"

Présentations similaires


Annonces Google