SlideShare une entreprise Scribd logo
1  sur  42
Test de Logiciels

Realisé par:
Bilel Abed

Encadrée par:
Mme Asma Sallemi
1
PLAN
1.

Introduction

2.

Types de tests

3.

Test statique

4.

Test dynamique

5.

Conclusion

2
Pourquoi vérifier et valider?
Pour éviter les bugs
coût de la correction des bugs

phase d'implantation

phase d'intégration (bug de
conception)
en phase de recette (bug de
spécification)

phase d'exploitation

3
Pourquoi vérifier et valider?
Pour assurer la qualité

Capacité fonctionnelle
Facilité d'utilisation

Fiabilité
Performance
Maintenabilité

Portabilité

• réponse aux besoins des utilisateurs
• prise en main et robustesse
• tolérance aux pannes

• temps de réponse, débit, fluidité...
• facilité à corriger ou transformer le logiciel
• aptitude à fonctionner dans un environnement différent
de celui prévu
4
Méthodes de vérification et validation
« Are we building the right product ? »

Vérification

Validation
assurer que le
système fonctionne
correctement

assurer que le
système fonctionne
selon les attentes de
l'utilisateur

Preuve formelle de
propriétés sur un
modèle du système

Assurance d'un
certain niveau de
confiance dans le
système

model-checking
Preuve

Test
5
Comparaison des méthodes de V&V
Test :
✔ Nécessaire : exécution du système réel, découverte d'erreurs à tous les niveaux

(spécification, conception, implantation)
✗ Pas suffisant : exhaustivité impossible
Preuve :
✔ Exhaustif
✗ Mise en oeuvre difficile, limitation de taille
Model-checking :
✔ Exhaustif, partiellement automatique
✗ Mise en oeuvre moyennement difficile (modèles formels, logique)

6
Comparaison des méthodes de V&V
Méthodes complémentaires :
 Test non exhaustif mais facile à mettre en oeuvre
 Preuve exhaustive mais très technique

Model-checking exhaustif et moins technique que la preuve
Mais :

Preuve et model-checking limités par la taille du système et vérifient des
propriétés sur un modèle du système (distance entre le modèle et le système réel ?)
Test repose sur l'exécution du système réel, quelles que soient sa taille et sa
complexité

7
Definitions
Tester un logiciel consiste à l’exécuter en ayant la totale maîtrise des données
qui lui sont fournies en entrée (jeux de test) tout en vérifiant que son
comportement est celui attendu
Le test est l’exécution ou l’évaluation d’un système ou d’un composant, par des
moyens automatiques ou manuels, pour vérifier qu’il répond à ses spécifications
ou identifier les différences entre les résultats attendus et les résultats obtenus.
(IEEE)
Tester c’est exécuter le programme dans l’intention d’y trouver des anomalies
ou des défauts. (G. Myers, The Art of Software Testing)
Le test est une technique de contrôle consistant à s’assurer, au moyen de son
exécution, que le comportement d’un programme est conforme à des données

8
Bug?
Anomalie (fonctionnement) : différence entre comportement attendu et
comportement observé
Défaut (interne) : élément ou absence d'élément dans le logiciel
entraînant une anomalie
Erreur (programmation, conception) : comportement du programmeur
ou du concepteur conduisant à un défaut

Anomalie

Défaut

Erreur

9
Processus de test
1.Choisir les comportements à tester (objectifs de test)
2. Choisir des données de test permettant de déclencher ces comportements &
décrire le résultat attendu pour ces données
3. Exécuter les cas de test sur le système + collecter les résultats
4. Comparer les résultats obtenus aux résultats attendus pour établir un verdict

sélection
• Spécifica
_tion,

génération
• Objectif
de test

exécution
• Cas de
test

oracle
• Résultats

.verdict

des tests

• Résultats
attendus
10
Types de tests
Stratégie (cycle de vie)
Système
Intégration
Unitaire
Boîte noire
Conformité

Boîte Blanche
Accessibilité

Robustesse
Performance

Sécurité
Critère d'évaluation
(qualité du logiciel)
11
Cycle de vie du logiciel
Cycle en V

12
Etapes et hiérarchisation des tests
Test fonctionnel - boîte noire
Indépendant de l’implémentation
Planifier à partir de la spécification fonctionnelle
Réutilisables
Test structurel - boîte blanche
Dépend de l implémentation
Les données de test sont produites à partir d’une analyse du code source

13
Test de conformité

But : Assurer
que le système
présente les
fonctionnalités
attendues par
l'utilisateur

Méthode : Sélection des
tests à partir de la
spécification, de façon à
contrôler que toutes les
fonctionnalités spécifiées
sont implantées selon
leurs spécifications

Exemple: Service de
paiement en ligne
Scénarios avec
transaction
acceptée/refusée,
couverture des
différents cas et cas
d'erreur prévus

14
Test de robustesse

But : Assurer
que le système
supporte les
utilisations
imprévues

Méthode : Sélection des
tests en dehors des
comportements spécifiés
(entrées hors domaine,
utilisation incorrecte de
l'interface,
environnement dégradé...)

Exemple: Service de
paiement en ligne
Login dépassant la
taille du buffer
 Coupure réseau
pendant la
transaction

15
Test de sécurité

But : Assurer que
le système ne
possède pas de
vulnérabilités
permettant une
attaque de
l'extérieur

Méthode : Simulation
d'attaques pour découvrir
les faiblesses du système
qui permettraient de
porter atteinte à son
intégrité

Exemple: Service de
paiement en ligne
Essayer d'utiliser
les données d'un
autre utilisateur
Faire passer la
transaction pour
terminée sans avoir
payé

16
Test de performance

But : Assurer que le
système garde des
temps de réponse
satisfaisants à
différents niveaux
de charge

