Introduction

Références pour ces notes:

Livres

  • The Art of software testing, G.J. Myers, Wiley, 2004 (2nde édition) 1979 (1ère édition).
  • Testing object-oriented systems, R.V. Binder, Addison Wesley, 2000.
  • A practical guide to testing OO software, J.D. McGregor, D.A. Sykes, Addison Wesley, 2001.
  • Le test des logiciels, Xanthakis et al., Hermés, 1998
  • Sytematic Black-box Testing, Boris Beizer, Prentice-Hall, 1993
  • Lessons learned in Software Testing, Cem Kaner, James Bach andBrett Pettichord, ?, 200?
  • Un processus pour les Systèmes d'Informations, Pezziardi et al.,Octo Technology, 2006
  • Le test de logiciels, ???, Vuibert, 2003
  • Practical Model-based Testing, M.Utting et B.Legeard,Addison-Wesley, 2007

Sites

Listes de diffusion

Objectif:

Testing is the process of executing a program with the intent of finding errors.

Participe à la validation des programmes:

. Néanmoins ne peut garantir que le programme est exempt d'erreurs:

Pourtant très coûteux !

L'exemple du Triangle

Une version en Ajax du problème du triangle: http://www.testobsessed.com/exercises/triangle.html

Version initiale:

  1. L'utilisateur rentre trois nombres sensés représenter les longueursdes côtés d'un triangle.
  2. Le programme répond en indiquant le type du triangle: scalene,isocèle, équilatéral, rectangle ou erreur

Version objet (Binder):

  1. La classe Triangle est construite avec trois longueurs
  2. Elle dispose de méthodes: isIsocele(), isRectangle(), isScalene()et isEquilateral()

Problème: Donner les cas de test permettant de vérifier et valider le bon fonctionnement de l'application Triangle.  

Terminologie

Distinguer panne et erreur :  

Tester révèle des pannes, déboguer enlève les erreurs à l'origine des pannes et en introduit d'autres, d'où l'importance de tester la non-régression donc de disposer d'un mode d'exécution automatisé des tests.

Un état d'esprit

Quelques évidences, pour la plupart issues du [Myers].

Concernant la forme des cas de test:

Concernant le contenu des cas de test:

Concernant le processus de test:

