Chapitre 5 : Test du logiciel

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

11

TERMINOLOGIE

Cas de test :

Jeu d'essai :

chemin fonctionnel à mettre en œuvre pour

atteindre un objectif de test. Un cas de test se

défini par le jeu d'essai à mettre en œuvre, le

scénario de test à exécuter et les résultats

attendus.

données en entrée d'un cas de test : valeurs à

saisir, données réelles (base existante ou de test),

génération automatique (aléatoire ou à partir de

spécifications). Le même jeu d'essai peut servir à

plusieurs cas de test.

«

G

L

-

A

C

O

O

»

E

N

S

I

C

o

u

r

s

Scénario de

test :

procédure à suivre par le testeur pour exécuter le

cas de test : manipulations à effectuer, dialogue

homme/machine... Le même scénario peut être

utilisé dans plusieurs cas de test.

12

TERMINOLOGIE

 « Un cas de test est un ensemble d'entrées de test, de

conditions d'exécution et de résultats attendus pour

un objectif particulier telle que la conformité du

programme avec une spécification donnée »

 Structure type d’un cas de test

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

13

APPROCHES DE TEST

 Deux approches complémentaires :

Tests

dynamiques

Tests

statiques

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

15

APPROCHES DE TEST

 Test dynamique : Exécuter un programme à l’aide d’un jeu de

tests. Les erreurs sont détectées en comparant les résultats

obtenus par l’exécution et ceux attendus

 Coût du test dynamique : 30 % à 60 % du coût de développement

total

Entrée

Programme

Sortie

 Test statique : Analyser les propriétés de l’application sans

exécution du code

 Selon des études, on peut détecter jusqu'à 60% des erreurs d'un

programme par cette technique.

Programme

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

16

LE TEST STATIQUE

1. Techniques formelles (Génie Logiciel 2)

• Preuve de théorèmes

• Model Cheking

2. Techniques informelles: Les éléments à examiner peuvent

être inspirés des erreurs de programmation les plus

communes

• toutes les variables du programmes sont -elles initialisées avant d'être

utilisées ?

• pour chaque instruction conditionnelle, la condition est -elle correcte ?

• est-ce que chaque boucle termine ?

• lorsque l'on traite des tableaux, la borne inférieur est -elle 0, 1 ou autre

valeur ?

• si on utilise un stockage dynamique, a -t-on alloué l'espace correctement

• si on modifie une structure chaînée, rétablit -on bien tous les liens ?

• les instructions composées sont-elles correctement parenthèsées ?

• etc.

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

17

LE TEST DYNAMIQUE

 C’est la détection des erreurs à l ’exécution dans l’intention

d’y trouver des anomalies ou des défauts

 Validation fonctionnelle (Test de conformité aux spécifications)

 Test de qualité (performance, sécurité, etc.)

Données (IN)

Résultats

attendus

Résultats

trouvés

Conformités



 Deux méthodes:

méthodes fonctionnelles (boîte noire)

méthodes structurelles (boîte blanche)

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

18

DIMENSIONS DU TEST

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

19

TYPES DE TEST

 Tests unitaires

 Test d'une fonction, une classe, un module (pendant le

développement)

 Permettent de vérifier le fonctionnement de chaque composant logiciel

modifié ou nouveau dans des cas de fonctionnement normal, aux

limites ou dégradé.

 Tests d'intégration

 Test de l'assemblage des modules (pendant le

développement)

 Permettent de vérifier progressivement que l'ensemble constitué par

les composants logiciels assemblés répond aux spécifications

fonctionnelles et techniques. Ils doivent, s'il y a lieu, activer les

interfaces avec les applications connexes.

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

20

TYPES DE TEST

 Tests de validation

 Chez le fournisseur, par l'équipe de qualification, puis

par le client

 Permettent de vérifier que les exigences fonctionnelles et

techniques du cahier des charges sont respectées. Ils s'effectuent

