T ES T ET F I ABI L I T E

DU LO GI CI E L
ASSOHOUN E. Stanislas
- UFR ENVIRONNEMENT (UJLoG)
PLAN

 CHI – GENERALITES SUR LES TESTS LOGICIELS

 CH2 – TECHNIQUES DE TESTS DE BOITE NOIRE ET

BLANCHE

 CH3 – PROCESSUS DE TEST

 OBJECTIFS
Omniprésent tout au long du cycle de développement et motivés par
une réalité économique (Généralement 40% du budget global des projet
logiciel est consacrée à l’effort de test), le test logiciel est une activité
qui mobilise de nombreuses connaissances et savoir-faire pour produire
des tests pertinents. Il a pour but de :
 Savoir placer les tests dans le cycle de développement
 Savoir ce que sont et comment utiliser les tests statiques
 Maîtriser les techniques de conception de tests dynamiques
 Connaître les principes du management des tests
 Savoir différencier et utiliser les différents outils de tests du marché.
 PROBLEMATIQUE
 Le coût du test dans le développement

 50% des start-up échouent à cause du trop grand nombre de bugs (mauvaise
campagne de test, maintenance difficile, pas de non régression)

 Constat : le test est le parent pauvre de tout projet logiciel

 On ne peut pas tester tout le temps ni tous les cas possibles. Cependant
prouver l’absence d’erreurs dans un programme est un problème indécidable.
 CHI
GENERALITES SUR TESTS LOGICIELS
vocabulaire et principaux concepts
 Introduction
Le test est une activité importante dont le but est d’arriver à un produit
« zéro défaut ». C'est la limite idéaliste vers laquelle on tend pour la
qualité du logiciel.
Un test logiciel désigne une procédure de vérification partielle d'un
système logiciel . Son objectif principal est d'identifier les
comportements problématiques du logiciel afin d'en augmenter la
qualité (si les problèmes identifiés lors des tests sont corrigés) et
d’apporter des informations quant à cette qualité.
 I- TERMINOLOGIE (1)
- Des erreurs peuvent être commises lors des différentes
activités réalisées pour obtenir le code exécutable
(spécification, conception, documentation, codage, etc.).
- Du fait de certaines de ces erreurs, le code peut
exécutable peut contenir des fautes.
À l’exécution, certaines de ces fautes peuvent entraîner une
défaillance
du programme.
erreur  faute  défaillance
 I- TERMINOLOGIE (2)
• - SPECIFICATION (ISO 8402): Document qui prescrit les exigences
auxquelles le produit ou le service doit se conformer.

• - SATISFACTION : Un programme satisfait sa spécification lorsqu’il est en

tout point conforme aux exigences de celle-ci.

• - VALIDATION ou VERIFICATION (ISO 9000-3) : Processus d'évaluation

du logiciel pour s'assurer qu’il satisfait aux exigences spécifiées. La validation
ou la vérification d'un produit cherche à s'assurer qu'on a construit le bon
produit (d’un point de vue externe ou interne). Le test est un cas particulier
de vérification.
 EXEMPLES DE DEFAILLANCES LOGICIELLES

• La présence de fautes dans l’exécutable peut entraîner (mais pas

systématiquement) des défaillances à l’exécution :
- l’exécution du programme produit un résultat qui n’est pas le bon
- l’exécution du programme ne se termine pas (boucle infinie)
- à l’exécution, le programme consomme trop de ressource et paralyse
la machine
- à l’exécution, une défaillance prévue se produit, un traitement d’exception
est réalisé, le programme se termine proprement, sans produire le résultat
- à l’exécution, une défaillance imprévue se produit, le noyau de
l’OS arrête immédiatement le programme, aucun résultat n’est produit
II- CLASSIFICATION DES FAUTES DE CODE
 III- DEFINITONS (1)
• - Définition (Test du logiciel (inspiré de [1]))
Tester, c’est exécuter un programme dans le but de constater des
défaillances et de trouver des fautes.
- Définition (Test du logiciel (inspiré de [2]))
Le test du logiciel consiste à vérifier dynamiquement que le comportement
d’un programme est conforme au comportement attendu. Cette vérification
est faîte sur un ensemble fini de cas de test, sélectionnés de façon adéquate
parmi l’ensemble potentiellement infini des cas possibles.

• Définition (Test du logiciel)

