TESTS

LOGICIELS
Définition
 Le test est l’ensemble des méthodes,
processus et outils permettant de détecter les
défaillances d’un logiciel.

 Le test de logiciel est une évaluation par

rapport

aux exigences des utilisateurs

des spécifications du système.

Définition IEEE
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
caractéristiques

Le test est une méthode dynamique qui

permet de trouver des anomalies ou des
défauts

Le test est une méthode qui permet de

révéler la présence partielle d’erreurs
mais jamais leur absence totale.
 Objectif des tests
Découvrir des situations menant le
logiciel à un comportement incorrect,
indésirable ou non conforme a sa
spécification.
aide à réduire les risques d’occurrence de
problèmes dans l’environnement
opérationnel.
 contribuent à la qualité des systèmes
logiciels
Erreur, Défaut et défaillance.
L’erreur : l’origine des défauts

 Les défauts : imperfections dans le

logiciel.

Les défaillances :situation au cours

desquels le logiciel ne fait pas ce qu’il
devrait faire .
Répartition des défauts
 Répartition des défauts
82 % des travaux de correction et de
reprise sont liés aux erreurs de définition
des exigences
les logiciels propriétaires affichent encore
une densité de 20-30 défauts par 1000
lignes de code
 la vérification est validation représente
environ
30% du développement d’un logiciel
standard
50 % du développement d’un logiciel
critique
Causes des erreurs

L’être humain à cause

Délai limité
la complexité du logiciel
Changements de technologies
interactions complexes entre les
systèmes ..
…
Rôle des tests dans les
activités V&V
Processus Validation :conformité vis-à-vis
des exigences client et besoins des
utilisateurs.

Processus Défauts :conformité vis-à-vis

des spécifications et absence d’erreurs et
de défauts
Niveau de confiance

Décider de combien de test est suffisant

devrait prendre en compte :
les aspects techniques
commerciaux
 humain
type de logiciel
Les contraintes de temps et de budget.
 Inspection vs test

Inspection : analyse d’une représentation

statique du systèmes pour découvrir les
défauts

Tests logiciels: exercice et observation du

comportement du produit de façon
dynamique
Caractéristiques de
l’Inspection

Examen de la représentation du système

de façon manuel
Peu se faire avant l’implémentation
Peut être appliqué a toute représentation
du système
Technique efficace pour la découverte des
défauts et des erreurs
Inspection vs test
Avantage des inspections
par rapport aux testes
Une section peut détecter plusieurs erreurs

pour le test une erreur masque les autres

Prend en compte des attributs de qualité

plus large que les tests :respect des
normes et la maintenabilité
Limites de l’inspection

Vérification de la conformité vis-à-vis les

spécification du systèmes mais pas les
exigences du client

Ne peut pas vérifier certaines exigences

non fonctionnelles tel que la performance
et la facilité d’utilisation
Inspection et test

Inspection et test son complémentaires et

nécessaires pour le processus de
vérification et validation
Processus simplifié de test
 Définitions

Cas de tests (CT) : scénario

Données de tests (DT) : données en entrée à un CT
Notion d’Oracle : résultats attendus de l’exécution
Script de Test : code qui lance le programme sur le
DT
Verdict : l’exécution est-elle conforme à la prédiction
de l’Oracle? échec ou succè
Jeu de tests : ensemble de scénarios
 Processus
1. Définir un cas test (CT)
2. Choisir les données de test (DT)
3. Prédiction de l’Oracle
4. Exécution sur les DT
5. Comparaison du résultat obtenu à la prédiction de
l’Oracle (verdict)
6. Rapport du le résultat de test : succès / échec
 Exemple
un programme pour trier un tableau
d’entiers ensupprimant les redondances
 Interface : int[] tri_tab(int[] tab)
Choix des cas de test

1. Un tableau de N entiers non redondants

2. Un tableau vide
3. Un tableau de N entiers dont 1 redondant
Exemple
1. DT = [5,3,15,12] resultat = [3,5,12,15]
2. DT = [] resultat= []
3. DT = [10,20,30,5,30,0] resultat =
[0,5,10,20,30]
Choix des cas de test

Mais d’autres cas test « intéressants »

 1. DT = [2,2,2,2,2] resAT = [2]