Méthode : Simulation à
différents niveaux de
charge d'utilisateurs
pour mesurer les temps
de réponse du système,
l'utilisation des
ressources...

Exemple: Service
de paiement en
ligne
 Lancer plusieurs
centaines puis
milliers de
transactions en
même temps

17
Test de non régression
Un type de test transversal

But : Assurer que
les corrections et
les évolutions du
code n'ont pas
introduit de
nouveaux défauts

Méthode : À chaque
ajout ou modification de
fonctionnalité, rejouer
les tests pour cette
fonctionnalité, puis pour
celles qui en dépendent,
puis les tests des
niveaux supérieurs

Lourd mais
indispensable
Automatisable
en grande partie

18
Techniques de « test statique »
Définition : ne requiert pas l ’exécution du logiciel sous test sur des données
réelles
Efficacité : plus de 50 % de l ’ensemble des fautes d ’un projet sont détectées
lors des inspections si il y en a (en moyenne plus de 75%)

Défaut : mise en place lourde, nécessité de lien transversaux entre équipes,
risques de tension…tâche plutôt fastidieuse
Règles
être méthodique
un critère : le programme peut-il être repris par quelqu’un qui ne l’a pas fait(R1)
un second critère : les algorithmes/l’architecture de contrôle apparaît-elle
clairement ?(R2)
décortiquer chaque algorithme et noter toute redondance curieuse et toute
discontinuité
19
Test statique
Exemple: vérification de la clarté procédurale
R1 :Détermination des paramètres globaux
et de leur impact sur les fonctions propres
Program :recherche_rec;
const
max_elt = 50;
choix1 = 1;
choix2 = 2;
fin = 3;
type
Tliste = array[1..max_elt] of
integer;
var
liste : Tliste;
taille, choix, val : integer;
complex : integer;

But du
programme non
exprimé
Manque de
commentaires
Identificateurs
non explicites

20
Test statique
Exemple: vérification de la clarté
R2 : Existence d’un entête clair pour chaque fonction

{-------------------------------------------------------------------Recherche récursive d'une valeur dans une liste triée
--------------------------------------------------------------------}

{ paramètres d'entrée :
liste L
la valeur recherchée
indice gauche
indice droit
résultat : complexité de la recherche }

Interface Spécifiée

Interface implanté

function rech_rec(L : Tliste ; val, g, d : integer) : integer ;
21
Techniques de « test dynamique »
 DT : Donnée de Test = une (séquence) d’entrée(s)
JT = {DT}
 D = domaine d’entrée du programme P sous test

 Soient F, les fonctions spécifiées du logiciel
F : D -> Sorties
Le problème du test dynamique est :
F=P?
D -----> Sorties
DEUX REGLES :
Conserver les tests déjà écrits
Conserver les réponses correctes correspondantes
22
Test dynamique structurel
“Testing can prove the presence of bugs, but
never their absence” (Dijkstra)

Le test structurel: abstraire pour
obtenir un critère formel

C
Si C alors l1
Sinon l2

l1

l2

23
Test unitaire structurel
Graphe de Contrôle (langages procéduraux/actionnels)
 But : représenter tous les chemins d’exécution potentiels
 Graphe orienté : avec un noeud d’entrée E et un noeud de sortie S
(noeud fictif ajouté si plusieurs sorties)
Sommets :
blocs élémentaires du programme, ou prédicats des conditionnelles
/boucles, ou noeuds de jonction “vide” associé à un noeud prédicat
Bloc élémentaire : séquence maximale d’instructions séquentielles
Arcs :enchaînement d’exécution possibles entre deux sommets

24
Test unitaire structurel
Exemple : PGCD de 2 nombres
Précondition: p et q entiers
naturels positifs lus au clavier
Effet : result = pgcd(p, q)
En pseudo-langage
pgcd: integer is
local p,q : integer;
do
read(p, q) B1
while p<> q do P1
P2
if p > q
then p := p-q B2
else q:= q-p B3
end -- if
end -- while
result:=p B4
end-- pgcd

E
B1

P1
P=q

P<>q
P2
P>q

B4

B2

P<=q
B3

S
25
Test unitaire structurel
Chemins : suite d’arcs rencontrés dans le graphe, en partant de E et finissant en S.
en général représenté sans perte d’information par une liste de sommets

 Prédicat de chemin : conjonction des prédicats (ou de leur négation) rencontrés
le long du chemin.
Pas toujours calculable
E B1 P1 P2 B2 S : p1=q1 & p0 > q0 (pi = ième valeur de p)
E B1 P1 P2 B3 S : p1=q1 & p0 <= q0 (pi = ième valeur de p)
E B1 P1 (P2 B2)n S : pn=qn & (pi > qi i ∈ [0..n])
Chemins infaisables : problème en général indécidable

26
Test unitaire structurel
Sélection des tests fondés sur le flot de contrôle
Couverture des instructions : chaque bloc doit être exécuté au moins une fois
 Couverture des arcs ou enchaînements

 tous les chemins élémentaires ou 1-chemins

tous les i-chemins : de 0 à i passages dans les boucles
tous les chemins : si boucles, potentiellement infinis

27
Test unitaire structurel
E
B1

P1
P=q

P<>q
P2
P>q

B4

S

B2

P<=q
B3

Tous les noeuds:
(E, B1, P1, P2, B2, P1, B4, S)
(E, B1, P1, P2, B3, P1, B4, S)
Tous les arcs : idem
Tous les chemins élémentaires (1chemin) :
idem + (E, B1, P1, B4, S)
Tous les 2-chemins :
idem +
(E, B1, P1, P2, B2, P1, P2, B2, P1, B4, S)
(E, B1, P1, P2, B2, P1, P2, B3, P1, B4, S)
(E, B1, P1, P2, B3, P1, P2, B2, P1, B4, S)
(E, B1, P1, P2, B3, P1, P2, B3, P1, B4, S)

