Test de Systèmes · PDF fileseptembre 2011! Test de Systèmes Informatiques! 2!...

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


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


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


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


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?


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


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


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 »



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


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


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


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


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)


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)



Première partie : Introduction au sujet Deuxième partie : concepts et problèmes Troisième partie : approches formelles,

2 exemples


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


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


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) ; …


A quoi sert un programme ?

n  Il peut être compilé puis intégré dans un système…


input

output


Preuve de Programme


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


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…


Intermède


Program

Assertions logiques

+ CORRECT!


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


“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



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


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?


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


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


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

?


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

?


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


L’exemple de nouveau

1 2 3 4

*,φ: _ /: _

/: _

*: _

φ: φ *: _

/: _

*: *

φ: _ /: / φ: * φ

Ensemble caractérisant : {*φ}

état *φ 1 _ 2 φ 3 *φ 4 **φ


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


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'


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 **φ


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


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


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)



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


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)


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


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


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 …


« 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


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é


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é


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


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


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


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…


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


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 ?


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


Le choix des hypothèses?

<SUT testable, ExhaustSP> <Hyp. Faible, Gros Jeu deTest >

<Hyp. Forte, Petit JT> <SUT correct, Ø>


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é


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


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


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…


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


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…


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…


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)


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


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)


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, …


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



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

Test de Systèmes · PDF fileseptembre 2011! Test de Systèmes Informatiques! 2!...

Documents

Transcript of Test de Systèmes · PDF fileseptembre 2011! Test de Systèmes Informatiques! 2!...