J. Paul Gibson paul.gibson@it-sudparis.eu www-public.it-sudparis.eu/~gibson/

1. J. Paul Gibson paul.gibson@it-sudparis.eu http://www-public.it-sudparis.eu/~gibson/ Bureau A 207, Le département LOgiciels-Réseaux http://www-public.it-sudparis.eu/~gibson/Teaching/IO21-OOTests2008Fr.ppt http://www-public.it-sudparis.eu/~gibson/Teaching/IO21-OOTests2008Fr.pdf

2. Les tests en orienté objet • Procédural vs Objet • Le test en Orienté Objet • Niveaux de tests • Tests de validation / use cases • Tests d’intégration • Tests unitaires Rappels Définitions Pourquoi tester ? Quand tester ? Niveaux de test Types de test Les limites du test Les techniques du test

3. Définition IEEE-STD 610.12-1990 • "Le test est l'exécution 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 observés" Questions: peut-on tester sans – spécifications/ résultats attendus l'exécution d'un système ou d'un composant

4. Cas de test (jeu) • Un cas de test spécifie • L’état de l’implantation sous test (IUT) et de son environnement avant le test • Le vecteur des entrées et/ou les conditions • Le résultat attendu • messages, exceptions • valeurs retournées • état résultant de l’IUT et de son environnement Implementation Under Test (IUT) System Under Test (SUT)

5. Pourquoi tester? • Fonctionnalités manquantes • Fonctionnalités incorrectes • Effets de bord, interactions indésirables • Mauvaises performances, pbs temps réel, deadlock… • Sorties incorrectes

6. Quand « tester » ? Resources pour corriger les fautes Ni trop tot ni trop tard 100 50 20 10 5 1 Spécification Conception Codage Tests Validation Maintenance

7. Ressources pour corriger les fautes Quand « tester » ? Ni trop tot ni trop tard 100 50 20 10 5 1 Spécification Conception Codage Tests Validation Maintenance Exigences Spec Concept Codage Tests System Texte et/ou Modeles (UML?)? Java? User System UML? ?? verification Validation

8. Niveaux de test • Tests de validation • Tests d’intégration • Tests unitaires Préparat ion exécution

9. Niveaux de test- chaque (sub)system Préparat ion exécution • Tests de validation • Tests d’intégration • Tests unitaire System Subsystem

10. Types de tests • Tests fonctionnels • Tests structurels • Tests de (non) régression • Tests de robustesse • Tests de performance

11. Les limites du test • L’espace des entrées • Les séquences d’exécution • Sensibilité aux fautes

12. Explosion combinatoireEX : dessiner 1 triangle • Hypothèse : Coordonnées [1..10] • 104 possibilités de dessiner 1 ligne • 1012 possibilités de dessiner 3 lignes • Hypothèse : écran 1024x768 • 2,37 1035 possibilités Quest: % valid?

13. Les séquences d’exécution for (int i=0; i<n; ++i) { if (a.get(i) ==b.get(i)) x[i] = x[i] + 100; else x[i] = x[i] /2; }

14. Les séquences d’exécution (n=1) for (int i=0; i<n; ++i) { if (a.get(i) ==b.get(i)) x[i] = x[i] + 100; else x[i] = x[i] /2; } i<n if +100 /2 ++i 3 Chemins a tester

15. Les séquences d’exécution

