Vous êtes sur la page 1sur 56

Introduction au test de logiciels

Delphine Longuet
delphine.longuet@lri.fr

Pourquoi vrier et valider ?


Pour viter les bugs

Sonde Mariner 1, 1962 : problme de spcication


http://fr.wikipedia.org/wiki/Mariner_1

Ariane V vol 501, 1996 : problme de conversion de nombres


Cot : 370 millions de dollars
http://fr.wikipedia.org/wiki/Vol_501_d'Ariane_5

Therac-25, 1985-87 : problme de synchronisation


Cot : plusieurs vies
http://fr.wikipedia.org/wiki/Therac-25

Panne d'lectricit aux tats-Unis et au Canada, 2003


Impact sur 55 millions d'habitants. Cot : 6 milliards de dollars
2

Pourquoi vrier et valider ?


Pour viter les bugs

Pour l'utilisateur : cot conomique, humain, environnemental

Pour le fournisseur : cot de la correction des bugs


en
en
en
en

phase
phase
phase
phase

d'implantation
d'intgration (bug de conception)
de recette (bug de spcication)
d'exploitation

cot
cot
cot
cot

1
10
100
> 1000
3

Pourquoi vrier et valider ?


Pour assurer la qualit

Capacit fonctionnelle : rponse aux besoins des utilisateurs


Facilit d'utilisation : prise en main et robustesse
Fiabilit : tolrance aux pannes
Performance : temps de rponse, dbit, uidit...
Maintenabilit : facilit corriger ou transformer le logiciel
Portabilit : aptitude fonctionner dans un environnement dirent
de celui prvu

Pourquoi des mthodes pour


vrier et valider ?
Pour rduire le cot

Vrication et validation :
environ 30% du dveloppement d'un logiciel standard
plus de 50% du dveloppement d'un logiciel critique
Phase de test souvent plus longue que les phases de spcication,
conception et implantation runies

Mthodes de vrication et validation


Vrication : assurer que le systme fonctionne correctement
Are we building the product right ?
Preuve formelle de proprits sur un modle du systme
model-checking, preuve
Validation : assurer que le systme fonctionne selon les attentes de
l'utilisateur
Are we building the right product ?
Assurance d'un certain niveau de conance dans le systme
test
6

Mthodes de vrication
Vrication :

Preuve

Le systme

vrie-t-il

insert(x : integer, l : list) : list


if l == []
then [x]
else if x <= hd(l)
then x::l
else hd(l)::insert(x,tl(l))

Model-checking

la proprit ?

Objectif : Prouver la correction du systme


7

Mthode de validation
Validation : Le systme est-il conforme au cahier des charges ?

Cahier des
charges

spcie
Systme
est conforme

Mthode de validation
Validation : Le systme est-il conforme au cahier des charges ?

Cahier des
charges

spcie
Systme
est conforme

Objectif : Dtecter les non conformits

Comparaison des mthodes de V&V


Test :
Ncessaire : excution du systme rel, dcouverte d'erreurs tous
les niveaux (spcication, conception, implantation)
Pas suisant : exhaustivit impossible
Preuve :
Exhaustif
Mise en uvre diicile, limitation de taille
Model-checking :
Exhaustif, partiellement automatique
Mise en uvre moyennement diicile (modles formels, logique)
10

Comparaison des mthodes de V&V


Mthodes complmentaires :

Test non exhaustif mais facile mettre en uvre

Preuve exhaustive mais trs technique

Model-checking exhaustif et moins technique que la preuve


Mais :

Preuve et model-checking limits par la taille du systme et


vrient des proprits sur un modle du systme (distance entre le
modle et le systme rel ?)

Test repose sur l'excution du systme rel, quelles que soient sa


taille et sa complexit
11

Dnitions du test
Norme IEEE (Standard Glossary of Software Engineering Terminology)
Le test est l'excution ou l'valuation d'un systme ou d'un
composant, par des moyens automatiques ou manuels, pour vrier
qu'il rpond ses spcications ou identier les dirences entre les
rsultats attendus et les rsultats obtenus.
Validation dynamique (excution du systme)
Comparaison entre systme et spcication

12

