Post on 08-Jul-2020
2009 INSA -- Test de Logiciels 1
Test Logiciel, Validation et Vérification
INSA - Rennes 2009-2010
Arnaud GotliebIRISA / CELTIQUE
www.irisa.fr/lande/gotliebArnaud.Gotlieb@irisa.fr
2009 INSA -- Test de Logiciels 2
Introductionhistorique et problèmatique du test
préh
istoi
re
Époq
ue te
st =
mise
au
poin
t
Époq
ue te
st =
des
truct
ion
Époq
ue te
st =
pré
vent
ion
1945 1960 1980 1990
2009 INSA -- Test de Logiciels 3
9/9/1945
2009 INSA -- Test de Logiciels 4
1960-80 : Test = mise au point
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 INSA -- Test de Logiciels 5
1980-90 : Test = destruction
« Testing is the process of executing a program with the intent of finding errors »
[G. Myers The Art of Software Testing 1979]
Conséquence immédiate : le testeur ne doit pas être le programmeur
Position dogmatique progressivement abandonnée !
2009 INSA -- Test de Logiciels 6
1990-.. : Test = prévention
« Se convaincre, par des techniques d’analyse ou d’exécution, qu’un programme répond à ses spécifications »
- Analyse Contrôle : vérifier des propriétés avant exécution
- Exécution Test : évaluer un résultat après exécution
2009 INSA -- Test de Logiciels 7 2009 INSA -- Test de Logiciels 8
2009 INSA -- Test de Logiciels 9
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 intentedusage »
Verification: « The process of determining whether the products of a given phase of the software developmentprocess fulfill the requirements established during the previous phase »
Testing: « Evaluating software by observing its execution »
2009 INSA -- Test de Logiciels 10
Test de programme : notre définition
- Tester = exécuter un programme P pour mettre en évidence la présence de fautes, par rapport àsa spécification F
- Recherche de contre-exemples :
∃X tq P(X) ≠ F(X) ?
2009 INSA -- Test de Logiciels 11
Prouver la correction d’un programme par le test
Pour cela, il est nécessaire de générer un jeu de test T tel que :
1. ∀X ∈ T, il existe une procédurepermettant de déterminer si P(X) termine
2. si ∀X ∈ T,P(X)=F(X) alors ∀X, P(X)=F(X)
2009 INSA -- Test de Logiciels 12
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
«Program Testing can be used to prove the presenceof bugs, but never their absence » [Dijkstra 74]
PS : développeur expérimenté 1 faute / 10 lignes de code163 fautes / 1000 instructions
[B. Beizer Software Testing Techniques 1990]
2009 INSA -- Test de Logiciels 13
Processus de test
Programme P
Exécuter
Donnée de test X Sortie P(X)Oracle okF
Vérifier
Verdict (pass,fail) 2009 INSA -- Test de Logiciels 14
Problème de l’oracle :Comment vérifier les sorties calculées ?
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
En pratique :- prédictions approximatives (à cause des calculs flottants,…)
- formules inconnues (car programme = formule)
- oracle contenant des fautes
2009 INSA -- Test de Logiciels 15
Problème de la sélection des DT
Données de test Sorties
A. Test fonctionnel : basé sur les spécifications
B. Test structurel : basé sur l’analyse du programme
Données de test Sorties
2009 INSA -- Test de Logiciels 16
A. Test fonctionnel
A base d’un modèle du programme issu des spécifications :
- Informelles (test partitionnel, test aux limites, ...)
- 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 INSA -- Test de Logiciels 17
B. Test structurel
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
2009 INSA -- Test de Logiciels 18
Spécifications :renvoie le produit de i par j
(i = 0, j = 0) --> 0(i = 10, j = 100) -->1000…
--> OK
prod(int i,int j ){int k ;if( i==2 )
k := i << 1 ;else(faire i fois l ’addition de j)
return k ;}
Le test structurel est indispensable (1)
2009 INSA -- Test de Logiciels 19
Faute non détectée pardu test fonctionnelpatch -> k := j << 1
prod(int i,int j ){int k ;if( i==2 )
k := i << 1 ;else(faire i fois l ’addition de j)
return k ;}
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…
2009 INSA -- Test de Logiciels 20
Software testing in the software developpement process
Requirements
Architecture & system
Usage & acceptance testing
Functional specifications
System testing(performence, load, robustness, security testing)
Coding design
Unit & Integration testing
2009 INSA -- Test de Logiciels 21
Test natif / test croisé
Test natif : machine de test = machine de développement
Test croisé : machine de test ≠ machine de développement
2009 INSA -- Test de Logiciels 22
Exemple de montage en test croisé : plateforme Java Card
javac converter verifier
Open Plateformloader
.java .class .cap
CardCommandsprocessor
.cmd
USB port
Java CardCard reader
Personal Computer
APDUs
2009 INSA -- Test de Logiciels 23
Tests de non-regréssion
1ère version
2nde version
3ème version
Jeu de Test 1Jeu de Test 2
Jeu de Test 3
Tests de non-régression
…
2009 INSA -- Test de Logiciels 24
Bibliographie : quelques livres
2009 INSA -- Test de Logiciels 25
Bibliographie : quelques revues
2009 INSA -- Test de Logiciels 26
Et quelques sites intéressants...
Software Testing Online Resources www.mtsu.edu/~storm/
Software Testing Stuff www.testdriven.com
Model-based Software Testingwww.geocities.com/model_based_testing/
Opensource ST www.opensourcetesting.org/unit_java.php
Tao Xie’s homepagewww.cs.washington.edu/homes/taoxie
2009 INSA -- Test de Logiciels 27
0. Préliminaires
1. Test logiciel : principes
2. Génération automatique de test
3. Techniques de test fonctionnel
4. Test de logiciel orienté-objet
5. Test à partir de modèles
Plan complet du cours
2009 INSA -- Test de Logiciels 28
TP1 : Test à partir de modèle avec LTG
TP2 : Test des systèmes d’information avec GEDIS
TP3 : Test des applications embarqués dans le cadre automobile : formation AUTOSARLABavec IBM Test RealTime
2009 INSA -- Test de Logiciels 29
0. Préliminaires
1. Test logiciel : principes
2. Génération automatique de test
3. Techniques de test fonctionnel
4. Test de logiciel orienté-objet
5. Test à partir de modèles
Plan complet du cours
2009 INSA -- Test de Logiciels 30
Gödel !
1931Un 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, ilexiste toujours des énoncés qu’il est impossible de démontrer.
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
2009 INSA -- Test de Logiciels 31
Idée de la preuve
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 INSA -- Test de Logiciels 32
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.
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 INSA -- Test de Logiciels 33
Puis Church...
Il existe des programmes exécutables par des Machines de Turing qu’on ne peut pas écrire !
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;’’);’’);
2009 INSA -- Test de Logiciels 34
Pire : un programme T qui determine si un programme B termine ou pas(* prog B1 *)while( true ) {};
(*prog B2*)a = 0;while( a ≠ 1 ) {
a = a + 2 ;}
(*prog B3*)scanf(‘’%d’’, &a) ;while (a < 10){
b = a + 2 ;}
T doit determiner que B1 et B2 ont une boucle infinieque B3 boucle infiniment si a prend une valeur a < 10.
2009 INSA -- Test de Logiciels 35
Que fait le programme T avec T en entrée ?
Si T repère une boucle infinie, il imprime un message d ’erreur et s ’arrête ; sinon, T boucle
Soit T boucle indéfiniment, soit T s’arrête.
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
Et si on implante T comme ceci :
2009 INSA -- Test de Logiciels 36
P = Problème de l’arret d’une machine de Turing.
« 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 ! »
Beaucoup de problèmes de test se ramènent à P !
- 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 applicableEtc.
Quel rapport avec le test des programmes ?
2009 INSA -- Test de Logiciels 37
0. Préliminaires
1. Test logiciel : principes
2. Génération automatique de test
3. Techniques de test fonctionnel
4. Test de logiciel orienté-objet
5. Test à partir de modèles
Plan complet du cours
2009 INSA -- Test de Logiciels 38
X1X2
X5
X4X3
Plusieurs techniques :- Test dos à dos : prototypes, N-versions, non-regression- Propriétés du programme : assertions, fonctions inverses, ...- Prédictions manuelles !
Dom(P)
Oracle
donnée de test : X ∈ Dom(P)
jeu de test : T = {Xi}i =1..N
“A mechanism to produce the predicted outcomes to compare with the actual outcomes of the software under test.” (Glossary BCS SIGIST)
2009 INSA -- Test de Logiciels 39
Définition formelle de l’oracle
Programme P : Dom(P) Ran(P)
Donnée de test : X ∈ Dom(P)Jeu de test : T = {Xi}i =1..N
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 INSA -- Test de Logiciels 40
Jeu de Test idéal
X1X2
X5
X4X3
T est idéal ssi∃X ∈ T, ¬okF(X,P(X)) {i.e. T est non réussi}ou si ∀X ∈ T, okF(X,P(X)) {i.e. T est réussi}
alors ∀X ∈ Dom(P), okF(X,P(X))
Dom(P)
okF(X1,P(X1))okF(X2,P(X2))...
2009 INSA -- Test de Logiciels 41
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
(ex : chemins de P)
P(int i,int j) {if( C1 )else ...
if( C2)else ...} i
j
¬C1∧¬C2
¬C1∧ C2
C1∧¬C2
C1∧C2
Dom(P)
2009 INSA -- Test de Logiciels 42
Repose sur une hypothèse d’uniformité : une seule donnée de test suffit pour tout le sous-domaine
X1X4
X3
X2
Couverture du critère de sélection C
Dom(P)
Prédicat COMPLETEP(T,C) vrai ssi T est sélectionné par C
2009 INSA -- Test de Logiciels 43
Jeu de Test idéal
X1X2
X5
X4X3
T est idéal ssi∃X ∈ T, ¬okF(X,P(X)) {i.e. T est non réussi}ou si ∀X ∈ T, okF(X,P(X)) {i.e. T est réussi}
alors ∀ X ∈ Dom(P), okF(X,P(X))
Dom(P)
okF(X1,P(X1))okF(X2,P(X2))...
2009 INSA -- Test de Logiciels 44
Critère fiable pour P
Critère fiable
Jeu de test
Défauts
C fiable pour P ssi∀T1,T2 tq COMPLETEP(T1,C) et COMPLETEP(T2,C),
T1 réussi est équivalent à T2 réussi
2009 INSA -- Test de Logiciels 45
Critère valide pour P
Critère valide
Jeux de test
Défauts
C valide pour P ssi∀X ∈ Dom(P) tq ¬okF(X,P(X)),∃T tq COMPLETEP(T,C) et T non réussi
2009 INSA -- Test de Logiciels 46
Spéc : F(n) = n² Prog : ush P(ush n) { return(n+n);}
C1 : sélection de DT à valeur paire <3 {0}, {2}, {0,2}
okF(0,P(0))
okF(2,P(2))
C1 est fiable et non valide pour P
Exemples (1)
2009 INSA -- Test de Logiciels 47
Exemples (2)
Spéc : F(n) = n² Prog : ush P(ush n) { return(n+n);}
C2 : sélection de 2 DT à valeur paire {0,2}, {2,4}, {0,4}, …
okF(0,P(0))
okF(2,P(2))
mais ¬okF(4,P(4))
C2 est valide et non fiable pour P
2009 INSA -- Test de Logiciels 48
Spéc : F(n) = n2 Prog : ush P(ush n) { return(n+n);}
C3 : sélection de 3 DT dont (X=1) {0,1,2},{1,2,3},{0,1,3},…
¬okF(1,P(1))
C3 est pour P
Exemples (3)
2009 INSA -- Test de Logiciels 49
Spéc : Fn = (n+1)ème nombre premier (par ex. F1 = 3)
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
Exercice :
2009 INSA -- Test de Logiciels 50
1.1 Théorème fondamental du test
Critère C valide et fiable
Jeu de test
Défauts
[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 INSA -- Test de Logiciels 51
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.
En particulier, TX est non réussi -- CONTRADICTION2009 INSA -- Test de Logiciels 52
1ère critique : les notions de validité/fiabilité sont relatives à P
Si P est correct, tout critère C est valide/fiable pour P
Déterminer un critère valide/fiable pour Pné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’
2009 INSA -- Test de Logiciels 53
Exemple de critère valide et fiable pour tout P : test exhaustif
- Critère C : sélection de toutes les données de test possiblesT = Dom(P)
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) {...}
232 possibilités × 232 possibilités × 232 possibilités = 296 possibilités2009 INSA -- Test de Logiciels 54
2nde critique : Test exhaustif = exemple unique !
Preuve [Weyuker & Ostrand 80] :
Car ∀P, ∀X ∈ Dom(P), ∃P’ tq ∀Y ∈ Dom(P) okF(Y,P’(Y)) {Y≠X}
et ¬okF(X,P’(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
2009 INSA -- Test de Logiciels 55
Howden’s negative result
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))
est indécidable dans le cas général !
D’où : recherche empirique de critères de test intéressants
2009 INSA -- Test de Logiciels 56
Papiers fondateurs
[Goodenough & Gerhart 75] «Toward a Theory of Test Data Selection»IEEE Trans. on Software Engineering SE-1 N°2 Jun 1975
[Howden 76] «Reliability of the Path Analysis Testing Strategy»IEEE Trans. on Software Engineering SE-2 N°3 Jun 1976
[Weyuker & Ostrand 80] «Theories of Program Testing and the Application of Revealing Subdomains»IEEE Trans. on Software Engineering SE-6 N°3 May 1980
[Rapps & Weyuker 85]«Selecting Software Test Data Using Data Flow Information »IEEE Trans. on Software Engineering SE-11 N°4 Apr 1985
2009 INSA -- Test de Logiciels 57
Représentations internes
Abstractions de la structure d’un programme
- Graphe de Flot de Contrôle [GFC]
- Graphe Def/Use [GDU]
[- Program Dependence Graph, ...]
2009 INSA -- Test de Logiciels 58
Graphe de flot de contrôle (GFC)
Graphe orienté et connexe (N,A,e,s) où
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
e : sommet “d’entrée” du programme
s : sommet de sortie du programme
2009 INSA -- Test de Logiciels 59
double P(short x, short y) {short w = abs(y) ;double z = 1.0 ;
while ( w != 0 ){
z = z * x ;w = w - 1 ;
}
if ( y<0 ) z = 1.0 / z ;
return(z) ; }
w != 0
y<0
a
b
c
d
e
f
Graphe de flot de contrôle (GFC) : exemple
fauxvrai
fauxvrai
2009 INSA -- Test de Logiciels 60
Critère : tous_les_sommets | toutes_les_instructions
Motivation : couvrir toutes les instructionsdu programme au moins une fois
Déf: Un ensemble C de chemins du GFC(N,A,e,s) satisfait tous_les_sommetsssi ∀n ∈ N, ∃Ci ∈ Ctq n est un sommet de Ci
Exemple : Ici un seul chemin suffita-b-c-b-d-e-f [6/6 sommets]
a
b
c
d
e
f
2009 INSA -- Test de Logiciels 61
Motivation : couvrir toutes les prises de décision au moins une fois
Déf : Un ensemble C de chemins du GFC (N,A,e,s) satisfait tous_les_arcsssi ∀a ∈ A, ∃Ci ∈ C
tq a est un arc de Ci
Exemple : Ici 2 chemins sont nécessairesa-b-c-b-d-e-f [6/7 arcs]a-b-d-f [3/7 arcs]
a
b
c
d
e
f
Critère structurel : tous_les_arcs | toutes_les_décisions
2009 INSA -- Test de Logiciels 62
Critère structurel : tous_les_chemins_simples
a
b
c
d
e
f
Motivation : couvrir toutes les cheminsd’exécution, sans itérer plus d’une fois dansles boucles
Exemple : Ici 4 chemins completssont nécessaires
a-b-d-f
a-b-d-e-fa-b-c-b-d-f
a-b-c-b-d-e-f
2009 INSA -- Test de Logiciels 63
Déf : Un ensemble C de chemins du GFC(N,A,e,s) satisfait tous_les_cheminsssi C contient tous les chemins de e à s
Ici, impossible car ∞ chemins et chemins non-exécutables !
tous_les_chemins plus fort que tous_les_arcstous_les_arcs plus fort que toutes_les_sommets
a
b
c
d
e
f
Critère structurel : tous_les_chemins
2009 INSA -- Test de Logiciels 64
Chemin sensibilisé : exec(P,X)
Principe:X sensibilise un unique chemin du GFC
Déf: séquence de sommets du GFC, nonnécessairement finie, empruntée lors del’exécution de P avec X comme entrée
Exemples :exec(P,(0,0)) = a-b-d-fexec(P,(3,2)) = a-b-(c-b)²-d-f
w != 0
z= z * xw= w-1
y<0
z=1.0 / z
a
b
c
d
e
f
P(short x,y)short w= abs(y)double z= 1.0
return(z)
2009 INSA -- Test de Logiciels 65
Problème des chemins non exécutables
Soit c un chemin du GFC de P,existence de X tq c=exec(P,X) ?
Ici, a-b-d-e-f est non-exécutable !
Weyuker 79Déterminer si un sommet, un arc, ou un chemin du GFC est exécutable est indécidable dans le cas général
Idée de la preuve: réduction au problème de l’arrêt d’une Machine de Turing
w != 0
z= z * xw= w-1
y<0
z=1.0 / z
a
b
c
d
e
f
P(short x,y)short w= abs(y)double z= 1.0
return(z)2009 INSA -- Test de Logiciels 66
Exercice
Trouver tous les chemins non-exécutables de ce programme
P(short x)x > 0
y=xx=0
x < 0 && y>= 0
a
b
d
f
g
c y= -xx= -1
v f
v f
e
2009 INSA -- Test de Logiciels 67
Condition / Décision dans un programme
if( A && (B || C))
Condition (bool., expr. arith, ...)
Décision (bool., expr. logique dans une structure de contrôle, ...)
Notation : Dec est la valeur de vérité de la décision2009 INSA -- Test de Logiciels 68
3. Modified Condition/Decision Criterion (MC/DC)
if( A && (B || C))
1. Decision Criterion (DC) : A=1,B=1,C=0 – Dec=1 A=0,B=0,C=0 – Dec=0
4. Multiple Condition/Decision Criterion: 23=8 cas de test
Critères de test liés aux décisions
2. Condition Criterion (CC) : A=1,B=1,C=0 – Dec=1A=0,B=0,C=1 – Dec=0
2009 INSA -- Test de Logiciels 69
Modified Condition/Decision Criterion (1)
Objectif : Démontrer l’action de chaque condition sur la valeur de vérité de la décision
if( A && (B || C))
Ex : pour A A=0, B=1,C=1 -- Dec=0A=1, B=1,C=1 -- Dec=1
Principe : pour chaque condition, trouvez 2 cas de test qui changent Dec lorsque toutes les autres conditions sont fixées
2009 INSA -- Test de Logiciels 70
Modified Condition/Decision Criterion (2)
if( A && (B || C))
pour A A=0, B=1,C=1 -- Dec=0A=1, B=1,C=1 -- Dec=1
pour B A=1, B=1,C=0 -- Dec=1A=1, B=0,C=0 -- Dec=0
pour C A=1, B=0,C=1 -- Dec=1A=1, B=0,C=0 -- Dec=0
Ici, 5 cas de test suffisent pour MC/DC !
2009 INSA -- Test de Logiciels 71
Exercice : peut-on faire mieux ?
if( A && (B || C))
pour A A= , B= ,C= -- Dec=A= , B= ,C= -- Dec=
pour B A= , B= ,C= -- Dec=A= , B= ,C= -- Dec=
pour C A= , B= ,C= -- Dec=A= , B= ,C= -- Dec=
2009 INSA -- Test de Logiciels 72
Modified Condition/Decision Criterion (3)
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
En l’absence de conditions couplées, le minimum (n+1) peut-être atteint
2009 INSA -- Test de Logiciels 73
Lien avec la couverture du code objet
Couvrir MC/DC ⇒ couvrir les décisions du code objetmais
Couvrir MC/DC ⇐ couvrir les décisions du code objet
Couvrir les chemins du code objet ⇒ couvrir MC/DCmais
Couvrir les chemins du code objet ⇐ couvrir MC/DC
2009 INSA -- Test de Logiciels 74
From the Galileo development standard
N/AN/AN/AN/A100%Modified Condition & Decision Coverage (Source code)
N/AN/AN/A100%N/ADecision coverage(source code)
N/AN/AN/AN/A100%Statement coverage (object code)
N/A90%100%100%N/AStatement coverage (source code)
DAL E
DAL D
DAL CDAL B
DAL AStructural coverage
2009 INSA -- Test de Logiciels 75
Représentations internes
Abstractions de la structure d’un programme
- 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 INSA -- Test de Logiciels 76
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}
Hypothèses : Toute variable utilisée possède une définitionet à chaque définition correspond au moins une utilisation
Graphe Def/Use (GDU) – [Rapps & Weyuker 85]
2009 INSA -- Test de Logiciels 77
double P(int x, int y) {w = abs(y) ;z = 1.0 ;
while ( w != 0 ){
z = z*x ;w = w-1 ;
}
if ( y<0 ) z = 1.0 / z ;
return(z) ; }
Graphe Def/Use : exemple
1
2
3
4
5
6
c-use(1) : ∅def(1) : x,y,w,z
p-use(2,4) : wc-use(3) : x,z,wdef(3) : z,w
p-use(4,6) : yc-use(5) : zdef(5) : z
c-use(6) : z
p-use(2,3) : w
p-use(4,5) : y
2009 INSA -- Test de Logiciels 78
Chemin sans définition (def-clear path)
i-n1-…-nm-j est un chemin sans déf. de x de i à j
ssi ∀k ∈ {1,..,m}, x ∉ def(nk)
Soient i un sommet d’un GDU (N,A,e,s) et x ∈ def(i)
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 INSA -- Test de Logiciels 79
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)= ∅
dcu(z,3)= {3,5,6}, dpu(z,3)= ∅dcu(w,3)= {3}, dpu(w,3)= {2-3,2-4}
dcu(z,5) = {6}, dpu(z,5) = ∅
1
2
3
4
5
6
c-use(1) : ∅def(1) : x,y,w,z
p-use(2,4) : wc-use(3) : x,z,wdef(3) : z,w
p-use(4,6) : yc-use(5) : zdef(5) : z
c-use(6) : z
p-use(2,3) : w
p-use(4,5) : y
2009 INSA -- Test de Logiciels 80
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 xde n à un élément de dcu(x,n) ou dpu(x,n)
Critère structurel : toutes_les_définitions
2009 INSA -- Test de Logiciels 81
1
2
3
4
5
6
c-use(1) : ∅def(1) : x,y,w,z
p-use(2,4) : wc-use(3) : x,z,wdef(3) : z,w
p-use(4,6) : yc-use(5) : zdef(5) : z
c-use(6) : z
p-use(2,3) : w
p-use(4,5) : y
Couverture de toutes_les_définitions
Ici, un seul chemin suffit !1-2-3-2-4-5-6
2009 INSA -- Test de Logiciels 82
Déf : C satisfait toutes_les_utilisationsssi ∀n∈ N et ∀x∈ def(n), ∃Ci ∈ Ctq 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
toutes_les_utilisations est plus fort quetoutes_les_définitions
Critère structurel : toutes_les_utilisations
2009 INSA -- Test de Logiciels 83
Chemin définition/utilisation p.r.à. x (du-path w.r.t. x)
Déf: p = i-..-j-k estun 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 INSA -- Test de Logiciels 84
1
2
3
4
5
6
c-use(1) : ∅def(1) : x,y,w,z
p-use(2,4) : wc-use(3) : x,z,wdef(3) : z,w
p-use(4,6) : yc-use(5) : zdef(5) : z
c-use(6) : z
p-use(2,3) : w
p-use(4,5) : y
Chemin définition/utilisation : exemples
du_path w.r.t. x : 1-2-3du_paths w.r.t. y :1-2-4-5, 1-2-4-6,1-2-3-2-4-5,1-2-3-2-4-6
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
du_paths w.r.t. w :1-2-3,1-2-4,3-2-3,3-2-4
2009 INSA -- Test de Logiciels 85
Déf: C satisfait tous_les_chemins_dussi ∀n∈ N et ∀x∈ def(n), C inclut tous les cheminsdéfinition/utilisationpar rapport à x
Ici, 5 chemins !1-2-4-6, 1-2-4-5-6,
1-2-(3-2)2-4-6,1-2-3-2-4-5-61-2-3-2-4-6
Critère structurel : tous_les_chemins_du
1
2
3
4
5
6
c-use(1) : ∅def(1) : x,y,w,z
p-use(2,4) : wc-use(3) : x,z,wdef(3) : z,w
p-use(4,6) : y
c-use(5) : zdef(5) : z
c-use(6) : z
p-use(2,3) : w
p-use(4,5) : y
2009 INSA -- Test de Logiciels 86
Relation entre les critères (“est plus fort que”)
C1 subsume C2 (noté C1 ⇒ C2) ssi∀GDU, ∀ensemble de chemins P qui satisfait C1,
P satisfait aussi C2
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 INSA -- Test de Logiciels 87
Les liens entre critères liés au GDU et au GFC
tous_les_cheminstous_les_chemins_du
toutes_les_utilisations
toutes_les_définitions
tous_les_arcs
tous_les_sommets
Critères liés au GDU Critères liés au GFC
2009 INSA -- Test de Logiciels 88
Et en plus… [Rapps & Weyuker 1985]
tous_les_chemins
tous_les_chemins_du
toutes_les_utilisations
toutes_les_définitions
tous_les_arcs
tous_les_sommets
toutes_les_c_use/quelques_p_use
toutes_les_p_use/quelques_c_use
toutes_les_p_use
2009 INSA -- Test de Logiciels 89
tous_les_chemins n’est pas fiable !
Spéc : F(n) = n² Prog : ush P(ush n) { return(n+n);}
Ici, tous_les_chemins est couvert par a-bOn a COMPLETEP({0}, tous_les_chemins)COMPLETEP({1}, tous_les_chemins)
Mais okF(0,P(0)) et ¬okF(1,P(1))donc tous_les_chemins n’est pas fiable !
a
b
ush P(ush n)
return(n+n)
2009 INSA -- Test de Logiciels 90
Quelques outils disponibles...
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 www.iplbath.com/products
- IBM Rational Test Realtimewww-306.ibm.com/software/awdtools/test/realtime
- LDRA Testbed www.ldra.co.uk/pages/testbed.htm
2009 INSA -- Test de Logiciels 91
TEST UNITAIRE AVEC CUNIT
2009 INSA -- Test de Logiciels 92
Units of language
Functions in C
Task in ADA
Methods or classes in C++ and Java
Predicates in Prolog
…
2009 INSA -- Test de Logiciels 93
Unit testing frameworks
- JUnit, Parasoft’s Jtest for Java- CUnit, CTC++, IBM Rational Test Real Time for C- Parasoft’s C++Test, Cantata++… for C++…
http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks
2009 INSA -- Test de Logiciels 94
Unit testing: atomic operation
Select test input variable values
Define expected output values (a.k.a. oracle)
Code a test script and register it in a database
Run the test !
2009 INSA -- Test de Logiciels 95
Cunit (http://cunit.sourceforge.net/) -- 1
Lightweight system for writing, managingand running unit test for C programs
Built as a static library which is linked withthe user’s test script
provides a rich set of assertions for testing common data types.
2009 INSA -- Test de Logiciels 96
Cunit (http://cunit.sourceforge.net/) -- 2
Automated Output to XML file, Non-interactiveBasic
Flexible programming interface, Non-interactiveConsole
Console interface (ANSI C), InteractiveCurses
Graphical interface (Unix only), Interactive
2009 INSA -- Test de Logiciels 97
Exampletypedef unsigned short ush;
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; }
Select a test input: (28, 24)
Define expected output: 4
Define another test input : (24,28)
Expect output: 4
Script and run the test !
2009 INSA -- Test de Logiciels 98
Typical test script: test_gcd.c#include "Basic.h"
void test_gcd(void) { CU_ASSERT(4 == gcd(24, 28)); CU_ASSERT(4 == gcd(28, 24)); }
main() {CU_pSuite pSuite = NULL;
if (CUE_SUCCESS != CU_initialize_registry()) return CU_get_error();
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();
return CU_get_error(); }
CU_basic_run_tests(); CU_cleanup_registry();
return CU_get_error(); }
2009 INSA -- Test de Logiciels 99
Makefile
CUnitHeaders=/c/CUnit-2.1-0/include/CUnitCUnitLibs=/c/CUnit-2.1-0/lib
test_gcd: gcd.o test_gcd.o$(CC) $^ -L$(CUnitLibs) -lcunit -o $@
gcd.o: gcd.c$(CC) -c -D static= gcd.c
test_gcd.o: test_gcd.c$(CC) -c -I$(CUnitHeaders) test_gcd.c
clean: $(RM) gcd.o test_gcd.o test_gcd.exe 2009 INSA -- Test de Logiciels 100
Let’s play, now !
Download and install Cunit (README)requires Jam, MinGW on windows
http://cunit.sourceforge.net
Code gcd.c, test_gcd.c and Makefile
Run and explain…
2009 INSA -- Test de Logiciels 101
JUnit for Java
http://www.irisa.fr/lande/gotlieb/resources/JUnit_Tutorial.mp4
2009 INSA -- Test de Logiciels 102
0. Préliminaires
1. Test logiciel : principes
2. Génération automatique de test
3. Techniques de test fonctionnel
4. Test de logiciel orienté-objet
5. Test à partir de modèles
Plan complet du cours
2009 INSA -- Test de Logiciels 103
2. Génération automatique de cas de test
2.1 Test aléatoire2.2 Test statistique structurel2.3 Méthode dynamique2.4 Evaluation symbolique2.5 Méthode à contraintes
Plan
2009 INSA -- Test de Logiciels 104
Rappels: définition du test de programme
- Tester = exécuter un programme P pour mettre en évidence la présence de fautes, par rapport àsa spécification F
- Recherche de contre-exemples :
∃X tq P(X) ≠ F(X) ?
- Hypothèse de travail : oracle disponible
2009 INSA -- Test de Logiciels 105
Rappels des notations
X1X2
X5
X4X3
Dom(P)
okF(X1,P(X1))okF(X2,P(X2))...
Programme P : Dom(P) Ran(P)
Donnée de test : X ∈ Dom(P)
Jeu de test : T = {Xi}i =1..N
Oracle okF : Dom(P) x Ran(P) Bool
2009 INSA -- Test de Logiciels 106
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
(ex : chemins de P)
P(int i,int j) {if( C1 )else ...
if( C2)else ...} i
j
¬C1∧¬C2
¬C1∧ C2
C1∧¬C2
C1∧C2
Dom(P)
2009 INSA -- Test de Logiciels 107
Génération d’une seule donnée de test par élément à vérifier !
X1X4
X3
X2
Couverture déterministe d’un critère C
Dom(P)
Repose sur une hypothèse d’uniformité : une seule donnée de test suffit pour tout le sous-domaine
2009 INSA -- Test de Logiciels 108
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)
X1
X7X2
X4X5X6
X8 X3
Dom(P)
2009 INSA -- Test de Logiciels 109
2.1 Test aléatoire
Loi de probabilité uniforme sur le domaine d’entrée
(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 INSA -- Test de Logiciels 110
Qualité de test pour le test aléatoire : QN
On a :pf = probabilité que ∃X généré aléatoirement tq P(X) ≠ F(X)
QN = probabilité que (un de ces) X soit détecté après la génération de N DT aléatoires
Théorème : QN = 1 – (1-pf)N
Remarques : - l’évaluation de pf repose sur la connaissance des fautes- pas de lien avec les critères de test
2009 INSA -- Test de Logiciels 111
PreuveQ1 = pf
Q2 = Q1+ (1-Q1).pf
…Qn-1 = Qn-2 + (1-Qn-2).pf
Qn = Qn-1 + (1-Qn-1).pf
Q1 = pf
Q2 = pf + (1-pf).Q1
…Qn-1= pf + (1-pf).Qn-2
Qn = pf + (1-pf).Qn-1
(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
QN = 1 – (1-pf)N
C.Q.F.D.
2009 INSA -- Test de Logiciels 112
Efficacité du test aléatoire pour couvrir un critère ?
Dom(P)
A1
A3
A4
A2
p{x∈A} : probabilité qu’une DT aléatoire x couvre l’élément A
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’estpas satisfaisant !
2009 INSA -- Test de Logiciels 113
pc = min { p{x∈A} | A ∈ SC }
qN = probabilité que chaque élément de SC soit activé après la génération de N DT aléatoires
Théorème : qN = 1 – (1-pc)N
Corollaire : si pC≠0 et pC≠1 N ≥ ln(1-qN) ln(1- pC)
NB : qN ≠ QN la qualité de test pour le test aléatoire (en général)
Qualité de test pour le test statistique : qN[Thévenod-Fosse 89]
2009 INSA -- Test de Logiciels 114
2. Génération automatique de cas de test
2.1 Test aléatoire2.2 Test statistique structurel2.3 Méthode dynamique2.4 Evaluation symbolique2.5 Méthode à contraintes
Plan
2009 INSA -- Test de Logiciels 115
2.2 Test statistique structurel
Déf : C est couvert avec une probabilité qNsi 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
- couvrir C avec une probabilite qN devientl’objectif de test
- conséquence : maximiser pc= min { p{x∈A} | A ∈ SC}
2009 INSA -- Test de Logiciels 116
qN = 1 – (1 – pC)N pour N=2, 8, 16 cas de test
N = 2
N = 8N = 16
2009 INSA -- Test de Logiciels 117
Algorithme pour le critère tous_les_chemins
Dom(P)
A1
A3
A4
A2
1ère étape : calculer un profil d’entrée tq PA1= ..=PAk=1/k2ème étape : choisir qN et en déduire N, le nombre de DT3ème étape : générer N DT selon PA1 ,..,PAk
PA : probabilité qu’une donnée de test aléatoire couvre l’élément A2009 INSA -- Test de Logiciels 118
1ère étape : calculer un profil d’entrée tq PA1= ..=PAk=1/k
Calcul des proba. sur Dom(P) afin que PA1 = .. =PAk= 1/k
qN = 1 – (1 – pC)N
2009 INSA -- Test de Logiciels 119
2ème étape : choisir qN et en déduire N
Si qN = 0.85
N = 8 convient
2009 INSA -- Test de Logiciels 120
A1
A3
A4
A2
3ème étape : générer N DT selon PA1 = ..= PAk = 1/k
2009 INSA -- Test de Logiciels 121
Test statistique structurel : exemple (1)
I ≥ 0I < 0
1
2
3
5
6
4
B¬ B
C
¬C
(I,B,C) ∈ Dom(P) = {-231,..,231-1} x {0,1} x {0,1}
objectif de test : couvrir tous_les_cheminsavec qN = 0,99
P1-2-5-6 = P{ I < 0 }P1-2-3-5-6 = P{ I ≥ 0 } . P{ B }P1-2-3-4-5-6 = P{ I ≥ 0 } . P{ ¬B } . P{ C }P1-2-3-4-6 = P{ I ≥ 0 } . P{ ¬B } . P{ ¬C }
2009 INSA -- Test de Logiciels 122
I ≥ 0I < 0
1
2
3
5
6
4
B¬ B
C
¬C
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 = ¼
on pose :x = P{I < 0}, y = P{B}, z = P{C}
d’où :x = ¼
(1-x) . y = ¼
(1-x) . (1-y) . z = ¼
(1-x) . (1-y) . (1-z) = ¼
Test statistique structurel : exemple (2)
2009 INSA -- Test de Logiciels 123
Test statistique structurel : exemple (3)
I ≥ 0I < 0
1
2
3
5
6
4
B¬ B
C
¬C
Profil d’entrée :P{I < 0} = 1/4 et P{I ≥ 0} = 3/4P{B} = 1/3 et P{¬B} = 2/3P{C} = 1/2 et P{¬C} = 1/2
Nbre de DT à générer (si qN = 0.99 ) :Par la relation
N ≥ ln(1-qN) / ln(1- pC) on obtient N ≥ 16
2009 INSA -- Test de Logiciels 124
Test statistique structurel : limites et extensions
- le biais introduit par les chemins non-exécutables n’estpas pris en compte
- génération du profil d’entrée pour les critèrestous_les_sommets, tous_les_arcs nécessite une prise encompte fine des boucles
- générateur uniforme dans un sous-domaine d’entréedéfini sous contraintes difficile à réaliser
Mais fonctionne bien avec des données expérimentales ![Thévenod-Fosse, Waeselynck 91]
Test statistique structurel : travaux et outils
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
IRISA / Celtique :AUGUSTE (LRI) : Test statistique et structures combinatoiresProjet GENETTA : Test statistique structurel pour Java Card
LSR-IMAG – équipe VaSCo :Test statistique fonctionnel de programmes Lustre --LUTESS 2009 INSA -- Test de Logiciels 126
Exercice :
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 ;
else5. if (x > z)6. t = x ;
else7. t = z;8. return t;
}
a) Que calcule P ?b) Déssiner le GFC de Pc) Calculer un profil d’entrée
qui rende équiprobablechacun des chemins de P
d) Déterminer le nombre N de DT à générer pour couvrirtous_les_chemins avec qN = 0.8
Indications : ln(0.2)=-1.6 et ln(0.75)=-0.28
2009 INSA -- Test de Logiciels 127
2. Génération automatique de cas de test
2.1 Test aléatoire2.2 Test statistique structurel2.3 Méthode dynamique2.4 Evaluation symbolique2.5 Méthode à contraintes
Plan
2009 INSA -- Test de Logiciels 128
2.3 Méthode dynamique [Korel 90]
Dom(P)
{X | c=exec(P,X)}
Objectif : Calcul de X tel que le chemin c soit sensibilisé ?
2009 INSA -- Test de Logiciels 129
Méthode dynamique orientée-chemin
Objectif :Calcul de X tel que c = exec(P,X) ?
Principe : Transformer le problème en un problème de minisation d’unefonction objectif, sous contraintes
Minimiser la fonction de branche F(X)
= problème classique de Recherche Opérationnelle
n3n4
n5
n6
s
e
n1
n2
2009 INSA -- Test de Logiciels 130
Méthode dynamique : algorithme
X random ;tant que( exec(P,X) ≠ e-n1-..nq-s) {
1) noter le flot (par instrumentation)exec(P,X) = e-p1-..-pj-s
2) identifier nk (ou pk) le premier sommetpour lequel nk+1 ≠ pk+1
3) X minimiser Fnk-nk+1(X)
en conservant e-n1-..-nk parcouru}
n4
n5
n6
s
e
n1
n2
n3
2009 INSA -- Test de Logiciels 131
Fonction de branche : définition
Fonction de branche Fd(X) à valeurs réelles :
Nota : Fd(X) dépend implicitement des variables d’entrée
< 0E1 – E2E1 < E2
< 0- abs(E1 – E2)E1 ≠ E2
= 0abs(E1 – E2)E1 = E2
≤ 0E1 – E2E1 ≤ E2
≤ 0
< 0Relat
E2 – E1E1 ≥ E2
E2 – E1E1 > E2
Fonction de branche Fd(X)Décision d
2009 INSA -- Test de Logiciels 132
Etape critique : minimiser la fonction de branche
Idée : utiliser des exécutions du programme
X minimiser Fnk-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 !
2009 INSA -- Test de Logiciels 133
Méthode dynamique : algorithme
X random ;tant que( exec(P,X) ≠ e-n1-..nq-s) {
1) noter le flot (par instrumentation)exec(P,X) = e-p1-..-pj-s
2) identifier nk (ou pk) le premier sommetpour lequel nk+1 ≠ pk+1
3) X minimiser Fnk-nk+1(X)
en conservant e-n1-..-nk parcouru}
n4
n5
n6
s
e
n1
n2
n3
2009 INSA -- Test de Logiciels 134
double P(short x, short y) {short w = abs(y) ;double z = 1.0 ;
while ( w != 0 ){
z = z * x ;w = w - 1 ;
}
if ( y<0 ) z = 1.0 / z ;
return(z) ; }
Exemple: programme Puissance(X,Y)
w != 0
z= z * xw= w-1
y<0
z=1.0 / z
a
b
c
d
e
f
P(short x,y)w= abs(y)z= 1.0
2009 INSA -- Test de Logiciels 135
Méthode dynamique orientée-chemin : exemple (1)
w != 0
z= z * xw= w-1
y<0
z=1.0 / z
a
b
c
d
e
freturn(z)
X 2
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 etFb-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
P(short x,y)w= abs(y)z= 1.0
2009 INSA -- Test de Logiciels 136
Méthode dynamique orientée-chemin : exemple (2)
w != 0
z= z * xw= w-1
y<0
z=1.0 / z
a
b
c
d
e
freturn(z)
X 2
Calcul de X tq a-b-(c-b)2-d-f
3) exec(P,(18,-2))=a-b-(c-b)2-d-e-f
4) donc k = d-f etFd-f((X,Y))= -y
on a Fd-f((18,-2))=2
par la méthode de la variable alternée :(X,Y) (18,2) etexec(P,(18,2))= a-b-(c-b)2-d-f
P(short x,y)w= abs(y)z= 1.0
2009 INSA -- Test de Logiciels 137
Méthode dynamique : limites et travaux
Limites :technique de minimisation limitée à l’essai de valeursheuristique incomplète
Extensions :- Illinois Institute of Technology (USA) – Bogdan Koreltous_les_arcs + analyse dynamique de flot de données
- University of York (UK) – group Testsigminimisation de la fonction de branche par recuit-simulé
- University of Arizona (USA) – projet et outil TGENrelaxation itérative + découverte dynamique d’invariants
2009 INSA -- Test de Logiciels 138
Bibliographie (sélective) pour ce cours
[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 INSA -- Test de Logiciels 139
Rappels (notations et un résultat)
Donnée de test : X ∈ Dom(P)
Jeu de test : T = {Xi}i =1..N
Oracle okF : Dom(P) x Ran(P) Bool
exec(P,X) : chemin complet du GFC sensibilisé par X
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 INSA -- Test de Logiciels 140
2. Génération automatique de cas de test
2.1 Test aléatoire2.2 Test statistique structurel2.3 Méthode dynamique2.4 Evaluation symbolique2.5 Méthode à contraintes
Plan
2009 INSA -- Test de Logiciels 141
2.4 Evaluation symbolique [King 76, Clarke 76]
Technique d’analyse orientée-chemin du GFC- Exécution symbolique simple- Evaluation symbolique dynamique- Evaluation symbolique globale
Utilisation d’expressions algébriques pour représenterles valeurs des variables
Utilisé en vérification (preuve), optimisation dans les compilateurs, spécialisation, en génération automatique de cas de test, etc.
2009 INSA -- Test de Logiciels 142
Exécution symbolique simple : exempleEvaluation (avant) d’un chemin du GFC
avec des valeurs symboliques
Ex : a-b-(c-b)2-d-f avec X,Ya: w := abs(Y); z := 1.0 ;
b: abs(Y) != 0;c: z := X; w := abs(Y) – 1;
b: abs(Y)-1 != 0;c: z := X * X; w := abs(Y) – 2;
b: abs(Y)-2 = 0;d: Y ≥ 0
f: return(X * X)
w != 0
z= z * xw= w-1
y<0
z=1.0 / z
a
b
c
d
e
f
P(short x,y)short w= abs(y)double z= 1.0
return(z)
2009 INSA -- Test de Logiciels 143
Etat symbolique
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 GFCState = {<v,ϕ>}v∈Var(P) -- ϕ une expr. algébrique de XPC = c1∧.. ∧ cn -- ck condition portant sur X
NB : PC pour Path Condition2009 INSA -- Test de Logiciels 144
<Path,State,PC> : exemples
w != 0
z= z * xw= w-1
y<0
z=1.0 / z
a
b
c
d
e
f
P(short x,y)short w= abs(y)double z= 1.0
return(z)
< a, {<z, ⊥>, <w, ⊥>}, true>
< a-b-c-b, {<z, X>, <w, abs(Y)-1>},abs(Y) != 0 >
< a-b-(c-b)2-d-f, {<z, X2>, <w, abs(Y)-2>},(abs(Y) != 0)∧(abs(Y) != 1)∧(abs(Y) = 2)∧(Y ≥ 0) >
2009 INSA -- Test de Logiciels 145
Etat symbolique : propriétés
<Path, State, PC> se calcule par induction surchaque instruction des sommets de Path
soit SPC l’ensemble solution de PC∀X∈SPC, Path est inclus dans exec(P,X)
Si SPC = ∅ alors Path est non-exécutableex : < a-b-d-e-f, {…}, abs(Y)=0 ∧ Y<0 >
2009 INSA -- Test de Logiciels 146
Analyses avant et arrière
Analyse avant :- suivi de Path dans le sens d’exécution- intéressant pour le calcul des états symboliquescomplets
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é)
2009 INSA -- Test de Logiciels 147
Analyse arrière : exemple
Ex : a-b-(c-b)2-d-f avec X,Y
PC f,d: Y ≥0
PC b: Y ≥0, w = 0
PC c: Y ≥0, w-1 = 0
PC b: Y ≥0, w-1 = 0, w != 0
PC c: Y ≥0, w-2 = 0, w-1 != 0
PC b: Y ≥0, w-2 =0, w-1 != 0,w != 0
PC a: Y ≥0, abs(Y)-2 = 0, abs(Y)-1 != 0, abs(Y) != 0
w != 0
z= z * xw= w-1
y<0
z=1.0 / z
a
b
c
d
e
f
P(short x,y)short w= abs(y)double z= 1.0
return(z)
X 2
2009 INSA -- Test de Logiciels 148
Génération automatique de données de test
Par exécution symbolique simple (analyse arrière de préférence)
a-b-(c-b)2-d-f
PC:(abs(Y) != 0)∧(abs(Y) != 1)∧(abs(Y) = 2)∧ (Y ≥ 0)+ Résolution interactive des conditions
w != 0
z= z * xw= w-1
y<0
z=1.0 / z
a
b
c
d
e
f
P(short x,y)short w= abs(y)double z= 1.0
return(z)
X 2
2009 INSA -- Test de Logiciels 149
Résolution interactive des conditions
- 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 surles programmes analysés
Problème 2 : choix d’un chemin au préalablechemin éventuellement non-exécutable !
2009 INSA -- Test de Logiciels 150
Evaluation symbolique dynamique
Evaluation symbolique simultanée d’un cheminconcrè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 INSA -- Test de Logiciels 151
Evaluation symbolique globale : principe
Représentation de tous les chemins par un arbred’exécution
Nécessite une analyse des boucles (loop analysis) :
while( w != 0 ){
z = z*x ;w = w-1 ;
}
Utile pour la preuve de programme et l’optimisation maistrès coûteux en temps de calcul et en place mémoire
z1 = 1.0w1 = abs(Y)
zk+1 = zk * Xwk+1 = wk - 1
2009 INSA -- Test de Logiciels 152
Evaluation symbolique globale : exemple
w != 0
z= z * xw= w-1
y<0
z=1.0 / z
a
b
c
d
e
f
P(short x,y)short w= abs(y)double z= 1.0
return(z)
<z1, 1.0>, <w1, abs(Y)>
PC: abs(Y) = 0 PC: abs(Y) != 0
∧ PC: Y<0
échec
∧ PC: Y≥0
<z,1.0>
<zk+1, zk * X>, <wk+1, wk - 1>
∧ PC: wk+1 = 0
∧ PC: Y<0 ∧ PC: Y≥0
<z, 1/zk+1> <z, zk+1>
2009 INSA -- Test de Logiciels 153
Propriétes : diagramme commutatif
P(X), DT
Esymb(P(X)), DT Econc(P(DT)) =Esymb(P(X)) DT
P(X), X DT
Programme P, X vecteur d’entrées symboliques, DT donnéeEconc : exécution concrèteEsymb : évaluation symbolique globale
Eval. symb. glob. Exec. concrète
2009 INSA -- Test de Logiciels 154
Problems for symbolic evaluation techniques
Number of iterations in loops must be selected prior to any symbolic execution
Arrays int P(int i) {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)
Symbolic execution constrains the shape of dynamically allocated objects
int P(struct cell *t) { if( t == t->next ) { …
constrains t to:
t
key next?
2009 INSA -- Test de Logiciels 155
Travaux et outils pour l’évaluation symbolique
* PathCrawler/CAVEAT(CEA) Vérification de programmes C
* SYMBAD/SESADA (Université Polytech. de Milan)Tableaux, Spécialisation de programme ADA
* MulSaw project (MIT) – Model-Checking pour Java* PREfix, SLAM (Microsoft Reliability Group) -- Détection de
fautes pour C
Outils commerciaux :MALPAS (TA Consultancy – UK) – SPADE pour ADA
2009 INSA -- Test de Logiciels 156
On-the-fly selection of feasible paths:The PathCrawler tool
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 2005http://www-list.cea.fr/labos/fr/LSL/test/pathcrawler/index.html
Addresses the problem of non-feasible paths in path-oriented test data generatorfor C programs
A randomized algo. based on dynamic symbolic execution and constraintsatisfaction over finite domains (a proprietary constraint library in Eclipse Prolog)
An (important) emerging idea in CBT: papers in PLDI (Godefroid et al. 2005), ESEC/FSE (Sen et al. 2005), POPL (Godefroid 2007), …
2009 INSA -- Test de Logiciels 157
The idea
1
2 3
4 5
Generate a random input anddynamic symbolic exec. over the corresp. feasible path
1
2 3
4 5
b
Try to solve the CS wherethe last constraint is refuted
If unsatisfiable then path is non-feasible and problem comesfrom the last constraint
Else coverage of feasible path is improved
1
2 3
4 5
b
Backtrack and try tosolve the remaining CS
2009 INSA -- Test de Logiciels 158
f( int i ){
j = 2;if( i ≤ 16 )
j = j * i;
if( j > 8)j = 0;
return j;}
5
4
3
2
1
f
t
t
f
An example (1)
2009 INSA -- Test de Logiciels 159
f( int i ){
j = 2;if( i ≤ 16 )
j = j * i;
if( j > 8)j = 0;
return j;}
5
4
3
2
1
f
t
t
f
An example (2)
Random imput generation
( i = 15448)
Path 1-3-5
2009 INSA -- Test de Logiciels 160
f( int i ){
j = 2;if( i ≤ 16 )
j = j * i;
if( j > 8)j = 0;
return j;}
5
4
3
2
1
f
t
t
f
An example (3)
Try to solve
j1=2i > 16
j1 > 8
Unsatisfiable, thereforePath 1-3-4 is non-feasible
2009 INSA -- Test de Logiciels 161
f( int i ){
j = 2;if( i ≤ 16 )
j = j * i;
if( j > 8)j = 0;
return j;}
5
4
3
2
1
f
t
t
f
An example (4)
Bactrack and try to solve
j1=2i <= 16
( i = 2 ) -- Path 1-2-3-5
2009 INSA -- Test de Logiciels 162
f( int i ){
j = 2;if( i ≤ 16 )
j = j * i;
if( j > 8)j = 0;
return j;}
5
4
3
2
1
f
t
t
f
An example (5)
Bactrack and try to solvej1 = 2i <= 16 j2 = j1*i
j2 > 8
( i = 10) -- Path 1-2-3-4-5
All-paths covered with three testdata (i = 15448, i = 2, i = 10)
2009 INSA -- Test de Logiciels 163
The PathCrawler method: discussion
Requires to bound the number of iterations in loopssuitable for automatic test data generation for the All-k-paths criterion
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 INSA -- Test de Logiciels 164
2. Génération automatique de cas de test
2.1 Test aléatoire2.2 Test statistique structurel2.3 Méthode dynamique2.4 Evaluation symbolique2.5 Méthode à contraintes
Plan
2009 INSA -- Test de Logiciels 165
f( int i ){
j = 2if( i ≤ 16 )
j = j * i
if( j > 8)j = 0
return j}
5
4
3
2
1
f
t
t
f
An example of the core problem
value of i to get there ?
2009 INSA -- Test de Logiciels 166
f( int i ){
j = 2if( i ≤ 16 )
j = j * i
if( j > 8)j = 0
return j}
Intuition of our approach
j > 8i > 16 ⇒ j = 2
i ≤ 16 ⇒ j = 2 * i
i ≤ 16, 2 * i > 8
5 ≤ i ≤ 16
2009 INSA -- Test de Logiciels 167
* Technique d’analyse du GFC orientée-but
* Transformation systèmatique du problème en un problème de résolution de contraintes
2.5 Méthode à contraintes
[Bicevskis 79, Gotlieb et al 98]
2009 INSA -- Test de Logiciels 168
Goal-oriented test data generation
A three-step process:
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 INSA -- Test de Logiciels 169
Viewing an assignment statement as a relation requires to rename the variables
i := i + 1 i2 = i1 + 1
Static Single Assignment (SSA) form (Cytron 1991) or single assignment language
A constraint model of imperative programs
2009 INSA -- Test de Logiciels 170
SSA form
x := x + y;y := x – y;x := x – y;
Each use of a variable refers to a single definition
At the junction nodes
i := ... i := ...
... := i + ...
1 2
3
x1 := x0 + y0;y1 := x1 – y0;x2 := x1 – y1;
i1 := ... i2 := ..
i3 := φ( i1,i2)... := i3 + ...
1 2
3
φ_functions
SSA : example
w != 0
z= z * xw= w-1
y<0
z=1.0 / z
a
b
c
d
e
f
P(short x,y)short w= abs(y)double z= 1.0
return(z)
w3 =φ( w1,w2)z3 = φ( z1,z2)w3 != 0
z2 = z3 * xw2= w3 - 1
y < 0
z4 =1.0 / z3
a
b
c
d
e
f
PSSA(short x,y)w1= abs(y)z1= 1.0
z5 = φ(z4,z3)return(z5)
2009 INSA -- Test de Logiciels 172
- les GFCs (N,A,e,s) de P et de PSSA sont identiques
- élimine les anti-dépandences (chemins_ud) et lesdépandences-de-sortie (chemins_dd)
- si D = définitions de x, U = utilisations de xalors 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)|
- SSA autorise la commutativité des instructions
Forme SSA : propriétés
2009 INSA -- Test de Logiciels 173
Variable declaration Domain constraint
ush i I ∈ 0 .. 232-1
Assignment, decision Arithmetical constraints {=, <,..}
j2 = j1 * i J2 = J1 * Ii == j I = Ji < j I < J
Conditionnal (SSA)If D then C1; else C2; v3=φ(v1,v2) (D /\ C1 /\ v3=v1) \/ (¬D /\ C2 /\ v3=v2)
Iteration (SSA)v3=φ(v1,v2) while D do C v3=v1 \/ (D1 /\ C1 /\ ¬D2 /\ v3=v2 ) \/ …
SSA form Constraint system
2009 INSA -- Test de Logiciels 174
Ce = ¬ Cond4 ∧ Cond2 ∧ Cond1
t
f
f
t
t
t
Cond1
Cond2
Cond4
Cond3
e
Testing objective (1)
Utilisation des dépendances de contrôle= ensemble de conditions à vérifier
pour atteindre e
Nota : calculable syntaxiquement sile programme est structuré
2009 INSA -- Test de Logiciels 175
- In functional testing, property to be refuted (e.g. a post-condition of the program)
Testing objective (2)
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) {...}
Ce = ¬( balance = old_balance – amount)
2009 INSA -- Test de Logiciels 176
Problems for goal-oriented test data generation
- Constraint solving over disjunctions of constraints is required(conditionals, switch, iterations)
- Conditional aliasing problems
« reaching branch 5-6 » ⇒ « p points to i at statement 4 » ⇒ « C is satisfied »
...1. if( C )2. p = &i ;3. i = 10 ;4. *p = 0 ;5. if( i < 5 ) 6. ...
How to reach branch 5-6 ?
2009 INSA -- Test de Logiciels 177
Bibliographie (sélective) pour ce cours
[King 76]« Symbolic Execution and Program Testing »Communications of ACM Vol 19, N°7, Jul. 1976
[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 INSA -- Test de Logiciels 178
InKa: a goal-oriented test data generatorbased on constraint combinators
Automatic Test Data Generation using Constraint Solving TechniquesA. Gotlieb, B. Botella, M. RueherACM 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 INSA -- Test de Logiciels 179
Modelling an error-free semantics
The constraint model of programs does not have to handleerrors or exceptions as it is targeted to generate test data for detectingfunctional faults
int f( int x, int y) {return( x / y ) R = X / Y}
Executing f with (x=1, y=0) throws an exception while the constraintR = X / Y just removes 0 from the domain of Y. Therefore, the possible erroneousexecution is not considered by the constraint model. This is ok as the goal of CBT is to detect functional faults and not runtime errors !
2009 INSA -- Test de Logiciels 180
Conditional: the combinator ite
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) MIN := Proj(IN, MTHEN ∪ MELSE)
1
0v := Decision ;if(v)
2
3
Else_partThen_part
2009 INSA -- Test de Logiciels 181
w(V, CBODY, MIN,MOUT) :-• V=1 → CBODY ∧ w(V, CBODY,MBODY,MOUT)• V=0 → MOUT = MIN
• ¬(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)
Where ∇ stands for a widening operator
V := Decision ;while( V )
1
2
Body3
Iteration: the combinator w
2009 INSA -- Test de Logiciels 182
Example (1)
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.
f( int i ){
j = 2;if( i ≤ 16 )
j = j * i;
if( j > 8)j = 0;
return j;}
2009 INSA -- Test de Logiciels 183
I = 18 ? I = 4
2 ≤ RET ≤ 8RET = 8 ?RET = 2
1 ≤ I ≤ 4 ?
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.
RET = 12 ?
Impossible
Example (2)
2009 INSA -- Test de Logiciels 184
f( int i ){
j = 2;if( i ≤ 16 )
j = j * i;
if( j > 8)j = 0;
return j,}
J3 > 8 ?
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.
5 ≤ I ≤ 16 Test datum: I = 10
Example (3)
2009 INSA -- Test de Logiciels 185
The InKa method: discussion
Handles nicely conditonals and loops
First introduction of constraint satisfaction techniques in structural software testing
Suitable for generating test data in front of a single testing objective(to complete an existing test suite)
Can be stucked on infinite loops (time-out required)
2009 INSA -- Test de Logiciels 186
Extensions (in CELTIQUE)
Handling conditional pointer aliasing problemsconstraint-based test data generation for pointer programs(Gotlieb Denmat Botella COMPSAC’05, ASE’05, IST’07)
Handling floating-point numbers in constraint-based structural test data generation (Botella Gotlieb Michel STVR 2006)
Efficient handling of conditional and iterations based on Abstract Interpretationtechniques (Denmat Gotlieb Ducassé CP 2007)
Efficient implemention in progress (access through a web service) : EUCLIDE (Gotlieb ICST 2009)
also http://euclide.gforge.inria.fr/
2009 INSA -- Test de Logiciels 187
Récapitulatif des techniques pour le test structurel
Test statistique
Eval. symbolique
Méthodedynamique
Méthode àcontraintes
2009 INSA -- Test de Logiciels 188
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
- Techniques de génération de cas de test variées
- Apport fondamental des « Contraintes » au domaine du Test
2009 INSA -- Test de Logiciels 189
0. Préliminaires
1. Test logiciel : principes
2. Génération automatique de test
3. Techniques de test fonctionnel
4. Test de logiciel orienté-objet
5. Test à partir de modèles
Plan complet du cours
2009 INSA -- Test de Logiciels 190
Techniques élémentaires
- Test exhaustif- Test par échantillions- Test aléatoire
Génération automatique de données de test (1)
2009 INSA -- Test de Logiciels 191
Test exhaustif
- Parcours exhaustif du domaine d’entrée des programmes
- Séléction de toutes les données de test possible
- Equivalent à une preuve de correction du programme
Dom(P)
2009 INSA -- Test de Logiciels 192
Test exhaustif : limitation et intérêt
- Mais, généralement impraticable !
- Estimation de la taille de l’espace de recherche face à un objectif de test
ex d’objectif : atteindre une instruction dans le programme
P (ush x1, ush x2, ush x3) { ... }
232 possibilités × 232 possibilités × 232 possibilités = 296 possibilités
2009 INSA -- Test de Logiciels 193
Test par échantillion
Dom(P)
Forme faible du test exhaustif : test par échantillionExemples :
{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)
X1
X5
X2 X3 X4
X6
2009 INSA -- Test de Logiciels 194
Test aléatoire
Loi de probabilité uniforme sur le domaine d’entrée
(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 INSA -- Test de Logiciels 195
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
(ex : chemins de P)
P(int i,int j) {if( C1 )else ...
if( C2)else ...} i
j
¬C1∧¬C2
¬C1∧ C2
C1∧¬C2
C1∧C2
Dom(P)
2009 INSA -- Test de Logiciels 196
Génération d’une seule donnée de test par élément à vérifier !
X1X4
X3
X2
Couverture déterministe d’un critère C
Dom(P)
Repose sur une hypothèse d’uniformité : une seule donnée de test suffit pour tout le sous-domaine
2009 INSA -- Test de Logiciels 197
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)
X1
X7X2
X4X5X6
X8 X3
Dom(P)
2009 INSA -- Test de Logiciels 198
Efficacité du test aléatoire pour couvrir un critère ?
Dom(P)
A1
A3
A4
A2
p{x∈A} : probabilité qu’une DT aléatoire x couvre l’élément A
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’estpas satisfaisant ! Test statistique structurel [Thévenod 90]
2009 INSA -- Test de Logiciels 199
Techniques de test fonctionnel
- Analyse partitionnelle- Test aux limites- Test à partir de Graphes Cause/Effet
Génération automatique de données de test (2)
2009 INSA -- Test de Logiciels 200
Un test pour soi-même
« The program reads three integer values from a card. Thethree values are interpreted as representing the lengths ofthe sides of a triangle. The program prints a message thatstates whether the triangle is scalene, isocele, or equilateral » [Myers 79]
Ecrire un jeu de test que vous sentez être adéquate pour tester ce programme
2009 INSA -- Test de Logiciels 201
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)
Exécutiondes tests pass / fail
Générationde tests
Jeu de test
spécifications
implementationi
Correction ?
2009 INSA -- Test de Logiciels 202
Analyse partitionnelle (1)
- Technique de test majoritairement employé en présence de spécifications informelles
- Idée : Découper le domaine d’entrée en classes d’équivalence : ensembles d’entrées aboutissant au même comportement fonctionnel
- Soit D le domaine d’entrée, {C1,..,Cn} est une partition de D ssi :
et Un
ii DC
1== ∅=∩∈∀ ji CCnji ,..1,
2009 INSA -- Test de Logiciels 203
Analyse partitionnelle (2)
- Permet au testeur de passer d’un nombre infini de données à un nombre fini et limité de données de test
- 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)Entier : a ≤ 0, a> 0 ou a<0, a=0,a>0Intervalle : ∅, [a,b] où a < b < ∞, [-∞,+∞]Ensemble : ∅, {a}, {a,b}, {a,b,c}, ...Arbre bin. : nil, , ... a
nilnil2009 INSA -- Test de Logiciels 204
Partitionnement unidimensionnel
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éepartitionnement 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étecterdes fautes
2009 INSA -- Test de Logiciels 205
Considérer le domaine d’entrée comme le produitCarté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 partitionnementmultidimensionnel.
Grand nombre de cas de test, difficiles à gérermanuellement. Cependant, bien que certaines classes créées puissent être invalides, cette méthode offre unegrande variété de cas de test.
Partitionnement multidimensionnel
2009 INSA -- Test de Logiciels 206
PGCD(ENTIER a, ENTIER b)
Classes validesC1 : a = 0, C2 : a > 0,D1 : b = 0,D2 : b > 0
Classes invalidesC3 : a < 0,D3 : b < 0
Partitionnement unidimensionnel : example
Problème : a = b = 0 appartient à C1 et à D1
2009 INSA -- Test de Logiciels 207
PGCD(ENTIER a, ENTIER b)Classes validesC1 : a = b = 0C2 : a = b, a > 0, b > 0C3 : a >= 0, b >= 0, a ≠ b
Classes invalidesC4 : a < 0, b < 0C5 : a < 0, b > 0C6 : a > 0, b < 0
Partitionnement multidimensionnel : example
2009 INSA -- Test de Logiciels 208
Erreurs aux limites
L’expérience montre que les programmeurs font souvent des erreurs aux bornes des classes d’équivalence
Par exemple, si le programme P est sensé calculerune 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 êtrerévelée par une analyse partitionnelle (x ≤ 0, x > 0 ou x<0, x=0, x>0).
2009 INSA -- Test de Logiciels 209
Test aux limites
- Idée : Identification des données de test « limites » définies par la spécification suite à l’analyse partitionnelle
- Sélection de données de test aux bornes valides et invalides
- Formalisation de la notion de limite difficile dans le cas général heuristiques de choix des valeurs
2009 INSA -- Test de Logiciels 210
Test aux limites de l’intervalle [1,100]
1 100
0 21 99 101100
Mais combinatoire importante en présence de vecteurs d’entrées définition de voisinages discrets
Ecrire des définitions possibles de voisinages discrets d’1 point en dimension 2, puis généralisez en dimension n
2009 INSA -- Test de Logiciels 211
Graphes cause-effet
- Idée : Réseau logique qui relie les effets d’un programme (sorties) à leurs causes (entrées)
4 types de symboles :identité négation
~OU logique
∨ET logique
∧
2009 INSA -- Test de Logiciels 212
Graphes cause-effet : example (1)« 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 premiercaractè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é »
Analyse des causes :A1 : le caractère de la première colonne est AA2 : le caractère de la première colonne est BA3 : le caractère de la deuxième colonne est un chiffre Analyse des effets :M1 : programme okM2 : message X12M3 : message X13
2009 INSA -- Test de Logiciels 213
Graphes cause-effet : example (2)
∨
~
~
∧
A1
M3
M1
M2
E
A3
A2
Analyse des causes :A1 : le car de col 1 est AA2 : le car de col 1 est BA3 : le car de col 2
est un chiffre Analyse des effets :M1 : programme okM2 : message X12M3 : message X13
2009 INSA -- Test de Logiciels 214
Graphes cause-effet : génération de cas de test
- Causes et effets sont vus comme des variables booléennes
- Génération automatique d’une matrice de décision (matrice booléenne, Vrai : 1 Faux : 0) à partir du graphe cause-effet
- Elimination des combinaisons invalides : «comportements inobservables» (représentées par une contrainte sur le graphe cause effet)
Par ex: A1 et A2 vrais où A1 : le car de col 1 est AA2 : le car de col 1 est B
2009 INSA -- Test de Logiciels 215
Matrice de décision
001101CT 6
100001CT 5
001110CT 4
100010CT 3
010100CT 2
110000CT 1
M3M2M1A3A2A1Cause-effet
∨
~
~
∧
A1
M3
M1
M2
E
A3
A2
2009 INSA -- Test de Logiciels 216
Génération de cas de test concrets
001101CT 6
100001CT 5
001110CT 4
100010CT 3
010100CT 2
110000CT 1M3M2M1A3A2A1
Analyse des causes :A1 : le car de col 1 est AA2 : le car de col 1 est BA3 : le car de col 2
est un chiffre
« Ca », X12, X13 émis
« C1 », X12 émis
Analyse des effets :M1 : programme okM2 : message X12M3 : message X13
« Bz », X13 émis
« B3 », ok« Ak », X13 émis
« A4 », ok
2009 INSA -- Test de Logiciels 217
Réduction de la combinatoire
- Si n = nombre de causes, m = nombre d’effetsalors 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 ?
Idée : Eliminer les CT redondants en identifiant ceux ayant des comportements similaires (mêmes effets) bien qu’ayant des causes différentes
Ex: CT3 et CT5
2009 INSA -- Test de Logiciels 218
Technique de réduction sur le graphe cause-effet
∨
~
~
∧
A1
M3
M1
M2
E
A3
A2
Par construction,(A1 = 1, A2 = 1)(A1 = 1, A2 = 0)(A1 = 0, A2 = 1)conduisent à E = 1 etaux mêmes effets
Seul un des trois est choisi
Règles similaires pour les autres connecteurs
2009 INSA -- Test de Logiciels 219
Exercice :
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 threearguments: the first argument should be an existing file in the sender’s home directory, the second argument should be the nameof the receiver’s file server, and the third argument should be the receiver’s userid. If all the arguments are correct, then the file issuccessfully sent ; otherwise the sender obtains an error message.
1. Modéliser cette commande avec un graphe cause-effet 2. Générer une matrice de décision
2009 INSA -- Test de Logiciels 220
Exercice (2): 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.
1) Modéliser en premier lieu le distributeur sans alarme avec un graphe cause-effet Puis modéliser le distributeur complet avec alarmes.
2) Générer une matrice de décision
3) Réduire la matrice et générer quelques cas de test représentatifs
2009 INSA -- Test de Logiciels 221
Modélisation sans alarmeCauses : Effets :C0 = Appuyer sur la touche t1 E0 = la boisson demandée couleC1 = Appuyer sur la touche t2 E1 = la touche t1 s’éteintC2 = Appuyer le verre contre la gâchette E2 = la touche t2 s’éteint
C0
C2
C1
E2
E1
E0∧∧
∧
~
~ ∧
2009 INSA -- Test de Logiciels 222
Modélisation avec alarmeCauses : Effets :C0 = Appuyer sur la touche t1 E0 = la boisson demandée couleC1 = Appuyer sur la touche t2 E1 = la touche t1 s’éteintC2 = Appuyer le verre contre la gâchette E2 = la touche t2 s’éteintC3 = Plus de boisson dans le réservoir E3 = Alarme activéeC4 = Récipient plein
C0
C2
C1
E2
E1
E0∧∧
∧
~
~ ∧
C3
C4
E3
∧~
~
~
2009 INSA -- Test de Logiciels 223
0
0
1
1
0
E3
0
0
0
1
0
C4
0
0
1
0
0
C3
…
010001CT 5
001101CT 4
000110CT 3
000000CT 2
000000CT 1
E2E1E0C2C1C0Cause-effet
Matrice de décision
2009 INSA -- Test de Logiciels 224
0
0
1
1
0
E3
0
0
0
1
0
C4
0
0
1
0
0
C3
…
010001CT 5
001101CT 4
000110CT 3
000000CT 2
000000CT 1
E2E1E0C2C1C0Cause-effet
Regroupement fonctionnel et cas de test
Fonctionnellement équivalents
t1 est appuyée et la gâchette enfoncée la boisson coule
Le récipient est plein L’alarme se déclenche
2009 INSA -- Test de Logiciels 225
1. Techniques de test élémentaires
2. Test de logiciel orientés-objet
3. Model-Based Testing
Plan du cours d’aujourd’hui
2009 INSA -- Test de Logiciels 226
Langages orientés objet / langages impératifs
Langages impératifs : fonctions qui transformentdes entrées en sortie
Langages OO : objets qui modélisent un problèmeet 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
2009 INSA -- Test de Logiciels 227
Langages OO et test : un aperçu des difficultés
Encapsulation des donnéesComment connaître les états internes des objets dont les attributssont privés ?
Dépendances fortes entre certaines classesDans quel ordre tester les classes ?Que tester dans une classe qui hérite d’une autre ?
PolymorphismePlusieurs parties de code peuvent “se cacher” derrière un appelde méthode polymorphe
2009 INSA -- Test de Logiciels 228
References
[1] Testing Object-oriented Systems, Models, Patterns, and Tools, Robert V. Binder, 2000, Addison-Wesley
[2] A Practical Guide to TestingObject-Oriented Software, John D. McGregor et David A. Sykes, 2001, Addison-Wesley
2009 INSA -- Test de Logiciels 229
Partie 1
Test de classe
2009 INSA -- Test de Logiciels 230
Principe du test de classe
Unité = la classe
Augmente la confiance que l’on a dans l’implémentation des unitésVérifie que l’implémentation d’une classe répond à saspécification
-> si l’implémentation de la classe est correcte, chaque instance de la classe devrait fonctionner correctement
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çageincorrect des unités qu’à une implémentation incorrecte de cetteclasse
2009 INSA -- Test de Logiciels 231
Quelles classes tester ?
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
classesEffort à 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
2009 INSA -- Test de Logiciels 232
Quand 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 INSA -- Test de Logiciels 233
Comment tester ?
Construction d’un script de test qui exécute les cas de test pour une classe et collecte les résultats des exécutions
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, étatde l’instance, modification des paramètres d’entrée, valeurdes attributs statiques de la classe ;
Si langage avec gestion mémoire, détruit les instances créées. 2009 INSA -- Test de Logiciels 234
Comment choisir des cas de test pertinents ?
Le développeur est susceptible de faire des erreursd’interprétation de la spécificationN’utiliser que le code pour identifier les cas de test risque de propager ces erreurs
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 nousrestreignons au test de classes dites primitives, c’est à dire indépendantes des autres classes.
2009 INSA -- Test de Logiciels 235
Utilisation des pre- et postconditions
Objectif : définir des cas de test pour une méthode à partir de sespre- et postconditions
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 postconditionpeut être atteinte ;créer des cas de test pour couvrir ces situations avec des valeursspécifiques, incluant des valeurs typiques et des valeurs aux limites ;dans le cas d’une programmation de type défensive, prévoir aussides cas où les préconditions ne sont pas respectées
2009 INSA -- Test de Logiciels 236
Utilisation des preconditions
(pre1,Post)(pre2,Post)(pre1 and pre2, Post)(not pre1 and not pre2, Exception) ●
pre1 or pre2
(pre1 and pre2,Post)(not pre1 and pre2, Exception) ●(pre1 and not pre2, Exception) ●(not pre1 and not pre2, Exception) ●
pre1 and pre2
(not pre1,Post)(pre1,Exception) ●
not pre1
(pre1,Post)(not pre1,Exception)●
pre1(true,Post)true
ContributionPrecondition en OCL
● Dans le cas d’une programmation défensive
2009 INSA -- Test de Logiciels 237
Utilisation des preconditions (suite)
(not pre1,Post)(pre2,Post)(not pre1 and pre2, Post)(pre1 and not pre2, Exception) ●
pre1 implies pre2
(pre1 and pre2,Post)(not pre1 and pre3,Post)(pre1 and not pre2, Exception) ●(not pre1 and not pre3, Exception) ●
If pre1 then pre2else pre3 endif
(pre1 and not pre2, Post)(not pre1 and pre2, Post)(pre1 and pre2, Exception) ●(not pre1 and not pre2, Exception) ●
pre1 xor pre2ContributionPrecondition en OCL
● Dans le cas d’une programmation défensive2009 INSA -- Test de Logiciels 238
Utilisation des postconditions
(Pre, post1 and not post2)(Pre, not post1 and post2)
post1 xor post2
(Pre, not post1 or post2)post1 implies post2
(Pre, post1)(Pre, post2)(Pre, post1 and post2)
post1 or post2
(Pre and ◘, post2)(Pre and not ◘, post3)
avec ◘ une condition qui rend post1 vraieau moment où s’applique la postcondition
If post1 then post2 else post3 endif
(Pre, post1 and post2)post1 and post2(Pre,post1)post1
ContributionPostconditions en OCL
2009 INSA -- Test de Logiciels 239
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() : intgetSpeedX(): intgetSpeedY(): intgetDirection() : int
setSpeed(speed : int);setDirection(dir : int);reverse();reverseY();reverseX();
Velocityspeed : intdirection : int
Velocity::setDirection(dir:int)pre : 0<=dir and dir<360post : direction=dir and speed=speed@pre
Velocity::reverseX()pre : truepost : speed = speed@pre and direction =
if direction@pre<=180 then (180 – direction@pre)else (540-direction@pre)
XθExemple extrait de [2]
2009 INSA -- Test de Logiciels 240
Critères de test basés sur le flot de contrôle
Critères pour le test de programmes impératifs sontapplicables
Couverture de toutes les instructionsCouverture de toutes les branchesEtc.
Mais, des critères spécifiques et mieux adaptés peuvent être définis
2009 INSA -- Test de Logiciels 241
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 mSoient :
vv : variable d’instance iijj : instruction de la méthode mjqui définit viikk : instruction de la méthode mkqui utilise v
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
mj{…ij…
}
mk{…ik…
}
c
A E
2009 INSA -- Test de Logiciels 242
Partie 2
Test d’intégration
2009 INSA -- Test de Logiciels 243
Notion de bouchon de test
Bout de code sans fonctionnalité qui vise à remplacer un code fonctionnel
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));…}
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 INSA -- Test de Logiciels 244
Analyse de dépendances
Exemples de dépendances entre classes :Invocation de méthode de B dans AObjets B utilisés en tant que paramètres de méthodes de AHéritage (cf partie 3)
Créer un graphe de dépendances
2009 INSA -- Test de Logiciels 245
Analyse de dépendances: diagramme de classes
FinancialService Transaction
Account
Rates
Money
AcctNum
Uses
Has Unique ►
Has ►
Applied to ▲
In Effect for ▲Posted for ▼
UsesProvided as ►
0..*
0..*
0..*
1..1
2..*
Extrait de [1]2009 INSA -- Test de Logiciels 246
Analyse de dépendances: graphe de dépendances
FinancialService
Transaction Account
Rates Money AcctNum
Array[Int]utilise
2009 INSA -- Test de Logiciels 247
Intégration Bottom-Up
Méthode d’intégration recommandée pour les programmes objetsL’intégration débute par les composants qui sont les plus indépendants
Script de test
bouchon
composant sous test
interface sous test
composant testé
Interface testée
2009 INSA -- Test de Logiciels 248
Intégration Bottom-Up
Script de test
bouchon
composant sous test
interface sous test
composant testé
Interface testée
2009 INSA -- Test de Logiciels 249
Intégration Bottom-Up
Script de test
bouchon
composant sous test
interface sous test
composant testé
Interface testée
2009 INSA -- Test de Logiciels 250
Script de test
bouchon
composant sous test
interface sous test
composant testé
Interface testée
Intégration Bottom-Up
2009 INSA -- Test de Logiciels 251
Script de test
bouchon
composant sous test
interface sous test
composant testé
Interface testée
Intégration Bottom-Up
2009 INSA -- Test de Logiciels 252
Script de test
bouchon
composant sous test
interface sous test
composant testé
Interface testée
Intégration Bottom-Up
2009 INSA -- Test de Logiciels 253
Avantages :Possibilité de débuter l’intégration dès qu’un composant de niveau feuille dans le graphe de dépendance est prêtPas d’écriture de bouchons
Inconvénients :Beaucoup de scripts de test à écrireSi un composant proche des feuilles dans le graphe estmodifié, certains tests de composants qui en dépendentdoivent être ré-exécutésLe composant principal du système est souvent à la racinedu graphe. Il est testé en dernier et risque de ne pas êtreassez testé si le temps manque.
Intégration Bottom-Up
2009 INSA -- Test de Logiciels 254
Méthode d’intégration privilégiant le test des composants des niveaux les plus élevés de l’arbre de dépendance
Script de test
bouchon
composant sous test
interface sous test
composant testé
Interface testée
Intégration Top-down
2009 INSA -- Test de Logiciels 255
Script de test
bouchon
composant sous test
interface sous test
composant testé
Interface testée
Intégration Top-down
2009 INSA -- Test de Logiciels 256
Script de test
bouchon
composant sous test
interface sous test
composant testé
Interface testée
Intégration Top-down
2009 INSA -- Test de Logiciels 257
Script de test
bouchon
composant sous test
interface sous test
composant testé
Interface testée
Intégration Top-down
2009 INSA -- Test de Logiciels 258
Script de test
bouchon
composant sous test
interface sous test
composant testé
Interface testée
Intégration Top-down
2009 INSA -- Test de Logiciels 259
Script de test
bouchon
composant sous test
interface sous test
composant testé
Interface testée
Intégration Top-down
2009 INSA -- Test de Logiciels 260
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
Peu de scripts de test à écrire
Test de non régression systématique à chaque ajout de composant
Intégration Top-down
2009 INSA -- Test de Logiciels 261
Inconvénients :Beaucoup de bouchons à écrire
L’ajout d’une contrainte (ex : précondition) à un composantproche des feuilles peut rendre nécessaires des changementsdans 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 sonttestés que dans le contexte de l’application sous test.
Intégration Top-down
2009 INSA -- Test de Logiciels 262
Cas de dépendances cycliquesLe graphe de dépendance peut comporter des composantesfortement connexes
Possibilité 1 : intégration Big-BangPrincipe : tester toutes les classes ensemble. Les dépendancesne 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 aussisusceptibles les unes que les autres de l’avoir provoquée.
A
C
B
2009 INSA -- Test de Logiciels 263
Cas de dépendances cycliques
Possibilité 2 : utilisation de bouchons
Avantage : intégration progressive des composantsInconvénient : écriture de bouchons
A
C
B
A
C
B
C’
Bouchonnage minimal
A
C
B
C’A
Bouchon spécifique
C’B
2009 INSA -- Test de Logiciels 264
Partie 3
Test en présenced’héritage
2009 INSA -- Test de Logiciels 265
Utilisation de l’héritage pour le 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) )
⌧Invariant de D : le même ou plus fort que celui de C( inv(C) inv(D) )
2009 INSA -- Test de Logiciels 266
Héritage de cas de test
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
-> processus de test incrémental et hiérarchique. Les cas de test hérités et additionnels dépendent des modifications apportées dansD par rapport à C
2009 INSA -- Test de Logiciels 267
Quels cas de test ajouter pour la sous-classe ?
Dans la suite de cette partie, C désigne une classe et D unede ses sous-classes.
Ajout d’une opération dans l’interface de D et potentiellementdans son implémentation :
Ajout de cas de test basés sur sa spécificationSi l’opération est implémentée : ajout de cas de test baséssur l’implémentation et pour le test d’intégration
C
D
2009 INSA -- Test de Logiciels 268
Quels cas de test ajoutés pour la sous-classe ?
Modification dans D de la spécification d’une opération m déclaréedans C :
Ajout de cas de test basés sur la spécification de m dans DRé-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écificationRevoir 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 INSA -- Test de Logiciels 269
Quels cas de test ajouter 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 surl’implémentation doivent aussi être ajoutés
Remarque sur la ré-exécution de cas de test : en pratique, tousles cas de test hérités sont ré-exécutés. En effet, l’effortnécessaire à la sélection des cas de test à ne pas ré-exécuter estsupérieur à l’effort nécessaire pour les exécuter de nouveau
2009 INSA -- Test de Logiciels 270
Exercice: quels cas de test ajouter pour tester Rectangle, connaissant les tests de Polygone ?
Polygone(Point[])
getCoins() : Point[]translate(Vector);aire() : intaffiche_caractéristiques();
Polygonecoins : Point[]
Utilise aire()
Rectangle(Point[]);aire() : intestCarre() : bool
Rectangle
2009 INSA -- Test de Logiciels 271
Comment tester en présence de polymorphismepar liaison dynamique ?
2009 INSA -- Test de Logiciels 272
Rappel sur la liaison dynamique
type déclaré de a : A
type effectif de a : A
le type effectif de a dépend de la branche suivie dans le if-then-else
type effectif de a : B
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.
A- int a
+ <<constr>> A() : A+ m() : int
B- int b
+ <<constr>> B() : B+ m() : int
Code Java
int foo(int i){A a;
if (i<0){a=new A();
} else {a=new B();
}
if (a.m() < 7){…
}…
}
C- int c
+ <<constr>> C() : C+ m() : int
2009 INSA -- Test de Logiciels 273
Critère de test structurel et polymorphisme
Soient mj et mk des méthodes appelées par la méthode mSoient :
vv : variable d’instance iijj : instruction de la méthode mjqui définit viikk : instruction de la méthode mkqui utilise v
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
mj{…ij…
}
mk{…ik…
}
c
A ESi mj et/ou mk sont polymorphes, plusieurs codes peuvent “se cacher”derrière les appels de méthodes en fonction du type de l’objet sur lequelelles s’appliquent
Si mj et/ou mk sont polymorphes, il fautdéterminer ces triplets pour chaque corps de méthode potentiellement exécuté. 2009 INSA -- Test de Logiciels 274
Critère de test structurel et polymorphisme
Soit m polymorphe, appelée par o de type déclaré A:
A::m, B::m ou C::m peuvent être appeléesCependant, le type effectif de o ne peut être que A ou B, ainsi l’appel de C::m() ne peut être couvert !
Déterminer les types effectifs possible nécessite uneanalyse globale de l’application (coûteux et complexe)
A
- int a
+ m () : int
B
- int b
+ m () : int
C- int c
+ m () : int
-> la mesure fiable du critère de couverture est compromise(problème à rapprocher de la détermination des chemins executables)
2009 INSA -- Test de Logiciels 275
Comment tester les classes abstraites ?
2009 INSA -- Test de Logiciels 276
Problématique des classes abstraites
Classe abstraite = classe sans instance, à l’implémentationincomplète – Utile pour la généricité et la lisibilité
Problème pour le test : impossible à tester en tant quetelle puisque pas instanciable.
Pratique de vérification usuelle : revue du code uniquement !
Nécessité de tester les opérations de la classe abstraiteau travers des sous-classes
2009 INSA -- Test de Logiciels 277
Comment tester une classe abstraite ?
Approche 1 : définition d’une classe concrète uniquementpour pouvoir tester la classe abstraite
Dans la classe concrète, les méthodes abstraites de la classeabstraite sont implémentées -> bouchons
Abstract_C
Concrete_C
2009 INSA -- Test de Logiciels 278
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.
⌧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
abstract class Abstract_C{
abstract int g(int a);
int f(int a){int i = g(a);…
}}
2009 INSA -- Test de Logiciels 279
Comment tester une classe abstraite ?Problèmes posés par l’approche 1 :
⌧ Soient, Abstract_C et Abstract_D deux classes telles queAbstract_D hérite de Abstract_C ;
⌧ Concrete_C et Concrete_D les classes qui leur sontrespectivement associées à des fins de test.
L’héritage multiple est nécessairepour que Concrete_D hérite des bouchonscréés dans Concrete_C-> OK en C++, mais en Java l’héritage multiple de classen’est pas autorisé
Abstract_C
Abstract_D
Concrete_C
Concrete_D
2009 INSA -- Test de Logiciels 280
Comment tester une classe abstraite ?
Approche 2 : Tester la classe abstraite avec son premier descendant
Hypothèse sous-jacente: si D passe sans problème les cas de test alors Abstract_C les passe également sans problème
Abstract_C
D
2009 INSA -- Test de Logiciels 281
Comment tester une classe abstraite ?
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.
Abstract_C
D
int f()
int f()
2009 INSA -- Test de Logiciels 282
Comment tester une classe abstraite ?Approche 3 : Utiliser une compilation conditionnelle pour avoirdans un même fichier :
la classe abstraite sous test avec ses méthodes abstraitesUne version de la classe où chaque méthode abstraite est remplacée par une implémentation (bouchon)
Ex : #ifdefined(TEST) <bouchon>#endif
Problème posé par l’approche 3 : le code est peu lisible
2009 INSA -- Test de Logiciels 283
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
Difficultés particulières :
- Test en présence de polymorphisme (liaison dynamique)
- Test de classes abstraites
2009 INSA -- Test de Logiciels 284
1. Techniques de test élémentaires
2. Test de logiciel orientés-objet
3. Model-Based Testing
Plan du cours d’aujourd’hui
2009 INSA -- Test de Logiciels 285
Processus de test à partir de modèles
Exigences
Modèle formelStateCharts,B,UML,…
Cas de test générés
Implémentation
Modélisation
ValidationScripts de testsexécutables
Génération de scripts
Génération de Test Spécifications etdéveloppement
Model-Based Testing
Originalité du MBT : construire le modèle dans le but d’automatiser le test2009 INSA -- Test de Logiciels 286
Génération de tests à partir de modèles
Directives de génération (définition d’un scénario de tests) :Critères de couverture du modèleCritères de sélection sur le modèle
Ensemble de Cas de tests
• séquence de stimuli• résultats attendus
Modèle formel
Directives de génération
Générateurde tests
Model-Based Testing
2009 INSA -- Test de Logiciels 287
Reference
« Practical Model-based Testing »M. Utting, B. Legeard, 2008
2009 INSA -- Test de Logiciels 288
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 INSA -- Test de Logiciels 289
Modéliser pour tester (1)
Modèle abstraitmodèle fonctionnel (et non modèle d’architecture et/ou d’implémentation)
Modèle détaillé et précisLe 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 ?
Modéliser pour tester
2009 INSA -- Test de Logiciels 290
Modéliser pour tester (2)
Modèle adapté aux objectifs de testPlus 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’observationdu système sous test
Modéliser pour tester
Modèle fonctionnel Banc de test
Générationdes tests
Générationdes scripts
2009 INSA -- Test de Logiciels 291
Critères de choix d’une notation / type d’application
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)
Modéliser pour tester
2009 INSA -- Test de Logiciels 292
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
Représentation : Graphique (plus « intuitive » ) ou textuelle (plus précise)
Modéliser pour tester
2009 INSA -- Test de Logiciels 293
Choix de notations
Méthode formelle
Diag. Etat
UnifiedModelingLanguage
Présentation
. Apprentissage. Sémantique claire. Précision
Notation B
. Faible sur les données
. Bien adapté -contrôleurs -systèmesEmbarqués
Statecharts
. Peu précise
. Pas de sémantique
. Grande diffusion. Variété de diagrammes
UML 2.0(Diag. Classe + OCL + Diag. État)
--++Notation
2009 INSA -- Test de Logiciels 294
Quelques outils…Systèmes de transitions :
IOLTS (STG – IRISA, TORX – Univ. Nijmegen)Statecharts (AGATHA – CEA)
Pré/post conditions – Machine abstraitesASML (Microsoft Research)B (LTG)UML/OCL (LTG, UML-Casting, …)
Systèmes hybrides (discret/continus)Simulink (Mathworks)
Langages synchronesLustre (GATEL – CEA)
Classification des techniques de génération
2009 INSA -- Test de Logiciels 295
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
La puce SIM est une carte à puces qui contient toutes les données utilisateurs et gére la protection de l’accès
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.
2009 INSA -- Test de Logiciels 296
Noyau de la norme GSM 11.11
Commandes :Verify_Chv(chv,code),Change_Chv(chv,code1,code2),
Disable_Chv(code),Enable_Chv(code),
Unblock_Chv(chv,code_unblock1, code_unblock2),Select_File(ff),Read_Binary,
Update_Binary(data),Reset,
Arborescence de fichiers
Modéliser pour tester
MF
DF_GSM ed_iccid
ed_lp ed_aded_imsi
2009 INSA -- Test de Logiciels 297
MACHINE GSM_11-11
SETSFILES = {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}
CONSTANTSFILES_CHILDREN, PERMISSION_READ, MAX_CHV, MAX_UNBLOCK, PUK
DEFINITIONSMF == {mf}; DF == {df_gsm}; EF == {ef_iccid,ef_lp,ef_imsi,ef_ad}; COUNTER_CHV == 0..MAX_CHV; COUNTER_UNBLOCK_CHV == 0..MAX_UNBLOCK
Modèle en B de la norme GSM 11-11 (fragment) – 1/4
2009 INSA -- Test de Logiciels 298
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
VARIABLES current_file, current_directory, counter_chv, counter_unblock_chv, blocked_chv_status, blocked_status, permission_session, pin, data
Modèle en B de la norme GSM 11-11 (fragment) – 2/4
2009 INSA -- Test de Logiciels 299
Modèle en B de la norme GSM 11-11 (fragment) – 3/4
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)}
2009 INSA -- Test de Logiciels 300
Modèle en B de la norme GSM 11-11 (fragment) – 4/4
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
ELSEcounter_chv := counter_chv - 1 || sw := 9804
ENDEND
END
END;
2009 INSA -- Test de Logiciels 301
Niveau Machine Abstraite(sans raffinement, mono-machine)
Permet une bonne prise en compte des données et des traitements
Bon niveau d’abstraction
Modélisation en B pour la génération de tests
sw CHANGE_Pin(old_code, new_code) =PREold_code ∈ Nat ∧ new_code ∈ NatTHEN
IF counter_pin = 0THENsw := 9840ELSE
IF code_pin = old_codeTHENcode_pin := new_code ||counter_pin := 3 ||permission_session := true ||sw := 9000ELSE IF counter_pin =1
THENcounter_pin := 0 ||permission_session := false ||sw := 9840ELSEcounter_pin := counter_pin – 1 ||sw := 9804
END END END END END ;2009 INSA -- Test de Logiciels 302
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 INSA -- Test de Logiciels 303
Processus Model-Based Testing – Schéma 1
Ingénieur modélisation
Analyse de besoinsDocumentation
Support dudéveloppement
Ingénieur validation
Adaptation
Générationdes tests
Cas de test
Modèle existant
2009 INSA -- Test de Logiciels 304
Processus Model-Based Testing – Schéma 2
Ingénieur validation
Modélisation
Générationdes tests
Cas de test
Spécificationsfonctionnelles
Pilotage
Développement
Modèle pour le testfonctionnel
2009 INSA -- Test de Logiciels 305
Génération automatique de tests fonctionnels
Automatiser les stratégies classiques :Analyse partitionnelle des données d’entréeTest aux limitesCouverture de critères de test défini sur le modèle
Ou bien sélection de comportements à tester en priorité
Objectif : Maîtriser la combinatoire des cas de test
2009 INSA -- Test de Logiciels 306
Composition d’un cas de testUn 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,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
Préambule Corps Identification Postambule
2009 INSA -- Test de Logiciels 307
Pilotage du banc de test et simulation de l’environnement
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.
Cas de testgénérés
Pattern de testgénérique
Table d’observabilité etd’exécutabilité
Génération des scriptsde tests exécutables
Script de tests exécutables
2009 INSA -- Test de Logiciels 308
Problématique de la traduction des tests générés en scripts exécutables
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
Verdict de test : Les tests générés comprennent le résultat attendusLe verdict est construit par comparaison entre le résultat attendu et le résultat obtenu pendant l’exécution du script de test
2009 INSA -- Test de Logiciels 309
Maîtriser la combinatoire : exemple de la validation terminal Carte Bancaire
2,64 Milliards de combinaisonsde données possibles
240
1570 comportements
3140 tests
Tests pour une configuration particulière
Tests pour toutes les configurationscartes possibles et les valeurs aux bornes
MagIC 500
Classes de comportements du système
Schlumberger device
2009 INSA -- Test de Logiciels 310
Analyse partitionnelle des domaines des données d’entrée
Sy stem
Ou tputs
Invalid in pu ts Valid in pu ts
Une classe d’équivalencecorrespond à un ensemble de données de tests qui activent le même comportement.
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.
2009 INSA -- Test de Logiciels 311
Test aux bornes des domaines des variables du modèle
Inférieur à 4 De 4 à 10 Supérieur à 10
34 10
11
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 INSA -- Test de Logiciels 312
Analyse partitionnelle - Exemple
Invariantx ∈ -1000 .. 1000
Preop
x ≤ 100Postop
IF x ≤ 0 THEN y := defaultELSE IF x ≤ 40
THEN y := lowELSE y:= high
END END
Classes de comportementsP1: x ≤ 0P2: x > 0 ∧ x ≤ 40P3: x > 40 ∧ x ≤ 100
Ensemble de tous les états du système qui permettent d’activer l’opération
P1
P2
P3
2009 INSA -- Test de Logiciels 313
P1
P2
P3
Calcul des données de test aux bornes
Prédicats après partitionnementP1: x ≤ 0P2: x > 0 ∧ x ≤ 40P3: x > 40 ∧ x ≤ 100
Tests aux bornesBG1 x = -1000BG2 x = 0BG3 x = 1BG4 x = 40BG5 x = 41BG6 x = 100
XBG1
BG2 X
X BG3
BG4 X
XBG5
X BG6
2009 INSA -- Test de Logiciels 314
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 INSA -- Test de Logiciels 315
Génération des tests à partir de critères
Critères de couverture du modèleObtenir le niveau de dépliage et de couverture souhaité à partir du modèle
Critères de sélectionFocaliser la génération sur certains comportements
Evolution du modèleSélectionner les tests par différentiel de comportements entre deux versions du modèle
Cas utilisateurAnimer le modèle pour définir des cas de test
2009 INSA -- Test de Logiciels 316
Critères de couverture
Critères de conditions multiples dans les décisionsToutes les décisionsToutes les conditionsToutes les décisions / conditions modifiées (MC/DC)Toutes les conditions/decisions multiples
…
SUR LE MODELE…
2009 INSA -- Test de Logiciels 317
Diagramme d’états du contrôleur de vitesse
Conditions multiples
2009 INSA -- Test de Logiciels 318
Critères de couverture
Critères de conditions multiples dans les décisionsToutes les décisionsToutes les conditions/décisionsToutes les décisions / conditions modifiées (MC/DC)Toutes les conditions/decisions multiples
Critères de couvertures des valeurs aux bornes équivalentes
Une valeurToutes les valeurs
2009 INSA -- Test de Logiciels 319
Diagramme d’états du contrôleur de vitesse
Valeurs aux limites
2009 INSA -- Test de Logiciels 320
Critères de couvertureCritères de conditions multiples dans les décisions
Toutes les décisionsToutes les conditions/décisionsToutes les décisions / conditions modifiées (MC/DC)Toutes les conditions/decisons multiples
Critères de couvertures des valeurs limites équivalentesUne valeurToutes les valeurs
Critères de couverture des transitionsToutes les transitionsToutes les paires de transitions
2009 INSA -- Test de Logiciels 321
Diagramme d’états du contrôleur de vitesse
Transition
2009 INSA -- Test de Logiciels 322
Critères de sélection
Focus sur le modèleSélection sur le choix des opérations / événements activablesSélection par choix sur les variables / valeurs du modèle
Evolution du modèle Test de tous les comportements ajoutés ou modifiésTest 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 INSA -- Test de Logiciels 323
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 INSA -- Test de Logiciels 324
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