Test de Systèmes Informatiques

Test de Systèmes Informatiques Première partie : Introduction au sujet Deuxième partie : concepts et problèmes Troisième partie : approches formelles, 2 exemples septembre 2011 Test de Systèmes Informatiques 1

Qu est-ce-que le test en Informatique? «We know less about the theory of testing, which we do often, than about the theory of program proving, which we do seldom» Goodenough J. B., Gerhart S., IEEE Transactions on Software Engineering, 1975 septembre 2011 Test de Systèmes Informatiques 2

En général Tester un système c'est : Provoquer son exécution dans des conditions bien définies et reproductibles Observer son comportement Décider si ce comportement est conforme aux spécifications Dans le but de trouver des fautes septembre 2011 Test de Systèmes Informatiques 3

Cas du logiciel : définitions Deux classes de méthodes Par examen de la spécification ou du programme : test statique Par exécution de tout ou partie du système obtenu après installation du logiciel : test dynamique Test dynamique : Choisir les données de test : jeu de tests Faire exécuter le système contre le jeu de tests Décider si le résultat est correct ou non : oracle Dans cette conférence, test dynamique septembre 2011 Test de Systèmes Informatiques 4

Les trois problèmes du test dynamique Sélection : d un jeu fini de tests parmi toutes les données possibles Soumission : par un contrôleur de test ( driver ), en utilisant si besoin des simulations, des modules fictifs ( stubs ) Décision ( oracle ) : le test soumis donne-til un résultat conforme à la spécification? septembre 2011 Test de Systèmes Informatiques 5

Instrumentation "driver" (ou contrôleur de test ou "mulet") oracle donnée de test résultat verdict composant sous test "stubs" (ou modules fictifs, ou "bouchons") septembre 2011 Test de Systèmes Informatiques 6

Sélection des tests Structurelle : basée sur la structure du programme Critères de couverture des instructions, des enchaînements, des chemins, des couples définitionsutilisations, Fonctionnelle : basée sur la spécification Couverture et composition des cas mentionnés dans la spécification Aléatoire ou statistique : tirage selon une distribution sur le domaine d entrée NB: l oracle est toujours basé sur la spécification septembre 2011 Test de Systèmes Informatiques 7

Sélection Structurelle/ Fonctionnelle Sélection basée uniquement sur la structure du programme Sélection basée uniquement sur la spécification résultats résultats Oracle basé sur la spécification C est une boîte noire! septembre 2011 Test de Systèmes Informatiques 8

Il faut faire les deux! Boite noire : permet de tester que tous les cas spécifiés sont traités correctement «On n a rien oublié» Structurel : permet de tester que tous les items couverts du programme satisfont la spécification «Tous les sous-cas introduits par la programmation sont corrects» septembre 2011 Test de Systèmes Informatiques 9

Base de la sélection structurelle : chemins et prédicats Graphe de contrôle Blocs élémentaires Enchaînements possibles Exécutions possibles => Chemins du graphe Condition d exécution d un chemin donné = prédicat sur les données obtenu par conjonction, négation éventuelle, et évaluation symbolique des conditions rencontrées lors de l exécution septembre 2011 Test de Systèmes Informatiques 10

Exemple : le bon vieux pgcd begin read(p, q) ; B1 r := p - p%q*q ; while r 0 do begin P1 p := q ; q:=r ; B2 r := p - p%q*q ; end ; write(q) ; B3 end B2 E B1 P1 B3 S septembre 2011 Test de Systèmes Informatiques 11

E Le pgcd, suite Chemins E B1 P1 (B2 P1)* B3 S Prédicats de chemins E B1 P1 B3 S : p 0 - p 0 %q 0 *q 0 = 0 (p 0 divisible par q 0 ) E B1 P1 B2 P1 B3 S : p 0 - p 0 %q 0 *q 0 0 p 1 = q 0 q 1 = p 0 - p 0 %q 0 *q 0 p 1 - p 1 %q 1 *q 1 = 0 ETC B2 Obtention d un test permettant d exécuter un chemin : on résout le prédicat du chemin B1 P1 B3 S septembre 2011 Test de Systèmes Informatiques 12

