Tests de logiciel

Introduction
Généralités, Problèmes, Contexte

Matériel Principal: LOG240 (Alain April, Roger Champagne)

Ré-utilise du matériel du
•cours LOG3430, Ecole Polytechnique de Montréal
(Auteur Principal: Giulio Antoniol ,Co-Auteur: Sègla Kpodjedo) 1
Définitions de base

Logiciel: Un ensemble de programmes, de procédures,

de documentation associée et les données qui concernent
le fonctionnement d’un système informatique (ISO 24765)
 Ensemble de programmes: code source ayant fait l’objet de
spécifications, conception, revues, essais, ...;
 Données: inventoriées, modélisées, normalisées, créées lors de
la production du logiciel;
 Processus: processus d’affaires des utilisateurs, décrits, étudiés
et optimisés;
 Règles: règles d’affaires décrites, validées, implantées et testées;
 Documentation: véhicule de communication, réalisée à toutes
les étapes clé du cycle de vie.

2
Assurance Qualité –
Vérification vs. Validation (IEEE Std 829)

Groupe d'assurance-qualité logicielle
 Équipe de personnes avec les compétences et la formation nécessaires
pour s'assurer que toutes les actions nécessaires sont prises durant le
processus de développement afin que le logiciel résultant soit conforme
aux exigences techniques établies.

Vérification
 Évaluation d'un système ou composant logiciel pour déterminer si les
produits d'une phase donnée du développement sont conformes aux
conditions imposées au début de cette phase. Activités: inspections et
revues par les pairs de divers livrables associés au logiciel, etc.

Validation
 Évaluation d'un système ou composant logiciel durant ou à la fin d'un
cycle de développement, dans le but de déterminer si les exigences
spécifiées sont satisfaites. La validation est habituellement associée à
des tests traditionnels basés sur l'exécution, c'est-à-dire en sollicitant le
logiciel avec des cas de test.
Missions de l’Assurance Qualité

Découvrir les fautes dans les documents où elles sont introduites,
d’une manière systématique, afin d’éviter les effets de
propagation. Les études structurées et systématiques de
documentation logicielle sont appelées inspections.

Dériver, d’une manière systématique, des cas de test efficaces
pour découvrir les anomalies.

Automatiser et étendre les activités de test et d’inspection à leur
maximum possible.

Surveiller et contrôler la qualité, e.g., fiabilité, facilité de
maintenance, sécurité, à travers toutes les phases et les activités
du projet.

Tout ceci implique de mesurer par une métrique appropriée le
produit logiciel et ses processus de même qu’une évaluation
empirique du test et des technologies d’inspection.
© G. Antoniol 2006 LOG2430 - Intro Vérification et validation 4
Défaillances logicielles: Histoires « drôles »

Hounslow, West London (2009). Un distributeur automatique

Tesco donne deux fois le retrait demandé après une “erreur
opérationnelle”, un “computer glitch”

“It makes a change for us to have the joke on the banks for once.”

Bank: "If the people using the ATM see it as a bit of fun, so be it."

Des événements similaires en 2008, 2011, Europe, Amérique du Nord
5
 Défaillances logicielles: Histoires « d’horreur »
Ariane 5, Vol 501 (1996)
 4000 m et 40 s 
• Pertes: 370 millions $ US
• Cause (entre autres):
Mauvaise gestion d’exceptions
PRE: -32768 <= x <= +32767
POST: y=int16(x)

Machine de radio-thérapie Therac-25 (85- Mars Climate Orbiter (1999)

87) • Écrasement du vaisseau sur Mars
• Sur-Radiations (jusqu’à 100 fois la dose) • Pertes: 300 millions $US
• Au moins 5 morts • Cause (entre autres):
• Cause: Aucun test sur les entrées non- Mélange des systémes impérial et
standard métrique 6
Problèmes dominants
Rappel: Nature du développement logiciel:
Pas une production. Utilisation intensive de l’effort humain.
Ingénierie, mais aussi processus social. Systèmes logiciels de
plus en plus complexes, impliquant diverses industries.

