Test Logiciel, Validation et Vérification

Transcription

Introduction
historique et problèmatique du test
INSA -- Test de Logiciels
ent
ion
ue
tes
t=
des
t=
tes
es
t=
Épo
q
oqu
e
Ép
1960
1980
2009
pré
v
tru
c
up
mi
se
a
1945
1
Ép
oq
u
Arnaud Gotlieb
IRISA / CELTIQUE
www.irisa.fr/lande/gotlieb
[email protected]
et
pré
his
toi
re
INSA - Rennes
2009-2010
2009
tion
oi n
t
Test Logiciel,
Validation et Vérification
1990
2
1960-80 : Test = mise au point
9/9/1945
Qu’avons-nous compris depuis ?
Chaîne causale :
erreur
faute
défaillance
En fait, 3 activités distinctes :
* détection de défaillances (rôle du test)
* localisation de fautes
(rôle de la mise au point)
* correction des erreurs
(rôle de la mise au point)
2009
3
2009
1980-90 : Test = destruction
[G. Myers The Art of Software Testing 1979]
« Se convaincre, par des techniques d’analyse ou
d’exécution, qu’un programme répond à ses
spécifications »
- Analyse
Conséquence immédiate :
le testeur ne doit pas être le programmeur
Position dogmatique progressivement abandonnée !
4
1990-.. : Test = prévention
« Testing is the process of executing a program
with the intent of finding errors »
2009
5
- Exécution
2009
Contrôle : vérifier des propriétés
avant exécution
Test : évaluer un résultat
après exécution
6
2009
7
2009
8
Test de programme : notre définition
Terminology
(IEEE Standard Glossary of SE, BCS’s standard for Softw. Testing)
Validation: « The process of evaluating software at the end
of software development to ensure compliance with intented
usage »
- Tester = exécuter un programme P pour mettre
en évidence la présence de fautes, par rapport à
sa spécification F
Verification: « The process of determining whether the
products of a given phase of the software development
process fulfill the requirements established during the
previous phase »
- Recherche de contre-exemples :
∃X tq
Testing: « Evaluating software by observing its execution »
2009
9
Prouver la correction d’un programme par le test
2009
P(X) ≠ F(X) ?
10
Correction de programme : limite fondamentale
Impossible de démontrer la correction d’un
programme dans le cas général
indécidabilité du
problème de l’arrêt d’une machine de Turing
Pour cela, il est nécessaire de générer
un jeu de test T tel que :
1. ∀X ∈ T, il existe une procédure
permettant de déterminer si P(X) termine
«Program Testing can be used to prove the presence
of bugs, but never their absence » [Dijkstra 74]
2. si ∀X ∈ T,P(X)=F(X) alors ∀X, P(X)=F(X)
PS : développeur expérimenté
2009
11
1 faute / 10 lignes de code
163 fautes / 1000 instructions
[B. Beizer Software Testing Techniques 1990]
2009
12
Processus de test
Problème de l’oracle :
Comment vérifier les sorties calculées ?
Programme P
Exécuter
Donnée de test X
Oracle okF
Sortie P(X)
En pratique :
- prédictions approximatives (à cause des calculs flottants,…)
- formules inconnues (car programme = formule)
- oracle contenant des fautes
Vérifier
Verdict (pass,fail)
2009
En théorie :
- par prédiction du résultat attendu
- à l’aide d’une formule issue de la spécification
- à l’aide d’un autre programme
13
2009
A base d’un modèle du programme issu des
spécifications :
A. Test fonctionnel : basé sur les spécifications
Sorties
- Informelles (test partitionnel, test aux limites, ...)
B. Test structurel : basé sur l’analyse du programme
Données de test
14
A. Test fonctionnel
Problème de la sélection des DT
Données de test
Sorties
- Semi-formelles (cas d’utilisation, diagrammes de
séquence, UML/OCL, graphes causes/effets…)
- Formelles (spéc. algébriques, machines B,
systèmes de transitions IOLTS, …)
2009
15
2009
A base d’un modèle du code source du programme
- modèle = représentation interne de la structure
- Utilisation importante de la Théorie des Graphes,
notamment des techniques de couverture
Spécifications :
renvoie le produit de
i par j
(i = 0, j = 0) --> 0
(i = 10, j = 100) -->1000
…
--> OK
16
Le test structurel est indispensable (1)
B. Test structurel
2009
17
2009
prod(int i,int j )
{
int k ;
if( i==2 )
k := i << 1 ;
else
(faire i fois l ’addition de j)
return k ;
}
18
Le test structurel est indispensable ! (2)
Spécifications :
renvoie le produit de
i par j
(i = 0, j = 0) --> 0
(i = 10, j = 100) -->1000
…
Faute non détectée par
du test fonctionnel
patch -> k := j << 1
2009
prod(int i,int j )
{
int k ;
if( i==2 )
k := i << 1 ;
else
(faire i fois l ’addition de j)
return k ;
}
Software testing in the software
developpement process
Usage &
acceptance testing
Requirements
Architecture & system
System testing
(performence, load, robustness, security testing)
Functional specifications
Unit & Integration testing
Coding design
19
Test natif / test croisé
2009
20
Exemple de montage en test croisé : plateforme Java Card
Test natif :
machine de test = machine de développement
Java Card
Card reader
USB port
.cmd
Card
Commands
processor
APDUs
Open
Plateform
loader
Test croisé :
machine de test ≠ machine de développement
.java
javac
.class
converter
.cap
verifier
Personal Computer
2009
21
2009
22
Bibliographie : quelques livres
Tests de non-regréssion
Jeu de Test 3
Jeu de Test 2
Jeu de Test 1
…
3ème version
2nde
version
Tests de
non-régression
1ère version
2009
23
2009
24
Bibliographie : quelques revues
Et quelques sites intéressants...
Software Testing Online Resources www.mtsu.edu/~storm/
Software Testing Stuff
www.testdriven.com
Model-based Software Testing
www.geocities.com/model_based_testing/
Opensource ST www.opensourcetesting.org/unit_java.php
Tao Xie’s homepage
www.cs.washington.edu/homes/taoxie
2009
25
2009
26
Plan complet du cours
0. Préliminaires
TP1 : Test à partir de modèle avec LTG
1. Test logiciel : principes
TP2 : Test des systèmes d’information
avec GEDIS
2. Génération automatique de test
3. Techniques de test fonctionnel
TP3 : Test des applications embarqués dans
le cadre automobile : formation AUTOSARLAB
avec IBM Test RealTime
4. Test de logiciel orienté-objet
5. Test à partir de modèles
2009
27
2009
28
0. Préliminaires
Gödel !
1931
Un système formel : un ensemble d’axiomes et de règles de déduction
qui permettent de produire des théorèmes (par preuve)
Si on prend l’ensemble des entiers muni des opérations classiques, il
existe toujours des énoncés qu’il est impossible de démontrer.
2009
Pire ! Si on rajoute ces énoncés à l’ensemble des axiomes initiaux,
on obtient un système comportant de nouveaux énoncés… non démontrables
29
2009
30
Idée de la preuve
Puis Turing …
Une machine de Turing se compose d'une partie de contrôle et d'une bande
infinie sur laquelle se trouvent écrits des symboles. Les symboles de la
bande sont lus et écrits par l'intermédiaire d'une tête de lecture.
Epiménide Le Crétois: « Tous les Crétois sont des menteurs ! »
Gödel a construit un énoncé analogue à l’intérieur d’un système formel
- Il numérote tous les signes utilisés dans un théorème concernant les
entiers (comme un code ASCII des maths !)
- A tout théorème, il fait correspondre un entier (son code)
-Il construit le théorème T:
« il n’existe pas de théorème ayant un code qui est la codification de T »
Idée simple, mais preuve rigoureuse difficile.
2009
31
Puis Church...
Les machines de Turing sont une abstraction des ordinateurs. La partie de
contrôle représente le microprocesseur. Un élément essentiel est que le
nombre d'états est fini car les microprocesseurs possèdent un nombre
déterminé et fini de registres d'une taille fixe.
2009
32
Pire : un programme T qui determine si un
programme B termine ou pas
Il existe des programmes exécutables par des
Machines de Turing qu’on ne peut pas écrire !
(* prog B1 *)
while( true ) {};
(*prog B2*)
a = 0;
while( a ≠ 1 )
{
a = a + 2 ;
}
Exemple : un programme qui imprime son texte source
a = 1;
b = 2;
printf(‘’a = 1; ’’);
printf(‘’b = 2;’’);
printf(‘’printf (‘‘a = 1;’’); ’’);
printf (‘’printf (‘’b = 2;’’);’’);
(*prog B3*)
scanf(‘’%d’’, &a) ;
while (a < 10)
{
b = a + 2 ;
}
T doit determiner que B1 et B2 ont une boucle infinie
que B3 boucle infiniment si a prend une valeur a < 10.
2009
33
Et si on implante T comme ceci :
2009
34
Quel rapport avec le test des programmes ?
Si T repère une boucle infinie, il imprime un message d ’erreur
et s ’arrête ; sinon, T boucle
P = Problème de l’arret d’une machine de Turing.
Que fait le programme T avec T en entrée ?
« Etant donné a une entrée et MT une machine de Turing,
déterminer si MT s’arrête si on lui fournit a en entrée est un
problème indécidable dans le cas général ! »
Soit T boucle indéfiniment, soit T s’arrête.
Beaucoup de problèmes de test se ramènent à P !
1. Si T boucle indéfiniment, T doit s’arrêter et le signaler.
C ’est impossible, puisqu ’on a supposé que T boucle indéfiniment !
2. Si T s’arrête, alors il est mis en bouclage infini…
donc T ne termine pas
Contradiction
2009
35
- déterminer si un programme est correct par rapport à sa
spécification
- déterminer si une instruction est atteignable (exécutable)
- déterminer si un chemin donné est faisable dans le programme
- déterminer si un critère de test est applicable
Etc.
2009
36
Oracle
0. Préliminaires
X3
donnée de test : X ∈ Dom(P)
X4
jeu de test
37
2009
Définition formelle de l’oracle
=1..N
38
Jeu de Test idéal
Dom(P)
Dom(P)
Ran(P)
X ∈ Dom(P)
T = {Xi}i =1..N
X2
X1
X3
Oracle :
okF : Dom(P) x Ran(P)
Bool
okF(X,P(X)) ssi X tq P(X)=F(X)
{i.e. X est réussi}
(seul lien avec F, procédure automatique ou manuelle, souvent partiel)
2009
: T = {Xi}i
Plusieurs techniques :
- Test dos à dos : prototypes, N-versions, non-regression
- Propriétés du programme : assertions, fonctions inverses, ...
- Prédictions manuelles !
Programme P :
Donnée de test :
Jeu de test
:
X5
“A mechanism to produce the predicted outcomes to compare with the
actual outcomes of the software under test.” (Glossary BCS SIGIST)
2009
Dom(P)
X2
X1
39
okF(X1,P(X1))
okF(X2,P(X2))
...
X5
X4
T est idéal ssi
{i.e. T est non réussi}
∃X ∈ T, ¬okF(X,P(X))
{i.e. T est réussi}
ou si ∀X ∈ T, okF(X,P(X))
alors ∀X ∈ Dom(P), okF(X,P(X))
2009
40
Critère de sélection C
Couverture du critère de sélection C
- Procédé de sélection de données de test
- Induit parfois une « partition » sur le domaine d’entrée
Repose sur une hypothèse d’uniformité :
une seule donnée de test suffit pour tout le sous-domaine
(ex : chemins de P)
j
P(int i,int j)
{
if( C1 )
else ...
if( C2)
else ...
}
2009
Dom(P)
Dom(P)
X4
X1
C1∧¬C2
C1∧C2
X2
X3
¬C1∧¬C2
¬C1∧ C2
i
41
Prédicat COMPLETEP(T,C) vrai ssi T est sélectionné par C
2009
42
Jeu de Test idéal
Critère fiable pour P
Défauts
Dom(P)
X2
X1
X3
X5
X4
okF(X1,P(X1))
okF(X2,P(X2))
...
Jeu de test
T est idéal ssi
{i.e. T est non réussi}
∃X ∈ T, ¬okF(X,P(X))
{i.e. T est réussi}
ou si ∀X ∈ T, okF(X,P(X))
alors ∀ X ∈ Dom(P), okF(X,P(X))
2009
Critère fiable
43
Critère valide pour P
C fiable pour P ssi
∀T1,T2 tq COMPLETEP(T1,C) et COMPLETEP(T2,C),
T1 réussi est équivalent à T2 réussi
2009
44
Exemples (1)
Prog : ush P(ush n) { return(n+n);}
Spéc : F(n) = n²
Défauts
Critère valide
C1 : sélection de DT à valeur paire <3
Jeux de test
okF(0,P(0))
okF(2,P(2))
C valide pour P ssi
∀X ∈ Dom(P) tq ¬okF(X,P(X)),
∃T tq COMPLETEP(T,C) et T non réussi
2009
C1 est fiable et non valide pour P
45
Exemples (2)
Spéc : F(n) = n²
2009
46
Exemples (3)
C2 : sélection de 2 DT à valeur paire
{0,2}, {2,4}, {0,4}, …
C3 : sélection de 3 DT dont (X=1)
{0,1,2},{1,2,3},{0,1,3},…
¬okF(1,P(1))
C3 est
C2 est valide et non fiable pour P
Spéc : F(n) = n2
okF(0,P(0))
okF(2,P(2))
mais ¬okF(4,P(4))
2009
{0}, {2}, {0,2}
47
2009
pour P
48
Exercice :
1.1 Théorème fondamental du test
Critère C valide et fiable
Spéc : Fn = (n+1)ème nombre premier (par ex. F1 = 3)
Défauts
Prog : ush P(ush n) { return(2*n + 1);}
C1 : sélection de 2 DT dont une contient une valeur ≤ 10 et
l’autre un impair quelconque
C2 : sélection d’un sous-ensemble de 2{1,2,3}
Q1 : C1,C2 sont-ils valides, fiables pour P ?
Q2 : Imaginer un critère C3 qui soit valide et fiable pour P
2009
49
Jeu de test
[Goodenough & Gerhart 75] :
Tout critère C valide et fiable pour P
ne sélectionne que des jeux de test idéaux pour P
2009
50
1ère critique :
les notions de validité/fiabilité sont relatives à P
Preuve
Tout critère C valide et fiable pour P
ne sélectionne que des jeux de test idéaux pour P
A démontrer : Soit TX un jeu de test tq COMPLETEP(TX,C)
si TX est réussi alors ∀X ∈ Dom(P), okF(X,P(X))
Par l’absurde : Soit Y tq ¬okF(Y,P(Y)) alors
∃TY tq COMPLETEP(TY,C)et TY non réussi
car C est valide, or C est fiable pour P donc
∀T tq COMPLETEP(T,C), T est non réussi.
Si P est correct,
tout critère C est valide/fiable pour P
Déterminer un critère valide/fiable pour P
nécessite pratiquement de connaître les fautes de P
Si P’ est une mise au point de P, alors
C n’est pas nécessairement valide/fiable pour P’
En particulier, TX est non réussi -- CONTRADICTION
2009
51
2009
52
Exemple de critère valide et fiable pour tout P :
test exhaustif
2nde critique : Test exhaustif = exemple unique !
- Critère C : sélection de toutes les données de test possibles
T = Dom(P)
Preuve [Weyuker & Ostrand 80] :
C est (trivialement) valide et fiable
- équivalent à une preuve de correction
- Mais impraticable en général ! (même si Dom(P) < +∞)
P(ush x1,ush x2,ush x3) {...}
Car ∀P, ∀X ∈ Dom(P),
∃P’ tq ∀Y ∈ Dom(P) okF(Y,P’(Y))
et ¬okF(X,P’(X))
{Y≠X}
D’où si C est valide/fiable pour tout programme
(en particulier P’ ), alors C doit sélectionner X,
∀X, C sélectionne X
232 possibilités × 232 possibilités × 232 possibilités = 296 possibilités
2009
53
2009
54
Papiers fondateurs
Howden’s negative result
[Goodenough & Gerhart 75]
«Toward a Theory of Test Data Selection»
IEEE Trans. on Software Engineering SE-1 N°2 Jun 1975
Etant donné un programme P, le problème qui consiste à
générer un jeu de test idéal réussi, i.e. T tel que :
si ∀X∈T, okF(X,P(X)) alors ∀X∈Dom(P), okF(X,P(X))
[Howden 76] «Reliability of the Path Analysis Testing Strategy»
IEEE Trans. on Software Engineering SE-2 N°3 Jun 1976
est indécidable dans le cas général !
[Weyuker & Ostrand 80] «Theories of Program Testing and
the Application of Revealing Subdomains»
IEEE Trans. on Software Engineering SE-6 N°3 May 1980
D’où : recherche empirique de critères de test intéressants
[Rapps & Weyuker 85]
«Selecting Software Test Data Using Data Flow Information »
IEEE Trans. on Software Engineering SE-11 N°4 Apr 1985
2009
55
Représentations internes
2009
56
Graphe de flot de contrôle (GFC)
Abstractions de la structure d’un programme
Graphe orienté et connexe (N,A,e,s) où
- Graphe de Flot de Contrôle [GFC]
N : ens. de sommets =
bloc d’instructions exécutés en séquence
E : relation de N x N =
débranchement possible du flot de contrôle
- Graphe Def/Use [GDU]
[- Program Dependence Graph, ...]
e : sommet “d’entrée” du programme
s : sommet de sortie du programme
2009
57
Graphe de flot de contrôle (GFC) : exemple
double P(short x, short y) {
short w = abs(y) ;
double z = 1.0 ;
2009
w != 0
Déf: Un ensemble C de chemins du GFC
(N,A,e,s) satisfait tous_les_sommets
ssi ∀n ∈ N, ∃Ci ∈ C
tq n est un sommet de Ci
faux
d
y<0
vrai
if ( y<0 )
z = 1.0 / z ;
return(z) ;
}
faux
a
b
c
d
Exemple : Ici un seul chemin suffit
a-b-c-b-d-e-f [6/6 sommets]
e
f
58
Motivation : couvrir toutes les instructions
du programme au moins une fois
vrai
c
Critère : tous_les_sommets | toutes_les_instructions
a
b
while ( w != 0 )
{
z =z*x;
w=w-1;
}
2009
59
2009
e
f
60
Critère structurel : tous_les_arcs | toutes_les_décisions
Motivation : couvrir toutes les prises de
décision au moins une fois
a
c
d
Exemple : Ici 2 chemins sont nécessaires
a-b-c-b-d-e-f [6/7 arcs]
a-b-d-f
[3/7 arcs]
2009
e
f
61
b
Ici, impossible car ∞ chemins
et chemins non-exécutables !
d
e
tous_les_chemins plus fort que tous_les_arcs
tous_les_arcs plus fort que toutes_les_sommets
f
Idée de la preuve: réduction au problème
de l’arrêt d’une Machine de Turing return(z)
2009
f
62
P(short x,y)
short w= abs(y)
double z= 1.0
b
w != 0
z= z * x
w= w-1
d
Exemples :
exec(P,(0,0)) = a-b-d-f
exec(P,(3,2)) = a-b-(c-b)²-d-f
2009
a
y<0
z=1.0 / z
e
f
64
Exercice
a
P(short x,y)
short w= abs(y)
double z= 1.0
b
w != 0
Trouver tous les chemins non-exécutables de ce
programme
a
z= z * x
w= w-1
d
c
return(z)
63
Problème des chemins non exécutables
c
e
Déf: séquence de sommets du GFC, non
nécessairement finie, empruntée lors de
l’exécution de P avec X comme entrée
c
Weyuker 79
Déterminer si un sommet, un arc, ou
un chemin du GFC est exécutable est
indécidable dans le cas général
d
Principe:
X sensibilise un unique chemin du GFC
a
Ici, a-b-d-e-f est non-exécutable !
c
Chemin sensibilisé : exec(P,X)
Déf : Un ensemble C de chemins du GFC
(N,A,e,s) satisfait tous_les_chemins
ssi C contient tous les chemins de e à s
Soit c un chemin du GFC de P,
existence de X tq c=exec(P,X) ?
b
Exemple : Ici 4 chemins complets
sont nécessaires
a-b-d-f
a-b-d-e-f
a-b-c-b-d-f
a-b-c-b-d-e-f
2009
Critère structurel : tous_les_chemins
2009
a
Motivation : couvrir toutes les chemins
d’exécution, sans itérer plus d’une fois dans
les boucles
b
Déf : Un ensemble C de chemins du GFC
(N,A,e,s) satisfait tous_les_arcs
ssi ∀a ∈ A, ∃Ci ∈ C
tq a est un arc de Ci
Critère structurel : tous_les_chemins_simples
y=x
x=0
v
b
f
d
v
e
65
2009
y= -x
x= -1
x < 0 && y>= 0
f
e
f
x>0
c
y<0
z=1.0 / z
P(short x)
f
g
66
Condition / Décision dans un programme
Critères de test liés aux décisions
if( A && (B || C))
Condition (bool., expr. arith, ...)
1. Decision Criterion (DC) :
if( A && (B || C))
A=1,B=1,C=0 – Dec=1
A=0,B=0,C=0 – Dec=0
2. Condition Criterion (CC) : A=1,B=1,C=0 – Dec=1
A=0,B=0,C=1 – Dec=0
3. Modified Condition/Decision Criterion (MC/DC)
Décision
(bool., expr. logique dans une structure de contrôle, ...)
Notation :
Dec est la valeur de vérité de la décision
2009
4. Multiple Condition/Decision Criterion: 23=8 cas de test
67
Modified Condition/Decision Criterion (1)
2009
Objectif : Démontrer l’action de chaque condition sur
la valeur de vérité de la décision
if( A && (B || C))
if( A && (B || C))
Principe : pour chaque condition, trouvez 2 cas de
test qui changent Dec lorsque toutes les autres
conditions sont fixées
Ex : pour A
2009
A=0, B=1,C=1
A=1, B=1,C=1
pour A
A=0, B=1,C=1
A=1, B=1,C=1
-- Dec=0
-- Dec=1
pour B
A=1, B=1,C=0
A=1, B=0,C=0
-- Dec=1
-- Dec=0
pour C
A=1, B=0,C=1
A=1, B=0,C=0
-- Dec=1
-- Dec=0
-- Dec=0
-- Dec=1
Ici, 5 cas de test suffisent pour MC/DC !
69
Exercice : peut-on faire mieux ?
A= , B= ,C=
A= , B= ,C=
-- Dec=
-- Dec=
pour B
A= , B= ,C=
A= , B= ,C=
-- Dec=
-- Dec=
pour C
A= , B= ,C=
A= , B= ,C=
2009
70
if( A && (B || C))
pour A
68
Propriété : Si n = #conditions alors
couvrir MC/DC requiert au moins n+1 DT et au plus 2n DT
n+1 ≤ #données de test ≤ 2*n
Conditions couplées : changer la valeur d’une condition
modifie la valeur d’une autre
-- Dec=
-- Dec=
En l’absence de conditions couplées, le minimum (n+1)
peut-être atteint
2009
71
2009
72
Lien avec la couverture du code objet
Couvrir MC/DC ⇒ couvrir les décisions du code objet
mais
Couvrir MC/DC ⇐ couvrir les décisions du code objet
Couvrir les chemins du code objet ⇒ couvrir MC/DC
mais
Couvrir les chemins du code objet ⇐ couvrir MC/DC
2009
73
Représentations internes
From the Galileo development standard
Structural coverage
Statement coverage
(source code)
Statement coverage
(object code)
Decision coverage
(source code)
Modified Condition &
Decision Coverage
(Source code)
2009
DAL A
N/A
DAL
DAL C
B
100% 100%
100% N/A
N/A
DAL
D
90%
DAL
E
N/A
N/A
N/A
N/A
100% N/A
N/A
N/A
N/A
N/A
100% N/A
N/A
Graphe Def/Use (GDU) –
74
Abstractions de la structure d’un programme
A chaque sommet j est associé
- def(j) :
{v ∈ Var(P) | v est définie en j }
- c-use(j) : {v ∈ Var(P) | v est utilisée en j dans un calcul
et ∃k ≠ j tel que v ∈ def(k)}
A chaque arc j-k issu d’une décision est associé
- p-use(j,k) : {v ∈ Var(P) | v est utilisée dans le prédicat j
et conditionne l’exécution de k}
- Graphe de flot de contrôle [GFC]
- Graphe Def/Use [GDU]
GFC + décoration des sommets/arcs avec infos
définitions/utilisations sur les variables
[- Program Dependence Graph, …]
2009
Hypothèses : Toute variable utilisée possède une définition
et à chaque définition correspond au moins une utilisation
75
Graphe Def/Use : exemple
if ( y<0 )
z = 1.0 / z ;
return(z) ;
}
2009
76
Chemin sans définition (def-clear path)
double P(int x, int y) {
w = abs(y) ;
z = 1.0 ;
while ( w != 0 )
{
z = z*x ;
w = w-1 ;
}
2009
1
c-use(1) : ∅
def(1) : x,y,w,z
2
p-use(2,3) : w
c-use(3) : x,z,w
def(3) : z,w
Soient i un sommet d’un GDU (N,A,e,s) et x ∈ def(i)
3
p-use(2,4) : w
4
p-use(4,6) : y
6
i-n1-…-nm-j est un chemin sans déf. de x de i à j
ssi ∀k ∈ {1,..,m}, x ∉ def(nk)
p-use(4,5) : y
5
c-use(5) : z
def(5) : z
c-use(6) : z
77
dcu(x,i): {j ∈ N | x ∈ c-use(j) et
∃un chemin sans déf. de x de i à j}
dpu(x,i): {j-k ∈ A | x ∈ p-use(j,k) et
∃un chemin sans déf. de x de i à j}
2009
78
Critère structurel : toutes_les_définitions
dcu(x,j) et dpu(x,j) : exemples
dcu(x,1)= {3}, dpu(x,1)= ∅
dcu(y,1)= ∅,
dpu(y,1)= {4-5,4-6}
dcu(w,1)= {3}, dpu(w,1)= {2-3,2-4}
dcu(z,1)= {3,5,6}, dpu(z,1)= ∅
p-use(2,3) : w
c-use(3) : x,z,w
def(3) : z,w
1
2
3
p-use(2,4) : w
4
dcu(z,3)= {3,5,6}, dpu(z,3)= ∅
dcu(w,3)= {3}, dpu(w,3)= {2-3,2-4} p-use(4,6) : y
dcu(z,5) = {6}, dpu(z,5) = ∅
2009
c-use(1) : ∅
def(1) : x,y,w,z
p-use(4,5) : y
5
6
c-use(5) : z
def(5) : z
c-use(6) : z
79
Couverture de toutes_les_définitions
1
Ici, un seul chemin suffit !
1-2-3-2-4-5-6
c-use(1) : ∅
def(1) : x,y,w,z
2
3
p-use(4,6) : y
6
Déf : C satisfait toutes_les_utilisations
ssi ∀n∈ N et ∀x∈ def(n), ∃Ci ∈ C
tq Ci inclut un chemin sans déf. de x de n à
tous les éléments de dcu(x,n) et dpu(x,n)
Exemple : Ici, trois chemins sont nécessaires !
par exemple : 1-2-4-6, 1-2-3-2-4-6 et 1-2-(3-2)2-4-5-6
p-use(4,5) : y
5
c-use(5) : z
def(5) : z
toutes_les_utilisations est plus fort que
toutes_les_définitions
c-use(6) : z
81
Chemin définition/utilisation p.r.à. x (du-path w.r.t. x)
Déf: p = i-..-j-k est
un chemin définition/utilisation par rapport à x ssi :
1. x ∈ def(i)
2a. soit x ∈ c-use(k) alors p est un chemin sans déf. de x
de i à k et p se trouve sur un chemin simple
2b. soit x ∈ p-use(j,k) alors p est un chemin sans déf.
de x de i à j et p se trouve sur un chemin simple
2009
82
Chemin définition/utilisation : exemples
du_path w.r.t. x : 1-2-3
du_paths w.r.t. y :
1
1-2-4-5, 1-2-4-6,
1-2-3-2-4-5,
1-2-3-2-4-6
2
c-use(3) : x,z,w
def(3) : z,w
du_paths w.r.t. z :
1-2-3,1-2-4-5,1-2-4-6,
3-2-3,3-2-4-5,3-2-4-6,
5-6
3
p-use(2,4) : w
4
p-use(4,6) : y
du_paths w.r.t. w :
83
2009
c-use(1) : ∅
def(1) : x,y,w,z
p-use(2,3) : w
1-2-3,1-2-4,3-2-3,3-2-4
2009
80
p-use(2,4) : w
4
2009
2009
Critère structurel : toutes_les_utilisations
p-use(2,3) : w
c-use(3) : x,z,w
def(3) : z,w
Déf : Un ensemble C de chemins du
GDU (N,A,e,s) satisfait toutes_les_définitions ssi
∀n ∈ N et ∀x ∈ def(n),
∃Ci ∈ C tel que
Ci inclut un chemin sans déf. de x
de n à un élément de dcu(x,n) ou dpu(x,n)
6
p-use(4,5) : y
5
c-use(5) : z
def(5) : z
c-use(6) : z
84
Relation entre les critères (“est plus fort que”)
Critère structurel : tous_les_chemins_du
Déf: C satisfait tous_les_chemins_du 1 c-use(1) : ∅
def(1) : x,y,w,z
ssi ∀n∈ N et ∀x∈ def(n),
C inclut tous les chemins
2
p-use(2,3) : w
définition/utilisation
par rapport à x
c-use(3) : x,z,w
p-use(2,4) : w
C1 subsume C2 (noté C1 ⇒ C2) ssi
∀GDU, ∀ensemble de chemins P qui satisfait C1,
P satisfait aussi C2
3
def(3) : z,w
4
p-use(4,5) : y
p-use(4,6) : y
Ici, 5 chemins !
1-2-4-6, 1-2-4-5-6,
5 c-use(5) : z
def(5) : z
1-2-(3-2)2-4-6,1-2-3-2-4-5-6
6
c-use(6)
:
z
1-2-3-2-4-6
2009
85
Les liens entre critères liés au GDU et au GFC
Critères liés au GDU
Propriétés :
- relation transitive ( C1 ⇒ C2 et C2 ⇒ C3 alors C1 ⇒ C3 )
- définit un ordre partiel entre les critères
Ex: tous_les_chemins_du subsume toutes_les_utilisations
2009
86
Et en plus…
tous_les_chemins
Critères liés au GFC
tous_les_chemins_du
tous_les_chemins_du
toutes_les_utilisations
tous_les_chemins
toutes_les_utilisations
toutes_les_c_use/
quelques_p_use
toutes_les_p_use/
quelques_c_use
tous_les_arcs
toutes_les_p_use
tous_les_arcs
2009
tous_les_sommets
tous_les_sommets
87
tous_les_chemins n’est pas fiable !
Spéc : F(n) = n²
a
ush P(ush n)
b
return(n+n)
88
Freeware:
- Gcov / gcc www.netadmintools.com/html/1gcov.man.html
- Hansel (Oregon University)
hansel.sourceforge.net
- Quilt / Junit
quilt.sourceforge.net
Outils commerciaux :
- IPL Cantata++ / ADATest
- IBM Rational Test Realtime
www.iplbath.com/products
www-306.ibm.com/software/awdtools/test/realtime
Mais okF(0,P(0)) et ¬okF(1,P(1))
donc tous_les_chemins n’est pas fiable !
2009
Quelques outils disponibles...
Ici, tous_les_chemins est couvert par a-b
On a
COMPLETEP({0}, tous_les_chemins)
COMPLETEP({1}, tous_les_chemins)
2009
- LDRA Testbed
89
2009
www.ldra.co.uk/pages/testbed.htm
90
Units of language
Functions in C
TEST UNITAIRE
AVEC CUNIT
Task in ADA
Methods or classes in C++ and Java
Predicates in Prolog
…
2009
91
2009
Unit testing frameworks
92
Unit testing: atomic operation
Select test input variable values
- JUnit, Parasoft’s Jtest for Java
- CUnit, CTC++, IBM Rational Test Real Time for C
- Parasoft’s C++Test, Cantata++… for C++
…
Define expected output values (a.k.a. oracle)
http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks
Code a test script and register it in a
database
Run the test !
2009
93
Cunit (http://cunit.sourceforge.net/) -- 1
94
Automated
Output to XML file, Non-interactive
Basic
Flexible programming interface, Non-interactive
Console
Console interface (ANSI C), Interactive
Curses
Graphical interface (Unix only), Interactive
Built as a static library which is linked with
the user’s test script
provides a rich set of assertions for testing
common data types.
Cunit (http://cunit.sourceforge.net/) -- 2
Lightweight system for writing, managing
and running unit test for C programs
2009
2009
95
2009
96
Typical test script: test_gcd.c
Example
#include "Basic.h"
typedef unsigned short ush;
void test_gcd(void) {
CU_ASSERT(4 == gcd(24, 28));
CU_ASSERT(4 == gcd(28, 24)); }
main() {
CU_pSuite pSuite = NULL;
Select a test input: (28, 24)
ush gcd(ush u, ush v)
{
while( u > 0 )
{
if ( v > u )
{
u = u + v;
v = u - v;
u = u * v;
}
u = u - v;
}
return v;
}
Define expected output: 4
if (CUE_SUCCESS != CU_initialize_registry())
return CU_get_error();
Define another test input : (24,28)
Expect output: 4
pSuite = CU_add_suite("Suite_1", 0, 0);
if (!pSuite) { CU_cleanup_registry();
return CU_get_error(); }
if ((!CU_add_test(pSuite, "test of fprintf()", test_gcd))
{ CU_cleanup_registry();
Script and run the test !
CU_basic_run_tests();
CU_cleanup_registry();
2009
97
2009
98
Let’s play, now !
Makefile
CUnitHeaders=/c/CUnit-2.1-0/include/CUnit
CUnitLibs=/c/CUnit-2.1-0/lib
Download and install Cunit (README)
requires Jam, MinGW on windows
http://cunit.sourceforge.net
test_gcd: gcd.o test_gcd.o
$(CC) $^ -L$(CUnitLibs) -lcunit -o $@
Code gcd.c, test_gcd.c and Makefile
gcd.o: gcd.c
$(CC) -c -D static= gcd.c
Run and explain…
test_gcd.o: test_gcd.c
$(CC) -c -I$(CUnitHeaders) test_gcd.c
clean:
2009
$(RM) gcd.o test_gcd.o
test_gcd.exe
99
JUnit for Java
2009
100
0. Préliminaires
http://www.irisa.fr/lande/gotlieb/resources/JUnit_Tutorial.mp4
2009
101
2009
102
Rappels: définition du test de programme
Plan
- Tester = exécuter un programme P pour mettre
en évidence la présence de fautes, par rapport à
sa spécification F
2. Génération automatique de cas de test
2.1 Test aléatoire
2.2 Test statistique structurel
2.3 Méthode dynamique
2.4 Evaluation symbolique
2.5 Méthode à contraintes
- Recherche de contre-exemples :
∃X tq
P(X) ≠ F(X) ?
- Hypothèse de travail : oracle disponible
2009
103
Rappels des notations
Dom(P)
Donnée de test :
X
Jeu de test
T =
Ran(P)
{Xi}i
(ex : chemins de P)
j
=1..N
Bool
P(int i,int j)
{
if( C1 )
else ...
Dom(P)
X2
X3
X5
okF(X1,P(X1))
okF(X2,P(X2))
...
X4
2009
104
∈ Dom(P)
Oracle okF : Dom(P) x Ran(P)
X1
Programme P :
:
2009
Dom(P)
C1∧¬C2
C1∧C2
if( C2)
else ...
}
105
Couverture déterministe d’un critère C
¬C1∧¬C2
¬C1∧ C2
i
2009
106
Couverture probabiliste du critère C
Génération aléatoire de données de test
selon une distribution de probabilités
(ou profil d’entrée)
Génération d’une seule donnée de test
par élément à vérifier !
Dom(P)
X4
X1
Dom(P)
X2
X1
X3
X5
107
X6
X8
2009
X2
X7
X4
2009
X3
108
2.1 Test aléatoire
Qualité de test pour le test aléatoire : QN
Loi de probabilité uniforme sur le domaine d’entrée
QN = probabilité que (un de ces) X soit détecté après
la génération de N DT aléatoires
(i.e. chaque DT est équiprobable)
- Utilisation de générateurs de valeurs pseudo-aléatoires
- Nécessité de disposer d’un oracle automatique
- Condition d’arrêt à déterminer (nombre de DT à générer,
critère de test couvert)
2009
109
= pf
= Q1+ (1-Q1).pf
(1-pf)n-1. Q1= pf .(1-pf)n-1
(1-pf)n-2. Q2= pf .(1-pf)n-2 + (1-pf)n-1.Q1
…
(1-pf).Qn-1 = pf . (1-pf). + (1-pf)2. Qn-2
Qn = pf
+ (1-pf). Qn-1
Remarques :
- l’évaluation de pf repose sur la connaissance des fautes
- pas de lien avec les critères de test
2009
110
Dom(P)
A2
QN = 1 – (1-pf)N
C.Q.F.D.
111
[Thévenod-Fosse 89]
pc = min { p{x∈A} | A ∈ SC }
A3
SC = {A1,..,A4}
Ici p{x∈A1} < p{x∈A2} < p{x∈A3} < p{x∈A4} donc le
test aléatoire couvre « mieux » A4 que A1, ce qui n’est
pas2009
satisfaisant !
112
Plan
qN = probabilité que chaque élément de SC soit activé après
la génération de N DT aléatoires
2.1 Test aléatoire
qN = 1 – (1-pc)N
Corollaire : si pC≠0 et pC≠1
A1
A4
Qualité de test pour le test statistique : qN
Théorème :
QN = 1 – (1-pf)N
p{x∈A} : probabilité qu’une DT aléatoire x couvre l’élément A
Q1 = pf
Q2 = pf + (1-pf).Q1
…
Qn-1= pf + (1-pf).Qn-2
Qn = pf + (1-pf).Qn-1
= Qn-2 + (1-Qn-2).pf
= Qn-1 + (1-Qn-1).pf
2009
Théorème :
Efficacité du test aléatoire pour couvrir un critère ?
Preuve
Q1
Q2
…
Qn-1
Qn
On a :
pf = probabilité que ∃X généré aléatoirement tq P(X) ≠ F(X)
N ≥ ln(1-qN)
ln(1- pC)
NB : qN ≠ QN la qualité de test pour le test aléatoire (en général)
2009
113
2009
114
qN = 1 – (1 – pC)N pour N=2, 8, 16 cas de test
Déf : C est couvert avec une probabilité qN
si tout élément de SC a une probabilité au moins qN d’être
couvert au cours de N exécutions avec des DT aléatoires
Remarques :
- ∀JT fini, aucune garantie de couverture du critère
N = 16
- couvrir C avec une probabilite qN devient
l’objectif de test
N=8
N=2
- conséquence : maximiser pc= min { p{x∈A} | A ∈ SC}
2009
115
2009
116
1ère étape : calculer un profil d’entrée tq PA1= ..=PAk=1/k
Algorithme pour le critère tous_les_chemins
Dom(P)
A1
A2
qN = 1 – (1 – pC)N
A3
A4
Calcul des proba. sur Dom(P)
afin que PA1 = .. =PAk= 1/k
1ère étape : calculer un profil d’entrée tq PA1= ..=PAk=1/k
2ème étape : choisir qN et en déduire N, le nombre de DT
3ème étape : générer N DT selon PA1 ,..,PAk
PA : probabilité qu’une donnée de test aléatoire couvre l’élément A
2009
117
2009
118
3ème étape : générer N DT selon PA1 = ..= PAk = 1/k
2ème étape : choisir qN et en déduire N
Si qN = 0.85
A1
A2
A3
N = 8 convient
A4
2009
119
2009
120
Test statistique structurel : exemple (1)
(I,B,C) ∈ Dom(P) = {-231,..,231-1} x {0,1} x {0,1}
objectif de test : couvrir tous_les_chemins
avec qN = 0,99
I≥0
Calcul des proba. sur Dom(P) afin que :
P1-2-5-6 = P1-2-3-5-6 = P1-2-3-4-5-6 = P1-2-3-4-6 = ¼
1
2
on pose :
x = P{I < 0}, y = P{B}, z = P{C}
2
I<0
3
¬B
P1-2-5-6 = P{ I < 0 }
C
P1-2-3-5-6 = P{ I ≥ 0 } . P{ B }
4
P1-2-3-4-5-6 = P{ I ≥ 0 } . P{ ¬B } . P{ C }
¬C
P1-2-3-4-6 = P{ I ≥ 0 } . P{ ¬B } . P{ ¬C }
2009
1
B
5
4
(1-x) . y = ¼
C
5
¬C
2009
122
Test statistique structurel : limites et extensions
- le biais introduit par les chemins non-exécutables n’est
pas pris en compte
2
I≥0
I<0
3
B
¬B
C
5
¬C
6
2009
¬B
6
121
1
4
B
(1-x) . (1-y) . (1-z) = ¼
6
Nbre de DT à générer (si qN = 0.99 ) :
Par la relation
N ≥ ln(1-qN) / ln(1- pC)
on obtient N ≥ 16
I<0
3
d’où :
x=¼
(1-x) . (1-y) . z = ¼
Profil d’entrée :
P{I < 0} = 1/4 et P{I ≥ 0} = 3/4
P{B}
= 1/3 et P{¬B} = 2/3
P{C}
= 1/2 et P{¬C} = 1/2
I≥0
123
- génération du profil d’entrée pour les critères
tous_les_sommets, tous_les_arcs nécessite une prise en
compte fine des boucles
- générateur uniforme dans un sous-domaine d’entrée
défini sous contraintes difficile à réaliser
Mais fonctionne bien avec des données expérimentales !
[Thévenod-Fosse,
Waeselynck 91]
2009
124
Test statistique structurel : travaux et outils
Exercice :
LAAS – groupe TSF :
Evaluation expérimentale sur quelques modules de
surveillance d’un réacteur nucléaire (critères GFC+GDU)
SESAME : test statistique et analyse de mutation
short P(short x, short y, short z)
{
short t ;
1. if (x < y)
2.
if (y < z)
3.
t=z;
else
4.
t=y;
else
5.
if (x > z)
6.
t=x;
else
7.
t = z;
8. return t;
}
IRISA / Celtique :
AUGUSTE (LRI) : Test statistique et structures combinatoires
Projet GENETTA : Test statistique structurel pour Java Card
LSR-IMAG – équipe VaSCo :
Test statistique fonctionnel de programmes Lustre -LUTESS
2009
a) Que calcule P ?
b) Déssiner le GFC de P
c) Calculer un profil d’entrée
qui rende équiprobable
chacun des chemins de P
d) Déterminer le nombre N de
DT à générer pour couvrir
tous_les_chemins avec
qN = 0.8
Indications : ln(0.2)=-1.6 et ln(0.75)=-0.28
126
[Korel 90]
Plan
Objectif : Calcul de X tel que le chemin c soit sensibilisé ?
{X | c=exec(P,X)}
2.1 Test aléatoire
2009
Dom(P)
127
2009
Méthode dynamique orientée-chemin
e
Principe :
Transformer le problème en
un problème de minisation d’une
fonction objectif, sous contraintes
n2
n1
2009
n3
n4
n5
= problème classique de
Recherche Opérationnelle
129
}2009
n2
n4
n3
n6
s
130
Idée : utiliser des exécutions du programme
Relat
< 0
≤ 0
< 0
≤ 0
= 0
< 0
X
minimiser Fn
k-nk+1
(X)
en conservant e-n1-..-nk parcouru
Avec la technique de la variable alternée--[Glass & Cooper 65]
si X=(x1,..xN), xi varie, xj est fixée ∀j≠i
* basée sur des essais de valeurs
* méthode directe (sans utilisation de différentielles)
* heuristique incomplète !
Nota : Fd(X) dépend implicitement des variables d’entrée
2009
k+1
n1
Etape critique : minimiser la fonction de branche
Fonction de branche Fd(X) à valeurs réelles :
Fonction de branche Fd(X)
E2 – E1
E2 – E1
E1 – E2
E1 – E2
abs(E1 – E2)
- abs(E1 – E2)
2) identifier nk (ou pk) le premier sommet
pour lequel nk+1 ≠ pk+1
n5
3) X minimiser Fn -n (X)
s
e
X
random ;
tant que( exec(P,X) ≠ e-n1-..nq-s)
{
1) noter le flot (par instrumentation)
exec(P,X) = e-p1-..-pj-s
k
n6
Fonction de branche : définition
Décision d
E1 > E2
E1 ≥ E2
E1 < E2
E1 ≤ E2
E1 = E2
E1 ≠ E2
128
Méthode dynamique : algorithme
Objectif :
Calcul de X tel que c = exec(P,X) ?
Minimiser la fonction de branche F(X)
131
2009
132
Exemple: programme Puissance(X,Y)
Méthode dynamique : algorithme
e
X
random ;
tant que( exec(P,X) ≠ e-n1-..nq-s)
{
1) noter le flot (par instrumentation)
exec(P,X) = e-p1-..-pj-s
n1
n2
n4
2) identifier nk (ou pk) le premier sommet
pour lequel nk+1 ≠ pk+1
n5
3) X minimiser Fn -n (X)
k
k+1
s
133
2009
Méthode dynamique orientée-chemin : exemple (1)
Calcul de X tq a-b-(c-b)2-d-f
(X,Y)
(18,-34)
1) exec(P,(18,-34))=
a-b-(c-b)2-(c-b)32-d-e-f
2) donc k=b-d et
Fb-d((X,Y))= abs(w)
on a Fb-d(18,-34)=32
par la méthode de la variable alternée :
(X,Y) (18,-2) et Fb-d(18,-2)=0
2009
X2
c
P(short x,y)
w= abs(y)
z= 1.0
b
w != 0
return(z)
y<0
e
f
135
Limites :
technique de minimisation limitée à l’essai de valeurs
heuristique incomplète
Extensions :
- Illinois Institute of Technology (USA) – Bogdan Korel
tous_les_arcs + analyse dynamique de flot de données
- University of York (UK) – group Testsig
minimisation de la fonction de branche par recuit-simulé
- University of Arizona (USA) – projet et outil TGEN
relaxation itérative + découverte dynamique d’invariants
b
w != 0
z= z * x
w= w-1
y<0
z=1.0 / z
e
f
134
Calcul de X tq a-b-(c-b)2-d-f
par la méthode de la variable alternée :
(X,Y) (18,2) et
exec(P,(18,2))= a-b-(c-b)2-d-f
2009
X2
c
a
P(short x,y)
w= abs(y)
z= 1.0
b
w != 0
z= z * x
w= w-1
d
y<0
z=1.0 / z
return(z)
e
f
136
Bibliographie (sélective) pour ce cours
Méthode dynamique : limites et travaux
2009
P(short x,y)
w= abs(y)
z= 1.0
d
3) exec(P,(18,-2))=
a-b-(c-b)2-d-e-f
4) donc k = d-f et
Fd-f((X,Y))= -y
on a Fd-f((18,-2))=2
z= z * x
w= w-1
z=1.0 / z
c
a
Méthode dynamique orientée-chemin : exemple (2)
a
d
while ( w != 0 )
{
z =z*x;
w=w-1;
}
if ( y<0 )
z = 1.0 / z ;
return(z) ;
}
n6
}2009
n3
double P(short x, short y) {
short w = abs(y) ;
double z = 1.0 ;
137
[Duran & Ntafos 84]
«An Evaluation of Random Testing»
IEEE Trans. on Software Engineering SE-10 N°4 July 1984
[Thévenod-Fosse & Waeselynck 91
«An Investigation of Statistical Software Testing»
Journal of Software Testing, Verification and Reliability Vol1
N°2 Juil-Sept. 1991
[Korel 90] «Automated SoftwareTest Data Generation»
IEEE Trans. on Software Engineering SE-16 N°8 Aug. 1990
2009
138
Rappels (notations et un résultat)
Plan
∈ Dom(P)
Donnée de test :
X
Jeu de test
:
T =
Oracle okF
: Dom(P) x Ran(P)
exec(P,X)
: chemin complet du GFC sensibilisé par X
{Xi}i
=1..N
Bool
2.1 Test aléatoire
Soit e un élément du GFC de P (sommet, arc ou chemin),
existence de X tel que e soit inclus dans exec(P,X) ?
Weyuker 79 : indécidable dans le cas général !
2009
139
[King 76, Clarke 76]
Utilisation d’expressions algébriques pour représenter
les valeurs des variables
Utilisé en vérification (preuve),
optimisation dans les compilateurs, spécialisation,
en génération automatique de cas de test, etc.
141
Etat symbolique
Exécution symbolique simple : exemple
a
P(short x,y)
short w= abs(y)
double z= 1.0
Ex : a-b-(c-b)2-d-f avec X,Y
b w != 0
a: w := abs(Y); z := 1.0 ;
z= z * x
b: abs(Y) != 0;
c w= w-1
c: z := X; w := abs(Y) – 1;
b: abs(Y)-1 != 0;
d y<0
c: z := X * X; w := abs(Y) – 2;
b: abs(Y)-2 = 0;
z=1.0 / z e
d: Y ≥ 0
return(z) f
f: return(X * X)
2009
142
<Path,State,PC> : exemples
Notations : P un programme de GFC (N,A,e,s),
X vecteur d’entrées symboliques,
Var(P) dénote l’ensemble des variables internes de P
Définition (Etat symbolique) : <Path, State, PC> où :
Path = ni-..-nj est un chemin (partiel) du GFC
State = {<v,ϕ>}v∈Var(P) -- ϕ une expr. algébrique de X
-- ck condition portant sur X
PC = c1∧.. ∧ cn
< a, {<z, ⊥>, <w, ⊥>}, true>
a
< a-b-c-b,
{<z, X>, <w, abs(Y)-1>},
abs(Y) != 0 >
b
c
< a-b-(c-b)2-d-f,
{<z, X2>, <w, abs(Y)-2>},
(abs(Y) != 0)∧(abs(Y) != 1)
∧(abs(Y) = 2)∧(Y ≥ 0) >
NB : PC pour Path Condition
2009
140
Evaluation (avant) d’un chemin du GFC
avec des valeurs symboliques
Technique d’analyse orientée-chemin du GFC
- Exécution symbolique simple
- Evaluation symbolique dynamique
- Evaluation symbolique globale
2009
2009
2009
w != 0
z= z * x
w= w-1
d
y<0
z=1.0 / z
return(z)
143
P(short x,y)
short w= abs(y)
double z= 1.0
e
f
144
Etat symbolique : propriétés
Analyses avant et arrière
Analyse avant :
- suivi de Path dans le sens d’exécution
<Path, State, PC> se calcule par induction sur
chaque instruction des sommets de Path
- intéressant pour le calcul des états symboliques
complets
soit SPC l’ensemble solution de PC
∀X∈SPC, Path est inclus dans exec(P,X)
Si SPC = ∅ alors Path est non-exécutable
ex : < a-b-d-e-f, {…}, abs(Y)=0 ∧ Y<0 >
2009
145
Ex : a-b-(c-b)2-d-f avec X,Y
a
PC f,d: Y ≥0
b
X2
PC c: Y ≥0, w-1 = 0
c
PC b: Y ≥0, w-1 = 0, w != 0
PC b: Y ≥0, w-2 =0, w-1 != 0,w != 0
2009
return(z)
P(short x,y)
short w= abs(y)
double z= 1.0
a
y<0
b
c
PC:
(abs(Y) != 0)∧(abs(Y) != 1)
∧(abs(Y) = 2)∧ (Y ≥ 0)
P(short x,y)
short w= abs(y)
double z= 1.0
w != 0
z= z * x
w= w-1
d
y<0
+
z=1.0 / z
e
z=1.0 / z
Résolution interactive des conditions
f
return(z)
147
2009
e
f
148
Evaluation symbolique dynamique
- Simplifications algébriques + traitement “manuel”
[King 76, Howden 76, Coen-Porisini et al. 91, Coward 95]
- Programmation Linéaire mixte –[Clarke 76, Boyer et al. 75]
- Essais de valeurs + retour arrière [Ramamoorthy et al 76]
Problème 1 : hypothèses très fortes sur
les programmes analysés
Problème 2 : choix d’un chemin au préalable
chemin éventuellement non-exécutable !
146
X2
a-b-(c-b)2-d-f
Résolution interactive des conditions
2009
Par exécution symbolique simple
(analyse arrière de préférence)
w != 0
z= z * x
w= w-1
d
PC c: Y ≥0, w-2 = 0, w-1 != 0
PC a: Y ≥0, abs(Y)-2 = 0,
abs(Y)-1 != 0, abs(Y) != 0
2009
Génération automatique de données de test
Analyse arrière : exemple
PC b: Y ≥0, w = 0
Analyse arrière :
- suivi de Path dans le sens inverse d’exécution
- intéressant pour le calcul de PC car moins coûteux en
place mémoire (State n’est pas calculé)
149
Evaluation symbolique simultanée d’un chemin
concrètement exécuté, avec une donnée de test DT
Le chemin suivi est celui de exec(P,DT)
Implantation par instrumentation de toutes les instructions
Fournit une vue symbolique de PC,
utile pour la mise au point du programme
2009
150
Evaluation symbolique globale : principe
Evaluation symbolique globale : exemple
<z1, 1.0>,
<w1, abs(Y)>
Représentation de tous les chemins par un arbre
d’exécution
Nécessite une analyse des boucles (loop analysis) :
∧ PC: Y<0
zk+1 = zk * X
wk+1 = wk - 1
b
<zk+1, zk * X>,
<wk+1, wk - 1>
Utile pour la preuve de programme et l’optimisation mais
très coûteux en temps de calcul et en place mémoire
151
échec
2009
∧ PC: Y≥0
<z,1.0>
c
∧ PC: Y<0
∧ PC: Y≥0
<z, 1/zk+1>
<z, zk+1>
w != 0
z= z * x
w= w-1
d
∧ PC: wk+1 = 0
P(short x,y)
short w= abs(y)
double z= 1.0
y<0
z=1.0 / z
return(z)
e
f
152
Problems for symbolic evaluation techniques
Propriétes : diagramme commutatif
Programme P, X vecteur d’entrées symboliques, DT donnée
Econc : exécution concrète
Esymb : évaluation symbolique globale
P(X), DT
PC: abs(Y) != 0
z1 = 1.0
w1 = abs(Y)
while( w != 0 )
{
z = z*x ;
w = w-1 ;
}
2009
PC: abs(Y) = 0
a
Number of iterations in loops must be selected prior to any symbolic execution
Arrays
int P(int i) {
P(X), X DT
A[47] = 18;
A[29] = 46;
if ( A[i] < 6 { …
A[47],A[29] et A[i] are seen as a single variable A.
Note that interesting solutions exist for this problem (Coen-Porisini & De Paoli 1993)
Exec. concrète
Eval. symb. glob.
Symbolic execution constrains the shape of dynamically allocated objects
int P(struct cell *t) {
if( t == t->next ) { …
Econc(P(DT)) =
Esymb(P(X)) DT
Esymb(P(X)), DT
t
constrains t to:
key next
?
2009
153
Travaux et outils pour l’évaluation symbolique
2009
154
On-the-fly selection of feasible paths:
The PathCrawler tool
* PathCrawler/CAVEAT(CEA) Vérification de programmes C
* SYMBAD/SESADA (Université Polytech. de Milan)
Tableaux, Spécialisation de programme ADA
N. Williams, B. Marre, P. Mouy and M. Roger. PathCrawler: Automatic Generation
of Path Tests by Combining Static and Dynamic Analysis. In Proc. Dependable
Computing - EDCC 2005, Budapest, Hungary, April 2005
http://www-list.cea.fr/labos/fr/LSL/test/pathcrawler/index.html
* MulSaw project (MIT) – Model-Checking pour Java
* PREfix, SLAM (Microsoft Reliability Group) -- Détection de
fautes pour C
Addresses the problem of non-feasible paths in path-oriented test data generator
for C programs
Outils commerciaux :
MALPAS (TA Consultancy – UK) – SPADE pour ADA
An (important) emerging idea in CBT: papers in PLDI (Godefroid et al. 2005),
ESEC/FSE (Sen et al. 2005), POPL (Godefroid 2007), …
2009
155
A randomized algo. based on dynamic symbolic execution and constraint
satisfaction over finite domains (a proprietary constraint library in Eclipse Prolog)
2009
156
An example (1)
The idea
1
1
2
2
3
4
1
1
3
2
f(
{
3
b
4
5
Generate a random input and
dynamic symbolic exec. over
the corresp. feasible path
4
5
Backtrack and try to
solve the remaining CS
return j;
)
j = 2;
if( i ≤ 16 )
j = j * i;
157
1
2009
( i = 15448)
2
f
Path 1-3-5
3
f(
{
int i
t
return j;
4
f
j = 2;
if( i ≤ 16 )
j = j * i;
j1=2
i > 16
if( j > 8)
j = 0;
j1 > 8
159
t
4
f
Unsatisfiable, therefore
Path 1-3-4 is non-feasible
2009
An example (4)
160
An example (5)
1
j = 2;
if( i ≤ 16 )
j = j * i;
3
return j;
}
2
f
5
)
t
Try to solve
)
5
int i
158
1
t
}
f(
{
4
f
An example (3)
if( j > 8)
j = 0;
2009
t
5
Random imput generation
int i
3
}
An example (2)
f(
{
2
f
if( j > 8)
j = 0;
If unsatisfiable then path is
non-feasible and problem comes
from the last constraint
Else coverage of feasible
path is improved
2009
t
)
j = 2;
if( i ≤ 16 )
j = j * i;
b
5
Try to solve the CS where
the last constraint is refuted
int i
1
t
Bactrack and try to solve
( i = 2 ) -- Path 1-2-3-5
if( j > 8)
j = 0;
2
f
j1=2
i <= 16
3
f(
{
int i
t
t
)
j = 2;
if( i ≤ 16 )
j = j * i;
Bactrack and try to solve
j1 = 2
i <= 16
j2 = j1*i
if( j > 8)
j = 0;
j2 > 8
2
f
3
t
( i = 10) -- Path 1-2-3-4-5
return j;
4
f
}
return j;
5
2009
4
f
All-paths covered with three test
data (i = 15448, i = 2, i = 10)
}
5
161
2009
162
Plan
The PathCrawler method: discussion
Requires to bound the number of iterations in loops
suitable for automatic test data generation for the All-k-paths criterion
2.1 Test aléatoire
Performance of the method depends on the first initial random input
Numerous extensions to handle pointers as input parameters, logical decisions,
function calls, bit-to-bit operations
2009
163
An example of the core problem
int i
if( j > 8)
j = 0
3
f(
{
2
f
int i
t
if( j > 8)
j = 0
value of i to get there ?
f
)
j = 2
if( i ≤ 16 )
j = j * i
4
i > 16 ⇒ j = 2
i ≤ 16 ⇒ j = 2 * i
i ≤ 16, 2 * i > 8
return j
return j
}
}
5 ≤ i ≤ 16
5
2009
164
j>8
t
)
j = 2
if( i ≤ 16 )
j = j * i
Intuition of our approach
1
f(
{
2009
165
2009
166
[Bicevskis 79, Gotlieb et al 98]
* Technique d’analyse du GFC orientée-but
Goal-oriented test data generation
A three-step process:
* Transformation systèmatique du problème en un
problème de résolution de contraintes
Generate a constraint model of the whole program
Choose a goal: point to be reached or property to be refuted
Generate a test data that respects the model and satisfies the goal
Useful for generating test data that reach a single testing objective
(reach a statement or a branch, find a counter-example to a property, etc.)
Main tools: InKa (Gotlieb Botella Rueher 2000), GATEL (Marre 2000),
EUCLIDE (Gotlieb 2008)
2009
167
2009
168
A constraint model of imperative programs
SSA form
Each use of a variable refers to a single definition
Viewing an assignment statement as a relation requires to rename the variables
x1 := x0 + y0;
y1 := x1 – y0;
x2 := x1 – y1;
x := x + y;
y := x – y;
x := x – y;
i2 = i1 + 1
i := i + 1
At the junction nodes
1
Static Single Assignment (SSA) form (Cytron 1991)
or single assignment language
i := ...
3
2009
169
SSA : example
a
b
c
PSSA(short x,y)
w1= abs(y)
z1= 1.0
P(short x,y)
short w= abs(y)
double z= 1.0
a
w != 0
b
w3 =φ( w1,w2)
z3 = φ( z1,z2)
w3 != 0
d
y<0
z= z * x
w= w-1
d
z2 = z3 * x
w 2= w 3 - 1
c
y<0
z=1.0 / z
e
e
z5 = φ(z4,z3)
return(z5)
return(z) f
2009
ush
3
... := i + ...
J 2 = J1 * I
I = J
I < J
Conditionnal (SSA)
If D then C1; else C2; v3=φ(v1,v2)
i3 := φ( i1,i2)
... := i3 + ...
170
- élimine les anti-dépandences (chemins_ud) et les
dépandences-de-sortie (chemins_dd)
D = définitions de x,
U = utilisations de x
le nombre de chemins_du par rapport à x est
en O(|D|x|U|) dans P, en O(|A|) dans PSSA
Nota: attention, |Var(PSSA)| >> |Var(P)|
Utilisation des
dépendances de contrôle
= ensemble de conditions à vérifier
pour atteindre e
Arithmetical constraints {=, <,..}
j2 = j1 * i
i == j
i < j
172
Cond1
t
Cond2
t
t
(D /\ C1 /\ v3=v1) \/ (¬D /\ C2 /\ v3=v2)
Nota : calculable syntaxiquement si
le programme est structuré
v3=v1 \/ (D1 /\ C1 /\ ¬D2 /\ v3=v2 ) \/ …
173
Ce = ¬ Cond4 ∧ Cond2 ∧ Cond1
2009
Cond3
f
Cond4
t
i2 := ..
2
Testing objective (1)
I ∈ 0 .. 232-1
Assignment, decision
2009
i1 := ...
Domain constraint
i
Iteration (SSA)
v3=φ(v1,v2) while D do C
1
- SSA autorise la commutativité des instructions
f
Constraint system
Variable declaration
i := ...
- les GFCs (N,A,e,s) de P et de PSSA sont identiques
2009
SSA form
2
Forme SSA : propriétés
- si
alors
z4 =1.0 / z3
φ_functions
f
e
174
Testing objective (2)
Problems for goal-oriented test data generation
- Constraint solving over disjunctions of constraints is required
(conditionals, switch, iterations)
- In functional testing, property to be refuted (e.g. a post-condition of the program)
- Conditional aliasing problems
Ex: JML specification of method debit() from the SUN’s Wallet Java Card program
//@ requires amount >= 0;
ensures balance == \old(balance) – amount;
signals (DebitException) amount > balance;
@*/
public void debit(int amount) {...}
How to reach branch 5-6 ?
1.
2.
3.
4.
5.
6.
Ce = ¬( balance = old_balance – amount)
...
if( C )
p = &i ;
i = 10 ;
*p = 0 ;
if( i < 5 )
...
« reaching branch 5-6 » ⇒ « p points to i at statement 4 » ⇒ « C is satisfied »
2009
175
2009
176
Bibliographie (sélective) pour ce cours
InKa: a goal-oriented test data generator
based on constraint combinators
[King 76]
« Symbolic Execution and Program Testing »
Communications of ACM Vol 19, N°7, Jul. 1976
Automatic Test Data Generation using Constraint Solving Techniques
A. Gotlieb, B. Botella, M. Rueher
[Clarke 76]
«A System to Generate Test Data and Symbolically Execute Programs »
IEEE Trans. on Software Engineering SE-2 N°3 Sep. 1976
[Bicevskis, Borzovs, Straujums,Zarins,Miller 79]
«SMOTL – A System to Construct Samples for Data Processing Program
Debugging»
IEEE Trans. on Software Engineering SE-5 N°1 Jan. 1979
2009
177
ACM International Symposium on Software Testing and Analysis (ISSTA'98), Clearwater
Beach, FL USA, March 1998
Addresses the problem of loops, non-feasible paths, floating-point numbers and pointer
aliasing in goal-oriented test data generator for C programs
A deterministic algo. based on SSA, Constraint combinators over finite domains
(built over SICStus clp(fd) constraint library)
More than 10 years of Research, three prototype tools, fifteen published papers
2009
178
Conditional: the combinator ite
Modelling an error-free semantics
0
The constraint model of programs does not have to handle
errors or exceptions as it is targeted to generate test data for detecting
functional faults
int f( int x, int y) {
return( x / y )
}
Then_part
v := Decision ;
if(v)
2
1
Else_part
3
R=X/Y
Executing f with (x=1, y=0) throws an exception while the constraint
R = X / Y just removes 0 from the domain of Y. Therefore, the possible erroneous
execution is not considered by the constraint model. This is ok as the goal of CBT
is to detect functional faults and not runtime errors !
ite( V, CTHEN, CELSE, MIN, MOUT) :• V=1
→ CTHEN ∧ MOUT = MTHEN
• V=0
→ CELSE ∧ MOUT = MELSE
• ¬(V=1∧ CTHEN∧ MOUT = MTHEN) → V=0 ∧ CELSE∧ MOUT = MELSE
• ¬(V=0∧CELSE∧ MOUT = MELSE) → V=1 ∧ CTHEN∧ MOUT = MTHEN
• MOUT := Proj(OUT, MTHEN ∪ MELSE)
2009
179
2009
MIN := Proj(IN, MTHEN ∪ MELSE)
180
Iteration: the combinator w
2
1
Example (1)
V := Decision ;
while( V )
Body
f(
{
3
I ∈ 0 .. 232-1,
J1 = 2,
ite( I ≤ 16, J2 = J1 * I ∧ J3 = J2,
RET = J5.
return j;
}
Where ∇ stands for a widening operator
181
Example (2)
2009
I=4
Impossible
1≤I≤4 ?
f(
{
I ∈ 0 .. 232-1,
J1 = 2,
ite( I ≤ 16,
J2 = J1 * I ∧ J3 = J2, J3 = J1),
ite( J3 > 8, J4 = 0 ∧ J5 = J4, J5 = J3),
RET = J5.
int i
RET = 8 ?
RET = 12 ?
Test datum: I = 10
)
j = 2;
if( i ≤ 16 )
j = j * i;
if( j > 8)
j = 0;
return j,
}
2009
182
Example (3)
5 ≤ I ≤ 16
RET = 2
J3 = J1),
ite( J3 > 8, J4 = 0 ∧ J5 = J4, J5 = J3),
if( j > 8)
j = 0;
• ¬(V=1 ∧ CBODY ) → V=0 ∧ MOUT=MIN
• ¬(V=0 ∧ MOUT=MIN)→ V=1 ∧CBODY ∧ w(V,CBODY,MBODY,MOUT)
• MOUT := Proj(OUT, MBefore ∇ MBody)
MIN := Proj(IN, MBefore ∇ MBody)
I = 18 ?
)
j = 2;
if( i ≤ 16 )
j = j * i;
w(V, CBODY, MIN,MOUT) :• V=1 → CBODY ∧ w(V, CBODY,MBODY,MOUT)
• V=0 → MOUT = MIN
2009
int i
I ∈ 0 .. 232-1,
J1 = 2,
ite( I ≤ 16,
J2 = J1 * I ∧ J3 = J2,
J3 = J1),
ite( J3 > 8, J4 = 0 ∧ J5 = J4, J5 = J3),
RET = J5.
J3 > 8 ?
2 ≤ RET ≤ 8
183
2009
184
Extensions (in CELTIQUE)
The InKa method: discussion
Handling conditional pointer aliasing problems
constraint-based test data generation for pointer programs
(Gotlieb Denmat Botella COMPSAC’05, ASE’05, IST’07)
Handles nicely conditonals and loops
Handling floating-point numbers in constraint-based structural test data
generation (Botella Gotlieb Michel STVR 2006)
First introduction of constraint satisfaction techniques in
structural software testing
Efficient handling of conditional and iterations based on Abstract Interpretation
techniques (Denmat Gotlieb Ducassé CP 2007)
Suitable for generating test data in front of a single testing objective
(to complete an existing test suite)
Efficient implemention in progress (access through a web service) :
EUCLIDE (Gotlieb ICST 2009)
Can be stucked on infinite loops (time-out required)
also http://euclide.gforge.inria.fr/
2009
185
2009
186
Récapitulatif des techniques pour le test structurel
Eval. symbolique
Conclusions sur cette partie du cours
- Test et preuve sont complémentaires
- Par essence, le test est une recherche de contre-exemples
- Test structurel et fonctionnel sont complémentaires
Test statistique
- Techniques de génération de cas de test variées
Méthode à
contraintes
- Apport fondamental des « Contraintes » au domaine du Test
Méthode
dynamique
2009
187
2009
188
Génération automatique de données de test (1)
0. Préliminaires
Techniques élémentaires
- Test exhaustif
- Test par échantillions
- Test aléatoire
2009
189
2009
190
Test exhaustif : limitation et intérêt
Test exhaustif
- Mais, généralement impraticable !
Dom(P)
P (ush x1, ush x2, ush x3)
{ ... }
232 possibilités × 232 possibilités × 232 possibilités = 296 possibilités
- Parcours exhaustif du domaine d’entrée des programmes
- Séléction de toutes les données de test possible
ex d’objectif : atteindre une instruction dans le programme
- Equivalent à une preuve de correction du programme
2009
- Estimation de la taille de l’espace de recherche
face à un objectif de test
191
2009
192
Test par échantillion
Test aléatoire
Dom(P)
Loi de probabilité uniforme sur le domaine d’entrée
(i.e. chaque DT est équiprobable)
X5 X6
X1 X2 X3
X4
- Utilisation de générateurs de valeurs pseudo-aléatoires
Forme faible du test exhaustif : test par échantillion
Exemples :
{0, 1, 2, 232-1} pour un ush
{NaN, -INF,-3.40282347e+38, -1.17549435e-38, -1.0, -0.0,.. }
pour un float (IEEE 754)
2009
193
- Nécessité de disposer d’un oracle automatique
- Condition d’arrêt à déterminer (nombre de DT à générer,
critère de test couvert)
2009
Génération d’une seule donnée de test
par élément à vérifier !
(ex : chemins de P)
j
Dom(P)
Dom(P)
X4
C1∧¬C2
C1∧C2
if( C2)
else ...
}
¬C1∧¬C2
X1
X2
X3
¬C1∧ C2
i
2009
195
Couverture probabiliste du critère C
X5
X4
196
A2
A1
A3
SC = {A1,..,A4}
A4
X6
X8
Dom(P)
X2
X7
2009
p{x∈A} : probabilité qu’une DT aléatoire x couvre l’élément A
Dom(P)
X1
Efficacité du test aléatoire pour couvrir un critère ?
Génération aléatoire de données de test
selon une distribution de probabilités
(ou profil d’entrée)
2009
194
Couverture déterministe d’un critère C
P(int i,int j)
{
if( C1 )
else ...
X3
197
Ici p{x∈A1} < p{x∈A2} < p{x∈A3} < p{x∈A4} donc le
test aléatoire couvre « mieux » A4 que A1, ce qui n’est
pas2009
satisfaisant !
TestINSA
statistique
structurel [Thévenod19890]
-- Test de Logiciels
Génération automatique de données de test (2)
« The program reads three integer values from a card. The
three values are interpreted as representing the lengths of
the sides of a triangle. The program prints a message that
states whether the triangle is scalene, isocele, or
equilateral »
[Myers 79]
Techniques de test fonctionnel
- Analyse partitionnelle
- Test aux limites
- Test à partir de Graphes Cause/Effet
2009
Ecrire un jeu de test que vous sentez être adéquate pour
tester ce programme
199
Quelques remarques générales sur le test fonctionnel
- Génération de données de test + oracle pour ces
données (à la différence du test structurel)
n
pass / fail
201
Analyse partitionnelle (2)
- Division du domaine d’entrée en classes valides et invalides
- Choix d’un représentant dans chacune des classes
d’équivalence
- Existence de règles générales de découpage (non uniques)
a ≤ 0, a> 0 ou a<0, a=0,a>0
∅, [a,b] où a < b < ∞, [-∞,+∞]
∅, {a}, {a,b}, {a,b,c}, ...
nil, a
, ...
nil nil
et
∀i, j ∈1..n, Ci ∩Cj = ∅
i=1
2009
202
Partitionnement unidimensionnel
- Permet au testeur de passer d’un nombre infini de données
à un nombre fini et limité de données de test
2009
Analyse partitionnelle (1)
U Ci = D
i
Exécution
des tests
200
- Soit D le domaine d’entrée, {C1,..,Cn} est une
partition de D ssi :
implementation
Entier
:
Intervalle :
Ensemble :
Arbre bin. :
- Idée : Découper le domaine d’entrée en classes
d’équivalence : ensembles d’entrées aboutissant
au même comportement fonctionnel
Génération
de tests
Jeu de test
2009
2009
- Technique de test majoritairement employé en
présence de spécifications informelles
spécifications
Correction ?
Un test pour soi-même
203
Considérer une variable à la fois. Ainsi, chaque variable
d’entrée du programme conduit à une partition du
domaine d’entrée. Cette méthode est appelée
partitionnement unidimensionnel
Ce type de partitionnement est le plus utilisé (et le plus
simple à mettre en oeuvre). Néanmoins, il n’exerce pas
certaines combinaisons pouvant conduire à détecter
des fautes
2009
204
Partitionnement multidimensionnel
Partitionnement unidimensionnel : example
Considérer le domaine d’entrée comme le produit
Cartésien des domaines de chaque variable d’entrée.
Cette méthode conduit à la création d’une unique
partition. Cette méthode est appelée partitionnement
multidimensionnel.
PGCD(ENTIER a, ENTIER b)
Classes valides
C1 : a = 0,
C2 : a > 0,
D1 : b = 0,
D2 : b > 0
Grand nombre de cas de test, difficiles à gérer
manuellement. Cependant, bien que certaines classes
créées puissent être invalides, cette méthode offre une
grande variété de cas de test.
2009
205
PGCD(ENTIER a, ENTIER b)
2009
206
L’expérience montre que les programmeurs font
souvent des erreurs aux bornes des classes
d’équivalence
Classes valides
C1 : a = b = 0
C2 : a = b, a > 0, b > 0
C3 : a >= 0, b >= 0, a ≠ b
Par exemple, si le programme P est sensé calculer
une fonction F1 lorsque x<0 est vraie et calculer F2
sinon et qu’il calcule F1 uniquement lorsque x< -1
alors P contient une faute qui peut ne pas être
révelée par une analyse partitionnelle (x ≤ 0, x > 0
ou x<0, x=0, x>0).
Classes invalides
C4 : a < 0, b < 0
C5 : a < 0, b > 0
C6 : a > 0, b < 0
Classes invalides
C3 : a < 0,
D3 : b < 0
Erreurs aux limites
Partitionnement multidimensionnel : example
2009
Problème :
a = b = 0 appartient à C1 et à D1
207
Test aux limites
2009
208
Test aux limites de l’intervalle [1,100]
1
- Idée : Identification des données de test « limites » définies
par la spécification suite à l’analyse partitionnelle
0
- Sélection de données de test aux bornes valides et
invalides
1
100
2
99 100
101
Mais combinatoire importante en présence de vecteurs
d’entrées
définition de voisinages discrets
- Formalisation de la notion de limite difficile dans le cas
général
heuristiques de choix des valeurs
Ecrire des définitions possibles de voisinages discrets
d’1 point en dimension 2, puis généralisez en dimension n
2009
209
2009
210
Graphes cause-effet : example (1)
Graphes cause-effet
- Idée : Réseau logique qui relie les effets d’un programme
(sorties) à leurs causes (entrées)
4 types de symboles :
Analyse des causes :
A1 : le caractère de la première colonne est A
A2 : le caractère de la première colonne est B
A3 : le caractère de la deuxième colonne est un chiffre
Analyse des effets :
M1 : programme ok
M2 : message X12
M3 : message X13
négation
identité
~
OU logique
ET logique
∨
∧
2009
« Le caractère dans la colonne 1 doit être un A ou un B.
Dans la colonne 2, il doit y avoir un chiffre. Si le premier
caractère est erroné, le message d’erreur X12 doit être
imprimé. Si dans la colonne 2 nous n’avons pas de
chiffre, alors le message X13 est imprimé »
211
Graphes cause-effet : example (2)
2009
212
Graphes cause-effet : génération de cas de test
- Causes et effets sont vus comme des variables booléennes
~
A1
∨
A1 : le car de col 1 est A
A2 : le car de col 1 est B
A3 : le car de col 2
est un chiffre
M1 : programme ok
M2 : message X12
M3 : message X13
M2
E
A2
∧
~
A3
2009
M1
M3
213
Matrice de décision
~
∨
∧
~
A3
2009
A1 et A2 vrais où A1 : le car de col 1 est A
2009
214
Génération de cas de test concrets
M2
E
A2
- Elimination des combinaisons invalides : «comportements
inobservables» (représentées par une contrainte sur le
graphe cause effet)
Par ex:
A1
- Génération automatique d’une matrice de décision
(matrice booléenne, Vrai : 1 Faux : 0)
à partir du graphe cause-effet
Cause A1 A2 A3 M1 M2 M3
-effet
CT 1
0 0 0 0
1
1
CT 2
M1
M3
0
0
1
0
1
0
CT 3
0
1
0
0
0
1
CT 4
0
1
1
1
0
0
CT 5
1
0
0
0
0
1
CT 6
1
0
1
1
0
0
215
CT 1
A1 A2 A3 M1 M2 M3
0 0 0 0
1
1
CT 2
0
0
1
0
1
0
« C1 », X12 émis
CT 3
0
1
0
0
0
1
« Bz », X13 émis
CT 4
0
1
1
1
0
0
« B3 », ok
CT 5
1
0
0
0
0
1
« Ak », X13 émis
CT 6
1
0
1
1
0
0
« A4 », ok
A1 : le car de col 1 est A
A3 : le car de col 2
est un chiffre
2009
« Ca », X12, X13 émis
M1 : programme ok
M2 : message X12
M3 : message X13
216
Réduction de la combinatoire
Technique de réduction sur le graphe cause-effet
- Si n = nombre de causes, m = nombre d’effets
alors matrice de décision de taille 2n x (n+m)
dans le pire cas
ne peut-être gérée automatiquement
si n est grand (> 30)
- Comment réduire la combinatoire ?
~
A1
∨
M2
E
A2
Idée : Eliminer les CT redondants en identifiant ceux
ayant des comportements similaires (mêmes effets) bien
qu’ayant des causes différentes
Par construction,
(A1 = 1, A2 = 1)
(A1 = 1, A2 = 0)
(A1 = 0, A2 = 1)
conduisent à E = 1 et
aux mêmes effets
∧
~
A3
M1
Seul un des trois est choisi
M3
Règles similaires pour les autres
connecteurs
Ex: CT3 et CT5
2009
217
Exercice :
218
Exercice (2):
The Sendfile command.
In a given network, the sendfile command is used to send a file to a
user on a different file server. The sendfile command takes three
arguments: the first argument should be an existing file in the
sender’s home directory, the second argument should be the name
of the receiver’s file server, and the third argument should be the
receiver’s userid. If all the arguments are correct, then the file is
successfully sent ; otherwise the sender obtains an error message.
1) Modéliser en premier lieu le distributeur sans alarme avec un graphe cause-effet
Puis modéliser le distributeur complet avec alarmes.
3) Réduire la matrice et générer quelques
cas de test représentatifs
219
Modélisation sans alarme
Causes :
C0 = Appuyer sur la touche t1
C2 = Appuyer le verre contre la gâchette
Considérons un distributeur de boissons.
Cet appareil comporte 2 touches lumineuses pour le choix du genre de boisson
désiré. Chacune d'elles clignote s'il n'y a plus de boisson dans le réservoir
correspondant et, dans ce cas, une alarme est émise durant 20 secondes, toutes les 3
minutes. L'alarme est automatiquement inhibée au bout de 15 minutes. Pour que la
distribution ait lieu, il faut appuyer sur une touche valide, puis appuyer le verre contre
la gâchette, sous l'orifice. L'écoulement s'arrête et la touche s'éteint lorsque le verre
n'est plus appuyé. Il se peut toutefois que cette dernière reste appuyée ou que le
liquide déborde du verre. En s'écoulant, le liquide traverse une grille et est recueilli
dans un récipient. Si ce dernier se remplit l'alarme est activée, comme ci-dessus.
2) Générer une matrice de décision
1. Modéliser cette commande avec un graphe cause-effet
2. Générer une matrice de décision
2009
2009
2009
220
Modélisation avec alarme
Causes :
C2 = Appuyer le verre contre la gâchette
C3 = Plus de boisson dans le réservoir
C4 = Récipient plein
Effets :
E0 = la boisson demandée coule
E1 = la touche t1 s’éteint
C0
∧
∧
Effets :
E0 = la boisson demandée coule
E3 = Alarme activée
C0
E0
∧
~
∧
∧
E0
C3
∧
C1
~
C2
2009
~
E3
C1
E1
C4
∧
C2
E2
221
2009
~
∧
~
~
~
∧
E1
E2
222
Matrice de décision
C0
Regroupement fonctionnel et cas de test
C1
C2
C3
C4
E0
E1
E2
E3
CT 1 0
0
0
0
0
0
0
0
0
CT 2 0
0
0
0
1
0
0
0
1
CT 3 0
1
1
1
0
0
0
0
1
Causeeffet
CT 4 1
0
1
0
0
1
0
0
0
CT 5 1
0
0
0
0
0
1
0
0
Caus
eeffet
C0
C1
C2
C3
C4
E0
E1
E2
E3
CT 1
0
0
0
0
0
0
0
0
0
CT 2
0
0
0
0
1
0
0
0
1
CT 3
0
1
1
1
0
0
0
0
1
CT 4
1
0
1
0
0
1
0
0
0
CT 5
1
0
0
0
0
0
1
0
0
…
…
2009
223
Plan du cours d’aujourd’hui
224
Langages OO : objets qui modélisent un problème
et collaborent entre eux pour trouver une solution
-> les techniques de test utilisées pour les
programmes impératifs doivent être adaptées pour
prendre en compte les spécificités des langages OO
Model-Based Testing
t1 est appuyée et la gâchette
enfoncée
la boisson coule
Langages impératifs : fonctions qui transforment
des entrées en sortie
2. Test de logiciel orientés-objet
2009
Fonctionnellement équivalents
Langages orientés objet / langages impératifs
1. Techniques de test élémentaires
3.
2009
Le récipient est plein
L’alarme se déclenche
225
Langages OO et test : un aperçu des
difficultés
2009
226
References
Encapsulation des données
Comment connaître les états internes des objets dont les attributs
sont privés ?
[1] Testing Object-oriented Systems,
Models, Patterns, and Tools,
Robert V. Binder, 2000, Addison-Wesley
Dépendances fortes entre certaines classes
Dans quel ordre tester les classes ?
Que tester dans une classe qui hérite d’une autre ?
Polymorphisme
Plusieurs parties de code peuvent “se cacher” derrière un appel
de méthode polymorphe
2009
227
[2] A Practical Guide to Testing
Object-Oriented Software,
John D. McGregor et David A. Sykes,
2001, Addison-Wesley
2009
228
Principe du test de classe
Partie 1
Unité = la classe
Augmente la confiance que l’on a dans l’implémentation des unités
Vérifie que l’implémentation d’une classe répond à sa
spécification
-> si l’implémentation de la classe est correcte, chaque instance de
la classe devrait fonctionner correctement
Test de classe
2009
Une fois les classes testées séparément : les erreurs lors de
l’intégration de la classe sont plus probalement liées à un interfaçage
incorrect des unités qu’à une implémentation incorrecte de cette
classe
229
Pour chaque classe, décider si on la teste :
comme une unité
comme un composant d’une partie plus large du système
Facteurs de décision :
Rôle de la classe dans le système, degré de risque associé
Complexité de la classe
⌧Nombres d’états, d’opérations, associations avec les autres
classes
Effort à fournir pour tester la classe
Illustration : si la classe fait partie d’une librairie, la tester
intensivement même si tester coûte cher / prend du temps
231
Comment tester ?
Avant l’intégration de la classe
Test de régression après tout changement de code
Modification de code liée à un bug : des cas de test doivent
être ajoutés ou modifiés pour détecter ce bug lors des tests
futurs
2009
232
Le développeur est susceptible de faire des erreurs
d’interprétation de la spécification
N’utiliser que le code pour identifier les cas de test risque de
propager ces erreurs
Un script de test :
crée des instances de classe et un environnement ;
envoie un message à une instance ;
vérifie le résultat de ce message : valeur retournée, état
de l’instance, modification des paramètres d’entrée, valeur
des attributs statiques de la classe ;
Si langage avec gestion mémoire, détruit les instances
créées.
230
Comment choisir des cas de test pertinents ?
Construction d’un script de test qui exécute les cas de test
pour une classe et collecte les résultats des exécutions
2009
Quand tester ?
Quelles classes tester ?
2009
2009
233
Méthode préconisée :
créer des cas de test à partir de la spécification ;
augmenter la suite de tests selon l’implémentation.
Remarque : pour le reste de cette partie 1, nous nous
restreignons au test de classes dites primitives, c’est à dire
indépendantes des autres classes.
2009
234
Utilisation des preconditions
Utilisation des pre- et postconditions
Precondition en OCL
Contribution
Objectif : définir des cas de test pour une méthode à partir de ses
pre- et postconditions
true
(true,Post)
pre1
(pre1,Post)
(not pre1,Exception)●
Idée générale :
déterminer toutes les combinaisons possibles de situations pour
lesquelles une précondition peut être vérifiée et une postcondition
peut être atteinte ;
créer des cas de test pour couvrir ces situations avec des valeurs
spécifiques, incluant des valeurs typiques et des valeurs aux
limites ;
dans le cas d’une programmation de type défensive, prévoir aussi
des cas où les préconditions ne sont pas respectées
not pre1
(not pre1,Post)
(pre1,Exception) ●
pre1 and pre2
(pre1 and pre2,Post)
(not pre1 and pre2, Exception) ●
(pre1 and not pre2, Exception) ●
(not pre1 and not pre2, Exception) ●
pre1 or pre2
(pre1,Post)
(pre2,Post)
(pre1 and pre2, Post)
2009
235
pre1 xor pre2
pre1 implies pre2
If pre1 then pre2
else pre3 endif
2009
Contribution
Postconditions en OCL
(pre1 and not pre2, Post)
(not pre1 and pre2, Post)
(pre1 and pre2, Exception) ●
post1
(Pre, post1 and post2)
(not pre1,Post)
(pre2,Post)
(not pre1 and pre2, Post)
(Pre, post1)
(Pre, post2)
(Pre, post1 and post2)
post1 xor post2
(Pre, post1 and not post2)
(Pre, not post1 and post2)
(pre1 and pre2,Post)
(not pre1 and pre3,Post)
post1 implies post2
(Pre, not post1 or post2)
If post1 then post2
else post3 endif
(Pre and ◘, post2)
(Pre and not ◘, post3)
avec ◘ une condition qui rend post1 vraie
au moment où s’applique la postcondition
237
Exercice: bâtir des cas de test pour la classe Velocity,
dans le cadre d’une Programmation Défensive
Velocity()
Velocity(speed : int, dir:int)
getSpeed() : int
getSpeedX(): int
getSpeedY(): int
getDirection() : int
setSpeed(speed : int);
setDirection(dir : int);
reverse();
reverseY();
reverseX();
Velocity::setDirection(dir:int)
pre : 0<=dir and dir<360
post : direction=dir and speed=speed@pre
Exemple extrait de [2]
2009
238
Critères de test basés sur le flot de contrôle
Critères pour le test de programmes impératifs sont
applicables
Couverture de toutes les instructions
Couverture de toutes les branches
Etc.
Velocity::reverseX()
pre : true
post : speed = speed@pre and direction =
if direction@pre<=180
then (180 – direction@pre)
else (540-direction@pre)
θ
2009
Contribution
(Pre,post1)
post1 or post2
Velocity
236
post1 and post2
● Dans le cas d’une programmation défensive
speed : int
direction : int
● Dans le cas d’une programmation
défensive
Utilisation des postconditions
Utilisation des preconditions (suite)
Precondition en OCL
2009
Mais, des critères spécifiques et mieux adaptés peuvent
être définis
X
239
2009
240
Exemple d’un critère de test basé sur le flot des
données
Soient mj et mk des méthodes appelées
par la méthode m
Soient :
v : variable d’instance
ij : instruction de la méthode mj
qui définit v
ik : instruction de la méthode mk
qui utilise v
Partie 2
mj{
…
ij
…
}
m k{
…
ik
…
}
Test d’intégration
c
Le critère est couvert si :
(v, ij, ik) faisable, un cas de test pour m qui sensibilise
un chemin c entre ij et ik sans redéfinition de v
E
A
2009
241
2009
242
Analyse de dépendances
Notion de bouchon de test
Bout de code sans fonctionnalité qui vise à remplacer un code
fonctionnel
Exemples de dépendances entre classes :
Invocation de méthode de B dans A
Objets B utilisés en tant que paramètres de
méthodes de A
Héritage (cf partie 3)
Utile lorsque le code fonctionnel n’est pas disponible, ou en test
d’intégration pour tester unitairement les méthodes
Ex: int m(int a, int b) {return 0;} à la place de
int m(int a, int b) {if(…) return(f(a)) else return(f(b));…}
Créer un graphe de dépendances
L’utilisation de bouchons est une pratique courante, en test
croisé de logiciels embarqués (cibles non dispo.) et en test de
logiciels OO (composants non dispo.)
2009
243
244
Analyse de dépendances: graphe de dépendances
Analyse de dépendances: diagramme de classes
Has Unique ►
2009
AcctNum
FinancialService
Has ►
0..*
Account
Transaction
Uses
2..*
Account
Applied to ▲
FinancialService
0..*
Provided as ►
Transaction
Uses
Rates
Money
Money
AcctNum
utilise
Array[Int]
0..*
In Effect for ▲
Posted for ▼
1..1
Rates
Extrait de [1]
2009
245
2009
246
Intégration Bottom-Up
Méthode d’intégration recommandée pour les programmes objets
L’intégration débute par les composants qui sont les plus
indépendants
2009
Script de test
Script de test
bouchon
bouchon
composant sous test
composant sous test
interface sous test
interface sous test
composant testé
composant testé
Interface testée
Interface testée
247
2009
248
Script de test
Script de test
bouchon
bouchon
composant sous test
composant sous test
interface sous test
interface sous test
composant testé
composant testé
Interface testée
Interface testée
249
2009
2009
2009
250
Script de test
Script de test
bouchon
bouchon
composant sous test
composant sous test
interface sous test
interface sous test
composant testé
composant testé
Interface testée
Interface testée
251
2009
252
Intégration Top-down
Avantages :
Possibilité de débuter l’intégration dès qu’un composant de
niveau feuille dans le graphe de dépendance est prêt
Pas d’écriture de bouchons
Méthode d’intégration privilégiant le test des composants des
niveaux les plus élevés de l’arbre de dépendance
Inconvénients :
Beaucoup de scripts de test à écrire
Si un composant proche des feuilles dans le graphe est
modifié, certains tests de composants qui en dépendent
doivent être ré-exécutés
Le composant principal du système est souvent à la racine
du graphe. Il est testé en dernier et risque de ne pas être
assez testé si le temps manque.
2009
253
2009
composant sous test
interface sous test
composant testé
Interface testée
2009
254
Script de test
Script de test
bouchon
bouchon
composant sous test
composant sous test
interface sous test
interface sous test
composant testé
composant testé
Interface testée
Interface testée
bouchon
255
2009
Script de test
2009
256
Script de test
Script de test
bouchon
bouchon
composant sous test
composant sous test
interface sous test
interface sous test
composant testé
composant testé
Interface testée
Interface testée
257
2009
258
Avantages :
Possibilité de tester tôt les composants les plus dépendants
(les plus hauts dans l’arbre de dépendance)
⌧démonstration des fonctionnalités des composants de haut
niveau disponible rapidement
Script de test
bouchon
Peu de scripts de test à écrire
composant sous test
interface sous test
Test de non régression systématique à chaque ajout de
composant
composant testé
Interface testée
2009
259
2009
260
Cas de dépendances cycliques
Inconvénients :
Beaucoup de bouchons à écrire
Le graphe de dépendance peut comporter des composantes
fortement connexes
A
L’ajout d’une contrainte (ex : précondition) à un composant
proche des feuilles peut rendre nécessaires des changements
dans le code de beaucoup de composants qui en dépendent
Difficulté d’atteindre une forte couverture des critères de test
pour les composants les plus bas dans l’arbre. Ils ne sont
testés que dans le contexte de l’application sous test.
2009
261
C
B
Possibilité 1 : intégration Big-Bang
Principe : tester toutes les classes ensemble. Les dépendances
ne sont pas exploitées pour définir un ordre de test.
Avantage : nombre d’exécutions de cas de test limité
Inconvénient : en cas d’erreur, toutes les classes sont aussi
susceptibles les unes que les autres de l’avoir provoquée.
2009
262
Cas de dépendances cycliques
Partie 3
Possibilité 2 : utilisation de bouchons
A
C
Bouchonnage minimal
B
A
C’
Bouchon spécifique
C’A
A
C’B
B
C
Test en présence
d’héritage
C
B
Avantage : intégration progressive des composants
Inconvénient : écriture de bouchons
2009
263
2009
264
Utilisation de l’héritage pour le test
Héritage de cas de test
Principe: si une classe a déjà été testée alors l’effort de test pour
les classes qui en héritent peut s’en trouver réduit
Hypothèse : le comportement associé à une sous-classe est un
rafinement du comportement de la classe de base.
Soit D héritant de C :
⌧préconditions de D : les mêmes ou moins fortes que celles de C
( précond(D)
précond(C) )
⌧postconditions de D : les mêmes ou plus fortes que celles de C ;
( postcond(C)
postcond(D) )
-> processus de test incrémental et hiérarchique. Les cas de test
hérités et additionnels dépendent des modifications apportées dans
D par rapport à C
⌧Invariant de D : le même ou plus fort que celui de C
( inv(C)
inv(D) )
2009
265
Quels cas de test ajouter pour la sous-classe ?
Dans la suite de cette partie, C désigne une classe et D une
de ses sous-classes.
C
D
Ajout d’une opération dans l’interface de D et potentiellement
dans son implémentation :
Ajout de cas de test basés sur sa spécification
Si l’opération est implémentée : ajout de cas de test basés
sur l’implémentation et pour le test d’intégration
2009
Si D hérite de C :
Sont aussi hérités de C par D :
⌧les cas de test basés sur la spécification ;
⌧la plupart des cas de test basés sur l’implémentation ;
⌧la plupart des cas de test issus des tests d’intégration
Des cas de test doivent parfois être ajoutés aux cas de test
hérités
267
Quels cas de test ajouter pour la sous-classe ?
2009
Modification dans D de la spécification d’une opération m déclarée
dans C :
Ajout de cas de test basés sur la spécification de m dans D
Ré-exécution des cas de tests de C pour m dans D
Surcharge dans D d’une opération m héritée de C :
Réutilisation de tous les cas de test basés sur la spécification
Revoir les cas de test basés sur l’implémentation et ceux pour
le test d’intégration : réutilisation d’une partie de ceux de C et
ajout de nouveaux cas de test
2009
269
268
Exercice: quels cas de test ajouter pour tester
Rectangle, connaissant les tests de Polygone ?
Polygone
coins : Point[]
Polygone(Point[])
getCoins() : Point[]
translate(Vector);
aire() : int
affiche_caractéristiques();
Remarque sur la ré-exécution de cas de test : en pratique, tous
les cas de test hérités sont ré-exécutés. En effet, l’effort
nécessaire à la sélection des cas de test à ne pas ré-exécuter est
supérieur à l’effort nécessaire pour les exécuter de nouveau
266
Quels cas de test ajoutés pour la sous-classe ?
Méthodes héritées telles quelles par D :
Les cas de test de C pour ces méthodes sont encore valides
⌧ils n’ont pas besoin d’être réexécutés en général…
⌧…sauf pour les méthodes qui utilisent des méthodes qui ont
été modifiées dans D. En ce cas, des cas de test basés sur
l’implémentation doivent aussi être ajoutés
2009
Utilise aire()
Rectangle
Rectangle(Point[]);
aire() : int
estCarre() : bool
2009
270
Rappel sur la liaison dynamique
A
- int a
Code Java
int foo(int i){
+ <<constr>> A() : A
+
m() : int
type déclaré de a : A
A a;
if (i<0){
Comment tester en
présence de polymorphisme
par liaison dynamique ?
a=new A();
B
a=new B();
+ <<constr>> B() : B
+
m() : int
}
if (a.m() < 7){
…
C
- int c
+ <<constr>> C() : C
+
m() : int
2009
271
}
type effectif de a : B
le type effectif de a dépend de la
branche suivie dans le if-then-else
méthode m() appelée : soit A::m() soit
B::m() selon le type effectif de a. C::m()
ne peut pas être appelée.
…
}
272
Critère de test structurel et polymorphisme
Critère de test structurel et polymorphisme
Soit m polymorphe, appelée par o de type déclaré A:
Si m et/ou m sont polymorphes,
j
k
Soient mj et mk des méthodes
appelées
par“se
la cacher”
méthode m
plusieurs codes
peuvent
derrière les appels de méthodes en
Soient :
fonction du type de l’objet sur lequel
v : variable d’instance elles s’appliquent
ij : instruction de la méthode mj
c
qui définit v
ik : instruction de la méthode mk
mk{
…
qui utilise v
2009
type effectif de a : A
} else {
- int b
mj{
…
ij
…
}
A
- int a
A::m, B::m ou C::m peuvent être appelées
Cependant, le type effectif de o ne peut être que A
ou B, ainsi l’appel de C::m() ne peut être couvert !
+ m () : int
B
- int b
+ m () : int
Déterminer les types effectifs possible nécessite une
analyse globale de l’application (coûteux et complexe)
ik
…
}
Le critère est couvert si :
(v, ij, ik) faisable, un cas de test pour m qui sensibilise
un chemin c entre ij et ik sans redéfinition de v
C
- int c
+ m () : int
E
-> la mesure fiable du critère de couverture est compromise
(problème à rapprocher de la détermination des chemins executables)
A
Si mj et/ou mk sont polymorphes, il faut
déterminer ces triplets pour chaque corps de
méthode potentiellement
exécuté.
2009
273
2009
274
Problématique des classes abstraites
Classe abstraite = classe sans instance, à l’implémentation
incomplète – Utile pour la généricité et la lisibilité
Comment tester les classes
abstraites ?
Problème pour le test : impossible à tester en tant que
telle puisque pas instanciable.
Pratique de vérification usuelle : revue du code uniquement !
Nécessité de tester les opérations de la classe abstraite
au travers des sous-classes
2009
275
2009
276
Comment tester une classe abstraite ?
Problèmes posés par l’approche 1 :
Les bouchons sont parfois difficiles à écrire :
⌧Soit f une méthode implémentée dans la classe abstraite, qui
appelle la méthode abstraite g de la même classe.
Approche 1 : définition d’une classe concrète uniquement
pour pouvoir tester la classe abstraite
Abstract_C
abstract class Abstract_C{
abstract int g(int a);
int f(int a){
int i = g(a);
…
}
Concrete_C
}
Dans la classe concrète, les méthodes abstraites de la classe
abstraite sont implémentées -> bouchons
2009
277
Problèmes posés par l’approche 1 :
⌧ Soient, Abstract_C et Abstract_D deux classes telles que
Abstract_D hérite de Abstract_C ;
⌧ Concrete_C et Concrete_D les classes qui leur sont
respectivement associées à des fins de test.
2009
Concrete_C
Approche 2 : Tester la classe abstraite avec son premier
descendant
Abstract_C
D
Hypothèse sous-jacente: si D passe sans problème les cas de test
alors Abstract_C les passe également sans problème
Abstract_D
Concrete_D
279
2009
280
Problème posé par l’approche 2 :
L’hypothèse n’est pas toujours valide !
⌧ Si D surcharge une méthode f de Abstract C alors la
méthode f de Abstract_C n’est pas testée. Il faudra la
tester dans une autre sous-classe de Abstract_C qui ne
surcharge pas cette méthode f.
Approche 3 : Utiliser une compilation conditionnelle pour avoir
dans un même fichier :
la classe abstraite sous test avec ses méthodes abstraites
Une version de la classe où chaque méthode abstraite est
remplacée par une implémentation (bouchon)
Ex : #ifdefined(TEST)
<bouchon>
#endif
Abstract_C
int f()
D
Problème posé par l’approche 3 :
le code est peu lisible
int f()
278
Abstract_C
2009
L’héritage multiple est nécessaire
pour que Concrete_D hérite des bouchons
créés dans Concrete_C
-> OK en C++, mais en Java
l’héritage multiple de classe
n’est pas autorisé
2009
⌧L’implémentation de g doit permettre de respecter la
postcondition de la fonction g.
-> le coût est parfois très élevé si g est une fonction complexe
281
2009
282
Plan du cours d’aujourd’hui
Test de logiciel orienté-objet:
conclusions
Spécificités à prendre en compte pour le test
(abstraction, encapsulation, modularité) pour ne pas rejouer trop
de test inutiles
1. Techniques de test élémentaires
2. Test de logiciel orientés-objet
Difficultés particulières :
- Test en présence de polymorphisme (liaison dynamique)
3.
Model-Based Testing
- Test de classes abstraites
2009
283
Model-Based Testing
2009
284
Model-Based Testing
Génération de tests à partir de modèles
Processus de test à partir de modèles
Modélisation
Exigences
Modèle formel
Modèle formel
StateCharts,B,UML,…
Ensemble de
Spécifications et
développement
Génération de Test
Cas de test
générés
Directives de
génération
Générateur
de tests
Cas de tests
• séquence de stimuli
• résultats attendus
Génération de scripts
Scripts de tests
exécutables
Validation
Directives de génération (définition d’un scénario de tests) :
Critères de couverture du modèle
Critères de sélection sur le modèle
Implémentation
Originalité du MBT : construire le modèle dans le but d’automatiser le test
2009
285
2009
286
Reference
« Practical Model-based Testing »
M. Utting, B. Legeard, 2008
Modéliser pour tester
Stratégies de génération de test
Sélection des tests – Critères de couverture
Exemple d’outils : SIMULINK DESIGN VERIFIER
2009
287
2009
288
Modéliser pour tester (1)
Modéliser pour tester (2)
Modèle abstrait
modèle fonctionnel (et non modèle d’architecture et/ou
d’implémentation)
Modèle détaillé et précis
Le modèle doit permettre de calculer les cas de test et les
résultats attendus
établir automatiquement le verdict de test
Modèle validé et vérifié
Si le verdict de test « Fail » : l’erreur est-elle dans
l’implantation ou dans le modèle ?
2009
Modèle adapté aux objectifs de test
Plus le modèle intègre d’informations inutiles par rapport aux
objectifs de tests, plus cela génère de « bruit » en
génération de tests
Modèle tenant compte des points de contrôle et d’observation
du système sous test
Génération
des tests
Génération
des scripts
Modèle fonctionnel
289
2009
Notations de modélisation
Systèmes de transitions (Etats / Transitions / Evénements)
⌧Flow Charts / CFGs
⌧Data Flow Diagrams
⌧Diagrammes d’état
Diagrammes objet & association (hiérarchie, héritage, …)
⌧Diagrammes de classe (UML)
⌧Modèles Entité-Relation
Représentation Pré/Post conditions
⌧OCL (Object Constraint Language) pour UML
⌧JML (Java Modeling Language) pour Java
⌧Machine Abstraite B
Applications type contrôle-commande (automobile, énergie, aéronautique, …)
Statecharts, Matlab/Simulink, Lustre, Signal
Applications mobiles et logiciels enfouis (télécom, électronique grand public,
carte à puces, monétique, …)
Pré/Post conditions (UML/OCL, B, …)
Systèmes d’information
Modélisation objet (UML)
2009
Représentation : Graphique (plus « intuitive » ) ou textuelle (plus précise)
291
Notation
Présentation
UML 2.0
(Diag.
Classe +
OCL + Diag.
État)
Statecharts
Unified
Modeling
Language
Diag. Etat
Méthode
formelle
2009
292
Classification des techniques de génération
Choix de notations
2009
290
Critères de choix d’une notation / type
d’application
Notation B
Banc de test
++
. Grande
diffusion
. Variété de
diagrammes
Quelques outils…
--
Systèmes de transitions :
IOLTS (STG – IRISA, TORX – Univ. Nijmegen)
Statecharts (AGATHA – CEA)
. Peu précise
. Pas de
sémantique
Pré/post conditions – Machine abstraites
ASML (Microsoft Research)
B (LTG)
UML/OCL (LTG, UML-Casting, …)
. Bien adapté - . Faible sur les
contrôleurs données
systèmes
Embarqués
. Sémantique . Apprentissage
claire
. Précision
293
Systèmes hybrides (discret/continus)
Simulink (Mathworks)
Langages synchrones
Lustre (GATEL – CEA)
2009
294
Noyau de la norme GSM 11.11
Exemple – La norme carte à puces GSM 11-11
La norme GSM 11-11 défini l’interface entre le Mobile (téléphone
GSM) et la puce SIM – Subscriber Identifier Module
Commandes :
Verify_Chv(chv,code),
Change_Chv(chv,code1,code2),
MF
Disable_Chv(code),
La puce SIM est une carte à puces qui contient toutes les données
utilisateurs et gére la protection de l’accès
Arborescence de
fichiers
Enable_Chv(code),
Unblock_Chv(chv,
code_unblock1, code_unblock2),
Le standard GSM 11-11 propose 21 API incluant la gestion du PIN –
Personal Identifier Number – et du PUK – Personal Unblocking Key –
et la lecture et mise à jour de données.
DF_GSM
ed_iccid
Select_File(ff),
Read_Binary,
Update_Binary(data),
ed_lp
ed_imsi
ed_ad
Reset,
2009
295
Modèle en B de la norme GSM 11-11 (fragment) – 1/4
CONSTANTS
FILES_CHILDREN,
PERMISSION_READ,
MAX_CHV,
MAX_UNBLOCK,
PUK
296
PROPERTIES
FILES_CHILDREN : FILES <-> FILES &
FILES_CHILDREN = {(mf|->df_gsm), (mf|->ef_iccid),(df_gsm|->ef_lp),
(df_gsm|->ef_imsi),(df_gsm|->ef_ad)} &
PERMISSION_READ : EF --> PERMISSION &
PERMISSION_READ = {(ef_imsi|->never),(ef_lp|->always),
(ef_iccid|->chv),(ef_ad|->adm)} &
MAX_CHV = 3 &
MAX_UNBLOCK = 10 &
PUK : CODE &
PUK = a_3
SETS
FILES = {mf,df_gsm,ef_iccid,ef_lp,ef_imsi,ef_ad};
PERMISSION = {always,chv,never,adm};
VALUE = {true, false};
BLOCKED_STATUS = {blocked, unblocked};
CODE = {a_1,a_2,a_3,a_4};
DATA = {d_1,d_2,d_3,d_4}
2009
MACHINE GSM_11-11
DEFINITIONS
MF == {mf};
DF == {df_gsm};
EF == {ef_iccid,ef_lp,ef_imsi,ef_ad};
COUNTER_CHV == 0..MAX_CHV;
COUNTER_UNBLOCK_CHV == 0..MAX_UNBLOCK
2009
VARIABLES
current_file,
current_directory,
counter_chv,
counter_unblock_chv,
blocked_chv_status,
blocked_status,
permission_session,
pin,
data
297
2009
298
sw <-- VERIFY_CHV(code) =
PRE
code : CODE
THEN
IF (blocked_chv_status = blocked)
THEN
sw := 9840
ELSE
IF (pin = code)
THEN
counter_chv := MAX_CHV || permission_session(chv) := true || sw := 9000
ELSE
IF (counter_chv = 1)
THEN
counter_chv := 0 || blocked_chv_status := blocked ||
permission_session(chv) := false || sw := 9840
ELSE
counter_chv := counter_chv - 1 || sw := 9804
END
END
END
INVARIANT
…
((blocked_chv_status = blocked) => ((chv|->false) : permission_session)) &
((counter_chv = 0) <=> (blocked_chv_status = blocked)) &
((counter_unblock_chv = 0) <=> (blocked_status = blocked))
INITIALISATION
current_file := {} ||
current_directory := mf ||
counter_chv := MAX_CHV ||
counter_unblock_chv := MAX_UNBLOCK ||
blocked_chv_status := unblocked ||
blocked_status := unblocked ||
permission_session := {(always|->true),(chv|->false),(adm|->false),(never|->false)} ||
pin := a_1 ||
data := {(ef_iccid|->d_1),(ef_lp|->d_2),(ef_imsi|->d_3),(ef_ad|->d_4)}
END;
2009
299
2009
300
Modélisation en B pour la génération de tests
CHANGE_Pin(old_code, new_code) =
PRE
old_code ∈ Nat ∧ new_code ∈ Nat
THEN
Niveau Machine Abstraite
IF counter_pin = 0
THEN
(sans raffinement, mono-machine)
sw := 9840
ELSE
IF code_pin = old_code
Permet une bonne prise en compte des
THEN
données et des traitements
code_pin := new_code
||
counter_pin := 3
||
permission_session := true ||
sw := 9000
Bon niveau d’abstraction
ELSE IF counter_pin =1
THEN
counter_pin := 0
permission_session := false
sw := 9840
ELSE
counter_pin := counter_pin – 1
sw := 9804
END END END END END ;
2009
sw
||
||
||
301
Analyse de
besoins
Ingénieur
modélisation
Spécifications
fonctionnelles
Documentation
Développement
Support du
développement
Modèle existant
Adaptation
Modèle pour le test
fonctionnel
Modélisation
Ingénieur
validation
Génération
des tests
302
Processus Model-Based Testing – Schéma 2
Processus Model-Based Testing – Schéma 1
2009
2009
Ingénieur
validation
Cas de test
303
Génération
des tests
Pilotage
2009
Cas de test
304
Composition d’un cas de test
Génération automatique de tests fonctionnels
Un cas de test généré se décompose en quatre parties:
Préambule : séquence des stimuli depuis l’état initial jusqu’à un
état recherché pour réalisé le test,
Automatiser les stratégies classiques :
Analyse partitionnelle des données d’entrée
Test aux limites
Couverture de critères de test défini sur le modèle
Corps : appel des stimuli testé
Identification : appel d’opérations d’observation pour consolider
l’oracle (facultatif)
Postambule : chemin de retour vers l’état initial ou un état connu
permettant d’enchaîner automatiquement les tests
Ou bien sélection de comportements à tester en priorité
Objectif : Maîtriser la combinatoire des cas de test
Préambule
2009
305
2009
Corps
Identification
Postambule
306
Pilotage du banc de test et simulation de
l’environnement
Problématique de la traduction des tests générés en scripts
exécutables
A partir des cas de tests abstraits, d’un source de test
générique et d’une table d’observabilité et d’exécutabilité,
les scripts exécutables sur le banc cible sont générés.
Le pilotage du banc permet une exécution des tests et
un verdict automatiques.
Nomage des appels et variables : Les tests générés sont des séquences d’appel
sur les opérations ou stimuli définis au niveau du modèle
Table de correspondance entre noms du modèle (variables et appels) et
noms de l’environnement d’exécution des tests
langage de tests : L’environnement d’exécution des tests prend en entrée un
langage de définition des scripts exécutables (TTCN, JUnit, Cunit, Pluto, …)
Définition d’un pattern générique au sein duquel les appels seront insérés
Pattern de test
générique
Table d’observabilité et
d’exécutabilité
Génération des scripts
de tests exécutables
Cas de test
générés
2009
Verdict de test : Les tests générés comprennent le résultat attendus
Le verdict est construit par comparaison entre le résultat attendu et le
résultat obtenu pendant l’exécution du script de test
Script de tests
exécutables
307
3140 tests
240
MagIC 500
Invali d in pu ts
Schlumberger device
Classes de comportements
du système
1570 comportements
Vali d in pu ts
La définition des classes
d’équivalence permet de
passer d’un nombre infinis de
données d’entrée à un nombre
fini et limité de données de
test.
Ou tput s
309
Test aux bornes des domaines des variables du
modèle
4
Inférieur à 4
11
De 4 à 10
Supérieur à 10
Le test aux bornes produit à la fois des cas de test valides
(tests nominaux dans l’intervalle) et invalides
(tests de robustesse hors intervalle)
2009
2009
Classes de comportements
P1: x ≤ 0
P2: x > 0 ∧ x ≤ 40
P3: x > 40 ∧ x ≤ 100
311
310
Analyse partitionnelle - Exemple
Invariant
x ∈ -1000 .. 1000
Preop
x ≤ 100
Postop
IF x ≤ 0 THEN y := default
ELSE IF x ≤ 40
THEN y := low
ELSE y:= high
END END
10
3
Une classe d’équivalence
correspond à un ensemble de
données de tests qui activent
le même comportement.
Sy stem
Tests pour toutes les configurations
cartes possibles et les valeurs aux bornes
Tests pour une configuration particulière
2009
308
Analyse partitionnelle des domaines des
données d’entrée
Maîtriser la combinatoire : exemple de la
validation terminal Carte Bancaire
2,64 Milliards de combinaisons
de données possibles
2009
2009
P1
P2
P3
Ensemble de tous les états du
système qui permettent d’activer
l’opération
312
Calcul des données de test aux bornes
Prédicats après partitionnement
P1: x ≤ 0
P2: x > 0 ∧ x ≤ 40
P3: x > 40 ∧ x ≤ 100
Tests aux bornes
BG1 x = -1000
BG2 x = 0
BG3 x = 1
BG4 x = 40
BG5 x = 41
BG6 x = 100
2009
X
BG1
P1
BG2
X
X
BG3
P2
BG4 X
X
BG5
P3
X BG6
313
Génération des tests à partir de critères
2009
Critères de conditions multiples dans les décisions
Toutes les décisions
Toutes les conditions
Toutes les décisions / conditions modifiées (MC/DC)
Toutes les conditions/decisions multiples
…
Critères de sélection
Focaliser la génération sur certains comportements
Evolution du modèle
Sélectionner les tests par différentiel de comportements entre deux
versions du modèle
SUR LE MODELE…
Cas utilisateur
Animer le modèle pour définir des cas de test
314
Critères de couverture
Critères de couverture du modèle
Obtenir le niveau de dépliage et de couverture souhaité à partir du
modèle
2009
315
2009
316
Diagramme d’états du contrôleur de vitesse
Toutes les conditions/décisions
Toutes les conditions/decisions multiples
Critères de couvertures des valeurs aux bornes
équivalentes
Une valeur
Toutes les valeurs
Conditions multiples
2009
317
2009
318
Toutes les conditions/décisions
Toutes les conditions/decisons multiples
Critères de couvertures des valeurs limites équivalentes
Une valeur
Toutes les valeurs
Critères de couverture des transitions
Toutes les transitions
Toutes les paires de transitions
Valeurs aux limites
2009
319
2009
320
Critères de sélection
Focus sur le modèle
Sélection sur le choix des opérations / événements activables
Sélection par choix sur les variables / valeurs du modèle
Transition
Evolution du modèle
Test de tous les comportements ajoutés ou modifiés
Test des comportements inchangés
Cas définis par l’utilisateur
Animation du modèle pour définir des séquences
d’activation: le générateur de test permet la production de
l’oracle de test
2009
321
2009
322
Conclusion du cours
Validation des logiciels dans le Monde Industriel
essentiellement basée sur le test logiciel
Spécificité du test des logiciels orientés-objet
Approches complémentaires:
Code-based Testing vs Model-based Testing
Nombreux outils pour tous les langages et notations de
modèles
2009
323
2009
324

Test Logiciel, Validation et Vérification

Transcription

Documents pareils

Notice biographique Repères biographiques communs Titres

Formation d`Ingénieurs Citoyens en NanoMicroTechnologies

folio administratif

le stage ouvrier - STPI

Les mobiliser pour la réforme, un grand défi • L`arrêt

Com@ENSCI *

Numéro 038 - L`Insatiable

Numéro 103 – Février 2005 - L`Insatiable