Assurance Qualité des

Logiciels
Chapitre 1

Dr. Imene Ben Hafaiedh

MP2L
Des bugs, des conséquences désastreuses...

• Service d’ambulances de Londres LAS [

1994] : 20 -30 morts
• Le Therac-25 [juillet 1985 ->avril 1986] : 3
morts
• Le crash d'AT&T [15 janvier 1990] : pertes
financières énormes + la réputation d'AT&T
entachée.
• Le Pentium [juin 1994] : pertes financières
énormes + psychose
• Ariane 5-01 [4 juin 1996]
 Le coût d’un Bug ?
Coût du bug de l’an 2000 ? Quelques chiffres
avancés : 300, 1600 ou même 5 000 milliards de
dollars.

Quel impact ?
• Sécurité́ des personnes,
• Retour des produits,
• Relations contractuelles,
• Notoriété, image,

⇒ Nécessité de « vérifier » certains

logiciels/systèmes
 Nécessité́ de la Validation, Vérification et Test
(VVT)
Vérification:
- le développement est-il correct par rapport à la
spécification initiale ?
- Est-ce que le logiciel fonctionne correctement?
Validation:
- a-t-on décrit le « bon » système ?
- est-ce que le logiciel fait ce que le client veut ?

Test:
- nécessaire : permet de découvrir des erreurs
- non exhaustif mais facile à mettre en œuvre (bon
rapport qualité/temps)
 Assurance qualité des Logiciels

• Objectif: accroitre les chances d’obtenir un

logiciel qui corresponde à ses objectifs (son
cahier des charges).

• Elle permet de mettre en œuvre un ensemble de

dispositions qui vont être prises tout au long des
différentes phases de fabrication d’un logiciel
 Assurance qualité des Logiciels
La mesure de la qualité d’un logiciel se fait selon
plusieurs dimensions:
En termes opérationnels:
ü Correction, fiabilité, sûreté: le logiciel réalise-t-il
les fonctions demandées et à quel niveau ?
ü Intégrité, sécurité : résiste-t-il aux attaques intentionnelles
ou aux maladresses de l’utilisateur ?
ü Efficacité, performance: quelles ressources le logiciel
requiert-il (temps, mémoire)?
ü Facilité d’utilisation
 Assurance qualité des Logiciels
La qualité du logiciel se mesure également en terme de
facilité de développement :

En termes opérationnels:

ü Maintenabilité : facilité à détecter et corriger des erreurs

ü Flexibilité́ : facilité à faire évoluer le logiciel ou l’adapter

ü Testabilité : facilité à dérouler une campagne de test

 Assurance qualité des Logiciels

La qualité d’un logiciel peut également être évaluée sous

l’angle de l’intégration :
En termes opérationnels:

ü Interopérabilité : capacité à interagir avec d’autres systèmes

ü Réutilisabilité : de tout ou partie

ü Portabilité : vers d’autres plateformes (OS, application, ...)

 Qualité et CMMI
Certain nombre de modèles d’organisation de la politique
de qualité (du logiciel ou du système) ont émergé:
Le modèle CMMI (Capability Maturity Model +
Integration) :

Il décrit 5 niveaux de maturité́ d’une organisation, mesurant

le degré auquel celle-ci a déployé explicitement et de façon
cohérente des processus qui sont documentés, gérés,
mesurés, contrôlés et continuellement améliorés.
• Niveau 1 : « l’ère des héros » (tout repose sur le développeur)

•Niveau 2 : plus classique, le chef de projet joue un rôle

important, le management et les ingénieurs ont une idée de
l’avancement global du projet qui peut être mesuré
quantitativement . . .

•Niveau 3 : l’entreprise dispose d’un référentiel qui permet de

capitaliser l’expérience acquise lors des projets

•Niveau 4 : gestion quantitative des processus (on fait des

statistiques pour repérer les problèmes)

•Niveau 5 : on optimise en permanence les processus sur la base

des analyses statistiques
 Génie Logiciel

§ Le GL est une réponse à la "crise du logiciel"

§ erreurs, budgets et échéances dépassés

§ Le GL est une démarche d'ingénierie

§ définition de processus, de méthodes et d'outils
§ s'applique à tous les aspects du logiciel

§ Il existe de nombreux processus, méthodes et

techniques qu'il faut choisir au mieux
§ sans trop en faire !
 Processus logiciels

§ Les processus logiciels définissent les activités liées

à la production de logiciels

§ Tous les processus incluent les phases :

§ de spécification du logiciel

§ de conception du logiciel

§ d'implantation du logiciel

§ de vérification / validation / Test (VVT)

 Nécessité́ de la Validation, Vérification et Test
(VVT)
Vérification:
- le développement est-il correct par rapport à la
spécification initiale ?
- Est-ce que le logiciel fonctionne correctement?
Validation:
- a-t-on décrit le « bon » système ?
- est-ce que le logiciel fait ce que le client veut ?

Test:
- nécessaire : permet de découvrir des erreurs
- non exhaustif mais facile à mettre en œuvre (bon
rapport qualité/temps)
 Définition du test

§ Tester un logiciel, c'est :

§ exécuter le logiciel
§ en maîtrisant les données en entrée
§ en s’assurant que le comportement est celui attendu

§ Maîtrise des entrées