Le logiciel est le plus souvent livré en retard, avec des
surcoûts et une qualité insatisfaisante.

La validation et la vérification de logiciel sont rarement
systématiques et ne sont pas souvent basées sur des
techniques sûres et bien définies.

Les processus de développement de logiciel sont
habituellement instables et incontrôlés.

La qualité du logiciel est naïvement mesurée, surveillée et
contrôlée.
7
Conséquences chiffrées d’une qualité faible

L’enquête du groupe Standish (1994)
• 350 compagnies, plus de 8000 projets.
• 31% des projets ont été annulés, seulement 9-16% ont été
livrés dans les coûts et budgets prévus

Étude américaine (1995) :
81 milliards $US dépensés par année pour des projets de
développement de logiciel qui ont échoué.

Étude NIST (2002) :

• les bugs coûtent 59.5 milliards $ par année.
• Une détection anticipée aurait pu sauver 22 milliards $.

8
Qualités des produits logiciels

Exactitude
Facilité de réparation

Fiabilité
Facilité d’évolution

Robustesse
Facilité de réutilisation

Performance
Portabilité

Convivialité
Facilité de compréhension

Facilité de vérification
Interopérabilité

Facilité de maintenance

9
Exemple : feu de signalisation

Exactitude, fiabilité :
laisse le trafic passer
selon un modèle correct
et une programmation
centralisée.

Contrôle

Robustesse, sécurité :
fournit une fonction
minimale quand c’est
possible ; ne signale
jamais des verts en
conflit. (les rouges
clignottants)
10
Subtilités de la sûreté de fonctionnement du logiciel

Un programme est correct s’il obéit à sa spécification. On

ne peut établir qu’un programme est correct mais on peut
en évaluer la fiabilité (approximation statistique)

Un programme est robuste s’il agit raisonnablement sous
des conditions sévères, inhabituelles ou illégales.

Spécification inadéquate ou partielle  correct mais pas
sécuritaire ou robuste.

Défaillances Rares  Fiable mais pas correct

Défaillances « gênantes »  Sécuritaire mais pas correct

Défaillances catastrophiques  peut-être Robuste mais
pas sécuritaire
11
Les besoins de sûreté de fonctionnement varient

Les applications à sécurité-critique :
 les systèmes de contrôle aérien ont des besoins stricts en matière
de sécurité;
 les systèmes de télécommunications ont des besoins stricts en
matière de robustesse.

Les produits de masse :

 la fiabilité est moins importante que le délai de livraison au marché.

Cela peut varier dans la même classe de produits :

 la fiabilité et la robustesse sont des aspects clés pour les systèmes
d’exploitation multi-utilisateurs (e.g., UNIX) mais moins importants
pour les systèmes d’exploitation mono-utilisateur(e.g., Windows or
MacOS)

12
 Traitement des fautes logicielles
Traitement des
fautes

Évitement Détection Tolérance

de fautes De fautes aux fautes

Méthodologie de Transactions Redondance

Inspections
Conception, atomiques modulaire

Gestion des
Vérification
Configurations
Test Déboguage

Test des Test Test du Exactitude du Performance

composants d’intégration système déboguage du déboguage

13
Définitions & Objectifs du test

14
Erreurs, Défauts, Défaillances (1/3)

Erreur (Error)
 Action humaine qui produit un résultat incorrect (ISO 24765).

Défaut ou faute (Defect)
 Une erreur qui, si elle n'est pas corrigée, pourra causer une
défaillance (failure) ou produire des résultats incorrects (ISO
24765).
 Un défaut est introduit dans le logiciel comme conséquence
d'une erreur.

Défaillance ou panne (Failure)
 Cessation de l'aptitude d'un produit à accomplir une fonction
requise ou de son incapacité à s’en acquitter à l’intérieur des
limites spécifiées précédemment (ISO 25000).
15
Erreurs, Défauts, Défaillances (2/3)

16
Erreurs, Défauts, Défaillances (3/3)

17
Tests vs. Debogage

Test de logiciel : Exécuter le logiciel pour trouver les

fautes ou gagner en confiance dans le système.

