Tests et Validation du logiciel

02/2007 – 06/2007 Willy ANDRZEJAK

Présentation

   Willy ANDRZEJAK – 30 ans Ingénieur Système – Adventec [email protected]

  Ingénieur Cnam depuis…… Professeur depuis ….

 UE GLG101 enseignée depuis…  A vous…

Consignes

      Vérifier en les quittant, la propreté des salles et, le cas échéant, faire ramasser les papiers ou autres détritus, Interdire l’introduction de toute denrée alimentaire ou boisson dans les salles de cours (seule les bouteilles d’eau sont tolérées) Vérifier les extinctions de lumières Vérifier qu’après la fin du cours, tous les auditeurs sont bien sortis de l’ENSAM, Respecter les horaires de fin de cours fixés à 21H30 Veiller au rangement des chaises et des tables dans la même disposition que celle trouvée en arrivant.

Calendrier

 06, 13, 20, 27 Février  06, 13, 20, 27 Mars  03, 10 Avril  Pas de cours pendant 4 semaines  15, 22, 29 Mai  05, 12 Juin  Horaires : 18h30  21h30

Organisation du cours

 Cours 45 h + travail personnel 15 h (rédaction d’une dossier et d’une présentation)    Cours participatif + exercices 1 ou 2 intervenants extérieurs pour présenter leur métier Présentation de vos exposés  Sources principales de ce cours

Vos exposés

    Individuel ou par groupes (2 maximum) Sujet libre (théorique, pratique) mais devant avoir un rapport avec les tests 1 dossier bien formé (20 pages de contenu minimum par personne) Fourniture de 1 ou 2 questions pour l’examen avec réponse   Date de fourniture des dossiers : 15 Mai 2007.

1 présentation oral 20-30 minutes par personne

Examen

 Les notes d’exposés comptent pour 1/3 de la note d’examen  Note d’exposé : 60% dossier / 40% présentation  Je vous indiquerai durant les cours, certaines questions qui pourraient être posées

Plan

   Introduction au test des logiciels    Définitions du test Classes de défaut Difficultés liées au tests  Types de tests vs Techniques de tests Stratégie - Généralités Tests dans le projet  Tests et cycle de vie    Test Unitaires Tests d’intégration Tests de charge  Techniques de test  Introduction     Approche fonctionnelle Approche structurelle Comparaison des approches Efficacité des techniques de tests

Le test ..

 D’après vous…

Quelques Bugs connus

 En 1996 la fusée Ariane 5 explose après 30s de vol   Erreur de conversion entre données numériques!

$500M en matériel + $7B en développement!

Quelques bugs connus

 En 2004 une défaillance du système d’alarme d’une centrale électrique produit une coupure d ’é lectricit é aux Etats-Unis et au Canada  50M de personnes privées d'électricité  $6B perdus!

 En 1992 les ambulances de Londres sont dirigées par un logiciel fautif  Des personnes perdent la vie…

Définition du test

 Erreur, défaut, anomalie  On constate une anomalie  Due à un défaut (on dit aussi une faute (!) ) du logiciel  Défaut du à une erreur du programmeur (ex. : confusion d ’un I avec un 1)

Définition du test « Program testing can be used to show the presence of bugs, but never to show their absence!

»

Edsger Wybe Dijkstra

Définition du test

 Qu’est ce qu’un test réussi ?

 Un test réussi n ’est pas un test qui n ’a pas trouvé de défauts, mais un test qui a effectivement trouvé un défaut (ou une anomalie) G.J. Myers

Définition du test

 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 les différences entre les résultats attendus et les résultats obtenus »

Définition du test

 Selon Bill Hetzel « Le test est une activité destinée à déterminer si l’évaluation d’une caractéristique ou d’une aptitude d’un programme ou d’un système donne les résultats requis. »

Définition du test

 Selon Glendford. J. 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 »

Définition du test

 « Le tests des logiciels » Edition Hermes; « Le test d’un logiciel est une activité qui fait partie du processus de développement. Il est mené selon les règles de l’assurance de la qualité et débute une fois que l’activité de programmation est terminée. Il s’intéresse aussi bien au code source qu’au comportement du logiciel. Son objectif consiste à minimiser les chances d’apparition d’une anomalie avec des moyens automatiques ou manuels qui visent à détecter aussi bien les diverses anomalies possibles que les éventuels défauts qui les provoqueraient ».

