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

globale

Tests

d’intégration

Conception

détaillée

Tests

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

OK

Mafalda

Lagaf

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 ?