Cas de test: Item relié aux tests et qui contient
 Un ensemble de données d'entrée de test: reçues d’une source
externe (matérielle, logicielle, ou humaine) par le code testé.
 Des conditions d'exécution: requises pour exécuter le test, par
exemple une base de données qui se trouve dans un certain état,
ou une configuration particulière d'un dispositif matériel.
 Les sorties attendues. Il s'agit des résultats spécifiés que le code
testé doit produire.

Jeu (Suite) de tests / Test : Ensemble de cas de test,
combiné ou non à un ensemble de procédure de test.

Débogage (localisation de défauts)
18
 localiser le défaut; réparer le code; tester le code à nouveau.
Harnais de tests: Substituts (stubs) et Drivers

Test Stub : implémentation partielle d’un
composant duquel dépend le
composant testé.

Test Driver: implémentation partielle d’un

composant qui dépend du
composant testé.

Test stubs et test drivers permettent aux composants

d’être isolés du reste du système pour être testés.

19
Sommaire des définitions

Suite de test

Exécute est révisé par

* * 1…n

cas de test Composant Correction

* *
*
Test stub
trouve
réparations
* Test driver

* *
Défaillance * * faute * * Erreur

est causée par est causée par

20
Buts du test

Dijkstra, 1972 : “Le test de programme peut être utilisé
pour montrer la présence de bugs,
mais jamais pour montrer leur
absence.”

Aucune certitude absolue ne peut être déduite du test.

Le test devrait être intégré avec d’autres activités de

vérification, e.g., les inspections.

But principal : démontrer que le logiciel a une sûreté de

fonctionnement suffisante.
21
Vue d’ensemble du processus du test

Représentation du
logiciel

Tests

Code du
Tests
logiciel

Résultats
Résultats
attendus
Oracle Comparaison

Oracle : n’importe quel moyen permettant de prédire le résultat.

22
Tests de haute qualité

Un nombre suffisant (le plus petit possible) de cas
significatifs de test sont exécutés pour révéler des erreurs
ou augmenter la confiance qu’on a dans le système.

Qualités recherchées
 Efficace pour découvrir des fautes
 Aide à localiser les fautes à débugger
 Répétable de telle façon qu’une compréhension précise de la
faute peut être déduite
 Automatisé afin d’abaisser le coût et la durée
 Systématique afin d’être prévisible

Conséquences positives
 utilisation plus efficace des ressources de l'organisation
 probabilité plus élevée de pouvoir réutiliser des tests
 meilleur respect du budget et des échéances du projet
 possibilité de livrer un produit de meilleure qualité 23
Principes fondamentaux

24
Propriété de la continuité

Tester la capacité d’un pont à soutenir un certain poids.

Si un pont peut soutenir un poids égal à W1, alors il

soutiendra tout poids W2 <= W1.

La même règle ne peut pas être appliquée au logiciel …

La propriété de continuité, i.e., petites différences dans

les conditions d’exploitation ne résultera pas en un
comportement significativement différent -> totalement
faux dans le cas d’un logiciel.



25
Test exhaustif

Le
test exhaustif, i.e., test d’un système logiciel utilisant toutes les
données possibles, est la plupart du temps impossible.

Exemples :
 Un programme qui calcule la fonction factorielle (n!=n.(n-1).(n-2)…1).
 Test exhaustif = exécuter le programme avec 0, 1, 2, …, 100, … comme
entrée!
 Un compilateur (e.g., javac)
 Test exhaustif = exécuter le compilateur de Java avec tous les programmes
(Java) possibles (i.e., code source)!!!.

Technique utilisée pour réduire le nombre de données :

 Le critère de test groupe les éléments d’entrée en classes
d’équivalence.
 Une entrée est sélectionnée dans chaque classe (notion de couverture des
entrées de test).

26
Test Intelligent

Peu importe les moyens pour l'éviter, il reste des défauts

dans tout composant logiciel

Responsabilité des testeurs: concevoir des tests qui
 révèlent des défauts
 peuvent être utilisés pour évaluer divers attributs de qualité du
