Tests et Validation du logiciel

02/2007 – 06/2007

Willy ANDRZEJAK
Présentation
 Willy ANDRZEJAK – 30 ans
 Ingénieur Système – Adventec
 wandrzejak@yahoo.fr

 Ingénieur Cnam depuis……

 Professeur depuis ….

 UE GLG101 enseignée depuis…

 A vous…
Consignes
 Vérifier en les quittant, la propreté des salles et, le
cas échéant, faire ramasser les papiers ou autres
détritus,
 Interdire l’introduction de toute denrée alimentaire ou
boisson dans les salles de cours (seule les
bouteilles d’eau sont tolérées)
 Vérifier les extinctions de lumières
 Vérifier qu’après la fin du cours, tous les auditeurs
sont bien sortis de l’ENSAM,
 Respecter les horaires de fin de cours fixés à 21H30
 Veiller au rangement des chaises et des tables dans
la même disposition que celle trouvée en arrivant.
Calendrier
 06, 13, 20, 27 Février
 06, 13, 20, 27 Mars
 03, 10 Avril
 Pas de cours pendant 4 semaines
 15, 22, 29 Mai
 05, 12 Juin

 Horaires : 18h30 21h30

Organisation du cours
 Cours 45 h + travail personnel 15 h (rédaction
d’une dossier et d’une présentation)

 Cours participatif + exercices

 1 ou 2 intervenants extérieurs pour présenter
leur métier
 Présentation de vos exposés

 Sources principales de ce cours

Vos exposés
 Individuel ou par groupes (2 maximum)
 Sujet libre (théorique, pratique) mais devant
avoir un rapport avec les tests
 1 dossier bien formé (20 pages de contenu
minimum par personne)
 Fourniture de 1 ou 2 questions pour l’examen
avec réponse
 Date de fourniture des dossiers : 15 Mai 2007.
 1 présentation oral 20-30 minutes par
personne
Examen

 Les notes d’exposés comptent pour 1/3

de la note d’examen
 Note d’exposé : 60% dossier / 40%
présentation

 Je vous indiquerai durant les cours,

certaines questions qui pourraient être
posées
Plan
 Introduction au test des  Techniques de test
logiciels  Introduction
 Définitions du test  Approche fonctionnelle
 Classes de défaut  Approche structurelle
 Difficultés liées au tests  Comparaison des approches
 Types de tests vs  Efficacité des techniques de
Techniques de tests tests
 Stratégie - Généralités
 Tests dans le projet
 Tests et cycle de vie
 Test Unitaires
 Tests d’intégration
 Tests de charge
Le test ..

 D’après vous…
Quelques Bugs connus

 En 1996 la fusée Ariane 5 explose après

30s de vol
 Erreur de conversion entre données numériques!
 $500M en matériel + $7B en développement!
Quelques bugs connus
 En 2004 une défaillance du système d’alarme
d’une centrale électrique produit une coupure
d’électricité aux Etats-Unis et au Canada
 50M de personnes privées d'électricité
 $6B perdus!

 En 1992 les ambulances de Londres sont

dirigées par un logiciel fautif
 Des personnes perdent la vie…
Définition du test

 Erreur, défaut, anomalie

 On constate une anomalie
 Due à un défaut (on dit aussi une faute (!) )
du logiciel
 Défaut du à une erreur du programmeur
(ex. : confusion d ’un I avec un 1)
Définition du test

« Program testing can be used

to show the presence of
bugs, but never to show their
absence! »
Edsger Wybe Dijkstra
Définition du test

 Qu’est ce qu’un test réussi ?

 Un test réussi n ’est pas un test qui n ’a
pas trouvé de défauts, mais un test qui
a effectivement trouvé un défaut (ou une
anomalie)
G.J. Myers
Définition du test

 Selon 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 »
Définition du test

 Selon Bill Hetzel « Le test est une

activité destinée à déterminer si
l’évaluation d’une caractéristique ou
d’une aptitude d’un programme ou d’un
système donne les résultats requis. »
Définition du test

 Selon Glendford. J. Myers (The Art of

software Testing); « Tester c’est
exécuter le programme dans l’intention
d’y trouver des anomalies ou des
défauts »
Définition du test
 « Le tests des logiciels » Edition Hermes;
« Le test d’un logiciel est une activité qui fait partie du
processus de développement. Il est mené selon les
règles de l’assurance de la qualité et débute une fois
que l’activité de programmation est terminée. Il
s’intéresse aussi bien au code source qu’au
comportement du logiciel. Son objectif consiste à
minimiser les chances d’apparition d’une anomalie
avec des moyens automatiques ou manuels qui visent
à détecter aussi bien les diverses anomalies possibles
que les éventuels défauts qui les provoqueraient ».
Définition du test
 Est-ce que le logiciel fonctionne comme prévu ?
 Le test est souvent associé avec les termes vérification et