Enfin: concevoir des cas de tests est (pourvu que le concepteur soit dans le bon état d'esprit)  une activité difficile mais créative et intéressante !  

Différentes approches

L'exécution sur une machine n'est pas la seule manière de tester un programme.

Test statique

Test «par l'humain», sans machine, par lecture du code:

Principes

Inspection

lecture du code accompagnée d'une liste des points à vérifier, par ex:

revue de code

plus complexe :

Test dynamique

Test par l'exécution du système = cas qui nous intéresse.

Schématisation du test dynamique. Il comporte:

Adéquation des tests

Tester complètement (exhaustivement) un logiciel est impossible:

L'adéquation peut se mesurer en termes de couverture, qui se mesure par exemple:

  1. en termes de la proportion de la spécification qui est testée;
  2. en termes de la proportion du code (de l'implantation) qui estsensibilisée par une suite de tests.
  3. en termes de la proportion des domaines de valeurs desdonnées en entrée/sortie

Correspond à deux approches de base pour le test:

  1. test basé sur ce que le logiciel est censé faire: laspécification sert à concevoir l'oracle et les cas detest;
  2. test basé sur ce que fait réellement l'implantation dulogiciel: la spécification sert à concevoir l'oracle, lecode sert à concevoir les cas de test.

Test fonctionnel

Aussi appelé test en boîte noire, ou test basé sur la spécification.

Le Modèle de base est la fonction caractérisant une relation entre des entrées et des sorties.  

Modèle fonctionnel

Tester, c'est sensibiliser le Composant sous Test (Component Under Test d'où CUT), c'est à dire lui fournir des input, et comparer les output réels aux output attendus au moyen d'un oracle

Test structurel

Aussi appelé test en boîte blanche (plus exactement boîte de verre !) ou test basé sur l'implantation:

En pratique :: Combinaison des deux approches, voir la section consacrée aux critères de tests

Triangle magique

Le code, les specs et les tests se vérifient l'un l'autre. Une erreur dans les tests peut avoir trois interprétations différentes :  

Trianglemagique des tests

Tests comme spécification

Lors de la mise en oeuvre du développement dirigé par les tests, ceux-ci peuvent être considérés comme une expression formalisée (exécutable) des spécifications, d'où le raccourci: les tests sont la spécification.  

Problème: les tests (unitaires) sont écrits par le développeur, donc ils ne peuvent être qu'une vision partiale des spécifications du logiciel. Nécessaire de compléter les tests par de la documentation orientée client.  

En fait, l'écriture des tests permet de mesurer la compréhension de la spécification par le testeur. Ce n'est pas la spécification elle-même qui est généralement inaccessible (dans l'empyrée des Idées).  

Le test dans le cycle de développement

Cycle en V

Modèle de développement normalisé par la RFA, nouvelle norme V-modell XT (2004). Le principe est d'associer une activité de vérification (test) à chaque phase du cycle de développement du logiciel.

Schématiquement :  


   Exigences   ---------
      \                 \
       \                 ---------- Recette 
     Spéc.                          /
   fonctionnelles-------           /
        \               \         /
         \                ------ Test système
      Architecture ---         /
         \            \       /
          \            -----  Test intégration
       Conception  --        /
          \          \      /
           \           --- Test unitaire
            \              / 
            +------+      /
            | Code |_____/
            +------+

Voir  B.Marick  pour une critique du modèle en V

Ce modèle offre une classification commode des différentes granularités auxquelles s'applique le test. Attention à la rigidité du modèle de développement.

Test unitaire

Test d'intégration

Test système

Sur une application complètement intégrée ds son environnement.

Et aussi...

Test de recette

Ou test d'acceptation, (ou User Acceptance Testing, ou  simplement recette) : effectué avec l'utilisateur final pour valider le système produit par rapport aux exigences, pour obtenir son approbation avant la livraison.  

Le modèle W

http://www.gerrardconsulting.com/default.asp?page=services/wmodel.html

Raffinement du modèle V pour mettre en avant les différentes activités de test et de vérification des artefacts produits pour le logiciel aux différentes étapes du cycle de développement.  

Le V principal est dupliqué par un autre V représentant les différentes activités de V&V ayant lieu au cours du développement:

La branche gauche du W lie à chaque activité de conception des activités d'analyse ou de "test statique":

La branche droite du W lie à chaque activité de construction d'une partie du logiciel final (unité, composant, sous-système, système) une activité de "test dynamique":

Le modèle Agile

Les méthodes Agiles (Extreme Programming essentiellement) utilisent le test comme moteur du processus de développement afin de:

Ce qui implique de:

Résultat: Développement Dirigé par les Tests (Test Driven Development) ou TDD

Tests unitaires et TDD

Technique de développement/conception (les deux sont synonymes en XP)

Principe:

  1. Ecrire un test
  2. S'assurer qu'il échoue
  3. Ecrire le code minimal permettant de réussir le test
  4. S'assurer qu'il réussit
  5. Réusiner (refactor) le code pour supprimer les doublons etaméliorer sa testabilité

Mantra:

Intérêt:  

Autres tests

Ce même principe est appliqué à tous les types de tests:

Comparaisons

Attention, cette comparaison est biaisée en faveur des modèles Agiles

Le coût de correction d'une erreur croît de manière exponentielleen fonction de l'interval de temps séparant la production del'erreur de sa manifestation sous forme d'une panne

B.Boehm, référence ??

Plus les tests sont réalisés/exécutés tôt, plus les erreurs qu'ils sont susceptibles de détecter seront révélées tôt, donc moins elles coûteront cher.  

Réduire les cycles de développement: analyse-conception-réalisation-test pour détecter au plus tôt les erreurs, omissions, incompréhensions, et réagir au changement dans les meilleurs délais.  

Le test dynamique

Définitions officielles: IEEE (Standard Glossary of Software Engineering Terminology).

Qu'est-ce qu'effectuer un test (dynamique) ?

  • déterminer un objectif de test: la propriété à tester;
  • choisir une donnée de test: au sens large des valeurs pour lesentrées qui permettent d'amener le programme (l'IUT) dans unétat propice à la vérification de l'objectif(positionnement de ses variables d'états);
  • écrire un cas de test: un programme qui amène l'IUT dans cet étatpropice et effectue le test;
  • stocker le cas de test ainsi que le résultat attendu: les deuxdoivent être conservés pour pouvoir rejouer les tests;
  • exécuter ce cas de test;
  • observer et enregistrer les résultats;
  • les comparer avec les résultats attendus

