VALIDATION VERIFICATION TESTS

1. VALIDATION VERIFICATION TESTS TESTS BOITES NOIRES et TESTS BOITES BLANCHES    STRUCTURE ET ORGANISATION DES PROGRAMMES EN VUE DES TESTS

2. TESTS BOITES NOIRES et TESTS BOITES BLANCHES

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. 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. Éléments visibles du composant (1/2) Canal d'intrusion Pvisu • 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 Elément ou Composant à Tester État initial État final DE DS Données Code Contrôle • DOMAINE ENTRÉE / LECTURE • initialisation avec une combinaison valide des données d'entrée • TRACES • États intermédiaires résultant de l'instrumentation Traces Canal d'observation

6. Éléments visibles du composant (2/2) 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 Pvisu Agents d'intrusion Données Code DE 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 post-conditions, etc.) Agents d'observation Traces Canal d'observation Table des états intermédiaires observables (i.e. « histoire » de la transformation)

7. États observables d’un programme :États programmes / états données Elément ou Composant à Tester État initial État final DE DS Données Code Contrôle État des données sous contrôle de P État programme • L’étatprogramme à 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

8. 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

9. TESTS BOITES BLANCHES (1/2) • ON PREND EN COMPTE DE DSET 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. 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

11. STRUCTURE ET ORGANISATION DES PROGRAMMES EN VUE DE LEUR CONSTRUCTION

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. 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 : 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. 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. REPRÉSENTATIONS ET PROPRIÉTÉS ÉLÉMENTAIRES DE LA BOÎTE BLANCHE

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. 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. 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. 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. 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. 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. 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. 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.

24. Définition du nombre cyclomatique(3/4) • Exemple    V(G) = 3 (donc 2 décisions)

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. APPLICATION : SÉLECTION ET DESCRIPTION DE CHEMINS a b c d e 4 6 1 3 5 2 OUI OUI DEBUT FIN NON NON i h g f l k j 9 7 10 8 OUI NON OUI m NON • CHEMINS DÉCISIONS LIENS • 4 6 7 9 a b c d e f g h i j k l m • abcde OUI OUI - - - - - • abhkgde NON OUI NON - - - - - - - • abhlibcde NON,OUI OUI OUI - - - - - - - - • abcdfjgde OUI NON,OUI OUI - - - - - - - - • abcdfmibcde OUI NON,OUI NON - - - - - - - -

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. 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

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 NOMBRE CYCLOMATIQUE (2/3) A&B&C A B&C A B C V V F F F M = 2 M = 3 M = 4

30. NOMBRE CYCLOMATIQUE (3/3) M = 2 DO WHILE 1 1 3 2 4 2,3,4 4 5 5 1 seul test pour les 2 chemins 2 tests pour les 2 chemins DO UNTIL 1 1 3 2 2 2,3,2 4 4

31. NOMBRE CYCLOMATIQUE ET EFFORT DE TEST M=5 M=1 Début Début 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  Bien que les nombres cyclomatiques soient très différents, l’effort de test est quasiment le même !!! Fin

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. 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. 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. DÉFAUTS SÉMANTIQUES POTENTIELLEMENT INDÉCELABLES PAR COUVERTURE SIMPLE (2/2) Erreur décelable par ajout de redondance Calcul de l’expression Comparaison des résultats Vrai Faux Calcul d’une expression sémantiquement équivalente (test en ligne) Auto diagnostique • Par exemple : • a2 + a×b + a + b • a× (a + b + 1) + b

36. Annexe et complément sur la programmation en vue des tests :STRUCTURE ET ORGANISATION DES PROGRAMMES EN VUE DES TESTS

37. MODÈLE DE COMPOSANT Composante transformationnelle Code fonctionnel nominal PARTIE VISIBLE État initial État final DE DS Post-conditions Pré-conditions Exceptions et/ou défaillances programmées et/ou inopinées    Autocontrôles Événements sortants Événements entrants PARTIE CACHÉE Composante réactive

38. Caractéristiques et classes de programmes • T = Transformationnel ; R = Réactif

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. 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. PROGRAMMEP Mémoire vue par P • 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. Appels directs aux fonctions du SE ZoneTampon(interface avec le SE) SYSTEME D'EXPLOITATION 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)

41. PROGRAMMES TRANSFORMATIONNELS (3/3) Données de la transformation SPHÈRE DE CONTRÔLE DU PROGRAMME Mémoire non persistante statique SPHÈRE DE CONTRÔLE DU SYSTÈME D’EXPLOITATION Mémoire non persistante dynamique Algorithmes de la transformation Mémoire persistante Via SGF et/ou SGBD

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. 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. M1,3 M1,3 M1,3 Tâche T3 Tâche T1 Tâche T2 M1,2 M1,2 M1,2 M1,1 M1,1 M1,1 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. • Contenu de la zone de communications : • Files d’attentes de messages à dispatcher, • Tables de verrouillage de ressources, • Sémaphores de synchronisation, etc. Zone de communication entre tâches La cohérence entre le système d'exploitation et les moniteurs doit être soigneusement validée et vérifiée. Différents moniteurs Ordonnancement des taches selon les priorités et les contraintes temporelles SYSTEME D'EXPLOITATION RESSOURCES (gérées par le SE) Dispatching des événements selon les moniteurs

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) Flot de la tâche T1  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 Durée t quelconque •••

46. TEST DE PROGRAMMES RÉACTIFS Exemple de la gestion de ressources logicielles

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. 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. 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. 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.