sans connaissance de la structure interne (tests "boîte noire").

 Tests de réception

 Permettent à un client de s'assurer que le cahier des

charges a été respecté.

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

 Tests de suivi d'exploitation

 Après installation

21

TYPES DE TEST

 Tests de non-régression

 Dans le cas de changement de version,

 permettent de vérifier que les modifications apportées n'ont pas

entraîné d'effets de bord non prévus qui pourraient dégrader le

comportement du logiciel antérieurement validé.

 portent sur l'exécution de tests déjà joués afin de s'assurer que le

système répond toujours aux exigences spécifiées.

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

22

NATURE DES TESTS

 Tests fonctionnels

 Réaction à certaines entrées (sorties produites)

 Tests de performance

 permettent de vérifier des contraintes de temps de réponse et

d'occupation mémoire.

 peuvent faire partie des tests de validation ou de non -régression.

 Tests de fiabilité

 résistance aux pannes

 Tests de sécurité, ...

☛ On est pas obligé de faire tous types de test : ça

dépend de la criticité du logiciel

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

23

VUES INTÉRIEURES ET

EXTÉRIEURES DES TESTS

 Deux techniques de tests

Les tests

boite noire

Les tests

boite

blanche

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

24

D I M E N S I O N S D U T E S T

S E L O N L E S I N F O R M AT I O N S

A C C É D É E S

 Test boîte noire [black box testing]

 évaluation de l'extérieur (sans regarder le code), uniquement en

fonction des entrées et des sorties sur le logiciel ou un de ses

composants

 Sélection des tests à partir d'une spécification du système sans

connaissance de l'implantation

 Possibilité de construire les tests avant le codage

 Test boîte blanche [white/glass box testing]

 Sélection des tests à partir de l'analyse du code source du

système

 Construction des tests uniquement pour du code déjà écrit

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

25

Les tests dans la pratique

Test

Unitaires

Portée

catégorie

Exécutant

Petites portions du code

source

Boite

blanche/Noire

Développeur

machine

Intégration

Classes/Composants

Blanche/Noire Développeur

Fonctionnel

Produit

Boite noire

Testeur

Système

Acceptation

Beta

Produit/Environnement

simulé

Produit/Environnement

réel

Produit/Environnement

réel

Boite noire

Testeur

Boite noire

Client

Boite noire

Client

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

Non-Régression

N’importe lequel

Blanche/

noire

N’importe

26

TEST BOÎTE NOIRE

Analyse partitionnelle (classes

d’équivalence)

Tests aux limites

27

TEST BOITE NOIRE(TBN)

 La génération des tests en boîte noire se base sur les

spécifications fonctionnelles d’un programme.

 Aucune connaissance de la structure interne du programme.

Catégories d'erreur:











fonctions incorrectes ou manquantes

erreurs d'interface

des erreurs dans les structures de données ou l'accès de base de

données externe

des erreurs de comportement ou de performance

erreurs d’initialisation et erreurs de terminaison.

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

28

TEST BOITE NOIRE(TBN)

MÉTHODES

Analyse partitionnelle (Equivalence

partitionning)

Analyse

valeurs

des

Boundary Value Analysis)*