validation.

 La validation est le moyen de confirmer le respect d’exigences

déterminées pour une utilisation spécifique prévue.
 Validation : Faisons-nous le travail attendu ?

 La Vérification est l’action de confirmer la satisfaction des

exigences spécifiques via l’étude et la mise à disposition de
preuves objectives.
 Vérification : Faisons-nous le travail correctement ?

IEEE Standard for software test documentation 1998

Définition du test
 Finalité : fiabilité du logiciel : taux de disponibilité pour les utilisateurs

 MTTR : Mean Time To Repair. Temps moyen mis pour réparer un

système en panne

 MTTF : Mean Time To Failure. Temps moyen que met un système à

tomber en panne. C'est une sorte d'unité de mesure de la faibilité d'un
système.

 MTBF : Mean Time Between Failures. Temps moyen écoulé entre deux
pannes, y compris le temps de réparation : MTBF = MTTF + MTTR (La
francisation en « Moyenne des Temps de Bon Fonctionnement » est
donc fausse). Voir aussi MTBE.

 MTBE : Mean Time Between Errors. Temps moyen entre deux erreurs

 Taux de disponibilité pour l’utilisateur : MTTF / MTBF

Définition du test
 Tests par l’affirmation (positive testing)
 « Le test est une activité destinée à déterminer si
l’évaluation d’une caractéristique ou d’une aptitude
d’un programme ou d’un système donne les
résultats requis. »

 Tests par la négation (negative testing)

 « Tester c’est exécuter le programme dans
l’intention d’y trouver des anomalies ou des
défauts »
Définition du test
 Le Bug

 Tests et débuggage
Jeux de test

DT = {x = 5, y = 5, b = 58}

Jeux de test : ensemble de données de test

Oracle de test : prédiction du résultat

Scénario de test : séquence d ’actions

Définition du test

 Définition de classes de d’erreurs

 Calcul
 Logique
 Entrée / sortie
 Traitement des données
 Interface
 Définition des données
Difficultés du test

 Paramètres rendant le test difficile :

 Tests Exhaustif
 Processus d’introduction des défaut
 Difficultés d’ordre psychologique ou culturel
 Difficultés formelles
 Autres
Difficultés du test
 Le test exhaustif est difficile à réaliser
 Exemple : un logiciel avec 5 paramètres de type byte (8
bits) admet 2^40 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
Difficultés du test
 Processus d’introduction des défaut
 Manipulation de données abstraites
 Succession de transformations:
Besoin réel
 Idée « abstraite »
et confuse du client
 Spécifications
 Conception
 Code source Besoin perçu Besoin modélisé
 Assemblage, ….
 Perte d’informations, introduction d’erreurs, etc.
Difficultés du test

 Difficultés d’ordre psychologique ou

culturel
 Activité tendant à montrer les erreurs des
programmeurs !
 Manque d’intérêt pour ce domaine du génie
logiciel
Difficultés du test

 Difficultés formelles
 Résultat d’un ensemble de travaux
théoriques sur les systèmes formel : « Il ne
peut exister aucun algorithme général (donc
aucun outil), capable de démontrer
l’exactitude totale de n’importe quel
programme  ».
 Travaux de Kurt Gödel , A. Turing et A
Church.
Difficultés du test

• Gödel : 1931 Idée de base : l ’autoréférence

Cette phrase est fausse.

- si elle est vraie, alors ce qu ’elle dit est vraie, i.e. elle
est fausse
- si elle est fausse, alors elle est vraie
Difficultés du test
• Puis Turing et Church...
• Il existe des algorithmes qu ’on ne peut écrire
– Exemple : un algo qui, sans utiliser des fichiers de
recopie ou autres artifices, donne comme résultat
d ’exécution l ’impression du texte source.
a := 1;
b := 2;
Il faudrait ajouter
writeln (‘ a := 1; ’); Mais comme ces 2 instructions
writeln (‘ b := 2; ’); appartiennent aussi au code source, il
faut ajouter :
writeln(‘ writeln (‘ ‘ a := 1;  ’’););
writeln (‘ writeln (‘ ‘ b := 2;  ’’););
Difficultés du test
 Autres difficultés
 Taille et complexité des programmes
 Perturbation / modification du comportement
normal du code par l’outillage de test
 Distinction environnement de
