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

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

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

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

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…

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)

output

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

w/λ*(ss,w)

w ∈I*: et dans la FSM, w mène de ss à s.

préambule

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

•  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

é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

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

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?

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

Places we love / Lausanne

These We Ens

We Love Social

We decouverte

We like octobre 2015

We Demain Argu commerciale

We love you Anne

WE SE7 IT FR

WE ART…VENISE

test test 1

We Design Silence - owa

We want Miles

Kampania we francji

We like aout 2015

we love technology · 2020. 1. 27. · *we love technology : on aime tous la technologie we love technology. Préface Le smartphone s’impose désormais chez les Français comme

we are colour FR

JIIPMEERR MBBBBSS ENTRANCC E TEST 2001199 ......JIPMER. Paper has 200 questions but we have included . only those many. q. uestions. which have been collected from the students as

Can we measure cognitive constructs consistently within ... · Tilburg University Can we measure cognitive constructs consistently within and across cultures? Evidence from a test

Analyse du Cycle de Vie - · PDF fileSeptembre 2012 Analyse du Cycle de Vie Un outil de quantification environnementale au service de votre stratégie Cluster de recherche Excellence

WE du 14 juillet