16. Sensibilité aux fautes short scale(short j) { j = j -1; // devrait être j = j+1 j = j/30000; return j; }

17. Sensibilité aux fautes • 65536 valeurs possibles • 6 rendent une valeur incorrecte : -32768 -30000 -29999 29999 30000 32767 • 99,9908 % de risque de ne pas trouver l’erreur si test aléatoire.

18. Autres limitations • Tester un programme permet de montrer la présence de fautes mais en aucun cas leur absence • Les tests basés sur une implémentation ne peut révéler des omissions car le code manquant ne peut pas être testé • On ne peut jamais être sûr qu’un système de test est correct

19. Techniques de test • Classes d’équivalence (éviter l’explosion combinatoire) • Graphe de cause à effet (identifier et analyser les relations devant être modélisées dans une table de décision) • Tables de décision (concevoir des cas de test)

20. 8 Classes valides triangle scalèle triangle isocèle équilatéral 25 Classes invalides 1 valeur = 0 3 valeurs = 0 1 valeur négative triangle isocèle plat 3 valeurs telles que la somme de 2 d’entre elles < à la 3ème 1 valeur non numérique 1 valeur manquante triangle scalène plat 1 valeur max Classes d’équivalence

22. Table de décision

24. Simplification: Precondition a<=b<=c Not a triangle: c>=b+a

25. Principe : représenter la spécification sous forme d’un graphe On définit les états d’entrées et les états de sorties On construit le graphe à l’aide de “connecteurs” logiques (et, ou, négation) Exemple : soit la spécification suivante: Tout identificateur de voiture doit commencer par les lettres A, B ou C et avoir comme 2ème caractère la lettre X. Les messages M1 et M2 sont émis respectivement en cas d’erreur sur le premier ou le second caractère. Si l’identificateur est correct, il est inséré dans la base de données. Graphe de cause à effet

26. Graphe de cause à effet E1 S2 E2 V V S3 E3 S1 E4

27. Graphe de cause à effet A B C X message M1 E1 S2 E2 inséré dans la base de données V V S3 E3 message M2 S1 E4

28. Table de décision

29. Table de décision: incoherence

30. Table de décision: redundancy

31. Table de décision: incomplete 0 1 0 1 ? ? ?

32. X X X ECRIRE BD ECRIRE BD ECRIRE BD [1er CARACTERE == B] [1er CARACTERE == C] [1er CARACTERE == A] X X X MESSAGE M2 MESSAGE M2 MESSAGE M2 MESSAGE M1 Diagramme d’activité [1er CARACTERE ! = ….]

33. X X X ECRIRE BD ECRIRE BD ECRIRE BD [1er CARACTERE == B] [1er CARACTERE == A] [1er CARACTERE == C] X X X MESSAGE M2 MESSAGE M2 MESSAGE M2 MESSAGE M1 Diagramme d’activité [1er CARACTERE ! = ….] X 2eme Interpretation? X MessageM2

34. Orienté Objet – (UML) • Niveau Application (spécification) • Diagramme des cas d’utilisation (Use cases) • Niveau Sous-Système (conception) • Diagramme des classes (ébauche) • Diagrammes de séquence • Diagrammes de transitions d’états • Niveau Classes (conception détaillée) • Classes détaillées

35. Comparaison – effort de test (1) • Lire 3 valeurs entières. • Ces trois valeurs sont interprétées comme représentant les longueurs des côtés d’un triangle. • Le programme imprime un message qui établit que le triangle est isocèle, équilatéral ou scalène.

36. Comparaison – effort de test (2) • Programmation procédurale • 33 cas de tests • Programmation objet • 58 cas de tests (26 sont les mêmes que ci-dessus, 32 sont dûs à la programmation objet)

37. SEGMENT TRIANGLE FIGURE FERMEE OUVERTE POLYGONE ELLIPSE MULTI-SEG CERCLE QUADRILATERE ….. …..

38. TRIANGLE SEGMENT POINT

39. Le test en orienté objet OO vs Non OO • System tests - use cases • Integration tests - class, sequence, interaction • Unit tests - class/methods • Regression tests - inheritance? • Automated testing - re-use? • UML - comment utiliser pour tester?

41. Tests de validation • Trouver les emprunts en retard • Tester le délai autorisé (fonction du type de client et du type de document) - 9 cas de test • Tester qu’un client peut avoir plusieurs documents en retard • Tester que la fiche d’emprunt est supprimée lorsque le document est rendu

42. Le test en orienté objet • Au niveau sous-système • test des associations, des agrégations (diagramme de classes) • multiplicité • création, destruction • test de séquences (diagramme de séquence) • construction d’un graphe de flot • test des exceptions controlées

43. Diagramme de classes

44. Triangle Segment Mediatheque Document LettreRappel FicheEmprunt Niveau Sous-Système 0..1

45. Classe FicheEmprunt • Multiplicité • tester qu’une fiche d’emprunt ne concerne qu’un et un seul client et qu’un et un seul document • tester qu’une fiche d’emprunt ne peut référencer qu’au plus une lettre de rappel. • tester que plusieurs fiches d’emprunts peuvent concerner un même client

46. Classe FicheEmprunt • Création • Test de validation (raffinement) • tester que dateLimite -DateEmprunt = délai autorisé • (Test unitaire) • tester que si dateLimite dépassée alors depasse = true.

47. Le test en orienté objet • Tests d’intégration (diagramme de classes => arbre des dépendances) • Techniques • big-bang • bottom-up • top-down

48. FicheEmprunt

49. FicheEmprunt • Test de validation (traçage) • Tester que la fiche d’emprunt est supprimée lorsque le document est rendu • Création • Tester que depasse = false • Tests de transition d’états • Tester que dateJour>dateLimite alors depasse = true (raffinement du test unitaire correspondant)

50. FicheEmprunt • Tester les actions liées aux états et aux transitions d ’états.