limites(

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

29

TEST PAR CLASSE

D’ÉQUIVALENCE

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

30

TEST PAR CLASSE

D’ÉQUIVALENCE

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

31

T E S T PA R C L A S S E

D ’ É Q U I VA L E N C E

( PA R T I T I O N S D ’ É Q U I VA L E N C E )

 Cette méthode consiste à partitionner le domaine d ’entrée

en plusieurs classes.

 Les entrées d’un système sont divisées en groupes qui doivent

montrer un comportement similaire → elles auront un traitement

identique.

 Prendre en compte les données invalides comme les données valides

: toutes sont des entrées

 Un seul test est nécessaire pour chaque classe. Le

test se fait avec un seul représentant par classe.

 Idée : chaque représentant d'une classe a une même «probabilité» que

les autres de mettre en évidence une erreur

 Partition du domaine d'entrées (souvent infini) en un nombre

fini de classes d'équivalence → limite le nombre de tests

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

32

TEST PAR CLASSE

D’ÉQUIVALENCE

 Exemple 1: fonction qui attend un numéro de département

entre 1 et 95

 Exemple 2 : fonction qui attend une réponse oui/non

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

33

EXERCICE

 Supposons que nous

élaborions un compilateur pour

le

langage X. Un extrait des spécifications précise :

 «L’instruction FOR n’accepte qu’un seul paramètre en tant

que variable auxiliaire. Son nom ne doit pas dépasser deux

caractères non blancs; Après le signe = on doit préciser aussi

une borne supérieure et une borne inférieure. Les bornes sont

des entiers positifs et on place entre eux le mot-clé TO. »

 Déterminer les jeux de test à produire pour l’instruction FOR

en utilisant la technique de test par classe d’équivalence

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

34

CORRIGÉ

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

35

TEST AUX LIMITES

 L'expérience prouve que

☛ Les erreurs se situent très souvent aux frontières

 Par exemple :

 indice de tableau tout juste trop grand ou trop petit

 boucles avec une itération en trop ou en moins

 comparaisons stricte au lieu de avec égalité, ou l'inverse

 Plusieurs représentants par classe d'équivalence

☛ une valeur « médiane » ordinaire + une ou plusieurs valeurs aux

limites

 Aussi appelé « test aux bornes »

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

36

TEST AUX LIMITES

Exemples

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

37

MÉTHODE GÉNÉRALE

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

38

TEST AUX LIMITES

 Exemple : fonction qui attend une réponse oui/non

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

39

EXERCICE

Algorith m e : Recherche dichoto miqu e dans une table d ’entiers. R := Recherch e

(Tab, taille, v)

On supposera que la fonction recevra un tableau d ’entiers ordonné et une valeur

v entière. Préparer un jeu de test en prenant en considération les classes

d’équivalen ce et les tests aux limites.

Correction

 T a b l e v i d e T a b = n i l ; t a i l l e = 0 ; v = 1 7 / R = - 1

 T a b l e n e c o n t e n a n t q u ' u n e v a l e u r é g a l e à l a v a l e u r c h e r c h é e : T a b = 1 7 ; t a i l l e = 1 ; v = 1 7 / R = 1

 T a b l e n e c o n t e n a n t q u ' u n e v a l e u r d i f f é r e n t e d e l a v a l e u r c h e r c h é e : T a b = 1 7 ; t a i l l e = 1 ; v = 0 / R = - 1

 T a b l e d e t a i l l e p a i r e , l a p r e m i è r e v a l e u r = v a l e u r c h e r c h é e : T a b = 1 7 , 2 3 ; t a i l l e = 2 ; v = 1 7 / R = 1

 T a b l e d e t a i l l e p a i r e , l a d e r n i è r e v a l e u r = v a l e u r c h e r c h é e : T a b = 1 7 , 2 3 ; t a i l l e = 2 ; v = 2 3 / R = 2

 T a b l e d e t a i l l e p a i r e n e c o n t e n a n t p a s l a v a l e u r c h e r c h é e : T a b = 1 7 , 2 3 ; t a i l l e = 2 ; v = 3 / R = - 1

 T a b l e d e t a i l l e i m p a i r e , l a p r e m i è r e v a l e u r = v a l e u r c h e r c h é e : T a b = 1 7 , 2 3 , 2 9 ; t a i l l e = 3 ; v = 1 7 / R = 1

 T a b l e d e t a i l l e i m p a i r e , l a d e r n i è r e v a l e u r = v a l e u r c h e r c h é e : T a b = 1 7 , 2 3 , 2 9 ; t a i l l e = 3 ; v = 2 9 / R = 3

 T a b l e d e t a i l l e i m p a i r e n e c o n t e n a n t p a s l a v a l e u r c h e r c h é e : T a b = 1 7 , 2 3 , 2 9 ; t a i l l e = 3 ; v = 4 / R = - 1

 T a b l e d e t a i l l e q u e l c o n q u e c o n t e n a n t l a v a l e u r c h e r c h é e : T a b = 1 7 , 2 3 , 2 9 , 3 5 , 4 1 ; t a i l l e = 5 ; v = 2 3 / R = 2

R e m a r q u e : p a s e x h a u s t i f m a i s r a i s o n n a b l e .

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

40

TEST BOÎTE BLANCHE

Principe

Graphe de flots

Complexité Cyclomatique

41

PRINCIPE

Etude détaillée de la logique interne et la

structure du code.

Effectuer des tests boîte blanche

Posséder une connaissance du

fonctionnement interne du code.

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

42

E S T - I L P O S S I B L E D E FA I R E D E S

T E S T S E X H A U S T I F S ?

for(int i=0; i<20;i++)

{

for(int j=0; j<20;j++)

{

if(exp1){...}else{...}

if(exp2){...}else{...}

if(exp3){...}else{...}

if(exp4){...}else{...}

}

}

Il y a environ 10 ^ 14 chemins possibles qui peuvent être exécutées

dans ce programme !!!

Que FAIRE ????

43

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

CRITÈRES DE COUVERTURE

 Les Critères de Couverture :

 Le critère de couverture des instructions : le jeu d’essai doit

assurer que toute instruction élémentaire est exécutée au moins

une fois

 Le critère de couverture des arcs du graphe de contrôle

 Le critère de couverture des chemins du graphe de contrôle

 Le critère de couverture des conditions : le jeu de tests doit

couvrir à vrai et à faux toutes les conditions élémentaires de

toutes les conditionnelles

 En général, il est conseillé de mélanger différents critères.

 Ce type de test structurel ne peut être réutilisé tel quel en

cas de modification du code.

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

44

GRAPHE DE FLOT DE

CONTRÔLE

 Représentation du flot de contrôle

 Description de la structure du programme

 Dans le graphe de flot:

 Cercle : nœud

 Flèches : arêtes ou liens

 Nœud prédicat : un nœud contenant une

condition.

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

 Zone délimitée par les nœuds et les arêtes : région.

 En comptant les régions, il faut ajouter l’extérieur du

graphe comme une région !!

45

GRAPHE DE FLOT DE

CONTRÔLE

NOTATION

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

Tout arc doit se terminer vers un nœud !!

46

GRAPHE DE FLOT DE

CONTRÔLE

EXEMPLES

SIMPLES

1

2

1 : read(x);

2 : read(y);

6

4

5

8

3

7

10

11

3 : if( x<y) then

4 : x++;

5 : else y++ ;

6: traitement

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

9

7 : while (x<y)

8 : x++;

9: traitement

10 : Repeat

x++;

11: until ( x<y)

47

GRAPHE DE FLOT DE

CONTRÔLE

EXEMPLE

 Exemple de graphe de flux de contrôle pour un programme

avec des conditions composées

if (a || b) then

x

else

y

On associe plusieurs chemins à la condition complexe « a || b »

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

48

GRAPHE DE FLOT DE

CONTRÔLE

EXEMPLE



Organigramme

Graphe de flot (flux de contrôle)

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

49

CAS DE TEST DÉRIVÉS

DES CHEMINS DE BASE

 Garantir l’exécution de tous les énoncés du code

au moins une fois durant les tests.

 ÉTAPE 1: Dessiner le graphe de flot pour

représenter la structure de contrôle du code

approprié.

 ÉTAPE 2: Calculer la complexité cyclomatique.

 ÉTAPE 3: Déterminer les chemins indépendants.

 ÉTAPE 4: Préparer les cas de test pour forcer

l'exécution de chaque chemin du code.

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

50

CHEMINS INDÉPENDANTS

 Un chemins indépendant :

 Dans le programme, c’est tout chemin qui introduit au moins un

nouvel ensemble d’instructions ou une nouvelle condition:

 Pour le graphe de flot, un chemin indépendant doit passer au moins

par un arc qui n'a pas été traversée avant que ce chemin ne soit défini

 Chemins indépendants pour ce

graphe sont:

Chemin 1: 1-11

Chemin 2: 1-2-3-4-5-10-1-11

Chemin 3: 1-2-3-6-8-9-10-1-11

Chemin 4: 1-2-3-6-7-9-10-1-11

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

Mais

1-2-3-4-5-10-1-2-3-6-8-9-10-1-11

n’est pas un chemin indépendant

= c’est une combinaison des

chemins 1, 2 et 3, et n’introduit

aucun arc nouveau.

51

COMPLEXITÉ

CYCLOMATIQUE

 Métrique logicielle donnant une mesure

quantitative de la complexité logique.

 Nombre de chemins indépendants : la valeur

calculée pour la complexité cyclomatique

 Définition de la borne supérieure : le nombre de

tests à effectuer pour s'assurer de l’exécution de

toutes les instructions au moins une fois.

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

52

COMPLEXITÉ

CYCLOMATIQUE

3 Méthodes de calcul de la complexité

cyclomatique :

1. Le nombre de régions du graphe de flot.

2. V (G) = E-N + 2.

 N : le nombre de nœuds du graphe

 E : le nombre d'arêtes.

3. V (G) = P + 1

P : le nombre de nœuds « conditions »

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

53

Organigramme

V (G) = nombre de décisions + 1 = 3 + 1 = 4

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

V (G) = Le nombre de régions =4

V (G) = E-N + 2 = 11 - 9+2 = 4

V (G) = E-N + 2 = 13-11+2 = 4

54

COMPLEXITÉ

CYCLOMATIQUE

COMPLEXITÉ CYCLOMATIQUE :

1 . Région R=4

2 . Nbr de nœuds=8

Nbr d’ arêtes=10

V(G)= E-N+2

=10-8+2=4

3 . Nbr de nœuds prédicats =3

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

V(G)=p+1=3+1=4

CHEMINS INDÉPENDANTS :

path 1 : 1-2-4-7-8

path 2 : 1-2-3-5-7-8

path 3 : 1-2-3-6-7-8

path 4 : 1-2-4-7-2-4-7-8

55

Automatisation des tests

56

E X E M P L E DE S OU TIL S DE

L’A U TOMATISATION DU TE S T

 L’offre en outils d’aide au test de logiciels couvre tous les

types de test

 Plus de 278 outils référencés sur le site spécialisé

http://www.stickyminds.com/

 Exemples d’outils pour les tests unitaires:

 Junit pour JAVA

 Nunit pour .Net

 CppUnit pour C++

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

57

CONCLUSION

 Le test vise à mettre en évidence les erreurs d ’un logiciel

 Le test est une méthode de vérification partielle de logiciels=>

la qualité du test dépend de la pertinence du choix des données

de test

 Pour un logiciel critique, le coût du test peut représenter plus

de 40% du coût du développement

 La mise au point d’une méthode optimale de vérification de

programmes, passe par une combinaison judicieuse de

l’utilisation de différentes méthodes de tests statiques et

dynamiques (boîte noire et boîte blanche).

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

58

Chapitre 5: Test du logiciel

Principale référence

R . P r e s s m a n « S o f t w a r e E n g i n e e r i n g A P r a c t i t i o n e r ’s Ap p r o a c h » S e p t i è m e é d i t i o n , 2 0 1 0

( c h a p i t r e 1 8 )

C

o

u

r

s

«

G

L

-

A

C

O

O

»

E

N

S

I

59

FIN CHAPITRE 5

60