2. DT = [5,4,3,2,1] resAT = [1,2,3,4,5]

3. DT = [1] resAT = [1]

Méthodes fonctionnels et
structurelles
 Test fonctionnel ou boîte noire
Les cas de test sont construits â partir des
spécifications.
On s’intéresse aux fonctionnalités du programme.
 Le programme est vu comme une boite noire.
le testeur ignore la conception et la structure du code,
 les ingénieurs de test et les utilisateurs finaux
effectuent ce test sur le logiciel.
Test structurel ou boîte blanche

Les cas de test sont construits à partir de la structure

interne du programme.
 Le programme est vu comme une boite ouverte ou
boite blanche.
non seulement la fonctionnalité est testée, mais
également la manière dont elle est mise en œuvre est
analysée.
Il est effectué pour tester le programme et sa mise en
oeuvre, afin d'améliorer l'efficacité ou la structure du
code.
Sélection de méthode

Les tests boîte noire et boîte blanche sont

complémentaires

Les approches structurelles trouvent plus

facilement les défauts de programmation

Les approches fonctionnelles trouvent

plus facilement les erreurs d’omission et
de spécification
 Exhaustivité du test
Impossible :
Nombre d'entrées valides très grand, voire infini
 Nombre d'entrées possibles non valides infini

Choix d'une stratégie

 Test "boîte noire"
Test "boîte blanche"
Techniques de test de la
boite noire
Test par partition et par
directives
Les principales techniques de base
utilisées pour les tests fonctionnels sont
le test par les classes d’équivalence,
le test aux limites,
le test par relation ‘cause-effet’,
le test par estimation d’erreurs
 Classe d'équivalence
L'entrée est divisée en classes similaires.
Dans la même partition le programme se
comporte de la même manière

Les cas de test doivent être choisis dans

chaque partition
Si un élément d'une classe réussit le test, on
suppose que toute la classe est réussie.
 Classe d'équivalence
étape1
Identification des classes d’équivalence

à partir des spécifications

 prévoir des classes d’équivalence pour. les

entrées valides et des classes d’équivalence
pour les entrées invalides.
Classe d'équivalence
étape2
Définition des cas de test

 les classes d’équivalence identifiées

précédemment sont utilisées pour
construire les cas de test du
programme.
Classe d'équivalence
Exemple
Exemple 2
la donnée à l’entrée est un entier qui doit compris
entre 10 000 et 99 999.
 trois conditions possibles pour l’entrée:
N < 10000
b. 10000 <= N <= 99999
N >= 100000
cas de test représentatif de chaque classe
 a. [0, 5000, 9999]
b. [10000, 50000, 99999]
c. 100000, 100001, 200000
 Valeurs limites

Erreurs souvent dues au fait que le programmeur

n’avait pas prévu le comportement du logiciel
pour des valeurs aux limites(aussi appelées
valeurs de bord)
Valeurs très grandes ou Valeurs non valide..

L'entrée est divisée en valeurs extrêmes

supérieure et inférieure.
Si ces valeurs réussissent le test, on suppose que
toutes les valeurs intermédiaires peuvent
également réussir.
Exemple

Une variable a dans le domaine [1,10]

Valeurs à tester : 0,1,2,9,10,11

Valeurs limites et classes
d’équivalence
On divisant les entrées et les sorties en
classes d’équivalence, il est important de
s’intéresser aux valeurs limites de ces
classes valeurs,
Dans ce cas les cas de test sont construits
pour les données égales ou proches des
bornes des classes d’équivalence.
Représentation graphique
des causes-effets
Dans les deux méthodes précédentes, une
seule valeur d'entrée à la fois est testée.

 Cause (entrée) -L'effet (sortie) est une

technique de test dans laquelle des
combinaisons de valeurs d'entrée sont
testées de manière systématique.
Intérêt

apporte une aide pour le choix des

combinaisons de données d’entrée
choisies dans les classes d’équivalence.

Il permet également de détecter des

erreurs dans les spécifications,
 Graphes Cause-Effet
