test de systèmes · pdf fileseptembre 2011! test de systèmes informatiques! 2!...
TRANSCRIPT
septembre 2011 Test de Systèmes Informatiques 1
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 2
Qu’est-ce-que le test en Informatique? n « 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 3
En général n Tester un système c'est :
n Provoquer son exécution dans des conditions bien définies et reproductibles
n Observer son comportement n Décider si ce comportement est conforme aux
spécifications n Dans le but de trouver des fautes
septembre 2011 Test de Systèmes Informatiques 4
Cas du logiciel : définitions n Deux classes de méthodes
n Par examen de la spécification ou du programme : test statique
n Par exécution de tout ou partie du système obtenu après installation du logiciel : test dynamique
n Test dynamique : n Choisir les données de test : “jeu de tests” n Faire exécuter le système “contre” le jeu de tests n Décider si le résultat est correct ou non : “oracle”
n Dans cette conférence, test dynamique
septembre 2011 Test de Systèmes Informatiques 5
Les trois problèmes du test dynamique
n Sélection : d’un jeu fini de tests parmi toutes les données possibles
n Soumission : par un contrôleur de test (“driver”), en utilisant si besoin des simulations, des modules fictifs (“stubs”)
n Décision (“oracle”) : le test soumis donne-t-il un résultat conforme à la spécification?
septembre 2011 Test de Systèmes Informatiques 6
composant sous test
"driver" (ou contrôleur de test
ou "mulet") oracle
donnée de test résultat verdict
… "stubs" (ou modules fictifs, ou
"bouchons")
Instrumentation
septembre 2011 Test de Systèmes Informatiques 7
Sélection des tests n Structurelle : basée sur la structure du programme
n Critères de couverture des instructions, des enchaînements, des chemins, des couples définitions-utilisations, …
n Fonctionnelle : basée sur la spécification n Couverture et composition des cas mentionnés dans la
spécification n Aléatoire ou statistique : tirage selon une
distribution sur le domaine d’entrée n NB: l’oracle est toujours basé sur la spécification
septembre 2011 Test de Systèmes Informatiques 8
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!
Il faut faire les deux! n Boite noire : permet de tester que tous les
cas spécifiés sont traités correctement n « On n’a rien oublié »
n Structurel : permet de tester que tous les items couverts du programme satisfont la spécification n « Tous les sous-cas introduits par la
programmation sont corrects »
septembre 2011 Test de Systèmes Informatiques 9
septembre 2011 Test de Systèmes Informatiques 10
Base de la sélection structurelle : chemins et prédicats n Graphe de contrôle
n Blocs élémentaires n Enchaînements possibles
n Exécutions possibles => Chemins du graphe n Condition d’exécution d’un chemin donné =
prédicat sur les données n obtenu par
n conjonction, n négation éventuelle, n et évaluation symbolique des conditions rencontrées lors de
l’exécution
septembre 2011 Test de Systèmes Informatiques 11
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
E
B1
P1
B2
B3
S
septembre 2011 Test de Systèmes Informatiques 12
Le pgcd, suite n Chemins
n E B1 P1 (B2 P1)* B3 S n Prédicats de chemins
n E B1 P1 B3 S : p0- p0%q0*q0 = 0 (p0 divisible par q0) n E B1 P1 B2 P1 B3 S :
n p0- p0%q0*q0 ≠ 0 n ∧ p1 = q0 ∧ q1 = p0- p0%q0*q0 ∧ p1- p1%q1*q1 = 0
n ETC n Obtention d’un test permettant d’exécuter un chemin : on
résout le prédicat du chemin
E
B1
P1
B2
B3
S
septembre 2011 Test de Systèmes Informatiques 13
Problème avec les chemins et les prédicats n Certains prédicats sont insatisfiables => le chemin
correspondant est infaisable et ne peut pas être couvert par un test
n 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 ; …
n 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 14
Plus généralement : cas infaisables n La satisfiabilité d’un prédicat est un problème
indécidable… n 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.
n Mais heureusement on peut souvent restreindre la logique considérée
n Solution partielle : la résolution n programmation logique et ses extensions, et/ou
résolution de contraintes : CLP, SMT solvers)
septembre 2011 Test de Systèmes Informatiques 15
Test « Boîte Noire » n Basé sur une analyse de la spécification
n Spécification « comportementale » : critères de couverture similaires au test structurel
n Spécification par propriétés : décomposition (dépliage) n Méthodes existantes et recherches :
n Comportements décrits par des automates/systèmes de transitions/machines à états
n Types de données décrits par des propriétés (axiomes, pré et post-conditions, invariants)
n On mélange les deux n Approches probabilistes (marches aléatoires, etc)
septembre 2011 Test de Systèmes Informatiques 16
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 17
Concepts et Problèmes n On teste un système n Ce n’est pas un texte ou
un diagramme : c’est une entité dynamique
n Il faut savoir contrôler cette entité
n Il faut savoir l’observer n 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 18
Digression sur le test et la preuve n On teste un système, on fait la preuve d’une
formule
n Le texte du programme, ou de sa spécification, n’est pas le système
“La carte n'est pas le territoire”
Programme
septembre 2011 Test de Systèmes Informatiques 19
n Tout le monde sait ce que c’est J n Un programme est un texte dans un
langage bien défini n Il y a une syntaxe, une (ou des)
sémantiques, et des compilateurs
n “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 20
A quoi sert un programme ?
n Il peut être compilé puis intégré dans un système…
{i=0 ; read(x); repeat { i++ ; perd(x, i); } until term(i,x) ; …
input
output
septembre 2011 Test de Systèmes Informatiques 21
Preuve de Programme
{i=0 ; read(x); repeat { i++ ; perd(x, i); } until term(i,x) ; …
Program
Assertions logiques
+
Vu comme une formule (par exemple, Le bon vieux {Pre} Prog {Post} )
Proof envt
Static Analyser SAT
solver
Theorem Prover
Libraries axiomatisation
septembre 2011 Test de Systèmes Informatiques 22
Qu’est-ce qu’une preuve ?
Formule ϕ
Théorie: Axiomes
Règles d’infèrence
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 23
Intermède
{i=0 ; read(x); repeat { i++ ; perd(x, i); } until term(i,x) ; …
Program
Assertions logiques
+ CORRECT!
septembre 2011 Test de Systèmes Informatiques 24
Retour au test
Données de test sélectionnées
n Le système est exécuté sur des données sélectionnées n NB: séquences de données pour
les systèmes réactifs n Ces exécutions sont observées,
et une décision est prise sur leur conformité par rapport à un modèle ou une spécification
n Problèmes : n Sélection n Oracle n Contrôle, non-déterminisme n Evaluation du résultat d’une
campagne de test
Résultats, observations
Oracle
défaillance/ résultat correct
septembre 2011 Test de Systèmes Informatiques 25
“Model-based testing”
n Domaine très ancien (75 et avant) et très actif n Il y a toute sorte de modèles (pourquoi pas J)
n Toujours présente, mais pas toujours explicite : hypothèse de testabilité. n Le système sous test se comporte comme un modèle
(inconnu) de même nature que celui qui guide le test n Origine [Chow 78] pour les FSM (machine avec nb.
d’ états fini) n [Bernot et al. 91] pour des spécifications algébriques
septembre 2011 Test de Systèmes Informatiques 26
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 27
Le modèle est une FSM
n Système sous test n inconnu, mais…
n 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 n 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)
FSM
SUT
output
input
equivalence?
septembre 2011 Test de Systèmes Informatiques 28
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 29
Finite State Machine n S: ensemble fini d’états, I: alphabet d’entrée, O:
alphabet de sortie n T: ensemble fini de transitions:
n s –x:y-> s' ∈ T, s, s'∈S, x ∈I, y ∈O n λ(s,x)=y, λ*(s,w)=w', w ∈ I*, w' ∈ O*
n Etats équivalents : ∀w, λ*(s,w) = λ*(s',w) n 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 30
Un des tests de s -x/y-> s’
“homing sequence” h∈I* => answ ∈O*: alors l’état du SUT doit être équivalent à ss. OU “reset”
h/answ
ss
w/λ*(ss,w)
s
w ∈I*: et dans la FSM, w mène de ss à s.
préambule
x/y ?
exécution de la transition
z/λ*(s’, z)
z est une des chaînes qui permettent de reconnaître s’
observation
?
septembre 2011 Test de Systèmes Informatiques 31
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 à ss. Ou reset
h/answ ss
w/λ*(ss,w)
?
w ∈I*: dans la FSM, w mène de ss à s.
préambule
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 32
Exemple: la “W method” n Théorème: toute telle FSM a un ensemble
caractérisant W= {w1, …, wm} ⊆ I+, qui permet de distinguer les états n s≠s' ⇒ ∃w ∈ W tel que λ*(s,w)≠ λ*(s',w)
n Séquences de test : p.z, avec p ∈ P, z ∈ Z n 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
n Z = W n i.e., couverture des transitions, avec observation des
états d’origine et de destination
septembre 2011 Test de Systèmes Informatiques 33
L’exemple de nouveau
1 2 3 4
*,φ: _ /: _
/: _
*: _
φ: φ *: _
/: _
*: *
φ: _ /: / φ: * φ
Ensemble caractérisant : {*φ}
état *φ 1 _ 2 φ 3 *φ 4 **φ
septembre 2011 Test de Systèmes Informatiques 34
Construction de P 1
1 1 2
* φ
/
3 1 2
* φ
/
4 3 3
* φ
/
4 3 1
• 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
Arbre qui couvre toutes les transitions
septembre 2011 Test de Systèmes Informatiques 35
Construction de P : algorithme n On construit un “arbre de test” dont les nœuds sont
étiquetés par les états, et les arcs par des données n La racine de l'arbre est étiqueté par l'état initial (niveau 1
de l'arbre) n Le niveau k+1 de l'arbre est obtenu en examinant les
nœuds du niveau k de gauche à droite. n 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.
n 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 36
Tableau des tests et résultats attendus
*φ rien
**φ rien
φ*φ rien
/*φ φ
//*φ φ
/φ*φ rien
/**φ *φ
/*/*φ /*φ
/*φ*φ φ*φ
/***φ **φ
/****φ ***φ
/**φ*φ *φ*φ
/**/*φ rien
1
1 1 2
* φ
/
3 1 2
* φ
/
4 3 3
* φ
/
4 3 1
état *φ 1 _ 2 φ 3 *φ 4 **φ
septembre 2011 Test de Systèmes Informatiques 37
Complétude de P.Z n Soit A, B, deux FSM avec mêmes I et O ;
n Soit V ⊆ I*; n sA est un état de A, sB est un état de B; n sA et sB sont V-équivalents ssi n ∀w ∈ V, λ*(sA,w) = λ*(sB,w)
n A et B sont V-équivalents : leurs états initiaux sont V-équivalents
n Théorème de Chow : soit A et B avec le même nb d’états, et mêmes I et O n A et B équivalents ⇔ A et B P.Z équivalents
septembre 2011 Test de Systèmes Informatiques 38
Analyse de cette stratégie de test n On a fait mieux depuis : élimination des sous-séquences
redondantes (préfixes) ; classes de FSM plus facilement observables ; nombre d’états ≥ n.
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.
n On fait des hypothèses fortes sur l'implémentation sous test : voir page suivante
n 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 39
Hypothèses sur l’implémentation n Elle se comporte comme une FSM, i.e. elle n'a pas
de mémoire n quelque soit p qui mène la FSM de l'état initial à l'état
si, la transition si –x:y-> sj, est exécutée de la même manière
n Elle se comporte comme une FSM déterministe à n états
n 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 40
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 41
Test boîte noire basé sur des spécifications formelles n relation de satisfaction : SUT sat SP
n Qu’est-ce que cela veut dire qu’un système satisfait une spécification?
n C’est beaucoup plus difficile à définir qu’il n’y paraît et l’équivalence n’est certainement pas adéquate
n On dérive de sat les notions : n test, n expérience de test, n et verdict (oracle): SUT passe T (où T est un Jeu de
Test)
septembre 2011 Test de Systèmes Informatiques 42
Hypothèses, exhaustivité n 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)
n 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 43
Sélection (test exhaustif souvent infini ou trop grand) n 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) n <H, T> est un contexte de test valide et non
biaisé n 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 44
Exemple de Spécifications n Spécifications algébriques des types de
données n ∑, Ax n Signature ∑ = <S, OP> : noms d’ensembles de
valeurs, et opérations ou prédicats sur ces ensembles
n Axiomes Ax : propriétés des opérations n x + 0 = x n x + s(y) = s(x+y) n x + y = y + x …
septembre 2011 Test de Systèmes Informatiques 45
« Types are Algebras » n Algèbres : des ensembles et des opérations sur ces
ensembles
n Attention, il n’y a pas de notion de modification d’état n « empiler(p,n) » construit une nouvelle valeur du type
Pile à partir de la valeur p et de n n « dépiler(p) » aussi
Les piles
Les entiers pile vide
dépiler
empiler
sommet
septembre 2011 Test de Systèmes Informatiques 46
Exemple : Stack spec STACK [ sort Elem] = sort Stack 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
généricité
septembre 2011 Test de Systèmes Informatiques 47
Rappel n Test « boîte noire », ou fonctionnel n On se base uniquement sur les spécifications
pour sélectionner des tests n On se sert également de la spécification
comme « oracle » (décision du succès ou de l’échec d’un test) n Mais… problèmes dus aux ≠ niveaux
d’abstraction et à l’observabilité
septembre 2011 Test de Systèmes Informatiques 48
Particularités du test basé sur des spécifications logiques n On ne veut pas vérifier des couples <données,
résultat> n On veut vérifier que les opérations implémentées
par le système satisfont les axiomes n 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 49
Qu’est-ce qu’un test? n Le SUT fournit des procédures ou des fonctions pour exécuter
les opérations de ∑SP n (exemple : classe Java, paquetage Ada, structure ML …)
n op est implémentée par opSUT n Etant donné un ∑-terme clos t, on note tSUT le résultat de son calcul
par SUT n Soit ε une ∑SP-équation
n test de ε : toute instanciation close t = t' de ε n expérience de test de P contre t = t' : évaluations de tSUT et t’SUT et
comparaison des valeurs résultats n NB : oracle ⇔ test de l'égalité
n Ces définitions se généralisent facilement à d’autres axiomes
septembre 2011 Test de Systèmes Informatiques 50
Retour à l’exemple n Test basé sur :
n X≤Y ∧ X≤Z => min3 (X, Y, Z) = X n t1≤t2 ∧ t1≤t3 => min3 (t1, t2, t3) = t1, où t1, t2, t3 sont des termes
clos, de sorte Nat, quelconques n Une expérience de test
n Exécution : évaluation de t1SUT ≤SUT t2SUT, t1SUT ≤SUT t3SUT, min3SUT (t1SUT, t2SUT, t3SUT), t1SUT
n Oracle :si le premier résultat est vrai, et le second aussi, alors le troisième et le quatrième doivent être identiques
n NB : Les termes qui ne satisfont pas les prémisses donnent des tests inintéressants
n On a ainsi tous les éléments pour construire un programme de test
septembre 2011 Test de Systèmes Informatiques 51
Jeu de test exhaustif n Soit une spécification SP = (∑, Ax), le jeu de test exhaustif
de SP, noté ExhaustSP est l'ensemble de toutes les instances closes bien typées de tous les axiomes de SP: n ExhaustSP = {Φσ | Φ ∈ Ax, σ = {σs : var(Φ)s → (T∑)s |
s∈S} } n NB1 : définition derivée de la notion classique de
satisfaction d'un axiome par un ∑-modèle n 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
n NB3 : ExhaustSP est exhaustif par rapport à la spécification, pas toujours par rapport au programme…
septembre 2011 Test de Systèmes Informatiques 52
Hypothèse de testabilité n Inévitable : quand on teste un système, on est
obligé de faire des hypothèses sur son comportement et son environnement
n Ici SUT est ∑-testable si : il définit un « ∑-modèle MSUT finiment engendré par rapport à ∑ », c’est-à-dire n Les opérations sont déterministes n Toutes les valeurs sont spécifiées (pas de « junks ») n Notation : Hmin
septembre 2011 Test de Systèmes Informatiques 53
Test et correction n On note SUT |= ExhaustSP le fait que SUT passe
tous les tests de ExhaustSP avec succès n On a Hmin => (MSUT |= Ax <=> SUT |= ExhaustSP )
n Autrement dit, sous l’hypothèse de testabilité, le succès du test exhaustif garantit la correction de SUT par rapport à SP
n Mais comment sélectionner des sous-ensembles finis de ExhaustSP ?
septembre 2011 Test de Systèmes Informatiques 54
Sélection et Hypothèses n On fait des hypothèses PLUS FORTES sur SUT n Exemple : Hypothèse d'Uniformité
n Φ(X) formule, SUT système, D sous-domaine n (∀ t0 ∈ D)( SUT |= Φ(t0) ⇒ (∀ t ∈ D) (SUT |= Φ(t)))
n Détermination des sous-domaines ? guidée par la spécification, à suivre…
n Autre exemple : Hypothèse de Régularité n ((∀ t ∈ T∑) (⎮t⎮≤ k ⇒ SUT |= Φ(t) )) ⇒ (∀ t ∈ T∑)
(SUT |= Φ(t)) n Détermination de |t|? cf. spécification
septembre 2011 Test de Systèmes Informatiques 55
Le choix des hypothèses?
<SUT testable, ExhaustSP> <Hyp. Faible, Gros Jeu deTest >
<Hyp. Forte, Petit JT> <SUT correct, Ø>
septembre 2011 Test de Systèmes Informatiques 56
Une Méthode n Point de départ : couverture des axiomes (un test
par axiome) n => hypothèses d’uniformité fortes sur les sortes
des variables ou sur le domaine de validité des prémisses
n 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
n 3 sous-domaines d’uniformité
septembre 2011 Test de Systèmes Informatiques 57
Affaiblissement des hypothèses n Affaiblissements successifs par utilisation des axiomes de
la spécification n L’exemple, intuitivement :
n ≤ correspond à deux sous-cas, < ou = n on le décompose dans les cas de test n X≤Y ∧ X≤Z => min3 (X, Y, Z) = X devient
n X=Y ∧ X=Z => min3 (X, Y, Z) = X n X=Y ∧ X<Z => min3 (X, Y, Z) = X n X<Y ∧ X=Z => min3 (X, Y, Z) = X n X<Y ∧ X=Z => min3 (X, Y, Z) = X
n Le domaine X≤Y ∧ X≤Z a été décomposé en 4 sous-domaines n En tout on a 12 cas de test
septembre 2011 Test de Systèmes Informatiques 58
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 n 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 59
Affaiblissement de l’hypothèse d’uniformité pour le 3e axiome n On va utiliser la table de vérité de ∧
n de true ∧ true <=> true on obtient : n A≤B ∧ sorted(cons(B, L)) => sorted(cons(A, cons(B, L))
n de true ∧ false <=> false on obtient : n A≤B ∧ ¬sorted(cons(B, L)) => ¬sorted(cons(A, cons(B, L))
n de false ∧ true <=> false on obtient : n ¬(A≤B) ∧ sorted(cons(B, L)) => ¬sorted(cons(A, cons(B, L))
n de false ∧ false <=> false on obtient : n ¬(A≤B) ∧ ¬sorted(cons(B, L)) => ¬sorted(cons(A, cons(B, L))
n On a alors 4 cas de test pour le 3e axiome n on peut tester encore plus…
septembre 2011 Test de Systèmes Informatiques 60
On décompose ≤ n Les deux premiers cas deviennent 4
n A≤B ∧ sorted(cons(B, L)) => sorted(cons(A, cons(B, L)) devient
n A=B ∧ sorted(cons(B, L)) => sorted(cons(A, cons(B, L)) n A<B ∧ sorted(cons(B, L)) => sorted(cons(A, cons(B, L))
n et A≤B ∧ ¬sorted(cons(B, L)) => ¬sorted(cons(A, cons(B, L)) devient
n A=B ∧ ¬sorted(cons(B, L)) => ¬sorted(cons(A, cons(B, L)) n A<B ∧ ¬sorted(cons(B, L)) => ¬sorted(cons(A, cons(B, L))
n On a 6 cas pour le 3e axiome ; on teste les cas « aux limites »
n On peut encore tester plus en « dépliant » sorted
septembre 2011 Test de Systèmes Informatiques 61
Dépliage
n Dépliage: une technique classique pour transformer (et comprendre) les définitions recursives
n Remplacement de f(op(x)) par la définition de f, avec remplacement adéquat des variables n fact(n) =def if n=0 then 1 else n*f(n-1) devient : n fact(n) =def if n=0 then 1 else if (n-1)=0 then n*1 else n*(n-1)*f(n-2)
n i.e. fact(n) =def if n=0 then 1 else if n=1 then 1 else n*(n-1)*f(n-2) n etc n 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 62
Retour au premier des 6 cas de tests n A=B ∧ sorted(cons(B, L)) => sorted(cons(A, cons(B, L))
n Sachant que n sorted (cons(x, cons(y, z)) <=> x≤y ∧ sorted(cons(y, z)) n On déplie la première instance de sorted :
n B -> A’ L -> cons(B’, L’) n sorted(cons(B, L)) devient sorted(cons(A’, cons(B’, L’))) qui
devient A’≤B’ ∧ sorted(cons(B’, L’)) n A=A’ ∧ A’≤B’ ∧ sorted(cons(B’, L’)) => sorted(cons(A,
cons(A’, cons(B’, L’)))) n On peut continuer ainsi, en décomposant ≤ et en dépliant
sorted jusqu’à ≈ le Jeu de Test Exhaustif n Pas tout à fait : des variables demeurent…
septembre 2011 Test de Systèmes Informatiques 63
Quand et comment s’arrêter n En fonction du contexte (risque, coût, délais), on décide
pour chaque spécification : n Quels prédicats décomposer n Quelles opération déplier et combien de fois (rarement
plus d’une fois) n Une bonne stratégie standard : composer tous les sous-cas
deux à deux n NB : on peut avoir des compositions de sous-cas
infaisables n Implémentation dans le cas d’axiomes positifs
conditionnels : surréduction (unification + réécriture)
septembre 2011 Test de Systèmes Informatiques 64
Le problème de l’oracle
n décider de l'égalité de tSUT et t’SUT n Le cas simple :
n la sorte s de t et t' correspond à un type du langage de programmation (sorte observable)
n ou on teste un prédicat n “Hypothèse d’oracle” faible :
n l’égalité sur les types du langage … n … et les booléens sont implémentés correctement
septembre 2011 Test de Systèmes Informatiques 65
Les autres cas n Comment tester que pop(push(S, X)) = S ? n Solution : les contextes observables n Exemples
top(_), top(pop(_)), top(push(pop(_), e)) n Pour tout contexte observable minimal C,
on teste : C(pop(push(S, X))) = C(S)
septembre 2011 Test de Systèmes Informatiques 66
Le jeu de test exhaustif observable
n OC∑[s] : ensemble des contextes observables (minimaux) sur s pour la signature ∑
n So sous-ensemble des sortes observables n Les axiomes dans Ax sont positifs conditionnels et
les équations dans les préconditions sont de sorte observable(*), n Soit L ⇒ t = u ∈ ExhaustSP , avec t et u de sorte s ∉ So ,
on teste L ⇒ C(t) = C(u) pour tout C ∈ OC∑[s] n Si t et u de sorte s ∈ So , on teste L ⇒ t = u n (*) sinon il y a risque de biais lorsqu'on sélectionne
n On sélectionne, …
septembre 2011 Test de Systèmes Informatiques 67
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
n Souvenez-vous : n Il faut faire aussi du test structurel! n On trouve la faute en couvrant toutes les
branches de top
septembre 2011 Test de Systèmes Informatiques 68
septembre 2011 Test de Systèmes Informatiques 69
Pour en savoir plus… n T.S. Chow. Testing software design modeled by finite-state machines. IEEE
Transactions on Software Engineering, SE-4(3):178–187, 1978. n 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.
n M.-C. Gaudel, Testing can be formal too, LNCSn°915, Springer-Verlag, pp. 82-96, 1995.
n M.-C. Gaudel and P. Le Gall. Testing data types implementations from algebraic specifications. LNCS n° 4949, Springer-Verlag, 2007. pp.209-239.
n Marie-Claude Gaudel. Checking models, proving programs, and testing systems. LNCS n° 6706, pp. 1-13. Springer-Verlag, 2011.
n See also http://www.lri.fr/~mcg/pubs/mcg.html