Le test est un moyen d’assurer la qualité des logiciels, en vérifiant sur
un ensemble de cas pertinents (car potentiellement capables de mettre
à jour une faute) que le comportement du code exécuté est conforme
au comportement attendu.
 III- DEFINITONS (2)
• Remarques

• Dans cette définition, le test n’est pas restreint à une simple vérification de
l’étape de codage :
- participe à l’activité de qualité logicielle
- peut être vu comme un guide pour l’étape de développement
(l’objectif est alors d’écrire du code « qui passe les tests »)
Scénario, jeu de test, oracle

Un jeu de test est un ensemble de données de test. Un scénario de test est

un ensemble d’actions à effectuer avant de soumettre le jeu de test. Le
scénario de test produit un résultat.
Un oracle de test est une spécification des résultats attendus par le test, qui
permet de décider de l’échec ou le succès du test.
 III- DEFINITONS (3)
• Exemple 1 avec oracle manuel

• Exemple 2 avec oracle manuel

 III- DEFINITONS (3)
• Exemple 1 avec oracle manuel

• Exemple 2 avec oracle manuel

 IV- CARACTERISTIQUES DE CRITERES DE TESTS (3)
• - Validité: Un critère de test est dit valide si pour tout programme
incorrect,
il existe un jeu de test non réussi satisfaisant le critère.
- Fiabilité: Un critère est dit fiable s'il produit uniquement des jeux de test
réussis ou des jeux de test non réussis.
- Complétude: Un critère est dit complet pour un programme s'il produit
uniquement des jeux de test qui suffisent à déterminer la correction du
programme (pour lequel tout programme passant le jeu de test avec
succès
est correct).
Remarque : Tout critère valide et fiable est complet.

•
 VI- NIVEAUX DE TEST : CLASSIFICATION SELON LES
CIBLES(1)
• Les techniques de test sont utilisées à différentes étapes du
développement d’un logiciel et sont donc appliquées à des cibles de
natures différentes. Selon ce critère, on aboutit aux 3 grandes classes
suivantes :
- tests unitaires
- tests d’intégration
- tests systèmes
Tests unitaires : Les tests unitaires visent à vérifier le fonctionnement en
isolation de portions de code testables séparément.

• Exemples d’unité de test :

* une méthode
* un service offert par un composant
 VI- NIVEAUX DE TEST : CLASSIFICATION SELON LES
CIBLES(2)

• Tests d’intégrations : Les tests d’intégration visent à vérifier le

fonctionnement de la composition de deux portions de codes (deux unités de
test) interagissant l’une avec l’autre.
- Exemple de test d’intégration :
* intégration d’une unité d’affichage d’une table et d’une unité de
traitement de table (tri, ajout, retrait, sélection, etc.)
* intégration d’une unité de connexion et d’une unité d’identification /
authentification
- Plusieurs approches :
bottom-up (resp. top-bottom) : intégration et test d’intégration en remontant
(resp. descendant) l’arbre de décomposition fonctionnelle
big-band : intégration et test d’intégration simultanément pour tous les
composants
 VI- NIVEAUX DE TEST : CLASSIFICATION SELON LES
CIBLES(3)

• exemple:

• l’intégration Top-Bottom se fera comme suit :

- on teste l’intégration de U1 avec U2, puis
- on teste l’intégration de (U1+U2) avec U3, puis
- on teste l’intégration de (U1+U2+U3) avec U4, puis
- on teste l’intégration de (U1+U2+U3+U4) avec U5.
 VI- NIVEAUX DE TEST : CLASSIFICATION SELON LES
CIBLES(4)

• l’intégration Bottom-Up se fera comme suit :

- on teste l’intégration de U5 avec U3, puis
- on teste l’intégration de (U5+U3) avec U4, puis
- on teste l’intégration de (U5+U3+U4) avec U2, puis
- on teste l’intégration de (U5+U3+U4+U2) avec U1.

Tests systèmes :Les tests systèmes visent à vérifier le comportement du

système complet :
* test des performances, de la sûreté de fonctionnement du système ;
* test d’intégration du système avec l’environnement d’exploitation
(Hardware, OS, librairies, etc.)
 VI- NIVEAUX DE TEST : CLASSIFICATION SELON LES