logiciel (performance, fiabilité,...)

Pour atteindre ces objectifs, le testeur doit
intelligemment choisir un sous-ensemble des
entrées de test possibles, ainsi que des combinaisons
de ces entrées, de telle sorte que la probabilité de
révéler des défauts soit maximisée, le tout en
respectant les contraintes (budget, temps, ressources) du
processus de test. 27
Stratégie de conception / Couverture des tests
Représentation du logiciel
(Modèle) Critère associé
Le jeu de test doit couvrir
toutes les éventualités
dans le modèle

Données
de test
Représentation de
• la spécification ⇒ Test Boîte noire
• l’implémentation ⇒ Test Boîte blanche

28
Tests Boite Noire

Aussi nommés "test basés sur les spécifications" ou "tests

fonctionnels"

le logiciel à tester est considéré comme une boite opaque

le testeur sait ce que fait le logiciel, mais pas comment

applicable à tous les niveaux (fonction, module, système
complet)

sources d'information pour la conception des tests:
 spécifications (formelles ou non)
 ensemble bien défini de pré- et post-conditions

particulièrement utile pour révéler des défauts au
niveau des spécifications
29
Tests Boite Noire - Exemple

Spécification du calcul de la factorielle d’un nombre:
Si la valeur d’entrée n est < 0, alors un message d’erreur approprié
devrait être imprimé. Si 0 < n < 20, alors la valeur exacte de n! devrait
être imprimée. Si 20 < n < 200, alors une valeur approximative de n!
devrait être imprimée en format virgule flottante, e.g., utilisant une
méthode approximative de calcul numérique. L’erreur admissible est
0.1% de la valeur exacte. Finalement, si n>=200, l’entrée peut être
rejetée en imprimant le message d’erreur approximatif.

À cause des variations attendues en comportement, il est naturel de

diviser le domaine d’entrée en classes {n<0}, {0< n <20}, {20 < n <
200}, {n >= 200}. Nous pouvons utiliser un ou plusieurs cas de test
de chacune des classes dans chaque jeu de test. Les résultats corrects
d’un tel jeu de test supportent l’assertion que le programme se
comportera correctement pour n’importe quelle autre valeur, mais il n’y
a pas de garantie!
30
Tests Boite Blanche

aussi nommés "boite transparente" ou "boite de verre"

concentrés sur la structure interne du code
 le code (ou un pseudo-code "fidèle") doit être disponible au
testeur

cas de tests conçus pour exercer certaines structures
spécifiques

plus longs à concevoir, coder, exécuter, et analyser les
résultats, donc typiquement appliqués à des "petits"
éléments logiciels

utiles pour révéler des défauts reliés à la conception, ou
au code (contrôle, logique, séquences,
initialisation, flux de données)
31
Tests Boite Blanche - Exemple
if x > y then
Max := x;
else
Max := x ; // faute!
end if;

{x=3, y=2; x=2, y=3} peut détecter l’erreur, plus de “couverture”

{x=3, y=2; x=4, y=3; x=5, y=1} est plus étendu mais ne peut pas le détecter.

Le critère de test groupe les domaines d’entrée en classes

d’équivalence (ici, les chemins dans le graphe de flot de
contrôle).

La couverture complète essaie d’exécuter les cas de test
de chacune des classes.

32
Test boîte noire et test boite blanche

33
Test boîte noire vs test boite blanche

Système

Spécification
Implémentation

Fonctionnalité manquante : Fonctionnalité inattendue :

ne peut être révélée par les ne peut être révélée par les
techniques de la boîte blanche. techniques de la boîte noire.
34
Test boîte blanche vs test boîte noire

Boîte noire  Boîte blanche
+ Vérifier la conformité avec + Il permet d’être certain au sujet de
les spécifications. la couverture du test.
+ Il s’adapte aux niveaux de + Il est basé sur la couverture du flot
granularité (différentes de contrôle ou de données.
techniques à différents – Il ne s’adapte pas aux niveaux de
niveaux de granularité). granularité (le plus souvent
– Il dépend de la notation des applicable à l’unité et aux niveaux
spécifications et de leur du test d’intégration).
degré de détail. – À la différence de la technique de
– On ne sait pas jusqu’à quel la boîte noire, il ne peut pas
point le système a été testé. révéler les fonctionnalités
– Quoi faire si le logiciel manquantes (partie de la
effectue des tâches non spécification qui n’est pas
spécifiées, indésirables? implémentée).