Questions : qu’est-ce que ne capture pas ce modèle ?
28
Test unitaire structurel

Couverture des
prédicats

Aspects données

if then imbriqués

Couverture des
dépendances
entre variables

Flot de données

Couverture des
domaines
d’entrée

Pertinence des
données

29
Test unitaire structurel
Graphe de Flot de Données
 But : représenter les dépendances entre les données du programme
dans le flot d’exécution.
 Graphe de contrôle décoré d’informations sur les données (variables)
du programme.
Sommets :idem GC
une définition (= affectation) d’une variable v est notée def(v)
une utilisation d’une variable est v notée P_use(v) dans un
prédicat et C_use(v) dans un calcul.

30
Test unitaire structurel
Exemple : PGCD de 2 nombres
Précondition: p et q entiers
naturels positifs lus au clavier
Effet : result = pgcd(p, q)
En pseudo-langage
pgcd: integer is
local p,q : integer;
do
P=q
read(p, q) B1 Def(p)
Def(q)
while p<> q do P1 Puse(p) Puse(q)
P2 Puse(p) Puse(q)
if p > q
Def(p)
Cuse(q) then p := p-q B2 Cuse(p)
Def(q)
Cuse(p) else q:= q-p B3 Cuse(q)
B4
end -- if
Cuse(p)
end -- while
result:=p B4 Cuse(p)
S
end-- pgcd

E
B1

P1

Def(p)

Puse(p)

P<>q
P2
P>q

Puse(p)

P<=q

B2

B3

Cuse(p)

Cuse(p)

