Tests
Logiciels
Plan
01 Introduction au test de logiciels
01
02 Les différents types de tests
02
03 Les techniques de test fonctionnel
03
2
Chapitre 1
Introduction au
test de logiciels
• Définitions & commentaires
• Approches et types de tests
• Difficultés du test
• Principes de base
• Les différentes étapes du test
• Etude de cas
Définitions & commentaires (1/6)
Qu’est-ce qu’un logiciel ?
➢ Un logiciel, ce n’est pas seulement du code, mais aussi :
• des besoins,
• une gestion de projet,
• une spécification (fonctionnalités, contraintes,
facteur de qualité, interface),
• une conception: fonctionnelle, architecturale,
algorithmes, conception détaillée,
• un code source,
• un exécutable,
• ... et des tests !
4
Définitions & commentaires (2/6)
Qu’est-ce que tester un logiciel ?
➢ que veut dire « tester un logiciel » ?
➢ Etant donné un logiciel, comment le tester ?
➢ Le tester, c’est vérifier qu’il est conforme, mais à quoi,
sur quel critères ?
• Définition possible :
« Processus d’analyse d’un programme avec l’intention de détecter des
anomalies dans le but de le valider »
5
Définitions & commentaires (3/6)
Définition de l’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. » (Standard Glossary of Software Engineering Terminology)-STD729 (1983)
• Remarques :
➢ Un programme sans spécifications est toujours correct !
➢ Tester peut révéler la présence d'erreurs mais jamais leur absence !
➢ Vérification partielle : le test ne peut pas montrer la conformité du
système (nécessité d'une infinité de tests).
6
Définitions & commentaires (4/6)
Définition de l’A.F.C.I.Q :
« 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 préétablies » AFCIQ : Association Française pour le Contrôle Industriel et la Qualité
Définition de GJM :
« Tester, c’est exécuter le programme dans l’intention d’y trouver des
anomalies ou des défauts. »
➢ Objectif : détection des bugs.
7
Définitions & commentaires (5/6)
Qu’est-ce que un 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.
Faute Erreur Anomalie Panne
8
Définitions & commentaires (6/6)
Pour conclure :
• Les tests répondent aux questions suivantes :
➢ Est-ce que ça marche comme prévu ? ➢ Quels sont les points à améliorer ?
➢ Est-ce que c’est conforme aux spécifications ? ➢ Est-ce que c’est prêt pour le déploiement ?
➢ Est-ce que ça correspond aux attentes du ➢ Est-ce que c’est compatible avec les autres
client ? systèmes ?
➢ Est-ce que le client apprécie ? ➢ Est-ce que ça s’adapte à un nombre important
d’utilisateurs ?
• Remarques :
Il faut distinguer entre le test et la mise au point :
➢ Test : on vérifie la présence d’erreurs.
➢ Mise au point : On localise et corrige les erreurs détectées
9
Approches et types de tests
Deux approches complémentaires :
1. Test statique
Analyser les propriétés de l’application Programme
sans exécution du code.
2. Test dynamique
Exécuter un programme à l’aide d’un jeu de tests. Les erreurs sont détectées en
comparant les résultats obtenus par l’exécution et ceux attendus.
Entrée Programme Sortie
10
Approches et types de tests
Types de tests statiques :
A. Techniques informelles
Les éléments à examiner peuvent être inspirés des erreurs de programmation les plus
communes.
➢ toutes les variables du programmes sont-elles initialisées avant d'être utilisées ?
➢ toutes les constantes ont-elles un nom ?
➢ pour chaque instruction conditionnelle, la condition est-elle correcte ?
➢ est-ce que chaque boucle termine ?
➢ lorsque l'on traite des tableaux, la borne inférieur est-elle 0, 1 ou autre valeur ?
➢ si on utilise un stockage dynamique, a-t-on alloué l'espace correctement
➢ si on utilise un langage faiblement typé, les paramètres effectifs correspondent-ils aux
paramètres formels ?
11
Approches et types de tests
Types de tests statiques :
B. Techniques formelles
Se basent sur des règles de preuves.
Ces méthodes sont de plus en plus employées.
Il reste le problème de l’adéquation entre le modèle formel et la réalité.
➢ Model-checking, SAT, ...,
➢ Méthode par raffinements (B)
➢ Interprétation abstraite (estimation d’erreur, runtime-error, ...)
12
Approches et types de tests
Types de tests dynamiques :
1. Tests fonctionnels
Vérifier que le logiciel respecte sa spécification (correction, facteurs qualité spécifies,
les performances, interfaces avec les équipements externes)
➢ Est-ce que le logiciel est conforme à la spécification ?
2. Tests structurels
Le but est de détecter les fautes d’implémentation. Par conséquent, de vérifier que le
logiciel n’en fait pas plus que sa spécification et qu’il n’existe pas de cas de plantage
(overflow, non initialisation, . . .).
➢ Est-ce que le codage est correct ?
13
Approches et types de tests
Combien coûte le test logiciel ?
• Le test représente de 30 à 40% des coûts de développement d’un logiciel suivant
son niveau de criticité.
➢ environ 30% du développement d'un logiciel standard
➢ plus de 50% du développement d'un logiciel critique
• Phase de test souvent plus longue que les phases de spécification, conception et
implantation réunies.
14
Difficultés du test
Difficulté n°1 :
Le test exhaustif est en général impossible à réaliser !
➢ En test structurel, le parcours du graphe de flot de contrôle conduit à une
forte explosion combinatoire !
15
Difficultés du test
Difficulté n°1 : (suite)
Le test exhaustif est en général impossible à réaliser !
➢ En test fonctionnel, l'ensemble des données d'entrée est en général infini ou très
grande taille.
• Exemple :
Un logiciel avec 5 entrées analogiques sur 8 bits admet 240 valeurs
différentes en entrée.
➢ Le test est une méthode de vérification partielle de logiciels.
➢ La qualité du test dépend de la pertinence du choix des données de test.
16
Difficultés du test
Difficulté n°2 :
Difficultés d'ordre psychologique ou culturel !
➢ Le test est un processus destructif : un bon test est un test
qui trouve une erreur alors que l'activité de programmation
est un processus constructif : on cherche à établir des
résultats corrects.
➢ Les erreurs peuvent être dues à des incompréhensions de
spécifications ou de mauvais choix d'implantation.
17
Difficultés du test
Pour conclure :
➢ Le test des logiciels est un processus d’introduction des défauts très
complexe et pénible.
➢ Il est mal perçu par les informaticiens et délaissé par les théoriciens.
Malheureusement, il est impossible de faire une
automatisation de test complète satisfaisante !
18
Principes de base
1. Indépendance
Un programmeur ne doit pas tester ses propres programmes.
➢ Mais il vaut mieux faire ses tests avant de délivrer, et aussi les conserver !
2. Paranoïa
Ne pas faire de tests avec l’hypothèse qu’il n’y a pas d’erreur (code trivial, déjà
vu, ...) ⇨ bug assuré !
➢ Conseil : un test doit retourner erreur par défaut. Le retour ok doit être
forcé.
19
Principes de base
3. Prédiction
La définition des sorties/résultats attendus doit être effectuée avant l’exécution
des tests. C’est un produit de la spécification.
➢ C’est nécessaire pour des développements certifiés.
➢ Les données sont fournies parfois au niveau système (ex: Matlab), mais les
résultats seront différents à l’implémentation.
➢ Parfois les données sont trop complexes à fournir directement (éléments
de compilation, environnement complexe...)
20
Principes de base
4. Vérification
Il faut inspecter minutieusement les résultats (trace) et la pertinence de chaque
test.
➢ C’est la séparation de l'exécution et de l'analyse.
5. Robustesse
Les jeux de tests doivent être écrits pour des entrées invalides ou incohérentes
aussi bien que pour des entrées valides.
➢ C’est important car on ne sait jamais ce qui peut arriver !
21
Principes de base
6. Complétude
Vérifier un logiciel pour détecter qu’il ne réalise pas ce qu’il est supposé faire
n’est que la moitié du travail.
➢ Il faut aussi vérifier ce que fait le programme lorsqu’il n’est pas supposé le
faire.
22
Principes de base
En cas de bug que faire ?
1) Vérifier que le test est bien correct (principe n°4).
2) Vérifier que le problème n'est pas déjà répertorié (base de bugs par
exemple).
3) Etablir un rapport de bug :
• Donner un synopsis précis.
• Donner une description claire, avec tous les détails de reproduction
du bug
23
Principes de base
Pour conclure :
Il faut :
• Commencer par les cas généraux avant les cas particuliers.
• Commencer par les cas prioritaires.
• Les tests montrent la présence d’erreurs et non pas leur absence.
• Les tests exhaustifs sont impossibles.
• Tester tôt.
24
Les différentes étapes du test des logiciels
Quand commencer ?
• Le test commence de suite ! Ici, le cycle en V. mais aussi approches incrémentale,
agile..
25
Les différentes étapes du test des logiciels
Les différents niveaux :
✓ Tests de recette : test de réception du logiciel chez le client final.
✓ Tests intégration système : test de l'intégration du logiciel avec d'autres logiciels.
➢ Tests système : test d'acception du logiciel avant livraison (nouvelle version
par exemple).
➢ Tests Intégration : test de l'intégration des différents composants (avec ou
sans hardware).
✓ Tests Unitaires : tests élémentaires des composants logiciels (une fonction, un
module, ...
26
Les différentes étapes du test des logiciels
La planification : (1/3)
➢ Ces différents niveaux de tests doivent être planifies (c'est l'objet du plan projet).
➢ Le plan de tests est un document obligatoire déterminant le déroulement des tests
durant le projet.
➢ Le plan de tests détermine la priorisation des défaillances.
➢ La priorisation facilite la communication entre développeurs et testeurs ainsi que
l’affectation et la planification des tâches.
➢ Théoriquement, on prépare les tests en même temps que le développement
correspondant au niveau.
➢ On peut aussi le faire d’une manière incrémentale, ou en pipeline.
➢ De toute façon, il y a re-bouclage permanent.
27
Les différentes étapes du test des logiciels
La planification : (2/3)
Élément Description Objectif
Acteurs et Décrit qui fait quoi dans les tests. Assure le suivi et
Responsabilités
affectation les affectations
Portée de tests,
Définit le processus et détaille les actions à
Tests plannings, durées et
entreprendre
priorités
Plan de Tout le monde doit savoir ce qu’il doit savoir avant
Communication
communication les tests et ce qu’il doit faire savoir après les tests
Analyse de Éléments critiques à Identification des domaines qui sont critiques dans
risques tester le projet
Traçage des Documentation des Documenter les défaillances et les détails les
défaillance défaillances concernant 28
Les différentes étapes du test des logiciels
La planification : (3/3)
Priorité Description
1 Fatal Impossible de continuer les tests à cause de la sévérité des défaillances.
Les tests peuvent continuer mais l’application ne peut passer en mode
2 Critique
production
L’application peut passer en mode production mais des exigences
3 Majeur
fonctionnelles importantes ne sont pas satisfaites.
L’application peut passer en mode production mais des exigences
4 Medium
fonctionnelles sans très grand impact ne sont pas satisfaites.
L’application peut passer en mode production, la défaillance doit
5 Mineur
être corrigée mais elle est sans impact sur les exigences métier.
Défaillances mineures relatives à l’interface (couleurs, police, …)
6 Cosmétique
mais n’ayant pas une relation avec les exigences du client
29
Les différentes étapes du test des logiciels
Le PVT : Une démarche d’assurance qualité
L’étape la plus importante en début de projet, c’est la définition d’un Plan de Test et
Validation - PTV
Objectif du test.
Techniques de test.
Phase de planning.
30
Les différentes étapes du test des logiciels
Les plans de test
Il doivent :
➢ Définir les moyens à mettre en place pour tester le logiciel
➢ Décrire la stratégie de tests à mettre en place pour tester la première
version, tester les versions suivantes,… critères d’arrêt des tests.
➢ Décrire les fiches de tests (détecter des incohérences et des incomplétudes
des documents).
31
Les différentes étapes du test des logiciels
Les fiches de test
Elles sont constituées :
➢ Des valeurs à positionner à l’entrée du test ou les actions à effectuer
➢ Des valeurs de sortie attendues ou la description du comportement du
logiciel
➢ Démontrer la couverture atteintes (traçabilité)
32
Les différentes étapes du test des logiciels
Pour conclure :
Pour chaque plan de test (TU, TI, TV), le testeur doit élaborer le rapport de tests :
➢ Exécuter les fiches de tests spécifiées (consiste à positionner les valeur
d’entrées ou effectuer les actions décrites dans la fiche de tests)
➢ Analyser les résultats obtenus (comparer les résultats attendus avec
les résultats obtenus et décider du statu du tests OK / KO)
➢ Emettre des fiches de non conformité si nécessaire
33
Etude de cas
• Soit la spécification suivante :
➢ Un programme prend en entrée trois entiers. Ces trois entiers sont
interprétés comme représentant des longueurs des cotés d’un triangle.
➢ Le programme rend un résultat précisant si il s’agit d’un triangle scalène,
isocèle ou équilatéral.
Travail demandé :
1. Ecrire un algorithme d’une fonction solution pour ce programme.
2. Produire une suite de cas de tests pour ce programme !
34
Etude de cas
Corrigé – Question 1 :
Fonction Triangle (……………..
Variables
Début
{Votre programme}
Fin 35
Etude de cas
Corrigé – Question 2 :
• Cas possibles de triangles :
o Pas un triangle :
➢ 1 côté à une longueur supérieure à la somme des 2 autres
o Isocèle :
➢ 2 côtés égaux uniquement
o Équilatéral :
➢ 3 côtés égaux
o Scalène :
➢ Les autres
36
Etude de cas
Corrigé – Question 2 :
• Cas valides : Données Résultat attendu
triangle scalène valide (10, 5, 7) scalène
triangle isocèle valide + permutations (3, 5, 5) isocèle
triangle équilatéral valide (3, 3, 3) équilatéral
triangle équilatéral valide (2, 3, 5)/(1,1,2) scalène/isocèle
• Cas non valides :
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 négative (2, -1, 6) triangle invalide/entrée invalide
une valeur non entière (‘a’, 4, 2) entrée invalide
mauvais nombre d'arguments (3, 5) entrée invalide 37
Etude de cas
Remarques + commentaires :
• 16 cas correspondant aux défauts constatés dans des implantations de cette
spécification.
• Moyenne des résultats obtenus par un ensemble de développeurs expérimentés :
55% :
➢ La construction de tests est une activité difficile,
➢ encore plus sur de grandes applications.
38
Etude de cas
Remarques + commentaires :
▪ 14 cas de test –GJ Myers –«The Art of Software Testing»-1979
1. Cas scalène valide (1,2,3 et 2,5,10 ne sont pas valides)
2. Cas équilatéral valide
3. Cas isocèle valide (2,2,4 n’est pas valide)
4. Cas isocèle valide avec les trois permutations (e.g. 3,3,4; 3,4,3; 4,3,3)
5. Cas avec une valeur à0
6. Cas avec une valeur négative
7. Cas ou la somme de deux entrées est égale àla troisième entrée
8. 3 cas pour le test 7 avec les trois permutations
39
Etude de cas
Remarques + commentaires :
▪ 14 cas de test –GJ Myers –«The Art of Software Testing»-1979
9. Cas ou la somme de deux entrées est inférieur à la troisième entrée
10. 3 cas pour le test 9 avec les trois permutations
11. Cas avec les trois entrées à0
12. Cas avec une entrée non entière
13. Cas avec un nombre erronée de valeur (e.g. 2 entrées, ou 4)
14. Pour chaque cas de test, avez-vous défini le résultat attendu ?
40
Etude de cas
Remarques + commentaires :
▪ 14 cas de test –GJ Myers –«The Art of Software Testing»-1979
• Chacun de ces 14 tests correspond à un défaut constaté dans des
implantations de cet exemple triangle.
• La moyenne des résultats obtenus par un ensemble de développeurs
expérimentés est de 7.8 sur 14.
➢ La conception de tests est une activité complexe, à
fortiori sur de grandes applications
41