35
Aspects pratiques

36
Plusieurs causes de défaillances

La spécification peut être incorrecte ou avoir un besoin
manquant.

La spécification peut contenir un besoin qui est impossible

à implémenter étant donné le logiciel et le matériel
prescrits.

La conception du système peut contenir une défaillance.

Le code du programme peut être inexact.

37
Organisation de test

Il peut y avoir différentes causes potentielles de
défaillance. Dans les gros systèmes, le test implique
plusieurs étapes :
 Module, composant ou unité de test
 Test d’intégration
 Test de fonction
 Test de performance
 Test d’acceptation
 Test d’installation

38
Code de composant
Organisation des tests logiciels
Unité
de test Descriptions Spécifications Spécifications Besoins du Environnement
de conception fonctionnelles d’autres client de l’utilisateur
du système logiciels
Unité
de test
Code de composant

Test Test de Test de Test d’ Test

. d’intégration Fonction performance acceptation d’Installation
.
. Modules Système Logiciel Système
integrés fonctionnel vérifié accepté
Code de composant

et validé

Unité
de test SYSTÈME
Pfleeger, 1998 Opérationel
39
Différences entre les activités de tests
Test d’unité Test d’intégration Test du système

A partir des spécifications A partir des spécifications A partir des

de module d’interface spécifications

Visibilité des Visibilité de la structure Pas de visibilité

détails de code d’intégration de code

Échafaudage Quelques Pas de «driver » ou

complexe échafaudages de « stubs »

Comportement de Interactions entre Fonctionnalités du

simples modules modules système

Pezze and Young, 1998

40
Test d’intégration
L’intégration de composants bien testés peut mener à une
défaillance due à :

Mauvaise utilisation des interfaces (mauvaises spécifications
d’interface / implémentation) ;

hypothèse incorrecte sur le comportement/état de modules
reliés (mauvaise spécification de fonctionnalité /
implémentation), e.g., supposition incorrecte concernant la
valeur de retour.

utilisation de drivers / stubs faibles : un module peut se
comporter correctement avec des drivers/stubs (simples),
mais peut avoir des défaillances quand il est intégré avec des
modules réels (complexes).

41
Test de système vs. test d’acceptation

Test de système
 Le logiciel est comparé avec les spécifications des besoins
(vérification).
 Toujours effectué par des développeurs qui connaissent le
système.

Test d’acceptation
 Le logiciel est comparé avec les spécifications de l’utilisateur final
(validation).
 Toujours effectué par le client (acheteur) qui connaît
l’environnement où le système est utilisé.
 Parfois on distingue entre « α - β - testing » pour les produits à
usage général.

42
Test durant le cycle de vie

Beaucoup d’artefacts de développement durant le cycle
de vie fournissent une source riche de données de test.

L’identification anticipée des besoins de test et des cas de

tests aide à réduire la durée de développement.

Ils peuvent aider à faire connaître les fautes.

Cela peut aussi aider à identifier tôt la faible testabilité

des spécifications ou de la conception.

43
Organisation du cycle de vie

besoins => Test d’acceptation

Spécifications/Analyses => Test de système

Conception => Test d’intégration

Diagramme de classe, méthodes, pré- et post-conditions,

structure => test de classe.

44
Exemple : besoins du système

Les erreurs à cette étape auront des effets dévastateurs
comme toutes les autres activités qui en sont dépendantes.

Langage naturel : flexible mais ambigu, testabilité faible.

Est-il possible développer un test pour vérifier si les besoins
ont été satisfaits ?

E.g., non testable : le système devrait être convivial, le
temps de réponse devrait être raisonnable.