développement et environnement de
production
 Le temps réel
 L’environnement extérieur
Types de tests vs Techniques de tests

 « Tests » : deux axes

 Types de tests
 Techniques de tests
Types de tests vs Techniques de tests

 Types de tests
 Catégories de tests effectués tout au long de la vie du
logiciel.
 Tests unitaires, tests d’intégration, tests système, tests
de non régression,…

 Techniques de tests
 Techniques utilisées durant les phases de tests (types
de tests)
 Techniques fonctionnelles, structurelles , dynamiques,
statiques, flots de données, graphes cause-effet, …
Tests Fonctionnels – black box
Tests Structurels – white box
Plan
 Introduction au test des  Techniques de test
logiciels  Introduction

 Définitions du test  Approche fonctionnelle

 Classes de défaut  Approche structurelle

 Comparaison des approches
 Difficultés liées au tests
 Efficacité des techniques de
 Types de tests vs
tests
Techniques de tests
 Stratégie - Généralités
 Tests dans le projet
 Tests et cycle de vie
 Test Unitaires
 Tests d’intégration
 Tests de charge
Stratégie de tests

 50 % ou plus des charges d’un projet

 Les tests doivent être conçus avant que

le logiciel soit réalisé

 Conception du logiciel  facilité de test.

Testabilité = exigence clé
Stratégie de tests

 Etapes de conception des tests

 Généralistes  détaillées
 Une stratégie de test.

 Une planification des tests.

 La conception des dossiers de test.

 L'élaboration d'une procédure de test.

Stratégie de tests
 Une stratégie de test devrait être idéalement une grande
organisation à l'image d'une organisation de développement.

 Enoncé de l'approche générale du test, en identifiant

 Types de tests qui seront effectués pour les différentes étapes du
projet et comment ils seront effectués
 Définition des couvertures de tests.
 Choix des outils
 Moyens et délais à investir dans l’activité de tests (effort)

 Développer une stratégie de test, qui répond efficacement aux

besoins d'une organisation, est critique pour assurer le succès du
développement des applications. L'application d'une stratégie de
test à un projet de développement devrait être détaillée dans le
plan qualité du projet.
Stratégie de tests

 Rendre l’effort de test efficace

 Maximiser les chances de détecter les
erreurs
 Trouver le plus d’erreurs possibles

 Le plus rapidement possible

 Faciliter le diagnostique
Stratégie de tests

 Critères d’arrêt des tests

 Une fois les jeux de tests passés avec
succès (donc pour une couverture définie
au préalable)
 En fonction du nombre d’erreurs trouvées,
ou du temps imparti (quid des erreurs qui
restent ?)
 En fonction du taux marginal de détection
(nombre d’erreurs trouvées par rapport au
temps)
Stratégie de tests

 Plan de test
 Les éléments à tester.
 L’ordre dans lequel ils doivent être testés.

 L’application de "la stratégie de test" au test

de chaque élément.
 La description de l'environnement de test.
Stratégie de tests

 L'objectif de chaque plan de test est de

fournir un programme pour vérifier, en
testant le logiciel produit, que celui-ci
satisfait les besoins ou la conception du
logiciel. Dans le cas du test de recette et
du test système, on fait référence à
l'étude des besoins généraux.
Stratégie de tests

 Définition des dossiers de test (scenario)

 N dossiers de tests pour chaque élément à tester de
chaque niveau de test
 Explique comment la mise en place d'un besoin
particulier ou d'un choix conceptuel doit être testé et
quel est le critère de succès de ce test.
 Nécessité de concevoir des dossiers de test
« positifs » et « négatifs »
 Peut permettre de trouver des problèmes de
conception avant même le début des
développements
Stratégie de tests

 Définition des procédures de tests

 Processus exact à suivre pour mener à bien
chaque dossier
 Le niveau de détail doit être tel que la
procédure de test est déterministe et
répétable
Stratégie de tests

 Documentation des résultats de tests

 Nécessité de consigner tous les résultats
d’exécution de tests.
 Des comptes-rendus de test peuvent être
produits à différents moments du processus.
Un compte-rendu résumera les résultats et
documentera toutes les analyses
Stratégie de tests - Conclusion

 Toujours tester en fonction d'une

spécification.
 Documenter le processus de test
 Tester à chaque niveau de spécification.
La détection précoce des erreurs réduira
finalement les coûts.
 Planifier les activités de test.
Stratégie de tests - Conclusion

 Utiliser les techniques telles d’analyse

statique et dynamique.
 Tester positivement, mais aussi
négativement
 Coupler gestion des tests et gestion des
corrections