Méthode :
1. Identifier les causes et les effets
2.proposer un graphe/réseau qui relie les
effets du programme (sorties) aux causes
(entrées) qui sont à leur origine.
Syntaxe: Op::=And|Or|Nand|NorOp
Graphes Cause-Effet

 3. traduire ce graphe sous la forme d’une

table dont les colonnes représentent les tests à
effectuer.

 Identifier les causes et les effets

 Donner le graphe Cause-Effet
 En déduire des DT
Le test par estimation
d’erreurs
Il est difficile d’établir une procédure pour
l’estimation des erreurs vu que le
processus est intuitif.
 L’idée de base est d’énumérer une liste
d’erreurs possibles puis construire les
cas de test nécessaires pour arriver à
détecter ces erreurs.
Test par paire

Le comportement du logiciel dépend de

plusieurs paramètres.

Dans les tests par paires, les paramètres

multiples sont testés par paires pour leurs
différentes valeurs.
Test basé sur l'état

Le système change d'état lors de la

fourniture d'une entrée.

Ces systèmes sont testés en fonction de

leurs états et de leurs entrées
Boite Blanche
 Boite blanche

le testeur connaît la conception et la

structure du code.

Les tests structurels sont fondés sur les

structures internes du programme à tester.
Tests structurels : principes

Le programme à valider est exécuté avec

des jeux d’essai préalablement établis

 on s’assure que la structure interne du

programme est « bien » parcourue par les
jeux d’essai.
Le test structurel permet de répondre à la
question « est-que toutes les parties du
code clans le programme ont été exercées
».
 Tests structurels : principes
Analyse du code pour produire les Données de
Test (DT)
Chaque fonction : représentée par un graphe de
controle
Comportement du programme = chemin dans le
graphe
Base sur différents critères de couverture
Certaines erreurs ne sont détectées que par le
test structurel
Méthode

Pour effectuer le test structurel, on peut