31
Test d’intégration
But : vérifier les interactions entre composants (se base sur
l’architecture de conception
Difficultés principales de l’intégration
interfaces floues
implantation non conforme au modèle architectural (dépendances
entre composants non spécifiées)
réutilisation de composants (risque d’utilisation hors domaine)

32
Test d’intégration
Stratégies possibles (si architecture sans cycles)
big-bang : tout est testé ensemble. Peu recommandé !
top-down : de haut en bas. Peu courant. Ecriture uniquement de
drivers de tests.
bottom-up : la plus classique. On intègre depuis les feuilles.

33
Test d’intégration

D

Driver

S

Stub

T

D

Composant testé
Composant sous test

Interface sous test
Interface testé

34
Test d’intégration
Bottom-up

D

D

D

D

D

D
D
T

T

T

T

35
Test d’intégration
Bottom-up

36
Test d’intégration
Bottom-up

37
Test d’intégration
Top-down

38
Test d’intégration
Top-down

39
Test d’intégration
Top-down

40
Test d’intégration
Top-down

41
Conclusion
Facteurs de bonne testabilité :
Précision, complétude, traçabilité des documents
Architecture simple et modulaire
Politique de traitements des erreurs clairement définie
Facteurs de mauvaise testabilité :
Fortes contraintes d’efficacité (espace mémoire, temps)
Architecture mal définie
Difficultés du test :
Indécidabilité : une propriété indécidable est une propriété
qu’on ne pourra jamais prouver dans le cas général
Explosion combinatoire : Le test n’examine qu’un nombre
fini (ou très petit) d’exécutions
Impossibilité d’une automatisation complète satisfaisante

42

Contenu connexe

Tendances

Automatisation des tests - objectifs et concepts - partie 1
Automatisation des tests  - objectifs et concepts - partie 1Automatisation des tests  - objectifs et concepts - partie 1
Automatisation des tests - objectifs et concepts - partie 1Christophe Rochefolle
 
Mémoire - L'automatisation des tests fonctionnels - Emeline Simon
Mémoire - L'automatisation des tests fonctionnels - Emeline SimonMémoire - L'automatisation des tests fonctionnels - Emeline Simon
Mémoire - L'automatisation des tests fonctionnels - Emeline SimonEmeline Simon
 
Présentation Agile Testing
Présentation Agile TestingPrésentation Agile Testing
Présentation Agile Testingjubehr
 
Types de tests vs techniques de tests
Types de tests vs techniques de testsTypes de tests vs techniques de tests
Types de tests vs techniques de testsSabrine MASTOURA
 
Strategie de test à agile tour bordeaux
Strategie de test à agile tour bordeauxStrategie de test à agile tour bordeaux
Strategie de test à agile tour bordeauxNicolas Fédou
 
Guide tests fonctionnels
Guide tests fonctionnelsGuide tests fonctionnels
Guide tests fonctionnelscvcby
 
Qualification Et Cycle De Vie Du Logiciel
Qualification Et Cycle De Vie Du LogicielQualification Et Cycle De Vie Du Logiciel
Qualification Et Cycle De Vie Du Logicieldanaobrest
 
Exposée: Processus de test logiciel
Exposée:  Processus de test logiciel Exposée:  Processus de test logiciel
Exposée: Processus de test logiciel Esaie88
 
Méthodologie de tests et qualité
Méthodologie de tests et qualitéMéthodologie de tests et qualité
Méthodologie de tests et qualitéSpikeeLabs
 
Automatisation des tests - objectifs et concepts - partie 2
Automatisation des tests  - objectifs et concepts - partie 2Automatisation des tests  - objectifs et concepts - partie 2
Automatisation des tests - objectifs et concepts - partie 2Christophe Rochefolle
 
Test unitaire
Test unitaireTest unitaire
Test unitaireIsenDev
 
Méthode d'Agile: Scrum
Méthode d'Agile: ScrumMéthode d'Agile: Scrum
Méthode d'Agile: ScrumChaymaMghazli
 
Méthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesMéthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesSirine Barguaoui
 
Introduction à la validation de logiciel
Introduction à la validation de logicielIntroduction à la validation de logiciel
Introduction à la validation de logicielJean-Paul CARMONA
 
Introduction à la qualité logicielle (1/5)
Introduction à la qualité logicielle (1/5)Introduction à la qualité logicielle (1/5)
Introduction à la qualité logicielle (1/5)Sylvain Leroy
 
Introduction au génie logiciel
Introduction au génie logicielIntroduction au génie logiciel
Introduction au génie logicielMohamed Diallo
 

Tendances (20)

Automatisation des tests - objectifs et concepts - partie 1
Automatisation des tests  - objectifs et concepts - partie 1Automatisation des tests  - objectifs et concepts - partie 1
Automatisation des tests - objectifs et concepts - partie 1
 
Mémoire - L'automatisation des tests fonctionnels - Emeline Simon
Mémoire - L'automatisation des tests fonctionnels - Emeline SimonMémoire - L'automatisation des tests fonctionnels - Emeline Simon
Mémoire - L'automatisation des tests fonctionnels - Emeline Simon
 
Présentation Agile Testing
Présentation Agile TestingPrésentation Agile Testing
Présentation Agile Testing
 
Types de tests vs techniques de tests
Types de tests vs techniques de testsTypes de tests vs techniques de tests
Types de tests vs techniques de tests
 
Strategie de test à agile tour bordeaux
Strategie de test à agile tour bordeauxStrategie de test à agile tour bordeaux
Strategie de test à agile tour bordeaux
 
Guide tests fonctionnels
Guide tests fonctionnelsGuide tests fonctionnels
Guide tests fonctionnels
 
Qualification Et Cycle De Vie Du Logiciel
Qualification Et Cycle De Vie Du LogicielQualification Et Cycle De Vie Du Logiciel
Qualification Et Cycle De Vie Du Logiciel
 
Exposée: Processus de test logiciel
Exposée:  Processus de test logiciel Exposée:  Processus de test logiciel
Exposée: Processus de test logiciel
 
Méthodologie de tests et qualité
Méthodologie de tests et qualitéMéthodologie de tests et qualité
Méthodologie de tests et qualité
 
Automatisation des tests - objectifs et concepts - partie 2
Automatisation des tests  - objectifs et concepts - partie 2Automatisation des tests  - objectifs et concepts - partie 2
Automatisation des tests - objectifs et concepts - partie 2
 
Test unitaire
Test unitaireTest unitaire
Test unitaire
 
Méthode d'Agile: Scrum
Méthode d'Agile: ScrumMéthode d'Agile: Scrum
Méthode d'Agile: Scrum
 
Méthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesMéthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiques
 
Génie Logiciel : les tests
Génie Logiciel : les testsGénie Logiciel : les tests
Génie Logiciel : les tests
 
Introduction à la validation de logiciel
Introduction à la validation de logicielIntroduction à la validation de logiciel
Introduction à la validation de logiciel
 
Introduction à la qualité logicielle (1/5)
Introduction à la qualité logicielle (1/5)Introduction à la qualité logicielle (1/5)
Introduction à la qualité logicielle (1/5)
 
Qualité logiciel - Generalités
Qualité logiciel - GeneralitésQualité logiciel - Generalités
Qualité logiciel - Generalités
 
Test unitaires
Test unitairesTest unitaires
Test unitaires
 
Méthodes agiles & Scrum
Méthodes agiles & ScrumMéthodes agiles & Scrum
Méthodes agiles & Scrum
 
Introduction au génie logiciel
Introduction au génie logicielIntroduction au génie logiciel
Introduction au génie logiciel
 

En vedette

test newspaper
test newspapertest newspaper
test newspaperprcpam
 
[PFE] Master en ingénierie du logiciel
[PFE] Master en ingénierie du logiciel[PFE] Master en ingénierie du logiciel
[PFE] Master en ingénierie du logicielUSTHB & DELTALOG
 
Cours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vieCours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vieMohammed Amine Mostefai
 
Tests ihm automatises avec selenium
Tests ihm automatises avec seleniumTests ihm automatises avec selenium
Tests ihm automatises avec seleniumsojavawest
 
Outils de tests open-source
Outils de tests open-sourceOutils de tests open-source
Outils de tests open-sourceGilles Mantel
 
Tests unitaires pour PostgreSQL avec pgTap
Tests unitaires pour PostgreSQL avec pgTapTests unitaires pour PostgreSQL avec pgTap
Tests unitaires pour PostgreSQL avec pgTapRodolphe Quiédeville
 
Intranet Partenaire
Intranet PartenaireIntranet Partenaire
Intranet PartenaireRuralitour
 
Software testing by risk management
Software testing by risk managementSoftware testing by risk management
Software testing by risk managementKobi Vider
 
1a.ficheformationcertificationistqb2012presentation
1a.ficheformationcertificationistqb2012presentation1a.ficheformationcertificationistqb2012presentation
1a.ficheformationcertificationistqb2012presentationDALISYS
 
Eclipse Day Paris 2010 - ProxiAD - Cedric Vidal - 1.0
Eclipse Day Paris 2010 - ProxiAD - Cedric Vidal - 1.0Eclipse Day Paris 2010 - ProxiAD - Cedric Vidal - 1.0
Eclipse Day Paris 2010 - ProxiAD - Cedric Vidal - 1.0Cedric Vidal
 
Sogeti mdday2010
Sogeti mdday2010Sogeti mdday2010
Sogeti mdday2010MD DAY
 
assertYourself - Breaking the Theories and Assumptions of Unit Testing in Flex
assertYourself - Breaking the Theories and Assumptions of Unit Testing in FlexassertYourself - Breaking the Theories and Assumptions of Unit Testing in Flex
assertYourself - Breaking the Theories and Assumptions of Unit Testing in Flexmichael.labriola
 
Software product line testing in practice
Software product line testing in practiceSoftware product line testing in practice
Software product line testing in practiceJohan Hoberg
 

En vedette (16)

test newspaper
test newspapertest newspaper
test newspaper
 
[PFE] Master en ingénierie du logiciel
[PFE] Master en ingénierie du logiciel[PFE] Master en ingénierie du logiciel
[PFE] Master en ingénierie du logiciel
 
Cours Génie Logiciel - Introduction
Cours Génie Logiciel - IntroductionCours Génie Logiciel - Introduction
Cours Génie Logiciel - Introduction
 
Cours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vieCours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vie
 
Tests ihm automatises avec selenium
Tests ihm automatises avec seleniumTests ihm automatises avec selenium
Tests ihm automatises avec selenium
 
Outils de tests open-source
Outils de tests open-sourceOutils de tests open-source
Outils de tests open-source
 
Modèle cahier des charges site web
Modèle cahier des charges site webModèle cahier des charges site web
Modèle cahier des charges site web
 
Tests unitaires pour PostgreSQL avec pgTap
Tests unitaires pour PostgreSQL avec pgTapTests unitaires pour PostgreSQL avec pgTap
Tests unitaires pour PostgreSQL avec pgTap
 
Intranet Partenaire
Intranet PartenaireIntranet Partenaire
Intranet Partenaire
 
Software testing by risk management
Software testing by risk managementSoftware testing by risk management
Software testing by risk management
 
1a.ficheformationcertificationistqb2012presentation
1a.ficheformationcertificationistqb2012presentation1a.ficheformationcertificationistqb2012presentation
1a.ficheformationcertificationistqb2012presentation
 
Eclipse Day Paris 2010 - ProxiAD - Cedric Vidal - 1.0
Eclipse Day Paris 2010 - ProxiAD - Cedric Vidal - 1.0Eclipse Day Paris 2010 - ProxiAD - Cedric Vidal - 1.0
Eclipse Day Paris 2010 - ProxiAD - Cedric Vidal - 1.0
 
Sogeti mdday2010
Sogeti mdday2010Sogeti mdday2010
Sogeti mdday2010
 
assertYourself - Breaking the Theories and Assumptions of Unit Testing in Flex
assertYourself - Breaking the Theories and Assumptions of Unit Testing in FlexassertYourself - Breaking the Theories and Assumptions of Unit Testing in Flex
assertYourself - Breaking the Theories and Assumptions of Unit Testing in Flex
 
Les tests en PHP
Les tests en PHPLes tests en PHP
Les tests en PHP
 
Software product line testing in practice
Software product line testing in practiceSoftware product line testing in practice
Software product line testing in practice
 

Similaire à Test de logiciels

13-Cours de Géniel Logiciel
13-Cours de Géniel Logiciel13-Cours de Géniel Logiciel
13-Cours de Géniel Logiciellauraty3204
 
test_logiciel_rappel_Master1_Université_JKZ.pptx
test_logiciel_rappel_Master1_Université_JKZ.pptxtest_logiciel_rappel_Master1_Université_JKZ.pptx
test_logiciel_rappel_Master1_Université_JKZ.pptxEnochBidima3
 
Session #2 du workshop sur la performance en environnement de production
Session #2 du workshop sur la performance en environnement de productionSession #2 du workshop sur la performance en environnement de production
Session #2 du workshop sur la performance en environnement de productionDEFO KUATE Landry
 
12-Cours de Géniel Logiciel
12-Cours de Géniel Logiciel12-Cours de Géniel Logiciel
12-Cours de Géniel Logiciellauraty3204
 
Performance ug#1
Performance ug#1Performance ug#1
Performance ug#1Marc Bojoly
 
"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014
"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014
"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014Benoît de CHATEAUVIEUX
 
Test Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teamsTest Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teamsThierry Gayet
 
Industrialisation des développements logiciels
Industrialisation des développements logicielsIndustrialisation des développements logiciels
Industrialisation des développements logicielsSylvain Leroy
 
Développement en méthode agile
Développement en méthode agileDéveloppement en méthode agile
Développement en méthode agilelaurent bristiel
 
Audit technique de code
Audit technique de codeAudit technique de code
Audit technique de codeMehdi TAZI
 

Similaire à Test de logiciels (20)

13-Cours de Géniel Logiciel
13-Cours de Géniel Logiciel13-Cours de Géniel Logiciel
13-Cours de Géniel Logiciel
 
Cours1.pptx
Cours1.pptxCours1.pptx
Cours1.pptx
 
Et4 4 testinformel
Et4 4 testinformelEt4 4 testinformel
Et4 4 testinformel
 
Conformiq
ConformiqConformiq
Conformiq
 
test_logiciel_rappel_Master1_Université_JKZ.pptx
test_logiciel_rappel_Master1_Université_JKZ.pptxtest_logiciel_rappel_Master1_Université_JKZ.pptx
test_logiciel_rappel_Master1_Université_JKZ.pptx
 
chap6_GL.pptx
chap6_GL.pptxchap6_GL.pptx
chap6_GL.pptx
 
Session #2 du workshop sur la performance en environnement de production
Session #2 du workshop sur la performance en environnement de productionSession #2 du workshop sur la performance en environnement de production
Session #2 du workshop sur la performance en environnement de production
 
J Unit
J UnitJ Unit
J Unit
 
12-Cours de Géniel Logiciel
12-Cours de Géniel Logiciel12-Cours de Géniel Logiciel
12-Cours de Géniel Logiciel
 
PrésQL.pdf
PrésQL.pdfPrésQL.pdf
PrésQL.pdf
 
Performance ug#1
Performance ug#1Performance ug#1
Performance ug#1
 
"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014
"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014
"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014
 
Anatomie du test
Anatomie du testAnatomie du test
Anatomie du test
 
Bbl sur les tests
Bbl sur les testsBbl sur les tests
Bbl sur les tests
 
Chapitre 1 rappel
Chapitre 1 rappelChapitre 1 rappel
Chapitre 1 rappel
 
Chapitre 1 rappel
Chapitre 1 rappelChapitre 1 rappel
Chapitre 1 rappel
 
Test Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teamsTest Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teams
 
Industrialisation des développements logiciels
Industrialisation des développements logicielsIndustrialisation des développements logiciels
Industrialisation des développements logiciels
 
Développement en méthode agile
Développement en méthode agileDéveloppement en méthode agile
Développement en méthode agile
 
Audit technique de code
Audit technique de codeAudit technique de code
Audit technique de code
 

Dernier

Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdfBibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdfBibdoc 37
 
La Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdfLa Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdfbdp12
 
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdf
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdfBibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdf
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdfBibdoc 37
 
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24BenotGeorges3
 
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...Bibdoc 37
 
Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)Gabriel Gay-Para
 