Le développement anticipé des tests d’acceptation à partir
des besoins nous permet d’évaluer si ces tests sont
testables et de durée raccourcie.

E.g., testable : le temps de réponse est moins de 1.5
seconde pour 95% du temps moyen du chargement du
système. 45
Exemple : besoins du système

Le niveau le plus bas du test des besoins consiste à
générer les données de test pour chaque besoin au
moins une fois.

Mais nous voulons utiliser des techniques qui sont un

peu plus exigeantes : limites et interactions des besoins.

Les techniques de test fonctionnel (boîte noire) peuvent

être appliquées.

Partitionnement d’équivalence, analyses des limites,

partition par catégorie, tables de décision, graphe de
cause à effet.

Les besoins de test d’acceptation sont identifiés. 46

Activités de test
Établir les objectifs des tests
Concevoir les cas de tests (jeu de test)
Écrire les cas de tests
Tester des cas de tests
Exécuter les tests
Évaluer les résultats de tests
Comprendre la cause des défaillances
Faire des tests de régression

47
les activités de test AVANT codage

Le test est une activité consommatrice du temps.

Développer une stratégie de test et identifier les besoins
de test représentent une partie substantielle du test.

Planifier est essentiel.

Les activités de test font subir une énorme pression si elles
sont exécutées vers la fin du projet.

Afin de raccourcir le délai de livraison (vers le marché) et
d’assurer un certain niveau de qualité, beaucoup d’activités
d’AQ (incluant le test) doivent être réalisées tôt dans le
cycle de vie du développement.

48
Modèle en V et activités de tests

Source: I. Burnstein, Practical Software Testing, Springer, 2003, figure 8.5. 49

Modèle en V et activités de tests

© G. Antoniol 2006 LOG2430 - Intro Vérification et validation 50

 Rôle du testeur

Le test est souvent perçu comme une activité destructrice:
 révéler des défauts
 trouver des points faibles ou des comportements incohérents
 trouver des circonstances où le logiciel ne fonctionne pas tel
qu'attendu

Il faut être à l'aise avec ce rôle !!!

Le testeur doit communiquer et collaborer avec plusieurs
intervenants.

Les testeurs devraient être hiérarchiquement indépendants
des développeurs.

Les testeurs sont des spécialistes (compétences et formation
spécifiques). Pas leur travail de déboguer !!!

Les testeurs doivent être supportés par l'administration 51
Principes de tests

1. Le test est un processus consistant à solliciter un

composant logiciel en utilisant un ensemble choisi de cas
de tests avec l'intention de (i) révéler des défauts et (ii)
évaluer la qualité.
2. Quand l'objectif du test est de détecter des défauts, un
bon cas de test en est un qui a une probabilité élevée de
révéler un défaut encore non-détecté.
3. Les résultats de tests devraient être inspectés
méticuleusement.
4. Un cas de test doit spécifier la sortie ou le résultat
attendu.
5. Des cas de tests devraient être développés pour des
entrées valides, mais aussi pour des entrées invalides. 52
Principes de tests

6. La probabilité qu'il existe des défauts additionnels dans

un composant logiciel est proportionnelle au nombre de
défauts déjà détectés dans ce composant.
7. Les tests devraient être réalisés par un groupe qui est
indépendant du groupe de développement.
8. Les tests doivent être répétables et réutilisables.
9. Les tests devraient être planifiés.
10. Les activités associées aux tests devraient être intégrées
dans le cycle de vie du logiciel.
11. Les tests requièrent de la créativité et représentent une
tâche avec un haut niveau de défi.
53
Tester demande de la créativité

Les tests sont souvent vus comme un travail ingrat (de
moins en moins).

Pour développer un test efficace, on devrait avoir :
 une compréhension détaillée du système ;
 Une bonne connaissance des techniques de test ;
 les compétences nécessaires pour appliquer ces techniques d’une
manière efficace.

Le test est mieux fait par des testeurs indépendants.

Le programmeur reste souvent fidèle à l’ensemble des
données qui font fonctionner le programme.

Souvent, un programme ne fonctionne pas quand il
est essayé par quelqu’un d’autre.
54