procéder comme suit:
- Etablir les graphes de contrôle,
- Décomposer statiquement le programme
à tester en portion de code »,
- Exécuter le programme avec des jeux
d’essai préétablis,
- Marquer « les portions de code »
exercées afin (le mesurer une couverture
de test.
Graphe de contrôle

la structure interne du programme (boite

ouverte) sera représentée sous forme de
graphe de contrôle
 permet de faciliter la tâche, lors du test,
par marquage des différentes structures
parcourues
Graphe de contrôle
Branche:

Une branche est une suite d’instructions,

menant d’un nœud vers un autre du
graphe,
 telles que l’exécution de la première
instruction de la branche entraîne celle de
la dernière.
Chemin:

Un chemin est une succession de branches

entre un point d’entrée et un point de
sortie du programme
Chemin de contrôle

Un chemin de contrôle est une séquence

de nœuds du graphe de contrôle partant

de l’entrée du programme et finissant à la

sortie du programme.
Chemin d’exécution:

Un chemin d’exécution est un chemin de

contrôle effectivement parcouru durant
l’exécution du programme.

Tous les chemins de contrôle ne sont pas

des chemins d’exécution.
 Types de tests structurels

Test de flux de contrôle

Test d’instructions, branches …
Test du flux de données

Cette technique de test vise à couvrir

toutes les variables de données incluses
dans le programme.
Chemin de contrôle:

Un chemin de contrôle est une séquence

de nœuds du graphe de contrôle partant
de l’entrée du programme et finissant à la
sortie du programme
Manuel et automatique
TEST MANUEL

Ce test est effectué sans l'aide d'outils de test

automatisés.
Le testeur de logiciel prépare les scénarios de test
pour différentes sections et niveaux du code, exécute
les tests.
Caractéristiques :
Les tests manuels demandent beaucoup de temps
et de ressources.
Le testeur doit confirmer si les bons cas de test
sont utilisés ou non.
La majeure partie des tests implique des tests
manuels.
Test automatisé

Ce test est une procédure de test

effectuée à l'aide d'outils

Les limites des tests manuels peuvent être

surmontées à l'aide d'outils de test
automatisés.
 Etapes du test automatisé
1. configuration :Définir les scénario de
test
Les entrés et les sorties attendues
2.Appel Appel de l’objet ( méthode a
tester)
Comparaison des résultats obtenu avec le
résultat
3. Comparaison : Comparaison des
résultats obtenu avec le résultat si vrai
succès si faux échec du test
Principe test automatisés
 Les tests automatisés doivent être
 Concis
 écrit aussi simplement que possible
 Auto-vérifiable
aucun intervention humaine ne doit être
nécessaire
 Répétable
 toujours sans intervention humaine
 Robuste
 un test doit toujours produire le même résultat
 Suffisants
 ils doivent couvrir tous les besoins du système
 Principe test automatisés
Nécessaires :pas de redondances dans les
tests
Clairs : faciles à comprendre
Spécifiques :en particulier chaque test
d’échec pointe un point précis
 Indépendants : ne dépendent pas de
l’ordre d’exécution des tests
Maintenables : ils doivent pouvoir être
aisément modifiés
Traçables
 Exemple manuel vs automatisé
Test de portabilité :
vérifier si une page Web peut être ouverte dans
Internet Explorer.
Cela peut être facilement fait avec des tests
manuels
Test de charge :
vérifier si un serveur Web peut supporter la charge
d'un million d'utilisateurs
il est impossible de tester manuellement.
 Il existe des outils logiciels et matériels qui aident
le testeur à effectuer
des tests de charge
Niveaux de test
Niveaux de tests
 Niveaux de test
Test de développement :
le système est testé pendant le développement
pour détecter les anomalies et les défauts
Tests de sorties :
une équipe distincte teste une version complète du
système avant de la distribuer aux utilisateurs
Tests d’utilisateurs :
 les utilisateurs potentiels du système testent le
système dans leur propre environnement
Test de développement
Tests de développement

Incluent toutes les activités de test

réalisées par l’équipe de développement
:
Tests unitaires
Tests d intégration
Test du système
Testes unitaires
Testes unitaires

Processus de test de composants

individuels isolés

Des classes d’objets sont testés

Se concentre sur le test de la

fonctionnalité des classes d’objets et des
méthodes
Techniques

 Tester toutes les opérations associés a un

objet
 Définition (set) et interrogation (get) de tous
les attributs de l’objet
 Faires des test à partir de tous les états
possible d’un objet
 ..
 Dans la mesure du possible les test unitaires
doivent être automatisés
Framework de test unitaires

Permet d’écrire et exécuter les tests

Les Framework de test unitaires
fournissent des classes de test génériques
qui seront étendu par le testeur pour créer
des cas de test spécifique
les tests implémentés peuvent ensuite etre
exécuter par le framework
Exemple (éclipse+Junit, Visual Studio)
 Choix des cas de test
unitaires
Type 1
reflète le fonctionnement normal du
programme
Utiliser les entrés prévu pour le composant
Type 2
 basé sur l’expérience de test tester la
présence de défauts fréquents
Utilise des entrés anormales pour vérifier
qu’elles sont correctement traités et ne
plante pas le composant
Testes d’integration
 Test d’intégration
Plusieurs unités individuelles sont
intégrées pour créer des composants
composites
Les test de composants doivent se
concentrer sur les interfaces des
composants dire les interactions entre
composants
Composants logiciels

Sont des composants composites

constitués de plusieurs objets interagissant

L’accés aux fonctionnalités de ces objets

se fait par l’interface du composant
Objectif

Le test est basé sur les composants

composites et doit se concentrer sur la
démonstration que l’interface du
composant se comporte conformément a
ses spécifications
Les test unitaires sur les objets individuels
sont supposé être terminés
Erreurs d’interface

Mauvaise utilisation de l’interface :

Paramètres dans le mauvais ordre
Interface malentendu :
Le composant appelant incorpore des
hypothèses sur le comportements du
composant appelé qui sont incorrect
Erreur de synchronisation:
Le composant appelé et le composant
appelant fonctionnent a des vitesses
Techniques

Concevoir des test pour les paramètres

d’une procédure appelé se trouvent aux
extrémités de leurs plages
Tester les paramètres de pointeur avec des
pointeurs null
Concevoir des test pour provoquer l’echec
du composant
…
Teste Système
Test de système

Se déroule pendant la période de

développement
 le test de système implique l’intégration
des composants pour créer une version
du système
Le logiciel est compilé en tant que
produit, puis testé dans son ensemble
caractéristiques

Test collectif
Peu impliquer une équipe distincte des
concepteurs et développeur du logiciel
Des digrammes tel que Diagramme de
cas d’utilisation et diagrammes de
séquences peuvent un support pour
guider le test du système
Technique de test

Toutes les fonctions système accessible

via des menus doivent être testés
Les combinaison de fonction auxquelles
pour accéder via des menues doivent être
tester
Toutes les fonctions qui requirent des
entrés de l’utilisateurs doivent être testés
avec des entrés valides et non valides
…
Développement piloté par
les tests
Développement piloté par les
tests

Test-Driven Developement TDD

Une approche de développement de
logiciels

dans les quelle le test est effectué en

même temps que le développement

 introduit par les méthodes agiles

TDD

Les tests sont écrit avant le code et passer

les testes guide la suite du développement
Le développement du code est fait de
façon incrémentale avec un test pour
chaque incrément
Le passage a l’incrément suivant est
effectué si le test du précédant est un
succès
Technique
 Identifier l’incrément ou la fonctionnalité
requise qui devrait être petit et facile a
implémenter en quelques lignes de codes

 Rédiger un test pour cette incrément et

l’implémenter autant que test automatisé
 Exécuter le test avec les autres tests mis en
œuvre (echec)

 Implémenter la fonctionnalité exécuter le test

 Une fois tous les tests exécutés passer a
l’incrément suivant
Avantages des TDD
 Couverture de code
Chaque segment a (incrément) au moins un test

 Les tests de régressions

Vérifié que l’incrément n’a pas brisé le
fonctionnement du code précédent

 Débogage simplifié
Facilité de localisation des erreurs

 Documentation système
 les test représente une forme de documentation
qui décrit le scenario normale du code (ce que
le code devrai faire)
Test de sortie
Tests de sortie ou version
 Le test de sortie est le processus de test d’une
version d’un logiciel destiné a être utilisé en
dehors de l’équipe du développement
 Une équipe de test distincte teste la version
du logiciel avant de le livrer aux utilisateurs.
 Généralement c’est un processus de test en
boite noir
 Les test sont uniquement dérivés des
spécifications des exigences
 Montrer que le logiciel fournit ses
fonctionnalités, ses performances, et sa
fiabilité lors d’une utilisation normale
 Permet de valider le produit pour une
utilisation externe
Objectif

Montrer que le logiciel fournit ses

fonctionnalités, ses performances, et sa
fiabilité lors d’une utilisation normale
Caractéristiques

Généralement un processus de test en

boite noir dans les quels les test sont
uniquement dérivés des spécifications
 Test de sortie et test de système
Les tests de sorties sont une forme de test de système

Test de sortie réalisé par une équipe distincte tandis

que le test système est réalisé par l’équipe de
développement

Test système a comme objectif de trouver les erreurs

(verification)

Test de sortie a comme objectif de prouver que les

exigences ont été respectés (validation)
Test Utilisateur ou client
Test d’utilisateur ou client

est une étape dans la quelle le client ou les

utilisateurs fournissent des entrés et des
avis sur le logiciel

Permet de juger la fonctionnalité ,

fiabilité, la performance , facilité
d’utilisation .. etc
Etapes du test
d’acceptation
1. Définir les critères d’acceptation
2. Planifier le test d’acceptation
3. Dériver les test d’acceptation
4. Exécuter les test d’acceptation
5. Négocier les résultats des tests
6. Rejeter ou accepter le logiciel
Types de tests utilisateurs

Test alpha: les utilisateurs travaillent avec

l’équipe de développement pour tester le
logiciel sur le site du développeur

Test beta: une version du logiciel est

remise aux utilisateurs pour leurs
permettre d’utiliser le logiciel et soulever
les problèmes
Test d’acceptation: les clients testent le
logiciel dans leurs environnement pour
décider s’il est validé
Références bibliographiques

 Raphael Y, Cours de génie logiciel 2, Master, Congo-

Kinshasa, 2019.

 Boudaa B, Génie logiciel, Cours Master 1, Université

Ibn khaldoun Tiaret , Algerie.

 LAYACHI S, Qualité des logiciels et techniques de test,

Cours Master1, Université Annaba