test logiciel, validation et...

2009 INSA -- Test de Logiciels 1

Test Logiciel, Validation et Vérification

INSA - Rennes 2009-2010

Arnaud GotliebIRISA / CELTIQUE

www.irisa.fr/lande/[email protected]


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


9/9/1945


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)


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 !


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


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 »


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) ?


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)


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]


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


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


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


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


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)


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…


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


Test natif / test croisé

Test natif : machine de test = machine de développement

Test croisé : machine de test ≠ machine de développement


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


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

…


Bibliographie : quelques livres


Bibliographie : quelques revues


Et quelques sites intéressants...

Software Testing Online Resources www.mtsu.edu/~storm/

Software Testing Stuff www.testdriven.com

Model-based Software Testingwww.geocities.com/model_based_testing/

Opensource ST www.opensourcetesting.org/unit_java.php

Tao Xie’s homepagewww.cs.washington.edu/homes/taoxie


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


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


0. Préliminaires








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


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.


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.


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


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.


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 :


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 ?


0. Préliminaires








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)


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)


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


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)


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


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)



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


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


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)


Exemples (2)


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


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)


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 :


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


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’


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


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


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


Représentations internes

Abstractions de la structure d’un programme

- Graphe de Flot de Contrôle [GFC]

- Graphe Def/Use [GDU]

[- Program Dependence Graph, ...]


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


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


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


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


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


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


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)


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


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


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


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



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 !


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=



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


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


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


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


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]


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


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}


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(4,6) : yc-use(5) : zdef(5) : z

c-use(6) : z

p-use(2,3) : w

p-use(4,5) : y


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


1

2

3

4

5

6

c-use(1) : ∅def(1) : x,y,w,z


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


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


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


1

2

3

4

5

6

c-use(1) : ∅def(1) : x,y,w,z


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


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(4,6) : y

c-use(5) : zdef(5) : z

c-use(6) : z

p-use(2,3) : w

p-use(4,5) : y


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


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


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


tous_les_chemins n’est pas fiable !


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)


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


TEST UNITAIRE AVEC CUNIT


Units of language

Functions in C

Task in ADA

Methods or classes in C++ and Java

Predicates in Prolog

…


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


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 !


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.


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


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 !


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


CU_basic_run_tests(); CU_cleanup_registry();



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…


JUnit for Java

http://www.irisa.fr/lande/gotlieb/resources/JUnit_Tutorial.mp4


0. Préliminaires








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


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


Rappels des notations

X1X2

X5

X4X3

Dom(P)


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




(ex : chemins de P)


if( C2)else ...} i

j

¬C1∧¬C2

¬C1∧ C2

C1∧¬C2

C1∧C2

Dom(P)


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)



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)


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)


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


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.


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 !


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]




Plan


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}


qN = 1 – (1 – pC)N pour N=2, 8, 16 cas de test

N = 2

N = 8N = 16


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


2ème étape : choisir qN et en déduire N

Si qN = 0.85

N = 8 convient


A1

A3

A4

A2

3ème étape : générer N DT selon PA1 = ..= PAk = 1/k


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 }


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) = ¼




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


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




Plan


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é ?


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


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


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


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 !


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


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


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



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



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


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


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



Plan


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.


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


return(z)


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


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


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 >


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é)


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


return(z)

X 2


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


return(z)

X 2


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 !


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


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


Evaluation symbolique globale : exemple

w != 0

z= z * xw= w-1

y<0

z=1.0 / z

a

b

c

d

e

f


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>


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


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?


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


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


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


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)


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


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


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


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)


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




Plan


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 ?


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


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


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)


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


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


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)


- 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


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


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é


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


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 ?


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


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


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 !


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


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


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;}


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)


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)


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)


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/


Récapitulatif des techniques pour le test structurel

Test statistique

Eval. symbolique

Méthodedynamique

Méthode àcontraintes


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


0. Préliminaires








Techniques élémentaires

- Test exhaustif- Test par échantillions- Test aléatoire

Génération automatique de données de test (1)


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)


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


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


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)




(ex : chemins de P)


if( C2)else ...} i

j

¬C1∧¬C2

¬C1∧ C2

C1∧¬C2

C1∧C2

Dom(P)


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)



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)


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]


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)


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


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 ?


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,


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


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


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


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


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


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


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


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

∧


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


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


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


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


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


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


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


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


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


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∧∧

∧

~

~ ∧


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

∧~

~

~


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


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


1. Techniques de test élémentaires

2. Test de logiciel orientés-objet

3. Model-Based Testing

Plan du cours d’aujourd’hui


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


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


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


Partie 1

Test de classe


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


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


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


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.


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


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


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


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]


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


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


Partie 2

Test d’intégration


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


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


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


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



Script de test

bouchon

composant sous test

interface sous test

composant testé

Interface testée



Script de test

bouchon

composant sous test

interface sous test

composant testé

Interface testée


Script de test

bouchon

composant sous test

interface sous test

composant testé

Interface testée



Script de test

bouchon

composant sous test

interface sous test

composant testé

Interface testée



Script de test

bouchon

composant sous test

interface sous test

composant testé

Interface testée



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.



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


Script de test

bouchon

composant sous test

interface sous test

composant testé

Interface testée



Script de test

bouchon

composant sous test

interface sous test

composant testé

Interface testée



Script de test

bouchon

composant sous test

interface sous test

composant testé

Interface testée



Script de test

bouchon

composant sous test

interface sous test

composant testé

Interface testée



Script de test

bouchon

composant sous test

interface sous test

composant testé

Interface testée



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



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.



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


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


Partie 3

Test en présenced’héritage


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


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


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


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


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


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


Comment tester en présence de polymorphismepar liaison dynamique ?


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


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)


Comment tester les classes abstraites ?


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


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



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

}}


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



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



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()


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


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


1. Techniques de test élémentaires

2. Test de logiciel orientés-objet

3. Model-Based Testing

Plan du cours d’aujourd’hui


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


Reference

« Practical Model-based Testing »M. Utting, B. Legeard, 2008


Modéliser pour tester

Stratégies de génération de test

Sélection des tests – Critères de couverture

Exemple d’outils : SIMULINK DESIGN VERIFIER


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 (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èle fonctionnel Banc de test

Générationdes tests

Générationdes scripts


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)



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)



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


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


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.


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


MF

DF_GSM ed_iccid

ed_lp ed_aded_imsi


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


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




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)}



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;


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






Processus Model-Based Testing – Schéma 1

Ingénieur modélisation

Analyse de besoinsDocumentation

Support dudéveloppement

Ingénieur validation

Adaptation


Cas de test

Modèle existant


Processus Model-Based Testing – Schéma 2

Ingénieur validation

Modélisation


Cas de test

Spécificationsfonctionnelles

Pilotage

Développement

Modèle pour le testfonctionnel


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


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


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


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


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


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.


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)


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


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







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


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…


Diagramme d’états du contrôleur de vitesse

Conditions multiples


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



Valeurs aux limites


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



Transition


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







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

test logiciel, validation et...

Documents