Définition du test

 

Est ce que le logiciel fonctionne comme prévu ?

Le test est souvent associé avec les termes

vérification validation

. et  La

validation

est le moyen de confirmer le respect d’exigences déterminées pour une utilisation spécifique prévue. 

Validation

: Faisons-nous le travail attendu ?

 La

Vérification

est l’action de confirmer la satisfaction des exigences spécifiques via l’étude et la mise à disposition de preuves objectives.



Vérification

: Faisons-nous le travail correctement ?

IEEE Standard for software test documentation 1998

Définition du test

 Finalité : fiabilité du logiciel : taux de disponibilité pour les utilisateurs 

MTTR

: Mean Time To Repair. Temps moyen mis pour réparer un système en panne 

MTTF

: Mean Time To Failure. Temps moyen que met un système à tomber en panne. C'est une sorte d'unité de mesure de la faibilité d'un système. 

MTBF

: Mean Time Between Failures. Temps moyen écoulé entre deux pannes, y compris le temps de réparation : MTBF = francisation en « Moyenne des Temps de Bon Fonctionnement » est donc fausse). Voir aussi MTBE . MTTF + MTTR (La 

MTBE

: Mean Time Between Errors. Temps moyen entre deux erreurs 

Taux de disponibilité pour l’utilisateur : MTTF / MTBF

Définition du test

 Tests par l’affirmation (positive testing)  « Le test est une activité destinée à déterminer si l’évaluation d’une caractéristique ou d’une aptitude d’un programme ou d’un système donne les résultats requis. »  Tests par la négation (negative testing)  « Tester c’est exécuter le programme dans l’intention d’y trouver des anomalies ou des défauts »

Définition du test



Le Bug



Tests et débuggage

Jeux de test

DT = {x = 5, y = 5, b = 58} Jeux de test : ensemble de données de test Oracle de test : prédiction du résultat Scénario de test : séquence d ’actions

Définition du test



Définition de classes de d’erreurs



Calcul

    

Logique Entrée / sortie Traitement des données Interface Définition des données

Difficultés du test

 Paramètres rendant le test difficile :     Tests Exhaustif Processus d’introduction des défaut Difficultés d’ordre psychologique ou culturel Difficultés formelles  Autres

Difficultés du test

 Le test exhaustif est difficile à réaliser  Exemple : un logiciel avec 5 paramètres de type byte (8 bits) admet 2^40 valeurs différentes en entrée  Le test est une méthode de vérification partielle de logiciels  La qualité du test dépend de la pertinence du choix des données de test

Difficultés du test

 Processus d’introduction des défaut  Manipulation de données abstraites  Succession de transformations:   Idée « abstraite » et confuse du client Spécifications  Conception Besoin réel    Code source Assemblage, ….

Besoin perçu Besoin modélisé Perte d’informations, introduction d’erreurs, etc.

Difficultés du test

 Difficultés d’ordre psychologique ou culturel  Activité tendant à montrer les erreurs des programmeurs !

 Manque d’intérêt pour ce domaine du génie logiciel

Difficultés du test

 Difficultés formelles  Résultat d’un ensemble de travaux théoriques sur les systèmes formel : « Il ne peut exister aucun algorithme général (donc aucun outil), capable de démontrer l’exactitude totale de n’importe quel programme ».

 Travaux de Kurt Gödel , A. Turing et A Church.

Difficultés du test

• Gödel : 1931 Idée de base : l ’autoréférence

Cette phrase est fausse

. - si elle est vraie, alors ce qu ’elle dit est vraie, i.e. elle est fausse - si elle est fausse, alors elle est vraie

Difficultés du test

• Puis Turing et Church...

• Il existe des algorithmes qu ’on ne peut écrire – Exemple : un algo qui, sans utiliser des fichiers de recopie ou autres artifices, donne comme résultat d ’exécution l ’impression du texte source.

a := 1; b := 2; Il faudrait ajouter writeln (‘ a := 1; ’); writeln (‘ b := 2; ’); Mais comme ces 2 instructions appartiennent aussi au code source, il faut ajouter : writeln(‘ writeln (‘ ‘ a := 1; ’’);); writeln (‘ writeln (‘ ‘ b := 2; ’’););

Difficultés du test

 Autres difficultés  Taille et complexité des programmes  Perturbation / modification du comportement normal du code par l’outillage de test    Distinction environnement de développement et environnement de production Le temps réel L’environnement extérieur

Types de tests vs Techniques de tests



« Tests » : deux axes

 Types de tests  Techniques de tests

Types de tests vs Techniques de tests

 Types de tests   Catégories de tests effectués tout au long de la vie du logiciel.

Tests unitaires, tests d’intégration, tests système, tests de non régression,…  Techniques de tests  Techniques utilisées durant les phases de tests (types de tests)  Techniques fonctionnelles, structurelles , dynamiques, statiques, flots de données, graphes cause-effet, …

Tests Fonctionnels – black box

Tests Structurels – white box

Plan

   Introduction au test des logiciels    Définitions du test Classes de défaut Difficultés liées au tests  Types de tests vs Techniques de tests Stratégie - Généralités Tests dans le projet  Tests et cycle de vie    Test Unitaires Tests d’intégration Tests de charge  Techniques de test   Introduction Approche fonctionnelle    Approche structurelle Comparaison des approches Efficacité des techniques de tests

Stratégie de tests

 50 % ou plus des charges d’un projet  Les tests doivent être conçus avant que le logiciel soit réalisé  Conception du logiciel  Testabilité = exigence clé facilité de test.

Stratégie de tests

 Etapes de conception des tests  Généralistes  détaillées  Une stratégie de test.

 Une planification des tests.

 La conception des dossiers de test.

 L'élaboration d'une procédure de test.

Stratégie de tests

 Une stratégie de test devrait être idéalement une grande organisation à l'image d'une organisation de développement.  Enoncé de l'approche générale du test, en identifiant   Types de tests qui seront effectués pour les différentes étapes du projet et comment ils seront effectués Définition des couvertures de tests.

  Choix des outils Moyens et délais à investir dans l’activité de tests (effort)  Développer une stratégie de test, qui répond efficacement aux besoins d'une organisation, est critique pour assurer le succès du développement des applications. L'application d'une stratégie de test à un projet de développement devrait être détaillée dans le

plan qualité

du projet.

Stratégie de tests

 Rendre l’effort de test efficace  Maximiser les chances de détecter les erreurs  Trouver le plus d’erreurs possibles  Le plus rapidement possible  Faciliter le diagnostique

Stratégie de tests

 Critères d’arrêt des tests   Une fois les jeux de tests passés avec succès (donc pour une couverture définie au préalable) En fonction du nombre d’erreurs trouvées, ou du temps imparti (quid des erreurs qui restent ?)  En fonction du taux marginal de détection (nombre d’erreurs trouvées par rapport au temps)

Stratégie de tests

 Plan de test  Les éléments à tester.

 L’ordre dans lequel ils doivent être testés.

 L’application de "la stratégie de test" au test de chaque élément.

 La description de l'environnement de test.

Stratégie de tests

 L'objectif de chaque plan de test est de fournir un programme pour vérifier, en testant le logiciel produit, que celui-ci satisfait les besoins ou la conception du logiciel. Dans le cas du test de recette et du test système, on fait référence à l'étude des besoins généraux.

Stratégie de tests

 Définition des dossiers de test (scenario)  N dossiers de tests pour chaque élément à tester de chaque niveau de test    Explique comment la mise en place d'un besoin particulier ou d'un choix conceptuel doit être testé et quel est le critère de succès de ce test. Nécessité de concevoir des dossiers de test « positifs » et « négatifs » Peut permettre de trouver des problèmes de conception avant même le début des développements

Stratégie de tests

 Définition des procédures de tests  Processus exact à suivre pour mener à bien chaque dossier  Le niveau de détail doit être tel que la procédure de test est déterministe et répétable

Stratégie de tests

 Documentation des résultats de tests  Nécessité de consigner tous les résultats d’exécution de tests.

 Des

comptes-rendus de test

peuvent être produits à différents moments du processus. Un compte rendu résumera les résultats et documentera toutes les analyses

Stratégie de tests - Conclusion

 Toujours tester en fonction d'une spécification.  Documenter le processus de test  Tester à chaque niveau de spécification. La détection précoce des erreurs réduira finalement les coûts.

 Planifier les activités de test.

Stratégie de tests - Conclusion

 Utiliser les techniques telles d’analyse statique et dynamique.

 Tester positivement, mais aussi négativement  Coupler gestion des tests et gestion des corrections