Dnitions du test
Tester peut rvler la prsence d'erreurs mais jamais leur absence
Vrication partielle : le test ne peut pas montrer la
conformit du systme (ncessit d'une innit de tests)

Tester, c'est excuter le programme dans l'intention d'y trouver des


anomalies ou des dfauts
Objectif : dtection des bugs

13

Bug ?
Anomalie (fonctionnement) : dirence entre comportement attendu
et comportement observ
Dfaut (interne) : lment ou absence d'lment dans le logiciel
entranant une anomalie
Erreur (programmation, conception) : comportement du programmeur
ou du concepteur conduisant un dfaut
erreur

dfaut

anomalie
14

Limites de la vrication
Indcidabilit : Un problme est indcidable s'il n'existe pas
d'algorithme capable de le rsoudre dans le cas gnral
Ex : Problmes indcidables

L'excution d'un programme termine

Deux programmes calculent la mme chose

Un programme est une implantation correcte de sa spcication


Il n'existe pas d'algorithme permettant de prouver la
correction de n'importe quel programme
15

Limites du test
Explosion combinatoire : Nombre d'excutions possibles d'un
programme potentiellement inni
Mais test = processus ni
Ncessit d'approcher l'inni (l'extrmement grand)
par le ni (heuristique)

16

volution du test
Aujourd'hui, le test de logiciels :

est la mthode la plus utilise pour assurer la qualit des logiciels

fait l'objet d'une pratique trop souvent artisanale


Demain, le test de logiciels devrait tre :

une activit rigoureuse

fonde sur des modles et des thories

de plus en plus automatique

17

chauement
Spcication : Le programme prend en entre trois entiers, interprts
comme tant les longueurs des cts d'un triangle. Le programme
retourne la proprit du triangle correspondant : scalne, isocle ou
quilatral.
Exercice : crire un ensemble de tests pour ce programme

18

chauement
Cas valides
triangle scalne valide
triangle isocle valide + permutations
triangle quilatral valide
triangle plat (a+b=c) + permutations
Cas invalides
pas un triangle (a+b<c) + permutations
une valeur 0
toutes les valeurs 0
une valeur ngative
une valeur non entire
mauvais nombre d'arguments
19

chauement
Cas valides

Donnes

Rsultat attendu

triangle scalne valide

(10,5,7)

scalne

triangle isocle valide + permutations

(3,5,5)

isocle

triangle quilatral valide

(3,3,3)

quilatral

triangle plat (a+b=c) + permutations

(2,2,4)

scalne

pas un triangle (a+b<c) + permutations

(2,1,5)

triangle invalide

une valeur 0

(3,0,4)

triangle invalide

toutes les valeurs 0

(0,0,0)

triangle invalide

une valeur ngative

(2,-1,6)

triangle invalide/entre invalide

une valeur non entire

('a',4,2)

entre invalide

(3,5)

entre invalide

Cas invalides

mauvais nombre d'arguments

20

chauement
16 cas correspondant aux dfauts constats dans des implantations de
cette spcication
Moyenne des rsultats obtenus par un ensemble de dveloppeurs
expriments : 55%
La construction de tests est une activit diicile,
encore plus sur de grandes applications

21

Vocabulaire du test
Objectif de test : comportement du systme tester
Donnes de test : donnes fournir en entre au systme de manire
dclencher un objectif de test
Rsultats d'un test : consquences ou sorties de l'excution d'un test
(aichage l'cran, modication des variables, envoi de messages...)
Cas de test : donnes d'entre et rsultats attendus
associs un objectif de test
_____________

Glossary of Testing Terms, ISTQB (International Software Testing Qualications Board)

22

Exemple : tri d'une liste d'entiers


Objectif de test

Donne d'entre Rsultat attendu Rsultat du test

liste vide

[]

[]

liste 1 lment

[3]

[3]

liste 2 lments,
dj trie

[2;6;9;13]

[2;6;9;13]

liste 2 lments,
non trie

[7;10;3;8;5]

[3;5;7;8;10]

23

Exemple : tri d'une liste d'entiers


Objectif de test

Donne d'entre Rsultat attendu Rsultat du test

liste vide

[]

[]

[...]

liste 1 lment

[3]

[3]

[...]

liste 2 lments,
dj trie

[2;6;9;13]

[2;6;9;13]

[...]

liste 2 lments,
non trie

[7;10;3;8;5]

[3;5;7;8;10]

[...]

galit ?
24

Problme de l'oracle
Oracle : dcision de la russite de l'excution d'un test, comparaison
entre le rsultat attendu et le rsultat obtenu
Problme : dcision pouvant tre complexe

types de donnes sans prdicat d'galit

systme non dterminisme : sortie possible mais pas celle attendue

heuristique : approximation du rsultat optimal attendu

25

Problme de l'oracle
Ex : Trouver le minimum d'une liste d'entiers
Entre : [4; 2; 3; 6]
Sortie attendue : 2
Oracle : galit entre entiers OK
Ex : Calculer l'itinraire le plus rapide entre deux villes
Entre : Paris Lyon
Sortie attendue : ...A6...
Oracle : galit des chemins ? Non
Ex : Problme du sac dos (rsolu avec une heuristique)
Oracle : Rsultat raisonnablementloign du rsultat optimal ?? Non
26

Problme de l'oracle
Ex : Trouver le minimum d'une liste d'entiers
Entre : [4; 2; 3; 6]
Sortie attendue : 2
Oracle : galit entre entiers OK
Ex : Calculer l'itinraire le plus rapide entre deux villes
Entre : Paris Lyon
Sortie attendue : ...A6...
Oracle : Trajet de 4h17 (quel que soit l'itinraire choisi) OK
Ex : Problme du sac dos (rsolu avec une heuristique)
Oracle : Rsultat = rsultat optimal + 5% OK
27

Problme de l'oracle
Oracle : En gnral, rsultat attendu = ensemble de conditions si
plusieurs solutions possibles et numration impossible
Risques : chec d'un programme conforme si dnition trop stricte du
rsultat attendu
Faux positif (false-fail)
Voir l'exemple du calcul d'itinraire dans lequel on impose un chemin.

28

Faux-positifs et faux-ngatifs
Validit des tests : Les tests n'chouent que sur des programmes
incorrects
Faux positif (false-fail) : fait chouer un programme correct
Compltude des tests : Les tests ne russissent que sur des
programmes corrects
Faux ngatif (false-pass) : fait passer un programme incorrect
Validit indispensable, compltude impossible en pratique
Toujours s'assurer que les tests sont valides
29

Processus de test
1. Choisir les comportements tester (objectifs de test)
2. Choisir des donnes de test permettant de dclencher ces
comportements + dcrire le rsultat attendu pour ces donnes
3. Excuter les cas de test sur le systme + collecter les rsultats
4. Comparer les rsultats obtenus aux rsultats attendus pour tablir
un verdict
slection
Spcication,
code, ide...

gnration
Objectif
de test

excution
Cas de
test

Rsultats
attendus

oracle
Rsultats
des tests

Verdict

30

Excution d'un test


Scnario de test :

Prambule : Suite d'actions amenant le programme dans l'tat


ncessaire pour excuter le cas de test

Corps : Excution des fonctions du cas de test

Identication (facultatif) : Oprations d'observation rendant


l'oracle possible

Postambule : Suite d'actions permettant de revenir un tat initial

Prambule

Corps Identication

Postambule
31

Excution d'un test


Ex : Pop (supprimer le sommet d'une pile)
Cas de test :

Excution du test :
Prambule

pop()

push(7)
push(2)
push(3)

3
2

Corps

pop()

Identication

top() = 2
pop()
top() = 7
pop()
top() = empty

32

Types de tests
Stratgie (cycle de vie)

Niveaux
Niveaux
de
de test
test

Mthodes
Mthodes de
de
slection
slection de
de tests
tests

Accessibilit

Caractristiques
Caractristiques
des
des tests
tests

Critre d'valuation (qualit du logiciel)


33

Types de tests
Stratgie (cycle de vie)

Bote noire

Bote blanche
Accessibilit

Critre d'valuation (qualit du logiciel)


34

Test bote noire


Slection des tests partir d'une spcication du systme (formelle ou
informelle), sans connaissance de l'implantation
Rsultats
attendus

Spcication
slection
Tests

oracle
excution

Systme

Verdict

Rsultats
des tests

Possibilit de construire les tests pendant la conception, avant le codage


35

Test bote noire


Ex : Distributeur de caf et th
caf = 20c, th = 50c
pice puis boisson
ne rend pas la monnaie
slection
on peut
acheter un
th avec 50c

insrer
50c

obtenir
un th

oracle
Systme

VERDICT ?

on obtient
un caf

36

Test bote noire


Ex : Distributeur de caf et th
?50c
!caf

?20c

?50c

!th

!caf

!th

fail

pass

slection

?50c

!th

?50c
excution

oracle
Systme

CHEC

!caf

37

Test bote blanche


Slection des tests partir de l'analyse du code source du systme

???
slection
oracle
Tests

excution

Systme

Verdict ?

Rsultats
des tests

Construction des tests uniquement pour du code dj crit


38

Test bote blanche

true
res := y

false
res := 0

analyse
du code

???

slection
x = 1, y = 0
excution

if x
then res := y
else res := 0
endif

oracle

Verdict ?

res = 0

39

Test bote blanche


x AND y
x

true
res := y

false
res := 0

analyse
du code

res = 0

slection
x = 1, y = 0
excution

if x
then res := y
else res := 0
endif

oracle

SUCCS

res = 0

40

Test bote blanche


x OR y
x

true
res := y

false
res := 0

analyse
du code

res = 1

slection
x = 1, y = 0
excution

if x
then res := y
else res := 0
endif

oracle

CHEC

res = 0

41

Test bote blanche


Slection des tests partir de l'analyse du code source du systme

Rsultats
attendus

Spcication
slection

oracle
Tests

excution

Systme

Verdict

Rsultats
des tests

Construction des tests uniquement pour du code dj crit


42

Bote noire vs. bote blanche


Complmentarit : dtection de fautes direntes

Bote noire : dtecte les oublis ou les erreurs par rapport la


spcication

Bote blanche : dtecte les erreurs de programmation


Ex : Addition d'entiers modulo 100 000
Function sum(x,y :
if (x = 600 and
then sum := x else sum := x +

integer) : integer
y = 500)
y
y

Bote noire : dtecte l'erreur par rapport la spcication


Bote blanche : dtecte l'erreur pour les valeurs (600,500)
43

Types de tests
Stratgie (cycle de vie)
Systme
Intgration
Unitaire

Bote noire

Bote blanche
Accessibilit

Critre d'valuation (qualit du logiciel)


44

Cycle de vie du logiciel


Spcication

Tests systme

Conception
gnrale

Tests d'intgration

Conception
dtaille

Tests unitaires

Ralisation

45

Test unitaire
Test des units de programme de faon isole, indpendamment les
unes des autres, c'est--dire sans appel une fonction d'un autre
module, une base de donnes...
mthodes, classes, modules, composants
Ex : GPS

Algorithme de calcul d'itinraire sur des exemples de graphes


construits la main

46

Test d'intgration
Test de la composition des modules via leur interface
communications entre modules, appels de procdures...
Ex : GPS

Lecture des donnes depuis la base de donnes

Communications avec l'IHM

47

Test systme
Test de la conformit du produit ni par rapport au cahier des charges,
eectu en bote noire au travers de son interface
Ex : GPS

Utilisation du logiciel sur des scnarios ralistes et complets

48

Types de tests
Stratgie (cycle de vie)
Systme
Intgration
Unitaire

Bote noire
Conformit

Bote blanche
Accessibilit

Robustesse
Performance
Scurit
Critre d'valuation (qualit du logiciel)
49

Test de conformit
But : Assurer que le systme prsente les fonctionnalits attendues par
l'utilisateur
Mthode : Slection des tests partir de la spcication, de faon
contrler que toutes les fonctionnalits spcies sont implantes selon
leurs spcications
Ex : Service de paiement en ligne

Scnarios avec transaction accepte/refuse, couverture des


dirents cas et cas d'erreur prvus
50

Test de robustesse
But : Assurer que le systme supporte les utilisations imprvues
Mthode : Slection des tests en dehors des comportements spcis
(entres hors domaine, utilisation incorrecte de l'interface,
environnement dgrad...)
Ex : Service de paiement en ligne

Login dpassant la taille du buer

Coupure rseau pendant la transaction

51

Test de scurit
But : Assurer que le systme ne possde pas de vulnrabilits
permettant une attaque de l'extrieur
Mthode : Simulation d'attaques pour dcouvrir les faiblesses du
systme qui permettraient de porter atteinte son intgrit
Ex : Service de paiement en ligne

Essayer d'utiliser les donnes d'un autre utilisateur

Faire passer la transaction pour termine sans avoir pay

52

Test de robustesse/scurit

53

Test de performance
But : Assurer que le systme garde des temps de rponse satisfaisants
dirents niveaux de charge
Mthode : Simulation dirents niveaux de charge d'utilisateurs pour
mesurer les temps de rponse du systme, l'utilisation des ressources...
Ex : Service de paiement en ligne

Lancer plusieurs centaines puis milliers de transactions en mme


temps

54

Un type de test transversal


Stratgie (cycle de vie)
Systme
Intgration
Unitaire

Bote noire
Test
Test de
de
non
non rgression
rgression
Conformit

Bote blanche
Accessibilit

Robustesse
Performance
Scurit
Critre d'valuation (qualit du logiciel)
55

Test de non rgression


But : Assurer que les corrections et les volutions du code n'ont pas
introduit de nouveaux dfauts
Mthode : chaque ajout ou modication de fonctionnalit, rejouer
les tests pour cette fonctionnalit, puis pour celles qui en dpendent,
puis les tests des niveaux suprieurs
Lourd mais indispensable
Automatisable en grande partie

56