OBJECTIFS ET LES TECHNIQUES(1)
• Selon les objectifs: Les techniques de test sont utilisées dans buts différents.
Selon ce critère, on aboutit aux classes suivantes :
- tests de conformité (ou test de correction, ou encore test fonctionnel )
- test de régression
- test de performance
- test d’utilisabilité
tests d’acceptation (ou de qualification, de recette)
- α-test et β-test
- etc.
-
Selon les objectifs: L’une des difficultés du test réside dans la sélection d’un
ensemble fini de données de test pertinentes . Pour surmonter cette
difficulté, des approches systématiques ont été proposées. Elles sont
généralement classées en 2 catégories :
- test en boite noire : sélection des cas de test sans rien connaître
de la façon dont l’entité testée est réalisée.
- test en boîte blanche : sélection des cas de test basée sur la connaissance
de la façon dont l’entité testée est réalisée.
 VI- NIVEAUX DE TEST : CLASSIFICATION SELON LES
OBJECTIFS (2)
• Tests de conformités : Les tests de conformité ont pour but de vérifier la
conformité entre le comportement à l’exécution et le comportement spécifié.
Tests de régression : Les tests de régression ont pour but de vérifier que des
modifications/évolutions n’ont pas eu d’effets négatifs inattendus, en
montrant que les tests qui passaient jusqu’alors et non impactés par
l’évolution/modification testée, passent toujours.

• Il s’agit de rejouer les tests passés précédemment : raison supplémentaire

pour intégrer les tests comme éléments sous contrôle de la gestion de
configuration

• Tests d’acceptation: Les tests d’acceptation ont pour but de valider le

développement complet du logiciel. Il s’agit de vérifier que le logiciel peut
être utilisé pour mener à bien un certain nombres de scénarios, fixés par le
client.
 VI- NIVEAUX DE TEST : CLASSIFICATION SELON LES
TECHNIQUES (1)

• L’une des difficultés du test réside dans la sélection d’un ensemble fini de
données de test pertinentes . Pour surmonter cette difficulté, des approches
systématiques ont été proposées. Elles sont généralement classées en 2
catégories :
* test en boite noire : sélection des cas de test sans rien connaître
de la façon dont l’entité testée est réalisée.
* test en boîte blanche : sélection des cas de test basée sur la connaissance
de la façon dont l’entité testée est réalisée.
 CHII
LES TECHNIQUES DE TESTS DE
BOITE NOIRE ET DE BOITE
BLANCHE
 I- TECHNIQUES DE TESTS DE BOITE NOIRE
Le test porte sur le fonctionnement externe du système. La façon dont le système
réalise les traitements n'entre pas dans le champ du test.
– é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

Les techniques suivantes relèvent de l’approche « boîte noire » :

* analyse partitionnelle
* étude aux limites
* analyse par table de décision
* test aléatoire
I-1 L’ANALYSE PARTITIONNELLE (1)

• Principes : le domaine d’entrée de l’entité à tester est partitionné en classes

d’équivalence. Pour tester l’implémentation, il suffit de choisir un cas de test
par classe d’équivalence, car un cas est représentatif de sa classe.
 I- TECHNIQUES DE TESTS DE BOITE NOIRE

• I-1 L’ANALYSE PARTITIONNELLE (2)

• Comment identifier les classes d’équivalence ?

* boîte noire pure : le domaine de chaque paramètre d’entrée est partitionné
en sous-domaines valides et invalides (= classes d’équivalence)
on choisit un représentant de chaque classe comme cas de test
* boîte grise : identification et utilisation du partitionnement réalisé par le
code.

• Exemple: Soit à tester la méthode

Fonction nbJoursDansMois( mois: entier , annee : entier)

• (la spécification précise que la méthode ne couvre que le XXIème siècle) ?

 I- TECHNIQUES DE TESTS DE BOITE NOIRE

• I-1 L’ANALYSE PARTITIONNELLE (3)

 - Boîte noire pure :

• On en déduit par exemple les cas de tests suivants :

(mois, annee) ∈ {(−4, 2010), (9, 2010), (15, 2222), (9, −10), (9, 2222)}

• - Limites:

• Permet de limiter le nombre des cas de test à 1 cas par classe d’équivalence
du domaine d’entrée : permet de déterminer si cette classe est correctement
traitée

• Mais : ne permet pas de vérifier si les frontières entre les classes sont
correctement établies; ne tient pas compte des éventuelles différences de
traitement entre les éléments appartement à la même classe (nécessite de
prendre en compte la relation entrées / sorties)
 I- TECHNIQUES DE TESTS DE BOITE NOIRE