Problème avec les chemins et les prédicats Certains prédicats sont insatisfiables => le chemin correspondant est infaisable et ne peut pas être couvert par un test Il s agit de chemins du graphe de contrôle qui comportent des conditions contradictoires : if x > 0 then B1 else B2 ; {x reste inchangé} ; if x > 0 then B3 else B4 ; Il n existe pas de test permettant de couvrir ces chemins car il n existe pas de données permettant de les exécuter septembre 2011 Test de Systèmes Informatiques 13

Plus généralement : cas infaisables La satisfiabilité d un prédicat est un problème indécidable Face à une conjonction de cas dans un programme ou une spécification, on n a pas de méthode générale pour décider si on doit tester ce cas ou non. Mais heureusement on peut souvent restreindre la logique considérée Solution partielle : la résolution programmation logique et ses extensions, et/ou résolution de contraintes : CLP, SMT solvers) septembre 2011 Test de Systèmes Informatiques 14

Test «Boîte Noire» Basé sur une analyse de la spécification Spécification «comportementale» : critères de couverture similaires au test structurel Spécification par propriétés : décomposition (dépliage) Méthodes existantes et recherches : Comportements décrits par des automates/systèmes de transitions/machines à états Types de données décrits par des propriétés (axiomes, pré et post-conditions, invariants) On mélange les deux Approches probabilistes (marches aléatoires, etc) septembre 2011 Test de Systèmes Informatiques 15

Test de Systèmes Informatiques Première partie : Introduction au sujet Deuxième partie : concepts et problèmes Troisième partie : approches formelles, 2 exemples septembre 2011 Test de Systèmes Informatiques 16

Concepts et Problèmes On teste un système Ce n est pas un texte ou un diagramme : c est une entité dynamique Il faut savoir contrôler cette entité Il faut savoir l observer On cherche à provoquer des défaillances, i.e. des comportements non conformes à ce qu on attend input output septembre 2011 Test de Systèmes Informatiques 17

Digression sur le test et la preuve On teste un système, on fait la preuve d une formule La carte n'est pas le territoire Le texte du programme, ou de sa spécification, n est pas le système septembre 2011 Test de Systèmes Informatiques 18

