Cours 1 : Introduction au test du logiciel

Philippe Ayrault

1 Présentation du cours
– 1 Cours sur l’organisation des tests.
– Qu’est-ce que le test d’un logiciel ?
– Les différentes étapes du test des logiciels
– Les différents documents pour le test des logiciels et leurs contenus
– 1 Cours / 2 ED sur les tests structurels
– Déterminer les jeux de tests pour les principaux types de couverture de tests structurels
– 1 Cours / 1 ED sur les tests fonctionnels
– Déterminer les jeux de tests pour les principaux types de couverture de tests fonctionnels
– 0,5 ED sur les autres types de tests
– Monté-Carlo, injection de fautes, ...
– Panorama des autres techniques de test des logiciels.
– 0,5 Cours sur les dossiers de tests

Cours et TD donnés conjointement par Valérie Menissier Morain (LIP6) / Philippe Ayrault (ex-
Surlog, Alcatel, Etersafe).

2 Introduction aux tests du logiciel

2.1 Qu’est-ce qu’un logiciel ?
– des documents de gestion de projet
– une spécification décrivant :
– la liste des fonctions à remplir par le logiciel
– les facteurs qualité du logiciel : sa portabilité, son évolutivité, sa robustesse, . . .
– les contraintes : performances temporelles et spatiales, . . .
– les interfaces avec son environnement
– une conception décrivant :
– la découpe de la spécification en modules (ou objets)
– la description les interfaces entre ces modules (ou objets)
– la description des algorithmes mis en place
– un code source
– un exécutable

1
Module Test page 2/4

2.2 Qu’est-ce que tester un logiciel ?

Question 1 : Qu’est-ce que ça veux dire que ”tester un logiciel” ?
Je vous donne un logiciel. Testez le. Comment faites-vous ?
Vérifier qu’il est conforme, par rapport à quoi ? Suivant quels critères ?
Tentative de définition « Processus d’exécution d’un programme avec l’intention de détecter des anomalies
dans le but de le valider. »
Question 2 : Y a-t-il plusieurs types de tests ?
Essentiellement deux types de tests :
– tests fonctionnels : vérifier que le logiciel respecte sa spécification (correction, facteurs qualité
spécifiés, les performances, interfaces avec les équipements externes, . . .).
– 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, . . .)
En fait,

Fonctions spécifiées Fonctions codées

pour le logiciel dans le logiciel

Question 3 : Y a-t-il une alternative aux tests ? Malheureusement non, c’est la seule activité de vérification
dynamique du logiciel.
– méthodes formelles : il reste le problème de l’adéquation entre le modèle formel et la réalité.
– relecture de code : elle permet de détecter les principales erreurs statiques dans le code mais pas les
erreurs dynamiques
– analyses de sécurité : elles permettent de valider une architecture mais pas de la vérifier.

Question 4 : Quel est le coût du test d’un logiciel ? Le test représente de 30 à 40% des coûts de
développement d’un logiciel suivant son niveau de criticité. Il représente généralement 1/3 dans le planning.

Conclusions : Le test des logiciels est un métier à part entière. Dans l’industrie, c’est la seule acti-
vité dans le cycle de développement où l’on peut voir toutes les fonctionnalités d’un produit logiciel.
Contrairement au développement, où les développeurs sont très compartimentés (spécialiste IHM, réseaux,
algorithmie,. . .).

Le test est une activité créatrice :

imaginer des scénarios plausibles pouvant mettre un logiciel en défaut
imaginer et construire des bancs de tests permettant de vérifier les fonctionnalités et les contraintes,. . .

Nécessité d’avoir plusieurs compétences : automatisme, électronique, réseau, . . .

Exemple : Vous devez tester le logiciel d’acquisition de la vitesse d’un train utilisant un capteur
odométrique, comment tester ce logiciel ?
– prendre le véritable capteur tachymétrique et le monter sur un moteur que l’on peut piloter à plusieurs
vitesse
– simuler le ou les signaux du capteur avec une carte électronique ou un autre logiciel

2005/2006
c (by UPMC/LMD/UE Test) 1er février 2007
Module Test page 3/4

– ...

Malheureusement, le test a mauvaise réputation, voici les principaux griefs :

– les testeurs sont les derniers dans la chaı̂ne de développement du logiciel, il accumule donc tous les
retards pris par les phases précédentes
– les testeurs découvrent des anomalies, par conséquent c’est de leur faute si le projet est en retard
– le complexe du développeur : je suis un bon développeur, donc mes logiciels sont sans bug (soit dit en
passant,”les bugs n’existent pas, il y a seulement que des caractéristiques non documentées”)

La nécessité de tester un logiciel de façon systématique n’est pas encore admise partout. Elle est admise
pour les logiciels sûrs de fonctionnement car les activités de vérification et de validation (V&V) sont décrites
de façon très détaillée dans les référentiels normatifs. De plus, un logiciel sûr ne pourra pas être mis en
service si la démonstration de sa sécurité n’a pas été effectuée généralement par une personne ou une
société indépendante du développeur.

2.3 Quelques principes de base

Présentation de quelques principes de base pour réaliser des tests.

Principe 1 : Un programmeur ne doit pas tester ses propres programmes.

Tout simplement pour ne pas être juge et partie.

Principe 2 : Ne pas effectuer des tests avec l’hypothèse de base qu’aucune erreur ne va être trouvée.

Principe 3 : La définition des sortie ou résultats attendus doit être effectuée avant l’exécution d’un test.
Ceci est une erreur fréquente du test. Ce n’est pas lorsque l’on effectue le test d’une procédure qu’il faut se
poser la question de la validité des résultats, car il y a des chances non négligeable de prendre un résultat
erroné mais semblant cohérent pour un résultat correct.

Principe 4 : Inspecter minutieusement les résultats (trace) de chaque test.

Pour une raison similaire au principe 2, il faut séparer l’exécution (action) et l’analyse des résultats.

Principe 5 : Les jeux de tests doivent être écrits pour des entrées invalides ou incohérentes aussi bien
que pour des entrées valides.
Simplement afin de découvrir les anomalies.

Principe 6 : 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.
Afin d’évaluer la robustesse du logiciel.

3 Les différentes étapes du test des logiciels

Le test ne commence pas après que le logiciel soit développé. Il commence dès la phase de spécification
d’un logiciel et se déroule durant chaque phase du cycle de développement.

– Plan Qualité du Logiciel

– l’organisation mise en place
– les responsabilités et les interfaces des personnes intervenant dans le processus de test

2005/2006
c (by UPMC/LMD/UE Test) 1er février 2007
Module Test page 4/4

– les objectifs de tests fixer pour chaque niveaux de tests du logiciel : z

– Tests Unitaires (TU)
– Tests d’Intégration (TI)
– Tests de Validation (TV).

– Pour chaque phase de définition du logiciel (spécification, architecture, conception détaillée) : à par-
tir du document de définition ; Dossier de Spécification du Logiciel(DSL), Dossier de Conception
Préliminaire (DCP), Dossier de Conception Détaillée (DCD), le testeur doit écrire dans les plans de
tests correspondant (resp. Plan de Tests de Validation (PTV), Plan de Tests D’Intégration (PTI), Plan
de Tests Unitaires (PTU)). Ces plans doivent : zzz
– 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). Une
fiche de tests est constituée :
– 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é)

– Pour chaque phase 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 status du tests OK / KO)
– émettre des fiches de non conformité si nécessaire

– Qualification
– émettre un avis sur le logiciel

2005/2006
c (by UPMC/LMD/UE Test) 1er février 2007