Qu'est-ce que tester dynamiquement ?

  • Exécuter sur l'IUT une suite de tests;
  • Corriger les erreurs révélées par les tests;
  • Relancer la suite de tests sur la nouvelle version de l'IUT;
  • Évaluer le critère d'arrêt/de couverture;
  • Compléter la suite de test si besoin;
  • On obtient une version de référence (baseline version);
  • Relancer cette suite lors des tests de régression, et dès quebesoin de comparaison avec la version de référence.

besoin d'automatisation du test.

Terminologie

qui teste-t-on ? :: une implantation du système: IUT = Implementation Under Test ou encore SUT = System Under Test

que teste-t-on ? :: une propriété/caractéristique à vérifier: l'objectif de test;

donnée de test :: valeurs spécifiques pour les entrées du programme et pour la simulation de l'environnement (peuvent servir pour plusieurs cas de test);

jeu de test ::  ensemble de données de test;

cas de test ::  test élémentaire associé à une donnée de test pour un objectif de test donné. Il contient souvent:

  • un préambule qui mène l'IUT dans une configuration particulière à la donnée de test;
  • un corps de test qui permet de vérifier l'objectif de test;
  • un postambule qui ramène par ex l'IUT ds un état permettant d'enchaîner un autre test;
  • le résultat attendu;
  • le résultat attendu inclut les sorties, le post-état del'IUT, les exceptions levées, les messages générés;

suite de test ::  un ensemble de cas de test rassemblés suivant un critère donné (ex: tests de toutes les méthodes d'une classe);  

critère d'arrêt ::  critère permettant d'évaluer si la confiance apportée par les tests effectués est suffisante;  stratégie de test ou critère de sélection: algorithme pour créer des cas de test;

critère d'adéquation ::  détermine a posteriori si un cas de test est intéressant, cf test par mutation;

  • un test réussit (passes) si les résultats obtenus sont lesrésultats attendue, sinon il échoue (fails);
  • en cas d'échec, l'IUT contient une faute (un bout de codeincorrect), causée par une erreur humaine.

Automatisation  des test unitaires

Source: xUnit Patterns, Gerald Meszaros, Addison-Wesley, 2007, pp.19-30

Motivation économique: le coût initial d'apprentissage, puis les coûts de construction et maintenance des tests sont justifiés par des gains lors du développement.  

Objectifs

Amélioration de la qualité

Les tests sont des spécifications exécutables:  

  • applicable surtout au TDD: un outil pour comprendre et détailler lefonctionnement de l'application
  • attention: ce n'est vrai que si les tests fournissent une bonnecouverture du comportement attendu (ie. de la spécification), cequi suppose des tests  manuels et une compréhensions du problème

Les tests automatisés ne détectent pas de pannes, ils servent à les prévenir ! Par contre, ils permettent éventuellement de localiser plus rapidement les défauts à l'origine des pannes, en étant précis et localisés.  

Compréhension du SUT

Les tests documentent le code, ce qu'il est sensé faire.

Ils permettent de limiter les risques, en les identifiant au plus tôt et en les levant.

Ils constituent un filet de sécurité pour les développeurs:

Les tests ne doivent pas augmenter les risques: ils doivent être simples, immediats, et tester effectivement le code (attention à l'abus de doubles).

Facilité d'exécution

Les tests doivent pouvoir être exécuté très fréquemment:

Facilité d'écriture

Les tests doivent être simples à lire et à écrire, et éviter la duplication, le recouvrement dans les comportements qu'ils testent.  

Limiter la maintenance

Les tests doivent être robustes: