©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 1 VALIDATION VERIFICATION.

Présentation au sujet: "©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 1 VALIDATION VERIFICATION."— Transcription de la présentation:

1 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 1 VALIDATION VERIFICATION TESTS TESTS BOITES NOIRES et TESTS BOITES BLANCHES    STRUCTURE ET ORGANISATION DES PROGRAMMES EN VUE DES TESTS

2 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 2 TESTS BOITES NOIRES et TESTS BOITES BLANCHES

3 ©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 (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.

4 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 4 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

5 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 5 Éléments visibles du composant (1/2) MAINTENABILITE / INSTRUMENTATION paramètres et/ou ordres de visualisation des états internes de l'élément P visu Elément ou Composant à Tester DEDE DSDS DOMAINE ENTRÉE / LECTURE initialisation avec une combinaison valide des données d'entrée DOMAINE SORTIE / ECRITURE État final résultant de l'exécution de l'élément à partir des données d'entrée T races TRACES États intermédiaires résultant de l'instrumentation DonnéesCode Contrôle Canal d'observation Canal d'intrusion État initial État final

6 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 6 Éléments visibles du composant (2/2) P visu DEDE DSDS T races DonnéesCode Contrôle Canal d'observation Canal d'intrusion Agents d'intrusion Agents d'observation 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 post- conditions, etc.) 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. Table des états intermédiaires observables (i.e. « histoire » de la transformation)

7 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 7 États observables d’un programme : États programmes / états données Elément ou Composant à Tester DEDE DSDS DonnéesCode Contrôle État initial État final 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 État programme État des données sous contrôle de P Parasites / Bruit de fond résultants des actions hors contrôle de P

8 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 8 TESTS BOITES NOIRES ON NE PREND EN COMPTE QUE D E ET D S »VALIDATION ANALYSE DE LA STRUCTURATION DE D E ET D S ANALYSE DES CORRESPONDANCES ENTRE D E ET D S (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

9 ©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 (1/2) ON PREND EN COMPTE D E D S 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

10 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 10 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 D s = Prog(D e ), 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

11 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 11 STRUCTURE ET ORGANISATION DES PROGRAMMES EN VUE DE LEUR CONSTRUCTION

12 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 12 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)

13 ©2000 Reproduction interdite J.Printz / 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 (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=cGOTO l –Celles qui permettent D’ORGANISER LE PROGRAMME en mémoire »Exp. : En COBOL : organisation en DIVISION, SECTION et paragraphes En Ada : 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; En C et C++ : etc.

14 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 14 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++

15 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 15 REPRÉSENTATIONS ET PROPRIÉTÉS ÉLÉMENTAIRES DE LA BOÎTE BLANCHE

16 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 16 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

17 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 17 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 : –Les nœuds « prédicatifs » (représentant une condition) matérialisés par : –Les nœuds « de regroupement » (qui sont vides) matérialisés par : f c

18 ©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 (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

19 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 19 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)

20 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 20 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

21 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 21 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

22 ©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(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)

23 ©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(2/4) Un graphe est fortement connexe si : –  n i et n j, deux nœuds du graphe,  un chemin reliant n i et n j »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.

24 ©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(3/4) Exemple   V(G) = 3 (donc 2 décisions) 

25 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 25 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

26 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 26 APPLICATION : SÉLECTION ET DESCRIPTION DE CHEMINS 13 810 52 46 97 DEBUTFIN m ihgf edcba lkj CHEMINSDÉCISIONSLIENS 46 79a b c d e f g h i j k l m abcdeOUIOUI- - - - - abhkgdeNONOUINON- - - - - - - abhlibcdeNON,OUIOUIOUI- - - - - - - - abcdfjgdeOUINON,OUIOUI- - - - - - - - abcdfmibcdeOUINON,OUINON- - - - - - - - NON OUI NON

27 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 27 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.

28 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 28 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 = 7 M = 1 M = 2

29 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 29 –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&CABAB&CC V F V FF M = 2M = 3M = 4 NOMBRE CYCLOMATIQUE (2/3)

30 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 30 DO WHILE DO UNTIL 4 32 1 5 1 4 5 2,3,4 1 23 4 1 2,3,2 4 2 M = 2 NOMBRE CYCLOMATIQUE (3/3) 1 seul test pour les 2 chemins 2 tests pour les 2 chemins

31 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 31 NOMBRE CYCLOMATIQUE ET EFFORT DE TEST Début Bloc N°1 Bloc N°2 Bloc N°3 Bloc N°4 Bloc N°5 Fin M=1 Début Bloc N°1Bloc N°2Bloc N°3Bloc N°4Bloc N°5 Fin M=5  Bien que les nombres cyclomatiques soient très différents, l’effort de test est quasiment le même !!!

32 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 32 COUVERTURES DÉTERMINENT LES DIFFÉRENTES FAÇONS DE PARCOURIR LE GRAPHE DE CONTROLE –TOUS LES NOEUDS:C0 –TOUS LES ARCS:C1 –TOUS LES CHEMINS: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

33 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 33 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

34 ©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 (1/2) Exemple :  Il faut passer plusieurs fois dans la même branche avec des valeurs différentes pour détecter l’erreur

35 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 35 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 :  a 2 + a×b + a + b  a× (a + b + 1) + b

36 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 36 Annexe et complément sur la programmation en vue des tests : STRUCTURE ET ORGANISATION DES PROGRAMMES EN VUE DES TESTS

37 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 37 MODÈLE DE COMPOSANT Pré-conditions Post-conditions Code fonctionnel nominal Exceptions et/ou défaillances programmées et/ou inopinées    Autocontrôles DEDE DSDS État initial État final Événements entrants Événements sortants Composante transformationnelle Composante réactive PARTIE VISIBLE PARTIE CACHÉE

38 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 38 Caractéristiques et classes de programmes T = Transformationnel ; R = Réactif

39 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 39 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

40 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 40 PROGRAMMES TRANSFORMATIONNELS (2/3) PROGRAMME P Mémoire vue par P Zone Tampon (interface avec le 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. 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. Appels directs aux fonctions du SE Recueille et traite tous les événements et les interactions avec l'extérieur (sous contrôle du SE) RESSOURCES (gérées par le SE) SYSTEME D'EXPLOITATION

41 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 41 PROGRAMMES TRANSFORMATIONNELS (3/3) Mémoire non persistante statique Mémoire non persistante dynamique Mémoire persistante Algorithmes de la transformation Données de la transformation SPHÈRE DE CONTRÔLE DU PROGRAMME SPHÈRE DE CONTRÔLE DU SYSTÈME D’EXPLOITATION Via SGF et/ou SGBD

42 ©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 (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)

43 ©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 (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)

44 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 44 M1,3 M1,2 M1,1 Tâche T3 PROGRAMMES RÉACTIFS (3/4) 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. M1,3 M1,2 M1,1 Tâche T2 M1,3 M1,2 M1,1 Tâche T1 Zone de communication entre tâches RESSOURCES (gérées par le SE) SYSTEME D'EXPLOITATION Différents moniteurs Dispatching des événements selon les moniteurs Contenu de la zone de communications : Files d’attentes de messages à dispatcher, Tables de verrouillage de ressources, Sémaphores de synchronisation, etc. Ordonnancement des taches selon les priorités et les contraintes temporelles La cohérence entre le système d'exploitation et les moniteurs doit être soigneusement validée et vérifiée.

45 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 45 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) Séquence quelconque d’instructions des autres tâches, des moniteurs, du système d ’exploitation 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 !!!

46 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 46 TEST DE PROGRAMMES RÉACTIFS Exemple de la gestion de ressources logicielles

47 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 47 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

48 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 48 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.

49 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 49 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

50 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 50 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.

51 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 51 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)

52 ©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 (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

53 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 53 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 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.

54 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 54 Pipeline de ressources (3/3) T Fin 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  T E Programme système d'analyse des résidus de la terminaison Séquences d'ordres complémentaires implicites relâchant le reliquat de ressources non encore libérées  Durée d'exécution  T I Application A  Exemple de terminaison d’une application

55 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 55 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

56 ©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 56 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