Programme Tout le monde sait ce que c est J Un programme est un texte dans un langage bien défini Il y a une syntaxe, une (ou des) sémantiques, et des compilateurs A program is a very detailed solution to a much more abstract problem [Ball, 2005] {i=0 ; read(x); repeat { i++ ; perd(x, i); } until term(i,x) ; septembre 2011 Test de Systèmes Informatiques 19

A quoi sert un programme? Il peut être compilé puis intégré dans un système {i=0 ; read(x); repeat { i++ ; perd(x, i); } until term(i,x) ; output input septembre 2011 Test de Systèmes Informatiques 20

Preuve de Programme Program {i=0 ; read(x); repeat { i++ ; perd(x, i); } until term(i,x) ; + Assertions logiques Theorem Prover Vu comme une formule (par exemple, Le bon vieux {Pre} Prog {Post} ) Static Analyser Libraries axiomatisation Proof envt SAT solver septembre 2011 Test de Systèmes Informatiques 21

Qu est-ce qu une preuve? Théorie: Axiomes Règles d infèrence Formule ϕ Moteur de preuve + Stratégies Théorème: (oui/non/?) Finalement: un processus sophistiqué mais purement syntaxique. On manipule des textes septembre 2011 Test de Systèmes Informatiques 22

Intermède Program {i=0 ; read(x); repeat { i++ ; perd(x, i); } until term(i,x) ; + CORRECT! Assertions logiques septembre 2011 Test de Systèmes Informatiques 23

Retour au test Le système est exécuté sur des données sélectionnées NB: séquences de données pour les systèmes réactifs Ces exécutions sont observées, et une décision est prise sur leur conformité par rapport à un modèle ou une spécification Problèmes : Sélection Oracle Contrôle, non-déterminisme Evaluation du résultat d une campagne de test Données de test sélectionnées Oracle Résultats, observations défaillance/ résultat correct septembre 2011 Test de Systèmes Informatiques 24

Model-based testing Domaine très ancien (75 et avant) et très actif Il y a toute sorte de modèles (pourquoi pas J ) Toujours présente, mais pas toujours explicite : hypothèse de testabilité. Le système sous test se comporte comme un modèle (inconnu) de même nature que celui qui guide le test Origine [Chow 78] pour les FSM (machine avec nb. d états fini) [Bernot et al. 91] pour des spécifications algébriques septembre 2011 Test de Systèmes Informatiques 25

Test de Systèmes Informatiques Première partie : Introduction au sujet Deuxième partie : concepts et problèmes Troisième partie : approches formelles, 2 exemples : FSM, Spéc. algébriques septembre 2011 Test de Systèmes Informatiques 26

Le modèle est une FSM Système sous test inconnu, mais FSM equivalence? SUT output Hypothèse de testabilité pour cette approche : Le Système sous Test se comporte comme une FSM (inconnue) qui a le même nombre d états que la description input Autrement dit, dans le SUT, quelque soit le chemin d exécution suivi pour atteindre un état s, l exécution de la transition s x:y-> s a le même effet (même donnée =>même sortie + même changement d état) septembre 2011 Test de Systèmes Informatiques 27

Exemple: reconnaissance de commentaires *,φ: _ 1 2 3 4 /: _ /: _ φ = tout caractère sauf * et / : *: _ φ: φ /: _ φ: _ /: / φ: * φ *: _ ceci n est pas un commentaire /* tout ceci / * est un ** commentaire */ ceci n est plus un commentaire *: * Cette FSM supprime d un texte donné tout ce qui n est pas un commentaire septembre 2011 Test de Systèmes Informatiques 28

Finite State Machine S: ensemble fini d états, I: alphabet d entrée, O: alphabet de sortie T: ensemble fini de transitions: s x:y-> s' T, s, s' S, x I, y O λ(s,x)=y, λ*(s,w)=w', w I*, w' O* Etats équivalents : w, λ*(s,w) = λ*(s',w) Ici, on considère des FSM : déterministes, complètes ( s S, x I, s x:y-> s' T), minimales (pas d états équivalents), et tous les états sont atteignables septembre 2011 Test de Systèmes Informatiques 29

Un des tests de s -x/y-> s? homing sequence h I* => answ O*: alors l état du SUT doit être équivalent à s s. OU reset h/answ s s préambule w/λ*(s s,w) w I*: et dans la FSM, w mène de s s à s. s x/y septembre 2011 Test de Systèmes Informatiques 30? exécution de la transition z/λ*(s, z) z est une des chaînes qui permettent de reconnaître s observation

Un des tests du préambule de s -x/y-> s? homing sequence h I* => answ O*: alors l état du SUT doit être équivalent à s s. Ou reset h/answ s s préambule w I*: dans la FSM, w mène de s s à s. w/λ*(s s,w)? z/λ*(s, z) z est une une des chaînes Qui permettent de de reconnaître s observation : on est dans l état requis septembre 2011 Test de Systèmes Informatiques 31

Exemple: la W method Théorème: toute telle FSM a un ensemble caractérisant W= {w 1,, w m } I +, qui permet de distinguer les états s s' w W tel que λ*(s,w) λ*(s',w) Séquences de test : p.z, avec p P, z Z P: pour toute transition s x:y-> s, il y a deux séquences de P, p et p.x, telles que p mène de l état initial à s Z = W i.e., couverture des transitions, avec observation des états d origine et de destination septembre 2011 Test de Systèmes Informatiques 32

L exemple de nouveau /: _ 1 2 3 4 /: _ *,φ: _ φ: _ /: / φ: * φ *: _ Ensemble caractérisant : {*φ} *: _ /: _ φ: φ *: * état *φ 1 _ 2 φ 3 *φ 4 **φ septembre 2011 Test de Systèmes Informatiques 33

Construction de P * 1 1 2 * 4 3 3 4 3 1 φ φ 1 / * φ 3 1 2 / septembre 2011 Test de Systèmes Informatiques 34 / Arbre qui couvre toutes les transitions la racine est l état initial les fils d un noeud sont les états atteignables à partir de ce noeud si un état est déjà dans l arbre il est terminal

Construction de P : algorithme On construit un arbre de test dont les nœuds sont étiquetés par les états, et les arcs par des données La racine de l'arbre est étiqueté par l'état initial (niveau 1 de l'arbre) Le niveau k+1 de l'arbre est obtenu en examinant les nœuds du niveau k de gauche à droite. Un nœud de niveau k étiqueté par l'état s est terminal si s apparaît déjà dans un nœud non terminal à un niveau j k. Sinon, si il existe une transition s x:y-> s', on attache à ce nœud un arc étiqueté par x, dont le nœud extremité est étiqueté par s' septembre 2011 Test de Systèmes Informatiques 35

Tableau des tests et résultats attendus *φ rien /*/*φ /*φ **φ rien /*φ*φ φ*φ état *φ 1 _ 2 φ 3 *φ 4 **φ φ*φ /*φ rien φ /***φ **φ /****φ ***φ * / φ 1 1 2 / //*φ φ /**φ*φ *φ*φ * φ 3 1 2 /φ*φ rien /**/*φ rien * φ / /**φ *φ 4 3 3 4 3 1 septembre 2011 Test de Systèmes Informatiques 36

Complétude de P.Z Soit A, B, deux FSM avec mêmes I et O ; Soit V I*; s A est un état de A, s B est un état de B; s A et s B sont V-équivalents ssi w V, λ*(s A,w) = λ*(s B,w) A et B sont V-équivalents : leurs états initiaux sont V-équivalents Théorème de Chow : soit A et B avec le même nb d états, et mêmes I et O A et B équivalents A et B P.Z équivalents septembre 2011 Test de Systèmes Informatiques 37

Analyse de cette stratégie de test On a fait mieux depuis : élimination des sous-séquences redondantes (préfixes) ; classes de FSM plus facilement observables ; nombre d états n. Le critère est la couverture des transitions : on vérifie qu'on part bien de l'état de départ et qu'on arrive bien à l'état d'arrivée. On fait des hypothèses fortes sur l'implémentation sous test : voir page suivante Dans la présentation de l'exemple, hypothèse d'uniformité sur les caractères de * et / : en fait φ est une classe d'équivalence au niveau de la spécification septembre 2011 Test de Systèmes Informatiques 38

Hypothèses sur l implémentation Elle se comporte comme une FSM, i.e. elle n'a pas de mémoire quelque soit p qui mène la FSM de l'état initial à l'état s i, la transition s i x:y-> s j, est exécutée de la même manière Elle se comporte comme une FSM déterministe à n états on sait se mettre dans l'état initial (procédure de reset correcte et pas trop coûteuse) septembre 2011 Test de Systèmes Informatiques 39

Test de Systèmes Informatiques Première partie : Introduction au sujet Deuxième partie : concepts et problèmes Troisième partie : approches formelles, 2 exemples : FSM, Spéc. algébriques septembre 2011 Test de Systèmes Informatiques 40

Test boîte noire basé sur des spécifications formelles relation de satisfaction : SUT sat SP Qu est-ce que cela veut dire qu un système satisfait une spécification? C est beaucoup plus difficile à définir qu il n y paraît et l équivalence n est certainement pas adéquate On dérive de sat les notions : test, expérience de test, et verdict (oracle): SUT passe T (où T est un Jeu de Test) septembre 2011 Test de Systèmes Informatiques 41

Hypothèses, exhaustivité Définition du Jeu de Test Exhaustif d'une spécification, et de l Hypothèse de Testabilité des systèmes : SUT testable => (SUT passe exhaust(sp) <=> SUT sat SP) Le jeu de test exhaustif sert ensuite de référence pour la sélection d un jeu de test fini septembre 2011 Test de Systèmes Informatiques 42

Sélection (test exhaustif souvent infini ou trop grand) Hypothèses de Sélection H, sur SUT, et construction de jeux de test finis T tels que : H valide pour SUT =>(SUT passe T <=> SUT sat SP) <H, T> est un contexte de test valide et non biaisé La spécification sert de point de départ pour le choix des hypothèses et la construction des tests septembre 2011 Test de Systèmes Informatiques 43

Exemple de Spécifications Spécifications algébriques des types de données, Ax Signature = <S, OP> : noms d ensembles de valeurs, et opérations ou prédicats sur ces ensembles Axiomes Ax : propriétés des opérations x + 0 = x x + s(y) = s(x+y) x + y = y + x septembre 2011 Test de Systèmes Informatiques 44

«Types are Algebras» Algèbres : des ensembles et des opérations sur ces ensembles pile vide empiler Les entiers Les piles dépiler sommet Attention, il n y a pas de notion de modification d état «empiler(p,n)» construit une nouvelle valeur du type Pile à partir de la valeur p et de n «dépiler(p)» aussi septembre 2011 Test de Systèmes Informatiques 45

Exemple : Stack spec STACK [ sort Elem] = sort Stack généricité ops empty : Stack push : Stack x Elem -> Stack pop : Stack ->?Stack top : Stack ->?Elem e : Elem ; S : Stack def top(empty) top(push(s, e)) = e def pop(empty) pop(push(s, e)) = S end opérations partielles prédicats de définition septembre 2011 Test de Systèmes Informatiques 46

Rappel Test «boîte noire», ou fonctionnel On se base uniquement sur les spécifications pour sélectionner des tests On se sert également de la spécification comme «oracle» (décision du succès ou de l échec d un test) Mais problèmes dus aux niveaux d abstraction et à l observabilité septembre 2011 Test de Systèmes Informatiques 47

Particularités du test basé sur des spécifications logiques On ne veut pas vérifier des couples <données, résultat> On veut vérifier que les opérations implémentées par le système satisfont les axiomes Exemple spec SPmin = NATURAL-ARITHMETIC then op min3 : Nat x Nat x Nat -> Nat X, Y, Z : Nat X Y X Z => min3 (X, Y, Z) = X Y X Y Z => min3 (X, Y, Z) = Y Z X Z Y => min3 (X, Y, Z) = Z end septembre 2011 Test de Systèmes Informatiques 48

Qu est-ce qu un test? Le SUT fournit des procédures ou des fonctions pour exécuter les opérations de SP (exemple : classe Java, paquetage Ada, structure ML ) op est implémentée par op SUT Etant donné un -terme clos t, on note t SUT le résultat de son calcul par SUT Soit ε une SP -équation test de ε : toute instanciation close t = t' de ε expérience de test de P contre t = t' : évaluations de t SUT et t SUT et comparaison des valeurs résultats NB : oracle test de l'égalité Ces définitions se généralisent facilement à d autres axiomes septembre 2011 Test de Systèmes Informatiques 49

Retour à l exemple Test basé sur : X Y X Z => min3 (X, Y, Z) = X t1 t2 t1 t3 => min3 (t1, t2, t3) = t1, où t1, t2, t3 sont des termes clos, de sorte Nat, quelconques Une expérience de test Exécution : évaluation de t1 SUT SUT t2 SUT, t1 SUT SUT t3 SUT, min3 SUT (t1 SUT, t2 SUT, t3 SUT ), t1 SUT Oracle :si le premier résultat est vrai, et le second aussi, alors le troisième et le quatrième doivent être identiques NB : Les termes qui ne satisfont pas les prémisses donnent des tests inintéressants On a ainsi tous les éléments pour construire un programme de test septembre 2011 Test de Systèmes Informatiques 50

Jeu de test exhaustif Soit une spécification SP = (, Ax), le jeu de test exhaustif de SP, noté Exhaust SP est l'ensemble de toutes les instances closes bien typées de tous les axiomes de SP: Exhaust SP = {Φσ Φ Ax, σ = {σ s : var(φ) s (T ) s s S} } NB1 : définition derivée de la notion classique de satisfaction d'un axiome par un -modèle NB2 : on n a pas forcément d oracle «fini» pour toutes les formes d axiomes (, ) ; certains tests sont inconclusifs et peuvent être supprimés NB3 : Exhaust SP est exhaustif par rapport à la spécification, pas toujours par rapport au programme septembre 2011 Test de Systèmes Informatiques 51

Hypothèse de testabilité Inévitable : quand on teste un système, on est obligé de faire des hypothèses sur son comportement et son environnement Ici SUT est -testable si : il définit un «- modèle M SUT finiment engendré par rapport à», c est-à-dire Les opérations sont déterministes Toutes les valeurs sont spécifiées (pas de «junks») Notation : H min septembre 2011 Test de Systèmes Informatiques 52

Test et correction On note SUT = Exhaust SP le fait que SUT passe tous les tests de Exhaust SP avec succès On a H min => (M SUT = Ax <=> SUT = Exhaust SP ) Autrement dit, sous l hypothèse de testabilité, le succès du test exhaustif garantit la correction de SUT par rapport à SP Mais comment sélectionner des sous-ensembles finis de Exhaust SP? septembre 2011 Test de Systèmes Informatiques 53

Sélection et Hypothèses On fait des hypothèses PLUS FORTES sur SUT Exemple : Hypothèse d'uniformité Φ(X) formule, SUT système, D sous-domaine ( t 0 D)( SUT = Φ(t 0 ) ( t D) (SUT = Φ(t))) Détermination des sous-domaines? guidée par la spécification, à suivre Autre exemple : Hypothèse de Régularité (( t T ) ( t k SUT = Φ(t) )) ( t T ) (SUT = Φ(t)) Détermination de t? cf. spécification septembre 2011 Test de Systèmes Informatiques 54

Le choix des hypothèses? <SUT testable, Exhaust SP > <Hyp. Faible, Gros Jeu detest > <Hyp. Forte, Petit JT> <SUT correct, Ø> septembre 2011 Test de Systèmes Informatiques 55

Une Méthode Point de départ : couverture des axiomes (un test par axiome) => hypothèses d uniformité fortes sur les sortes des variables ou sur le domaine de validité des prémisses Exemple : 3 cas de test pour SPmin X Y X Z => min3 (X, Y, Z) = X Y X Y Z => min3 (X, Y, Z) = Y Z X Z Y => min3 (X, Y, Z) = Z 3 sous-domaines d uniformité septembre 2011 Test de Systèmes Informatiques 56

Affaiblissement des hypothèses Affaiblissements successifs par utilisation des axiomes de la spécification L exemple, intuitivement : correspond à deux sous-cas, < ou = on le décompose dans les cas de test X Y X Z => min3 (X, Y, Z) = X devient X=Y X=Z => min3 (X, Y, Z) = X X=Y X<Z => min3 (X, Y, Z) = X X<Y X=Z => min3 (X, Y, Z) = X X<Y X=Z => min3 (X, Y, Z) = X Le domaine X Y X Z a été décomposé en 4 sous-domaines En tout on a 12 cas de test septembre 2011 Test de Systèmes Informatiques 57

Un exemple plus complexe spec LIST-NAT-WITH-SORT = NATURAL-ARITHMETIC then generated type List ::= empty cons(nat ; List) pred sorted : List ; x, y : Nat ; z : List sorted(empty) sorted (cons(x, empty)) sorted (cons(x, cons(y, z)) <=> x y sorted(cons(y, z)) end couverture des axiomes (exemple) sorted(empty) doit être vrai sorted (cons(23, empty)) doit être vrai sorted (cons(151, cons(55, )) et 151 255 sorted(cons(255, ) doivent donner le même résultat septembre 2011 Test de Systèmes Informatiques 58

Affaiblissement de l hypothèse d uniformité pour le 3e axiome On va utiliser la table de vérité de de true true <=> true on obtient : A B sorted(cons(b, L)) => sorted(cons(a, cons(b, L)) de true false <=> false on obtient : A B sorted(cons(b, L)) => sorted(cons(a, cons(b, L)) de false true <=> false on obtient : (A B) sorted(cons(b, L)) => sorted(cons(a, cons(b, L)) de false false <=> false on obtient : (A B) sorted(cons(b, L)) => sorted(cons(a, cons(b, L)) On a alors 4 cas de test pour le 3e axiome on peut tester encore plus septembre 2011 Test de Systèmes Informatiques 59

On décompose Les deux premiers cas deviennent 4 A B sorted(cons(b, L)) => sorted(cons(a, cons(b, L)) devient A=B sorted(cons(b, L)) => sorted(cons(a, cons(b, L)) A<B sorted(cons(b, L)) => sorted(cons(a, cons(b, L)) et A B sorted(cons(b, L)) => sorted(cons(a, cons (B, L)) devient A=B sorted(cons(b, L)) => sorted(cons(a, cons(b, L)) A<B sorted(cons(b, L)) => sorted(cons(a, cons(b, L)) On a 6 cas pour le 3e axiome ; on teste les cas «aux limites» On peut encore tester plus en «dépliant» sorted septembre 2011 Test de Systèmes Informatiques 60

Dépliage Dépliage: une technique classique pour transformer (et comprendre) les définitions recursives Remplacement de f(op(x)) par la définition de f, avec remplacement adéquat des variables fact(n) = def if n=0 then 1 else n*f(n-1) devient : fact(n) = def if n=0 then 1 else if (n-1)=0 then n*1 else n*(n-1)*f(n-2) etc i.e. fact(n) = def if n=0 then 1 else if n=1 then 1 else n*(n-1)*f(n-2) NB : on remplace la définition de la fonction fact par son graphe, i.e. son test exhaustif septembre 2011 Test de Systèmes Informatiques 61

Retour au premier des 6 cas de tests A=B sorted(cons(b, L)) => sorted(cons(a, cons(b, L)) Sachant que sorted (cons(x, cons(y, z)) <=> x y sorted(cons(y, z)) On déplie la première instance de sorted : B -> A L -> cons(b, L ) sorted(cons(b, L)) devient sorted(cons(a, cons(b, L ))) qui devient A B sorted(cons(b, L )) A=A A B sorted(cons(b, L )) => sorted(cons(a, cons(a, cons(b, L )))) On peut continuer ainsi, en décomposant et en dépliant sorted jusqu à le Jeu de Test Exhaustif Pas tout à fait : des variables demeurent septembre 2011 Test de Systèmes Informatiques 62

Quand et comment s arrêter En fonction du contexte (risque, coût, délais), on décide pour chaque spécification : Quels prédicats décomposer Quelles opération déplier et combien de fois (rarement plus d une fois) Une bonne stratégie standard : composer tous les sous-cas deux à deux NB : on peut avoir des compositions de sous-cas infaisables Implémentation dans le cas d axiomes positifs conditionnels : surréduction (unification + réécriture) septembre 2011 Test de Systèmes Informatiques 63

Le problème de l oracle décider de l'égalité de t SUT et t SUT Le cas simple : la sorte s de t et t' correspond à un type du langage de programmation (sorte observable) ou on teste un prédicat Hypothèse d oracle faible : l égalité sur les types du langage et les booléens sont implémentés correctement septembre 2011 Test de Systèmes Informatiques 64

Les autres cas Comment tester que pop(push(s, X)) = S? Solution : les contextes observables Exemples top(_), top(pop(_)), top(push(pop(_), e)) Pour tout contexte observable minimal C, on teste : C(pop(push(S, X))) = C(S) septembre 2011 Test de Systèmes Informatiques 65

Le jeu de test exhaustif observable OC [s] : ensemble des contextes observables (minimaux) sur s pour la signature S o sous-ensemble des sortes observables Les axiomes dans Ax sont positifs conditionnels et les équations dans les préconditions sont de sorte observable(*), Soit L t = u Exhaust SP, avec t et u de sorte s S o, on teste L C(t) = C(u) pour tout C OC [s] Si t et u de sorte s S o, on teste L t = u (*) sinon il y a risque de biais lorsqu'on sélectionne On sélectionne, septembre 2011 Test de Systèmes Informatiques 66

Tous les contextes sont nécessaires pour certaines fautes! proc empty_stack() ; stack.h := 0 ; stack.foo := 2 ; end empty_stack ; proc push(x: natural) ; stack.a[stack.h] := x ; stack.h := stack.h +1 ; stack.foo := stack.foo+1; end push ; proc pop() ; if stack.h > 0 then stack.h := stack.h - 1 ; stack.foo := 0 ; end if ; end pop ; proc top() ; if stack.foo = 1 then return stack.h ; --!!! elseif stack.h > 0 then return stack.a[stack.h] ; end if ; end top ; /* Exemple dû à Gilles Bernot septembre 2011 Test de Systèmes Informatiques 67

Souvenez-vous : Il faut faire aussi du test structurel! On trouve la faute en couvrant toutes les branches de top septembre 2011 Test de Systèmes Informatiques 68

Pour en savoir plus T.S. Chow. Testing software design modeled by finite-state machines. IEEE Transactions on Software Engineering, SE-4(3):178 187, 1978. G. Bernot, M.-C. Gaudel, B. Marre, Software Testing based on Formal Specifications : a theory and a tool, Software Engineering Journal, 6(6), Nov. 1991. M.-C. Gaudel, Testing can be formal too, LNCSn 915, Springer-Verlag, pp. 82-96, 1995. M.-C. Gaudel and P. Le Gall. Testing data types implementations from algebraic specifications. LNCS n 4949, Springer-Verlag, 2007. pp. 209-239. Marie-Claude Gaudel. Checking models, proving programs, and testing systems. LNCS n 6706, pp. 1-13. Springer-Verlag, 2011. See also http://www.lri.fr/~mcg/pubs/mcg.html septembre 2011 Test de Systèmes Informatiques 69