TESTS BOITES NOIRES et TESTS BOITES BLANCHES
publicité
C E N T R E D E MAITRISE DES SYSTEMES ET DU LOGICIEL VALIDATION VERIFICATION TESTS TESTS BOITES NOIRES et TESTS BOITES BLANCHES STRUCTURE ET ORGANISATION DES PROGRAMMES EN VUE DES TESTS ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 1 TESTS BOITES NOIRES et TESTS BOITES BLANCHES ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 2 Typologie des systèmes informatiques (1/2) • Deux grandes classes de programmes et/ou de systèmes qui interagissent de plus en plus : – Programmes TRANSFORMATIONNELS séquentiels et/ou concurrents – Transforment progressivement, et par étapes, les données entrées en résultats – La description des données est primordiale » Exp. : • une transaction dans un système d’information • un calcul dans une simulation numérique, etc. – Programmes RÉACTIFS synchrones et/ou asynchrones – Maintiennent une relation constante avec l’environnement – La description du comportement est primordiale (ce qui implique un modèle de l’environnement) » Exp. : • un ensemble de transactions dans un système d’information qui interagissent avec un ensemble d’usagers du SI • le pilote automatique d’un avion, etc. ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 3 Typologie des systèmes informatiques (2/2) • Dans les deux cas, l’architecture logicielle est une caractéristique fondamentale – Architecture des DONNÉES – MCD, schémas et vues des données, types des données, codage des données, variables essentielles/inessentielles, dépendances fonctionnelles, Domaines et plages de valeurs des données – Architecture des TRAITEMENTS – Enchaînements des fonctions qui réalisent la transformation entre un état initial (supposé cohérent) et un état final qui soit l’exact reflet de la réalité que le programme et/ou le système modélise – Principe ACID de la programmation transactionnelle – Architecture des CONTRÔLES – Événements programmés et/ou inopinés, interruptions, attentes, retards, synchronisation, protocoles, états, transitions, automates – État nominal de l’environnement et contrôle de l’environnement ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 4 Éléments visibles du composant (1/2) Pvisu Canal d'intrusion DOMAINE SORTIE / ECRITURE • État final résultant de l'exécution de l'élément à partir des données d'entrée MAINTENABILITE / INSTRUMENTATION • paramètres et/ou ordres de visualisation des états internes de l'élément État initial DE DOMAINE ENTRÉE / LECTURE • initialisation avec une combinaison valide des données d'entrée Elément ou Composant à Tester Données Code Contrôle Canal d'observation ©2000 Reproduction interdite J.Printz État final DS TRACES • États intermédiaires résultant de l'instrumentation Traces / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 5 Éléments visibles du composant (2/2) Pvisu Table des paramètres et ordres d'intrusion construite à l'avance, devant conduire à l'observation d'un comportement et de résultats intermédiaires déterminés à l'avance. Canal d'intrusion Agents d'intrusion DE Données Code DS Contrôle Les programmes agents sont une forme de redondance qu'il faut doser de façon à perturber le moins possible le comportement de l'élément tout en assurant les conditions d'une bonne observation. Ces agents peuvent être générés sur options, activés ou désactivés (actions de «debug», code OLTD, pré et postconditions, etc.) ©2000 Reproduction interdite J.Printz Agents d'observation Canal d'observation Traces Table des états intermédiaires observables (i.e. « histoire » de la transformation) / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 6 États observables d’un programme : États programmes / états données Elément ou Composant à Tester État initial DE Données État final DS Code Contrôle État programme État des données sous contrôle de P L’état programme à l’instant t résulte de : • Données directement sous le contrôle du programme P toujours accessibles état données • Données induites par le système d’exploitation, le SGBD, les Télécom, etc. ) très difficilement accessibles Parasites / Bruit de fond résultants des actions hors contrôle de P ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 7 TESTS BOITES NOIRES • ON NE PREND EN COMPTE QUE DE ET DS » VALIDATION • ANALYSE DE LA STRUCTURATION DE DE ET DS • ANALYSE DES CORRESPONDANCES ENTRE DE ET DS (i.e. on valide complètement la sémantique de la transformation) • ASPECTS COMBINATOIRES • LIMITE DES TESTS BOITES NOIRES » LA DÉTERMINATION DES DOMAINES EST PROBLÉMATIQUE » RENDEMENT DE L'EFFORT DE TESTS POTENTIELLEMENT TRÈS MAUVAIS ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 8 TESTS BOITES BLANCHES (1/2) • ON PREND EN COMPTE DE DS ET LA STRUCTURE INTERNE DE L’ÉLÉMENT » VÉRIFICATION » NIVEAU DE GRANULARITÉ DE L'OBSERVATION • INSTRUCTIONS ÉLÉMENTAIRES • SÉQUENCES LINÉAIRES D'INSTRUCTIONS • BLOCS DE CODE REGROUPANT PLUSIEURS SÉQUENCES APPARENTÉES ( i.e. RÉGIONS FORTEMENT CONNEXES ) • FONCTIONS ET/OU PROCÉDURES DU LANGAGE » ENVIRONNEMENT D'EXECUTION • ASPECTS TEMPORELS, GESTION DES RESSOURCES, etc. • LIMITE DES TESTS BOITES BLANCHES » QUANTITÉ ET PERTINENCE DE L'INFORMATION PRODUITE » STABILITÉ DES TESTS : – MEME STABILITÉ QUE LE CODE » COINCIDENCE ET RECOUVREMENT NON GARANTIS ENTRE VÉRIFICATION ET VALIDATION ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 9 TESTS BOITES BLANCHES (2/2) • Fondés sur l’aspect structural (i.e. syntaxique) du composant à tester au moyen du graphe de contrôle – On s’intéresse à l’agencement des instructions, et non à leur signification » Exp. : DO WHILE ((a>5) & (a<5)) DO; bloc d’instructions; END DO; • Graphes de contrôle et nombre cyclomatique ignorent l’aspect sémantique – La sémantique prend en compte la nature de la transformation Ds = Prog(De), c.a.d. aux domaines de valeurs et au sens des opérateurs » Exp. : la condition ((a>5) & (a<5)) est toujours FAUSSE, donc le bloc d’instructions n’est jamais exécuté • Par définition, les tests de chemins ne peuvent pas détecter les chemins manquants – Il n’assurent pas la complétude de l’implémentation par rapport à la spécification du composant ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 10 STRUCTURE ET ORGANISATION DES PROGRAMMES EN VUE DE LEUR CONSTRUCTION ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 11 Terminologie • STRUCTURE d’un programme – Résulte des différentes catégories d’instructions utilisées pour construire le programme et pour réaliser la transformation souhaitée – Résulte directement des règles de syntaxe et de sémantique du langage de programmation utilisé • ORGANISATION d’un programme – Regroupement des instructions constitutives de la transformation en : » procédures, sous programmes, classes, tâches, etc. – Les instructions correspondantes (qui ne modifient pas l’état mémoire) sont, en fait, des directives d’assemblage » unités d’alimentation (mémoire virtuelle mémoire centrale) utilisées par l’éditeur de liens dynamique et/ou le chargeur (i.e. loader) du système d’exploitation (découpage en fichiers / segments / pages selon les SE) ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 12 STRUCTURE GÉNÉRALE DES LANGAGES DE PROGRAMMATION IMPÉRATIFS (1/2) • Dans ce type de langage de programmation 3 catégories d’instructions : – Celles qui MODIFIENT L’ÉTAT MÉMOIRE du programme » Exp. : a=b; MOVE a TO b CALL tri-rapide (f1,f2); etc. – Celles qui MODIFIENT LE FLOT D’EXÉCUTION des instructions (instructions dites de contrôle) » Exp. : IF c THEN a=b ELSE a=c GOTO l – Celles qui permettent D’ORGANISER LE PROGRAMME en mémoire » Exp. : En COBOL : En Ada : En C et C++ : ©2000 Reproduction interdite J.Printz organisation en DIVISION, SECTION et paragraphes blocs d’instructions declare … begin … end; organisation en classes package p is … end p; pakage body p1 is procedure p2 … end p2; … end p1; tâches task body t is… end t; etc. / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 13 STRUCTURE GÉNÉRALE DES LANGAGES DE PROGRAMMATION IMPÉRATIFS (2/2) • Marquage des instructions – Toutes les instructions sont repérables par : » leur nom (en anglais label) l1 : a=b; l1 : DO …. END l1; GOTO l1; » leur N° d’ordre dans le programme » leur adresse machine (symbolique ou physique) • Cf. : les références croisées et les cartes d ’allocation mémoire produite par les compilateurs et les éditeurs de liens – Obligatoire pour des raisons d’édition et de mise au point • La plupart des langages ont des fonctions d’édition incorporées qui permettent de composer le programme à compiler à partir de motifs pré-enregistrés – Clauses COPY en COBOL – Unités generic en Ada – Macros en C / C++ ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 14 REPRÉSENTATIONS ET PROPRIÉTÉS ÉLÉMENTAIRES DE LA BOÎTE BLANCHE ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 15 Graphe de contrôle d’un programme • Tout programme peut se représenter sous forme de graphe où : – Les nœuds sont les instructions – Les arcs sont les branchements • Exemple : Un if-then-else ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 16 Les types de nœuds du graphe • Il y a trois types de nœuds : – Les nœuds « fonction » (toute instruction est une fonction) matérialisés par : f – Les nœuds « prédicatifs » (représentant une condition) matérialisés par : c – Les nœuds « de regroupement » (qui sont vides) matérialisés par : ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 17 Programmation structurée (1/3) • Si l’on examine tous les graphes de 1 à 4 nœuds (il y en a 15), seuls 7 sont pertinents car les autres n’ont pas de nœuds fonction (il n’y a donc pas d’instruction !) • Ces 7 graphes sont à l’origine de la programmation structurée ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 18 Programmation structurée (2/3) • En effet, on a : – L’instruction : a = b; par exemple – La séquence : a = b; c = d; » Remarque : correspond à la composition de fonctions – Les alternatives : » If-then » If-then-else – Les itératives : » While-do » Do…while (ou repeat…until) » Do-while-do (test de « milieu » de boucle) ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 19 La programmation structurée (3/3) • On remarque que : – Il n’y a pas le « case » (switch) » C’est un confort syntaxique pour exprimer des cascades de if-then-else imbriqués – Il n’y a pas de boucle « for » » La boucle «for » n’est pas une vraie boucle ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 20 Programme structuré • Un programme structuré est donc : – Un programme qui ne possède qu’un point d’entrée et un point de sortie – Constitué à partir des 7 formes de bases (appelées structures premières) – Tel que pour chaque nœud il existe un chemin reliant l’entrée à la sortie ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 21 Définition du nombre cyclomatique(1/4) • À partir du graphe de programme on peut calculer le nombre cyclomatique (Mc Cabe-1976) V(g) tel que : – V(g) = e – n + 2 (e : edge [arc] ; n : node [nœud]) • Le nombre cyclomatique représente : – Le nombre de chemins linéairement indépendants dans un graphe fortement connexe – Le nombre de décisions + 1 prises dans un programme (i.e. le nombre de nœuds prédicatifs + 1) ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 22 Définition du nombre cyclomatique(2/4) • Un graphe est fortement connexe si : – ni et nj, deux nœuds du graphe, un chemin reliant ni et nj » On remarque qu’un programme bien structuré n’a pas un graphe fortement connexe car il n’y a pas de chemin reliant la sortie à l’entrée ! (on ajoute donc cet arc fictif) • Le nombre de chemins linéairement indépendants correspond au nombre de régions du plan délimitées par le graphe quand les arcs ne se recoupent pas. ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 23 Définition du nombre cyclomatique(3/4) • Exemple V(G) = 3 (donc 2 décisions) ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 24 Définition du nombre cyclomatique(4/4) • Quelle valeur maximum ? – On considère généralement que le nombre cyclomatique doit être inférieur à 10 dans chaque sous-programme • Remarque importante – Le nombre cyclomatique ne mesure que la complexité structurelle statique ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 25 APPLICATION : SÉLECTION ET DESCRIPTION DE CHEMINS a 1 b c 3 d 4 e 5 6 2 OUI DEBUT OUI NON i h l 10 g k f j 9 OUI 8 NON 7 OUI m CHEMINS abcde abhkgde abhlibcde abcdfjgde abcdfmibcde ©2000 Reproduction interdite J.Printz FIN NON DÉCISIONS 4 6 7 OUI OUI NON OUI NON,OUI OUI OUI NON,OUI OUI OUI NON,OUI NON NON 9 NON OUI LIENS a b c - - - - - - - - - - d - e f g h - - - - - i j k l m - - - / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 - Page 26 INTÉRETS DES MODES DE REPRÉSENTATION • GRAPHE DE CONTRÔLE : LE PLUS INTUITIF « ça se voit » ! • MODES DE REPRÉSENTATION PLUS ABSTRAITS : – Expressions régulières: • correspondance directe GC ER – Automates » Machines logiques à mémoire VOLONTAIREMENT rudimentaire • Automates à états finis • Automates à pile(s) • Machines de Turing » Ont des propriétés mathématiques très intéressantes et permettent des preuves (sémantique parfaitement définie) – Machines abstraites » Adaptées aux problèmes à résoudre, donc moins générales que les automates » Rendent explicites ce que le programmeur considère comme important • les événements à contrôler auxquels on va associer les instructions de la machine. • les états mémoire dont on peut choisir la structure et la topologie. ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 27 NOMBRE CYCLOMATIQUE (1/3) • MESURE DE COMPLEXITÉ DE Mc CABE » M = Arcs - Noeuds + 2P – Arrière plan mathématique : • s'applique à des graphes non orientés • chemins minimaux à partir desquels on peut engendrer tous les chemins possibles – notion de base d'un espace vectoriel – Exemples : M=2 M=2 M=1 M=7 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 28 NOMBRE CYCLOMATIQUE (2/3) – Applications • évaluation du nombre de tests minimaux • critère pour investigations plus poussées (révélateur d'anomalies) – revues, inspections – Faiblesses • les programmes sont des graphes orientés; la notion de chemin est différente . • la mesure n'est pas fidèle. » Exemples: • conditions multiples • boucles A&B&C A V F ©2000 Reproduction interdite J.Printz A B C V F M=2 B&C F M=3 M=4 / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 29 NOMBRE CYCLOMATIQUE (3/3) M=2 DO WHILE 1 1 3 2 4 2,3,4 4 5 DO UNTIL 1 seul test pour les 2 chemins 5 2 tests pour les 2 chemins 1 3 2 1 2 2,3,2 4 4 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 30 NOMBRE CYCLOMATIQUE ET EFFORT DE TEST Début M=1 Début M=5 Bloc N°1 Bloc N°2 Bloc N°1 Bloc N°2 Bloc N°3 Bloc N°4 Bloc N°5 Bloc N°3 Fin Bloc N°4 Bloc N°5 Fin ©2000 Reproduction interdite J.Printz Bien que les nombres cyclomatiques soient très différents, l’effort de test est quasiment le même !!! / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 31 COUVERTURES • DÉTERMINENT LES DIFFÉRENTES FAÇONS DE PARCOURIR LE GRAPHE DE CONTROLE – TOUS LES NOEUDS: – TOUS LES ARCS: – TOUS LES CHEMINS: C0 C1 C • FACILITÉ DE MISE EN OEUVRE – C0 et C1 très faciles – C très difficile • RENDEMENT – C1 EXCELLENT, EN PARTICULIER ASSOCIÉE AVEC PROGRAMMATION STRUCTURÉE ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 32 LIMITATIONS DES GRAPHES DE CONTROLE • LA SIMPLIFICATION DU MODELE CONDUIT A NE PAS OU A MAL REPRÉSENTER LES ÉLÉMENTS SUIVANTS : » » » » » » » » » le détail des expressions booléennes l'itération simple les assignations et la dépendance fonctionnelle des variables les déclarations de données, la portée des variables la segmentation des données et du code (packaging en mémoire virtuelle pour bénéficier des effets « cluster » grâce aux caches) les appels de fonctions et de procédures les ordres d'entrées sorties et d’une façon générale les appels système les macros et/ou l’héritage de code les exceptions et les interruptions ; la synchronisation (i.e. programmes réactifs) TOUS CES ÉLÉMENTS JOUENT UN ROLE TRES IMPORTANT ET SONT SOURCE DE NOMBREUSES ERREURS ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 33 DÉFAUTS SÉMANTIQUES POTENTIELLEMENT INDÉCELABLES PAR COUVERTURE SIMPLE (1/2) Exemple : N°1 N°2 N°3 N°4 N°5 Valeurs initiales a=0 ; b=0 a=0 ; b=1 a=1 ; b=0 a=1 ; b=1 a=1 ; b=2 (a+b)(a+1) 0 1 2 4 6 Programmes faux (a-b)(a+1) (a+1)(a+1) (b+b)(a+1) (a+b)+(a+1) (a+b)(a-1) 0 -1 0 0 0 -1 -1 2 2 -1 2 0 0 3 0 0 0 4 4 0 -2 0 8 5 0 4 0 1 2 0 Résultats corrects mais programme faux Il faut passer plusieurs fois dans la même branche avec des valeurs différentes pour détecter l’erreur ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 34 DÉFAUTS SÉMANTIQUES POTENTIELLEMENT INDÉCELABLES PAR COUVERTURE SIMPLE (2/2) Erreur décelable par ajout de redondance Calcul de l’expression Calcul d’une expression sémantiquement équivalente (test en ligne) Comparaison des résultats Vrai Faux Auto diagnostique Par exemple : a2 + a×b + a + b a× (a + b + 1) + b ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 35 Annexe et complément sur la programmation en vue des tests : STRUCTURE ET ORGANISATION DES PROGRAMMES EN VUE DES TESTS ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 36 PARTIE CACHÉE État initial DE Événements entrants ©2000 Reproduction interdite J.Printz Code fonctionnel nominal Exceptions et/ou défaillances programmées et/ou inopinées Autocontrôles Post-conditions Composante transformationnelle Pré-conditions PARTIE VISIBLE MODÈLE DE COMPOSANT État final DS Événements sortants Composante réactive / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 37 Caractéristiques et classes de programmes • T = Transformationnel ; R = Réactif Asynchrone (Rendez-vous) Synchrone (Temps vrai, respect de priorités) ©2000 Reproduction interdite J.Printz Séquentiel Concurrent T T R T (temps contraint) R T (temps + RDV contraints) R / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 38 PROGRAMMES TRANSFORMATIONNELS (1/3) • Pour le programmeur, tout se passe comme si le programme dispose instantanément de toutes les ressources système nécessaires à son exécution – Toute ressource nommée dans le programme est considérée comme acquise – Le programme est très proche de l’idéal déterministe • La plupart des mécanismes système lui sont cachés par le système d’exploitation – La sémantique de la transformation ne dépend pas de ces mécanismes (propriété d’idempotence) – La « sphère de contrôle » du programme est strictement incluse dans celle du système d’exploitation de la machine • Le programme est une abstraction logique intemporelle sur lequel on peut raisonner de façon sûre avec toutes les ressources de la logique mathématique ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 39 PROGRAMMES TRANSFORMATIONNELS (2/3) Le programme est généralement mono processus et ne s'exécute que sur un seul processeur à la fois. Il n'a aucune relation directe avec l'extérieur. Il est assimilable à une suite d’instructions ininterruptibles. Il faut parfaitement connaître les interfaces avec le système d'exploitation. PROGRAMME Mémoire vue par P P Zone Tampon (interface avec le SE) Appels directs aux fonctions du SE Contenu de la zone tampon : • Buffer pool pour fichiers et/ou bases de données, • Mémoire virtuelle, • Files d'attente de messages télécoms vus comme des fichiers, etc. SYSTEME D'EXPLOITATION RESSOURCES (gérées par le SE) ©2000 Reproduction interdite J.Printz Recueille et traite tous les événements et les interactions avec l'extérieur (sous contrôle du SE) / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 40 Données de la transformation Mémoire non persistante statique Mémoire non persistante dynamique Mémoire persistante SPHÈRE DE CONTRÔLE DU PROGRAMME Algorithmes de la transformation Via SGF et/ou SGBD ©2000 Reproduction interdite J.Printz SPHÈRE DE CONTRÔLE DU SYSTÈME D’EXPLOITATION PROGRAMMES TRANSFORMATIONNELS (3/3) / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 41 PROGRAMMES RÉACTIFS (1/4) • Pour le programmeur, tout se passe comme si le programme doit lui-même gérer les ressources système nécessaires à son exécution – Toute ressource utilisée par le programme doit être acquise (statiquement ou dynamiquement) conformément au protocole d’acquisition propre de la ressource – Le programme est très éloigné de l’idéal déterministe • La plupart des mécanismes système sont visibles par le programme lui-même – La sémantique de la transformation peut dépendre de ces mécanismes – La « sphère de contrôle » du programme déborde celle du système d’exploitation de la machine • Chaque instance (i.e. exécution) du programme est susceptible d’une histoire particulière qui dépend aléatoirement des événements qui l’engendrent ; on ne peut plus raisonner de façon sûre avec les seules ressources de la logique mathématique (i.e. nouvelle logique temporelle) ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 42 PROGRAMMES RÉACTIFS (2/4) • MODÈLE ASYNCHRONE : PARTAGE DE RESSOURCES + CONCURRENCE POUR LES RESSOURCES EXCLUSIVES » MODÈLE CLIENT-SERVEUR ET PROTOCOLES DE COMMUNICATIONS » LE MODÈLE LE PLUS RÉPANDU EST CELUI DE LA PROGRAMMATION TRANSACTIONNELLE (en COBOL dès les années 70) • LE PROGRAMME SE PARTAGE PLUSIEURS PROCESSEURS • IL Y A CONCURRENCE SUR LES DONNÉES (accès aux bases de données) • LES RESSOURCES AFFECTÉES AU PROGRAMME SONT BANALISÉES • MODÈLE SYNCHRONE : TEMPS RÉEL » LE TEMPS VRAI EST UN PARAMÈTRE FONDAMENTAL • INTERRUPTIONS ET PRIORITÉS • RESSOURCES DEDIÉES (y compris les processeurs) • MODÈLES MIXTES » SYSTÈMES C3I • COHABITATION D ’INTERACTIONS DE TYPE CONVERSATIONNEL - temps « réfléchi » où l’attente est possible - ET DE TYPE RÉFLEXE où la réponse doit être immédiate » SYSTÈMES HYBRIDES • COHABITATION ÉQUIPEMENTS ANALOGIQUES - fonctionnant en continu - ET ORDINATEURS (le tout fonctionnant en boucles fermées) ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 43 PROGRAMMES RÉACTIFS (3/4) M1,3 Tâche T3 M1,2 M1,1 M1,3 Tâche T2 M1,2 M1,1 M1,3 Tâche T1 M1,2 M1,1 Ordonnancement des taches selon les priorités et les contraintes temporelles Le programme est multitâches qui peuvent s'exécuter sur plusieurs processeurs et gérer plusieurs contextes. Il est en permanence en relation directe avec l'extérieur. L’exécution des instructions peut être interrompue à tout moment phénomène d ’entrelacement (interleaving). Il faut parfaitement connaître le fonctionnement des moniteurs qui notifient les événements aux différentes tâches. Zone de communication entre tâches Contenu de la zone de communications : • Files d’attentes de messages à dispatcher, • Tables de verrouillage de ressources, • Sémaphores de synchronisation, etc. Différents moniteurs La cohérence entre le système d'exploitation et les moniteurs doit être soigneusement validée et vérifiée. SYSTEME D'EXPLOITATION RESSOURCES (gérées par le SE) ©2000 Reproduction interdite J.Printz Dispatching des événements selon les moniteurs / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 44 PROGRAMMES RÉACTIFS (4/4) • Conséquences de l’entrelacement sur le flot des instructions » Contrôle rigoureux des règles de partage des données (en particulier pour les mises à jour et les lectures « sales ») » Contrôle rigoureux des règles de rupture de séquence (section critique, propriétés ACID des transactions) Flot de la tâche T1 •• • Durée t quelconque Potentialité de générer très facilement des états incohérent du programme qui provoqueront des défaillances très difficiles, voire impossibles, à reproduire !!! Séquence quelconque d’instructions des autres tâches, des moniteurs, du système d ’exploitation •• • ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 45 TEST DE PROGRAMMES RÉACTIFS Exemple de la gestion de ressources logicielles ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 46 Principes • Expliciter aussi précisément que possible la sphère de contrôle du programme et/ou du système à tester – Faire un modèle de l’environnement dans lequel opère le programme – Faire l’inventaire des événements qui doivent remonter sur le programme • Tester d’abord les composantes transformationnelles du programme – Couverture 100% • Mettre en place, à demeure dans le programme, un jeu de traces que l’on peut activer ou débrayer dynamiquement, y compris in situ – Identifier exhaustivement toutes les variables partagées, les points de synchronisation, les sections critiques, les ressources partagées, etc. – Journalisation des événements sur des mémoires circulaires stables (pour éviter la perte d’information) – Relaxation progressive de la granularité en fonction de l’évolution de la courbe de maturité jusqu’à obtention du grain nominal ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 47 Ressource logicielle (1/4) Ce qui permet à une fonction logicielle de s’exécuter • Exp : Mémoire, fichiers, DB, appareil, ligne télecom, 1 ou n processus, une donnée, etc. • L’acquisition d’une ressource résulte toujours d’une demande – Explicite sous contrôle du/des programmeur(s) • Ouverture d’un fichier, allocation d’une zone mémoire, etc. – Implicite à partir de l’information des programmes • Par le compilateur, l’éditeur de liens, le système d’exploitation, le moniteur de contrôle, etc. ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 48 Ressource logicielle (2/4) • Etat d’une ressource – Disponible » Libre / Attribuée (à 1 ou n, i.e. partagée) – Indisponible » Temporairement (saturation, attente, etc.) » Définitivement (types de pannes) – Réparable / Non réparable Mot d’état associé à la ressource » Visibilité du mot d’état : Broadcast / Polling ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 49 Ressource logicielle (3/4) • La prise en compte de la demande par l’environnement peut être faite – A la compilation et/ou édition de liens Construction déterministe – Au démarrage de l’application lors du chargement – Dynamiquement, au dernier moment Construction non déterministe (d’où contrôle de charge) » Cas fréquent en programmation objet • L’exécution de la demande peut être synchrone ou asynchrone Priorité, durée, etc. ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 50 Ressource logicielle (4/4) • Types de ressources » Banalisée / homogène : une zone mémoire, une tâche, un fichier temporaire, etc. Possibilité d’épuisement ; ressources centralisées » Spécifique / hétérogène : un fichier particulier, une donnée (i.e. données « essentielles »), un processus système, etc. Possibilité de conflit avec une autre demande ; ressources distribuées » Composite (toute combinaison autorisée) » Persistante : la demande survit à la fin logique du processus/programme : i.e. rangement dans un cache. • Régulière : restituée automatiquement à l’environnement à la terminaison du programme (i.e. critère LRU) • Irrégulière : restituée si notification explicite (i.e. time out) ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 51 Pipeline de ressources (1/3) • Notion de pipeline • Pipeline permettant le chargement anticipé d’instructions et de données avant leur emploi réel (Localité + régularités statistiques) Mécanisme fondamental (mais très délicat) des UC modernes qui évite de synchroniser la machine sur les organes les plus lents (le bus, E/S, etc.) • Anticipation des demandes de ressources • la ressource est disponible au moment de son utilisation effective • Relaxation progressive en fin de demande • la fin logique d’une demande de ressource ne coïncide pas nécessairement avec la restitution physique des ressources ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 52 Pipeline de ressources (2/3) Espace d'adresse d'une application particulière A Espace système contenant toutes les ressources accessibles depuis A Zone de communication permettant d'échanger des informations ©2000 Reproduction interdite J.Printz Espace machine global contenant toutes les entités adressables, y compris le système d'exploitation et tous ses sous-systèmes. La construction de cet espace est faite par le « Boot » du système d'exploitation qui à son tour créera tous les autres espaces nécessaires aux applications. / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 53 Pipeline de ressources (3/3) Exemple de terminaison d’une application TFin Application A Fin de l'exécution de l'application A, du point de vue du programmeur ••• Séquences d'ordres explicites relâchant certaines ressources temporairement utilisées par A Durée d'exécution TE Programme système d'analyse des résidus de la terminaison ••• ©2000 Reproduction interdite J.Printz Séquences d'ordres complémentaires implicites relâchant le reliquat de ressources non encore libérées Durée d'exécution TI / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 54 Ingénierie de l’architecture • L’architecture doit identifier : – Le code fonctionnel basique, – Le code fonctionnel dur – Le code non fonctionnel • Facilités d ’emploi, Fiabilité, Performance, Maintenabilité, Portabilité – La structure de contrôle la plus appropriée à la logique d ’enchaînement – Le jeu d’interfaces qui minimise le volume du code – La taille maximum des composants critiques pour la survie de l’application Concept d’architecture testable et maintenable ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 55 Dilemme de l’architecte • Pour réduire le coût à risque constant, la performance doit être réduite • Pour réduire le risque à coût constant, la performance doit être réduite • Pour réduire le coût à performance constante, un niveau de risque plus élevé doit être accepté • Pour réduire le risque à performance constante, un coût plus élevé doit être accepté Cf. Vade-mecum du chef de projet ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 56