• I-2 ETUDE AUX LIMITES (2)

 - Principe :

• Idée : de nombreuses erreurs résultent en une faute logique ou calculatoire,

qui peut avoir pour conséquence de provoquer un branchement erroné pour les
éléments aux limites des classes d’équivalence du domaine d’entrée. On va
donc tester particulièrement des éléments situés sur ces frontières :
- juste avant la frontière;
- sur la frontière;
- juste après la frontière.

Cette technique s’utilise en complément de l’analyse partitionnelle

 I- TECHNIQUES DE TESTS DE BOITE NOIRE

• I-2 ETUDE AUX LIMITES (2)

 - Exemple :

• On établit des cas de test pour la méthode

• Fonction nbJoursDansMois( mois: entier , annee : entier)

• Proposez des cas de test qui permettent de réaliser une étude aux limites.
- limite pour le paramètre mois : entre 0 et 1 (limite basse) et entre 12 et 13
(limite haute)

- limite pour le paramètre année : entre 2000 et 2001 (limite basse) et entre
2100 et 2101 (limite haute)

• On en déduit par exemple les cas de tests suivants :

(mois, annee) ∈{(0, 2010), (1, 2010), (12, 2010), (13, 2010), (6, 2000), (6, 2001),
(6, 2100), (6, 2101)}
 I- TECHNIQUES DE TESTS DE BOITE NOIRE

• I-2. ETUDE AUX LIMITES (3)

 - Limites :

• Permet de vérifier si les frontières entre les classes d’équivalence sont

correctement établies.

• Mais :
- multiplie les cas de tests : à utiliser uniquement aux endroits utiles (basés sur
l’expérience du développeur / testeur)
- ne tient pas compte des éventuelles différences de traitement entre les
éléments appartement à la même classe nécessite de prendre en compte la
relation entrées / sorties
 I- TECHNIQUES DE TESTS DE BOITE NOIRE

• I-3. TABLES DE DECISION (1)

 - Principes :

• Idée : on élargit l’analyse partitionnelle au domaine de sortie de l’unité testée.

On met ensuite en relation les classes d’équivalence du domaine d’entrée et
celles du domaine de sortie. On choisit alors un cas de test pour chaque
nouvelle classe créée.
Les tables de décision sont aussi un moyen (déclaratif) de spécifier le
comportement attendu du système : pour un seul effort intellectuel,
on dispose donc

• - d’une spécification de l’unité testée

• - d’un ensemble de cas de test (à compléter (ou pas) par une étude aux
limites).
 I- TECHNIQUES DE TESTS DE BOITE NOIRE

• I-3. TABLES DE DECISION (2)

 - Limites :

