Chapitre II : Introduction au test de

logiciels

1. Terminologie liée à l’activité de test

L’activité de test concerne, bien sûr les spécifications formulées lors des étapes de conceptions du
logiciel à développer.

1.1. Spécification, ISO 8402

Document qui prescrit les exigences auxquelles le produit ou le service doit se conformer.

1.2. Satisfaction
Un programme satisfait sa spécification lorsqu’il est en tout point conforme aux exigences de celle-ci.

1.3. Validation ou Vérification, ISO 9000-3

Processus d'évaluation du logiciel pour s'assurer qu’il satisfait aux exigences spécifiées.
La validation ou vérification d'un produit permet ainsi de s'assurer qu'on a construit le bon produit
(preuve).
Le test est un cas particulier de vérification.

 Remarque (Difficulté formelle) : Il n’existe pas d’algorithme (méthode) apte à démontrer la

correction (preuve) d’un programme *Gödel 1931+.

1.4.Tester un logiciel
Processus d’exécution d’un programme avec l’intention de détecter des anomalies dans le but de le
valider.

1
 Autre définitions
1. 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 des
différences entre les résultats attendus et les résultats obtenus.
2. Dans “G. 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.

3. Selon l’AFCIQ :
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.

Quelques remarques
1. Il s’agit en réalité d’un ensemble d’activités réparties dans le cycle de vie,
2. Une grande partie des activités de test se situe en fin de cycle de développement,
3. Il est difficile d’évaluer l’effort nécessaire. Il est admis que 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 du planning.
4. Une mauvaise manière de voir le test est de le considérer comme une activité intervenant
uniquement dans la phase « codage et test » du cycle de vie.

Test et Cycle de vie

Dans le cycle de vie d’un logiciel, le test est un processus de vérification et de validation
complémentaire à l’analyse statique (études) et les activités liées à ce test se déroulent tout
au long du cycle de vie et interagissent fortement avec les autres activités de développement
(conceptuelles et pratiques).

Activités de test
1. Planification : Plans de test, choix de méthodes, budget
2. Conception : Choix des jeux de test
3. Implémentation : Réalisation nécessaire à l’exécution des jeux de tests
4. Exécution : Monitoring, analyse des résultats

2. Hiérarchie ou niveaux des tests

Comme nous l’avons présenté dans le cycle de vie en « V » d’un logiciel, les tests sont réalisés dans
l’ordre suivant :

2.1.Test unitaires
But
Consiste à tester les composants (procédures et modules) logiciels de manière isolés dans le but de
s'assurer qu’il ne comporte pas d'erreur d'analyse ou de programmation et par rapport à sa
spécification détaillée.

Quand
Dès qu’un composant à été codée et compilée correctement

Qui
Pour les logiciels de faible criticité, elle peut être réalisée par l’équipe de développement (mais pas
par le développeur ayant codé le composant).

2
 2.2.Test d’intégration
« Une progression ordonnée de tests dans laquelle des éléments logiciels et matériels sont
assemblés et testés jusqu'à ce que l’ensemble du système soit testé. » (IEEE 729)

But
Validation des sous-systèmes logiciels entre eux. Consiste ainsi à tester le bon comportement lors de
la composition de procédures et modules

Quand
Dès qu’un sous-système fonctionnel (module, objet) est entièrement testé unitairement

Qui
Toujours par une équipe de tests indépendante de l’équipe de développement.

2.3.Test système ou Test de validation

« Test, généralement effectué par l'acquéreur dans ses locaux après installation d'un système ou
d'une unité fonctionnelle, avec la participation du fournisseur, pour vérifier que les dispositions
contractuelles sont bien respectées. » (ISO/IEC 2382-20)

But
Vérifier la conformité du logiciel à la spécification du logiciel. Consiste ainsi à tester les spécifications
externes et doit permettre de répondre à la question : A-t-on bien fait le logiciel ?

Quand
Dès que l’ensemble des sous-systèmes fonctionnels ont été testé et intégré

Qui
Ces tests sont toujours réalisés par une équipe de tests indépendante de l’équipe de développement.

Remarque : Encore une fois, comme nous l’avons précisé précédemment, les activités liées à ces
trois niveaux de tests se déroulent tout au long du cycle de vie du développement d’un logiciel et
commencent donc dès les phases d’étude des besoins. Ainsi les activités de planification et de
conception des tests peuvent commencer en parallèle avec les premières phases du cycle de vie (cf
schéma du cycle de vie en « V »)

3. Types de tests (ou Techniques de tests)

Il existe essentiellement deux types de tests :

3.1.Tests fonctionnels (ou Tests boite noire)

Consiste à vérifier que le logiciel respecte sa spécification indépendamment de son implémentation.
Ils sont planifiés à partir des spécifications fonctionnelles du logiciel. Ils sont schématiquement
représentés comme suit :

a
S1
b Spécification
c S2

3.2.Tests structurels (ou Tests boite blanche)

Ce type de tests consiste à étudier la structure de l’implémentation (code) dans le but de détecter les
fautes d’implémentation. Il existe deux catégories de tests de ce type :

3
Tests Statiques :
Sans exécuter le programme

Tests Dynamiques
Avec exécution du programme

4. Niveaux de tests VS types de tests

5. Complémentarité test fonctionnel –structurel

Les techniques fonctionnelles et structurelles sont utilisées de façon complémentaire.

Exemple : Soit le programme suivant censé calculer la somme de deux entiers

Function sum(x,y : integer) : integer;
begin
if (x = 600) and (y = 500) then sum:= x-y
else sum:= x+y;
end

Une approche fonctionnelle détectera difficilement le défaut alors qu’une approche par analyse de
code pourra produire le test : x = 600, y = 500 qui permet de trouver l’anomalie.

Conclusion :
En examinant ce qui à été réalisé, on ne prend pas forcément en compte ce qui aurait du être fait :
⇒ Les approches structurelles détectent plus facilement les erreurs commises
⇒Les approches fonctionnelles détectent plus facilement les erreurs d’omission et de
spécification.

6. 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.

4
 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égligeables 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’´evaluer la robustesse du logiciel.

5
 7. COURS N°3 (11 Mars 2008)

8. Suite

9. Chap2.1 Généralités

3.3.2.1.N. Graphe de Contrôle (langages procéduraux/actionnels) :

– But : représenter tous les chemins d’exécution potentiels

– Graphe orienté : avec un nœud d’entrée E et un nœud de sortie S (nœud
fictif ajouté si plusieurs sorties)

– Sommets :
Blocs élémentaires du programme, ou prédicats des conditionnelles/boucles, ou nœuds de jonction
“vide” associé à un nœud prédicat

Bloc élémentaire : séquence maximale d’instructions séquentielles

– Arcs :
Enchaînement d’exécution possible entre deux sommets

2.1.n+1. Chemins de contrôle : suite d’arcs rencontrés dans le graphe, en partant du noued
d’entrée E et finissant sur le nœud de sortie S. Un chemin de contrôle représente une exécution
possible d’un programme à partir d’une DT donnée .

A. Expression des chemins de contrôle

10. Pour le flot de données : cf doc « Cours1CompactTest.pdf »