PIE-A2-P 5- Supports stagiaires.pptx.pdf
PIE-A2-P 5- Supports stagiaires.pptx.pdfPIE-A2-P 5- Supports stagiaires.pptx.pdf
PIE-A2-P 5- Supports stagiaires.pptx.pdfRiDaHAziz
 
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdfVulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdfSylvianeBachy
 
Apprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceursApprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceursStagiaireLearningmat
 
Bernard Réquichot.pptx Peintre français
Bernard Réquichot.pptx   Peintre françaisBernard Réquichot.pptx   Peintre français
Bernard Réquichot.pptx Peintre françaisTxaruka
 
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptxPrésentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptxJCAC
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx      Film   françaisPas de vagues.  pptx      Film   français
Pas de vagues. pptx Film françaisTxaruka
 
Chana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienneChana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienneTxaruka
 
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdfBibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdfBibdoc 37
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx   Film     françaisPas de vagues.  pptx   Film     français
Pas de vagues. pptx Film françaisTxaruka
 
PIE-A2-P4-support stagiaires sept 22-validé.pdf
PIE-A2-P4-support stagiaires sept 22-validé.pdfPIE-A2-P4-support stagiaires sept 22-validé.pdf
PIE-A2-P4-support stagiaires sept 22-validé.pdfRiDaHAziz
 
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptxDIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptxMartin M Flynn
 

Dernier (18)

Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdfBibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
 
La Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdfLa Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdf
 
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdf
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdfBibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdf
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdf
 
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
 
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
 
Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)
 
PIE-A2-P 5- Supports stagiaires.pptx.pdf
PIE-A2-P 5- Supports stagiaires.pptx.pdfPIE-A2-P 5- Supports stagiaires.pptx.pdf
PIE-A2-P 5- Supports stagiaires.pptx.pdf
 
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdfVulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
 
Apprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceursApprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceurs
 
Bernard Réquichot.pptx Peintre français
Bernard Réquichot.pptx   Peintre françaisBernard Réquichot.pptx   Peintre français
Bernard Réquichot.pptx Peintre français
 
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptxPrésentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx      Film   françaisPas de vagues.  pptx      Film   français
Pas de vagues. pptx Film français
 
Bulletin des bibliotheques Burkina Faso mars 2024
Bulletin des bibliotheques Burkina Faso mars 2024Bulletin des bibliotheques Burkina Faso mars 2024
Bulletin des bibliotheques Burkina Faso mars 2024
 
Chana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienneChana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienne
 
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdfBibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx   Film     françaisPas de vagues.  pptx   Film     français
Pas de vagues. pptx Film français
 
PIE-A2-P4-support stagiaires sept 22-validé.pdf
PIE-A2-P4-support stagiaires sept 22-validé.pdfPIE-A2-P4-support stagiaires sept 22-validé.pdf
PIE-A2-P4-support stagiaires sept 22-validé.pdf
 
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptxDIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
 