• Avec bissextile =
• {x ∈ [2001, 2100] : (x mod 4=0 Et x mod 100 <>0 ) OU (x mod 400 = 0}
On en déduit par exemple les cas de test suivants :
(mois, anne) ∈ {(−3, 2050), (15, 2050), (3, 1930), (3, 2111), (3, 2010), (4,
2010), (2, 2004), (2, 2005)}
 I- TECHNIQUES DE TESTS DE BOITE NOIRE

• I-3. TABLES DE DECISION (3)

 - Limites :

 Affine l’analyse partitionnelle, en tenant compte de la relation entre

les classes d’équivalence des entrées et celles des sorties
Mais :
ne permet pas de tester les frontières entre les classes d’équivalence : à
utiliser conjointement avec une étude aux limites pour les cas adaptés
 I- TECHNIQUES DE TESTS DE BOITE NOIRE

• I-3. TESTS ALEATOIRE (1)

 - Principe :

 Idée : pour certaines unités testées, il est possible de générer

automatiquement des cas de test. On a donc, gratuitement, la possibilité de
tester massivement l’unité. Deux intérêts :
- permet de trouver des fautes non mises à jour par les autres techniques
- offre une mesure de la qualité des autres cas de test (si les cas de test
générés aléatoirement trouvent plus de fautes que les cas de test générés
systématiquement, ces derniers sont sans doute à revoir).

 Par ailleurs, dans certains cas, les techniques systématiques ne sont

pas applicables : le test aléatoire est alors la seule possibilité restante.
 I- TECHNIQUES DE TESTS DE BOITE NOIRE

• I-3. TESTS ALEATOIRE (1)

 - Limites :

 Permet de mesurer la qualité des tests systématiques, et éventuellement de

détecter des fautes « non classiques »
Mais :
ne peut venir qu’en complément des tests systématiques car ne garantissent
aucun critère de couverture nécessite de disposer d’un oracle pour permettre
la génération automatique des Cas de Test (CT) pas applicable dans toutes les
situations !
 II- TECHNIQUES DE TESTS DE BOITE BLANCHE

 Le test vérifie les détails d'implémentation, c'est à dire le comportement interne

du logiciel..

– exploite le code (→ besoin du source/de l'architecture)

– tests de portions de code : bloc, branche, etc.
 Les techniques en boîte blanche se basent sur une analyse du code source de
l’unité à tester :
- Tests basés sur l’analyse du graphe de flot de contrôle
* couverture de toutes les conditions
* couverture de tous les chemins
- Tests basés sur l’analyse du graphe de flot de données
* couverture des chaînes définitions / références pour chaque variable
La génération de cas de test relevant de techniques boîte blanche est
automatisable.
 II- TECHNIQUES DE TESTS DE BOITE BLANCHE

• II-1. Graphe de flot de contrôle (1)

 La structures de contrôle se présente sous la forme d'un graphe dit graphe de
flot. Ce dernier peut être représenté sous forme algébrique.
 Formalisme
 II- TECHNIQUES DE TESTS DE BOITE BLANCHE

• II-1. Graphe de flot de contrôle (2)

 Exemple (graphe de contrôle ou de flot)
 II- TECHNIQUES DE TESTS DE BOITE BLANCHE

• II-1. Graphe de flot de contrôle (3)

 Chemin de contrôle
 Le graphe G1 (cf figure précédente) est un graphe de contrôle qui admet une
entrée -le nœud a -, une sortie -le nœud g.
 le chemin [a, c, d, e, g] est un chemin de contrôle,
 le chemin [b, d, f, g] n’est pas un chemin de contrôle.

 Le graphe G1 comprend 4 chemins de contrôle :

 ch1 = [a, b, d, f, g]
 ch2 = [a, b, d, e, g]
 ch3 = [a, c, d, f, g]
 ch4 = [a, c, d, e, g]
 II- TECHNIQUES DE TESTS DE BOITE BLANCHE

• II-1. Graphe de flot de contrôle (4)

 Chemin de contrôle : expression algebrique
 Le graphe G1 peut-être exprimé sous forme algébrique sous la forme suivante :
G1 = abdfg+ abdeg+ acdfg+ acdeg
le signe + désigne le «ou» logique entre chemins.

 Simplification de l’expression de chemins

G1 = a (bdf+ bde+ cdf+ cde) g
G1 = a (b + c) d (e + f) g
 II- TECHNIQUES DE TESTS DE BOITE BLANCHE

• II-1. Graphe de flot de contrôle (5)

 Exemple 2
 II- TECHNIQUES DE TESTS DE BOITE BLANCHE

• II-1. Graphe de flot de contrôle (6)

 Exemple 3
• - Etablir le graphe de flot de contrôle du programme ci-dessous
• - Fournir l’expression des chemins
 II- TECHNIQUES DE TESTS DE BOITE BLANCHE

• II-1. Graphe de flot de contrôle (6)

 Corrigé exemple 3
 II- TECHNIQUES DE TESTS DE BOITE BLANCHE

• II-2. Mesure de complexité de Mac Cabr (1)

Cette mesure donne le nombre de chemins minimaux. Elle est donnée par la
formule suivante qui correspond au nombre de régions du graphe de flot :
Nombre cyclomatique = nombre d’arcs – nombre de nœuds +2

• exemple 4 : soit le programme ci-dessous présenté sous forme d’organigrammes

•
 II- TECHNIQUES DE TESTS DE BOITE BLANCHE
• II-2. Mesure de complexité de Mac Cabr (2)
exemple 4 : (2) On en déduit le graphe de flot suivant :

• Donc le nombre cyclomatique est : Nb.Arcs – Nb.Nœuds + 2 = 13 – 11 + 2 = 4

Pour vérifier, on regarde les chemins minimaux (un test par chemin pour tester
toutes les possibilités du programme) : 1- 1.11 ; 2- 1.2.3.4.5.10.1.11 ;
3- 1.2.3.6.7.9.10.1.11 ; 4- 1.2.3.6.8.9.10.1.11
 CHIII
PROCESSUS DE TEST