§ sélectionner assez de données
§ mais pas trop
§ Vérification du comportement
§ pouvoir observer le comportement
§ adopter une vision critique
 Exécution des tests

§ « à la main »
§ Programmes de test / batch
§ Utilisation d’outils spécialisés
§ J-unit
§ Cpp-unit
§…
 Pourquoi tester ?

§ C’est la question clé

§ Pourquoi est-ce que vous testez ?
 Pourquoi tester ? (2)

§ On attend du logiciel certaines propriétés

§ adéquation aux besoins
§ absence d’erreur, robustesse,
§ performances, ...
§ Preuves formelles ou autres techniques
§ Pas toujours possibles
§ Pas toujours convaincantes
§ Est-ce que vous accepteriez de monter dans un avion qui
n’a jamais été testé en vol mais dont les fabricants vous
garantissent qu’ils ont «!prouvé!» que tout allait bien se
passer ?
Types de test – ce que l’on veut tester!
l Tests nominal ou test de bon fonctionnement
n Les cas de test correspondent à des données d’entrée
valide: Test-to-pass

l Tests de robustesse.
Les cas de test correspondent à des données d’entrée
invalides : Test-to-fail
l Règle usuelle : Les tests nominaux sont passés avant les
tests de robustesse
l Tests de performance
nn Load testing (test avec montée en charge)
nn Stress testing (soumis à des demandes de ressources
anormales)
 Pourquoi tester ? (2)

§ On attend du logiciel certaines propriétés

§ adéquation aux besoins
§ absence d’erreur, robustesse,
§ performances, ...
§ Preuves formelles ou autres techniques
§ Pas toujours possibles
§ Pas toujours convaincantes
§ Est-ce que vous accepteriez de monter dans un avion qui
n’a jamais été testé en vol mais dont les fabricants vous
garantissent qu’ils ont «!prouvé!» que tout allait bien se
passer ?
 Pourquoi tester ? (3)

§ Soit une propriété attendue

§ Exemple : absence d ’erreur
§ Le test ne peux pas garantir que la propriété est vraie
§ Si un contre-exemple est trouvé, on a la preuve que la
propriété est fausse

§ Tester : rechercher des erreurs (Myers 79)

 Types de tests

On caractérise l’activité de test en fonction

§ de son objectif
§ Test de conformité
§ Test de performances, test de montée en charge
§ Test de non régression
§ du moment ou il effectué dans le développement
§ Test unitaire
§ Test d’intégration
§ Test système
§ Test d’acceptation (ou de recette)
§ Test de non-régression
 Types de test (2)

Analyse
des besoins Test d’acceptation

Spécification Tests système

Conception Tests
globale d’intégration

Conception Tests
détaillée unitaires

Codage
 Pourquoi le test est difficile (1)

§ Difficultés théoriques
§ On ne peut pas tout tester
§ Infinité de données et/ou pas le temps/argent
§ Quelles données choisir ?
§ Comment décider que le résultat est correct ?
§ Quand peut-on / doit-on s’arrêter ?

§ Difficulté psychologique
§ Programmation : activité constructive
§ Test : activité « destructive »
§ Il est difficile de détruire ce que l’on a construit
 Difficulté du test
Limite théorique = Notion d'indécidabilité
Propriété indécidable = qu'on ne pourra jamais prouver dans
le cas général (pas de procédé systématique)
Exemples de propriétés indécidables :
• L’exécution d’un programme termine
• Deux programmes calculent la même chose
• Un programme n'a pas d'erreur
Une bataille perdue d'avance :
• un programme a un nombre infini (ou immense) d'exécutions possibles
• un jeu de tests n'examine qu'un nombre fini d'exécutions possibles

Solutions: trouver des heuristiques :

- Approcher l'infini (ou le gigantesque) avec le fini (petit)
- Tester les exécutions les plus « représentatives »
 Pourquoi le test est difficile (2)
Le choix de données
§ Test exhaustif
§ Exécuter le logiciel avec toutes les données d’entrée
possibles dans toutes les situations possibles
§ Impossible
§ Choisir des donnée pour découvrir des erreurs
§ Quelles données pour trouver des erreurs ?
§ Quelles données pour trouver toutes les erreurs ?
§ Chaque programme est particulier = aucune technique
générale
§ Démarches classiques, basées sur l’expérience
(ensemble de « trucs »)
 Pourquoi le test est difficile (3)
Résultat correct ?
§ Décider si le comportement du programme est
correct
§ Problème de l’oracle
§ Pouvoir observer :
§ quelles sont les sorties du logiciels
§ Savoir décider
§ Comment décide-t-on que le comportement est OK ?
§ Exple : Soit un programme de tri alphabétique

Lagaf Mafalda
Mafalda Lagaf
OK KO
 Pourquoi le test est difficile (3)
Résultat correct ?
§ Décider si le comportement du programme est
correct
§ Problème de l’oracle
§ Pouvoir observer :
§ quelles sont les sorties du logiciels
§ Savoir décider
§ Comment décide-t-on que le comportement est OK ?
§ Exple : Soit un programme de tri alphabétique

Lagaf G. La Poste
La Poste Lagaf G.
 Pourquoi le test est difficile (4)
Quand s’arrêter ?
§ Le test n’a pas révélé d’anomalies
§ Absence d’erreur ?
§ Mauvais choix de données ?

§ Le test a révélé des anomalies

§ Existe-t-il d’autres erreurs ?