Test de logiciels

  • 1. Test de Logiciels Realisé par: Bilel Abed Encadrée par: Mme Asma Sallemi 1
  • 2. PLAN 1. Introduction 2. Types de tests 3. Test statique 4. Test dynamique 5. Conclusion 2
  • 3. Pourquoi vérifier et valider? Pour éviter les bugs coût de la correction des bugs phase d'implantation phase d'intégration (bug de conception) en phase de recette (bug de spécification) phase d'exploitation 3
  • 4. Pourquoi vérifier et valider? Pour assurer la qualité Capacité fonctionnelle Facilité d'utilisation Fiabilité Performance Maintenabilité Portabilité • réponse aux besoins des utilisateurs • prise en main et robustesse • tolérance aux pannes • temps de réponse, débit, fluidité... • facilité à corriger ou transformer le logiciel • aptitude à fonctionner dans un environnement différent de celui prévu 4
  • 5. Méthodes de vérification et validation « Are we building the right product ? » Vérification Validation assurer que le système fonctionne correctement assurer que le système fonctionne selon les attentes de l'utilisateur Preuve formelle de propriétés sur un modèle du système Assurance d'un certain niveau de confiance dans le système model-checking Preuve Test 5
  • 6. Comparaison des méthodes de V&V Test : ✔ Nécessaire : exécution du système réel, découverte d'erreurs à tous les niveaux (spécification, conception, implantation) ✗ Pas suffisant : exhaustivité impossible Preuve : ✔ Exhaustif ✗ Mise en oeuvre difficile, limitation de taille Model-checking : ✔ Exhaustif, partiellement automatique ✗ Mise en oeuvre moyennement difficile (modèles formels, logique) 6
  • 7. Comparaison des méthodes de V&V Méthodes complémentaires :  Test non exhaustif mais facile à mettre en oeuvre  Preuve exhaustive mais très technique Model-checking exhaustif et moins technique que la preuve Mais : Preuve et model-checking limités par la taille du système et vérifient des propriétés sur un modèle du système (distance entre le modèle et le système réel ?) Test repose sur l'exécution du système réel, quelles que soient sa taille et sa complexité 7
  • 8. Definitions Tester un logiciel consiste à l’exécuter en ayant la totale maîtrise des données qui lui sont fournies en entrée (jeux de test) tout en vérifiant que son comportement est celui attendu Le test est l’exécution ou l’évaluation d’un système ou d’un composant, par des moyens automatiques ou manuels, pour vérifier qu’il répond à ses spécifications ou identifier les différences entre les résultats attendus et les résultats obtenus. (IEEE) Tester c’est exécuter le programme dans l’intention d’y trouver des anomalies ou des défauts. (G. Myers, The Art of Software Testing) Le test est une technique de contrôle consistant à s’assurer, au moyen de son exécution, que le comportement d’un programme est conforme à des données 8
  • 9. Bug? Anomalie (fonctionnement) : différence entre comportement attendu et comportement observé Défaut (interne) : élément ou absence d'élément dans le logiciel entraînant une anomalie Erreur (programmation, conception) : comportement du programmeur ou du concepteur conduisant à un défaut Anomalie Défaut Erreur 9
  • 10. Processus de test 1.Choisir les comportements à tester (objectifs de test) 2. Choisir des données de test permettant de déclencher ces comportements & décrire le résultat attendu pour ces données 3. Exécuter les cas de test sur le système + collecter les résultats 4. Comparer les résultats obtenus aux résultats attendus pour établir un verdict sélection • Spécifica _tion, génération • Objectif de test exécution • Cas de test oracle • Résultats .verdict des tests • Résultats attendus 10
  • 11. Types de tests Stratégie (cycle de vie) Système Intégration Unitaire Boîte noire Conformité Boîte Blanche Accessibilité Robustesse Performance Sécurité Critère d'évaluation (qualité du logiciel) 11
  • 12. Cycle de vie du logiciel Cycle en V 12
  • 13. Etapes et hiérarchisation des tests Test fonctionnel - boîte noire Indépendant de l’implémentation Planifier à partir de la spécification fonctionnelle Réutilisables Test structurel - boîte blanche Dépend de l implémentation Les données de test sont produites à partir d’une analyse du code source 13
  • 14. Test de conformité But : Assurer que le système présente les fonctionnalités attendues par l'utilisateur Méthode : Sélection des tests à partir de la spécification, de façon à contrôler que toutes les fonctionnalités spécifiées sont implantées selon leurs spécifications Exemple: Service de paiement en ligne Scénarios avec transaction acceptée/refusée, couverture des différents cas et cas d'erreur prévus 14
  • 15. Test de robustesse But : Assurer que le système supporte les utilisations imprévues Méthode : Sélection des tests en dehors des comportements spécifiés (entrées hors domaine, utilisation incorrecte de l'interface, environnement dégradé...) Exemple: Service de paiement en ligne Login dépassant la taille du buffer  Coupure réseau pendant la transaction 15
  • 16. Test de sécurité But : Assurer que le système ne possède pas de vulnérabilités permettant une attaque de l'extérieur Méthode : Simulation d'attaques pour découvrir les faiblesses du système qui permettraient de porter atteinte à son intégrité Exemple: Service de paiement en ligne Essayer d'utiliser les données d'un autre utilisateur Faire passer la transaction pour terminée sans avoir payé 16
  • 17. Test de performance But : Assurer que le système garde des temps de réponse satisfaisants à différents niveaux de charge Méthode : Simulation à différents niveaux de charge d'utilisateurs pour mesurer les temps de réponse du système, l'utilisation des ressources... Exemple: Service de paiement en ligne  Lancer plusieurs centaines puis milliers de transactions en même temps 17
  • 18. Test de non régression Un type de test transversal But : Assurer que les corrections et les évolutions du code n'ont pas introduit de nouveaux défauts Méthode : À chaque ajout ou modification de fonctionnalité, rejouer les tests pour cette fonctionnalité, puis pour celles qui en dépendent, puis les tests des niveaux supérieurs Lourd mais indispensable Automatisable en grande partie 18
  • 19. Techniques de « test statique » Définition : ne requiert pas l ’exécution du logiciel sous test sur des données réelles Efficacité : plus de 50 % de l ’ensemble des fautes d ’un projet sont détectées lors des inspections si il y en a (en moyenne plus de 75%) Défaut : mise en place lourde, nécessité de lien transversaux entre équipes, risques de tension…tâche plutôt fastidieuse Règles être méthodique un critère : le programme peut-il être repris par quelqu’un qui ne l’a pas fait(R1) un second critère : les algorithmes/l’architecture de contrôle apparaît-elle clairement ?(R2) décortiquer chaque algorithme et noter toute redondance curieuse et toute discontinuité 19
  • 20. Test statique Exemple: vérification de la clarté procédurale R1 :Détermination des paramètres globaux et de leur impact sur les fonctions propres Program :recherche_rec; const max_elt = 50; choix1 = 1; choix2 = 2; fin = 3; type Tliste = array[1..max_elt] of integer; var liste : Tliste; taille, choix, val : integer; complex : integer; But du programme non exprimé Manque de commentaires Identificateurs non explicites 20
  • 21. Test statique Exemple: vérification de la clarté R2 : Existence d’un entête clair pour chaque fonction {-------------------------------------------------------------------Recherche récursive d'une valeur dans une liste triée --------------------------------------------------------------------} { paramètres d'entrée : liste L la valeur recherchée indice gauche indice droit résultat : complexité de la recherche } Interface Spécifiée Interface implanté function rech_rec(L : Tliste ; val, g, d : integer) : integer ; 21
  • 22. Techniques de « test dynamique »  DT : Donnée de Test = une (séquence) d’entrée(s) JT = {DT}  D = domaine d’entrée du programme P sous test  Soient F, les fonctions spécifiées du logiciel F : D -> Sorties Le problème du test dynamique est : F=P? D -----> Sorties DEUX REGLES : Conserver les tests déjà écrits Conserver les réponses correctes correspondantes 22
  • 23. Test dynamique structurel “Testing can prove the presence of bugs, but never their absence” (Dijkstra) Le test structurel: abstraire pour obtenir un critère formel C Si C alors l1 Sinon l2 l1 l2 23
  • 24. Test unitaire structurel Graphe de Contrôle (langages procéduraux/actionnels)  But : représenter tous les chemins d’exécution potentiels  Graphe orienté : avec un noeud d’entrée E et un noeud de sortie S (noeud fictif ajouté si plusieurs sorties) Sommets : blocs élémentaires du programme, ou prédicats des conditionnelles /boucles, ou noeuds de jonction “vide” associé à un noeud prédicat Bloc élémentaire : séquence maximale d’instructions séquentielles Arcs :enchaînement d’exécution possibles entre deux sommets 24
  • 25. Test unitaire structurel Exemple : PGCD de 2 nombres Précondition: p et q entiers naturels positifs lus au clavier Effet : result = pgcd(p, q) En pseudo-langage pgcd: integer is local p,q : integer; do read(p, q) B1 while p<> q do P1 P2 if p > q then p := p-q B2 else q:= q-p B3 end -- if end -- while result:=p B4 end-- pgcd E B1 P1 P=q P<>q P2 P>q B4 B2 P<=q B3 S 25
  • 26. Test unitaire structurel Chemins : suite d’arcs rencontrés dans le graphe, en partant de E et finissant en S. en général représenté sans perte d’information par une liste de sommets  Prédicat de chemin : conjonction des prédicats (ou de leur négation) rencontrés le long du chemin. Pas toujours calculable E B1 P1 P2 B2 S : p1=q1 & p0 > q0 (pi = ième valeur de p) E B1 P1 P2 B3 S : p1=q1 & p0 <= q0 (pi = ième valeur de p) E B1 P1 (P2 B2)n S : pn=qn & (pi > qi i ∈ [0..n]) Chemins infaisables : problème en général indécidable 26
  • 27. Test unitaire structurel Sélection des tests fondés sur le flot de contrôle Couverture des instructions : chaque bloc doit être exécuté au moins une fois  Couverture des arcs ou enchaînements  tous les chemins élémentaires ou 1-chemins tous les i-chemins : de 0 à i passages dans les boucles tous les chemins : si boucles, potentiellement infinis 27
  • 28. Test unitaire structurel E B1 P1 P=q P<>q P2 P>q B4 S B2 P<=q B3 Tous les noeuds: (E, B1, P1, P2, B2, P1, B4, S) (E, B1, P1, P2, B3, P1, B4, S) Tous les arcs : idem Tous les chemins élémentaires (1chemin) : idem + (E, B1, P1, B4, S) Tous les 2-chemins : idem + (E, B1, P1, P2, B2, P1, P2, B2, P1, B4, S) (E, B1, P1, P2, B2, P1, P2, B3, P1, B4, S) (E, B1, P1, P2, B3, P1, P2, B2, P1, B4, S) (E, B1, P1, P2, B3, P1, P2, B3, P1, B4, S) Questions : qu’est-ce que ne capture pas ce modèle ? 28
  • 29. Test unitaire structurel Couverture des prédicats Aspects données if then imbriqués Couverture des dépendances entre variables Flot de données Couverture des domaines d’entrée Pertinence des données 29
  • 30. Test unitaire structurel Graphe de Flot de Données  But : représenter les dépendances entre les données du programme dans le flot d’exécution.  Graphe de contrôle décoré d’informations sur les données (variables) du programme. Sommets :idem GC une définition (= affectation) d’une variable v est notée def(v) une utilisation d’une variable est v notée P_use(v) dans un prédicat et C_use(v) dans un calcul. 30
  • 31. Test unitaire structurel Exemple : PGCD de 2 nombres Précondition: p et q entiers naturels positifs lus au clavier Effet : result = pgcd(p, q) En pseudo-langage pgcd: integer is local p,q : integer; do P=q read(p, q) B1 Def(p) Def(q) while p<> q do P1 Puse(p) Puse(q) P2 Puse(p) Puse(q) if p > q Def(p) Cuse(q) then p := p-q B2 Cuse(p) Def(q) Cuse(p) else q:= q-p B3 Cuse(q) B4 end -- if Cuse(p) end -- while result:=p B4 Cuse(p) S end-- pgcd E B1 P1 Def(p) Puse(p) P<>q P2 P>q Puse(p) P<=q B2 B3 Cuse(p) Cuse(p) 31
  • 32. Test d’intégration But : vérifier les interactions entre composants (se base sur l’architecture de conception Difficultés principales de l’intégration interfaces floues implantation non conforme au modèle architectural (dépendances entre composants non spécifiées) réutilisation de composants (risque d’utilisation hors domaine) 32
  • 33. Test d’intégration Stratégies possibles (si architecture sans cycles) big-bang : tout est testé ensemble. Peu recommandé ! top-down : de haut en bas. Peu courant. Ecriture uniquement de drivers de tests. bottom-up : la plus classique. On intègre depuis les feuilles. 33
  • 34. Test d’intégration D Driver S Stub T D Composant testé Composant sous test Interface sous test Interface testé 34
  • 42. Conclusion Facteurs de bonne testabilité : Précision, complétude, traçabilité des documents Architecture simple et modulaire Politique de traitements des erreurs clairement définie Facteurs de mauvaise testabilité : Fortes contraintes d’efficacité (espace mémoire, temps) Architecture mal définie Difficultés du test : Indécidabilité : une propriété indécidable est une propriété qu’on ne pourra jamais prouver dans le cas général Explosion combinatoire : Le test n’examine qu’un nombre fini (ou très petit) d’exécutions Impossibilité d’une automatisation complète satisfaisante 42