J Paul Gibson paul gibson it-sudparis eu http www-public

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/IO 21 -OOTests 2008 Fr. ppt http: //www-public. it-sudparis. eu/~gibson/Teaching/IO 21 -OOTests 2008 Fr. pdf

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

Définition IEEE-STD 610. 12 -1990 • "Le test 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

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)

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

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

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

Niveaux de test • Tests de validation • Tests d’intégration • Tests unitaires P r é p a r a t i o n e x é c u t i o n

Niveaux de test- chaque (sub)system • Tests de validation • Tests d’intégration • Tests unitaire System Subsystem P r é p a r a t i o n e x é c u t i o n

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

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

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

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; }

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 ++i 3 Chemins a tester /2

Les séquences d’exécution

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

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

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 correct

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)

Classes d’équivalence • 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

Table de décision

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

Graphe de cause à effet • 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 M 1 et M 2 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 E 1 S 2 E 2 V V S 3 E 4 S 1

Graphe de cause à effet E 1 B E 2 S 2 V C E 4 S 3 E 3 X V A S 1 message M 1 inséré dans la base de données message M 2

Table de décision E 1 1 0 0 0 X E 2 0 1 0 0 X E 3 0 0 1 0 X E 4 1 1 1 X 0 S 1 0 0 1 S 2 0 0 0 1 0 S 3 1 1 1 0 0

Table de décision: incoherence E 1 1 0 0 0 X E 2 0 1 0 0 X E 3 0 0 1 0 X E 4 1 0 1 X 0 S 1 0 0 1 S 2 0 0 0 1 0 S 3 1 1 1 0 0

Table de décision: redundancy E 1 1 0 0 0 X E 2 0 1 0 0 X E 3 0 0 1 0 X E 4 1 0 1 X 0 S 1 0 0 1 S 2 0 0 0 1 0 S 3 1 0 0

Table de décision: incomplete E 1 1 0 0 0 X 0 E 2 0 1 0 0 X 1 E 3 0 0 1 0 X 0 E 4 1 0 1 X 0 1 S 1 0 0 1 ? S 2 0 0 0 1 0 ? S 3 1 0 0 ?

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

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

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

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.

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

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

TRIANGLE SEGMENT POINT

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

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

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

Diagramme de classes

Niveau Sous-Système Mediatheque Lettre. Rappel Triangle Document Segment Fiche. Emprunt 0. . 1

Classe Fiche. Emprunt • 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

Classe Fiche. Emprunt • Création • Test de validation (raffinement) – tester que date. Limite -Date. Emprunt = délai autorisé • (Test unitaire) – tester que si date. Limite dépassée alors depasse = true.

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

Fiche. Emprunt

Fiche. Emprunt • 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 date. Jour>date. Limite alors depasse = true (raffinement du test unitaire correspondant)

Fiche. Emprunt • Tester les actions liées aux états et aux transitions d ’états.

Fiche. Emprunt

Fiche. Emprunt • Tester la chronologie des actions – dn = document. duree. Emprunt() – date. Limite = client. date. Retour(date. Emprunt, dn) – document. emprunter () – Client. emprunter () – tn =document. tarif. Emprunt() – Tarif = client. somme. Due(tn)

Le test en orienté objet • Au niveau de la classe – test des méthodes • “concevoir pour tester” • graphe de contrôle – test des séquences d’activation des méthodes • diagramme de transition d’états – test des méthodes héritées • diagramme de classes

Concevoir pour Tester lire I, J; début. Cas cas I = 5 et J < 4 alors M = 23; cas I = 5 et J >= 4 alors M = J + 16; cas (J + 1) < I et I<0 alors M = 4 I +J; cas (J + 1) < I et I >= 0 et I /= 5 alors M = 5 I + 2 cas (J + 1) >= I et J < 2 alors M = 2 I + 3 J - 4; cas (J + 1) >= I et J>= 2 et I /= 5 alors M = 3 I +2 J – 2; fin. Cas écrire M; lire I, J; si I <= J + 1 alors K = I + J -1 sinon K = 2 I + 1 finsi si K >= I+1 alors L = I + 1 sinon L = J - 1 finsi si I = 5 alors M = 2 L + K sinon M = L + 2 K - 1 finsi écrire M;

Le test en orienté objet • L’interaction de méthodes (individuellement correctes) de classes et sous-classes peut générer des erreurs. => Ces interactions doivent être systématiquement exercées.

Le test en orienté objet • Omettre de tester les interactions d’une méthode redéfinie dans la hierarchie de classe est facile. => Les suites de tests conçues pour les superclasses doivent être réexécutées sur les sous-classes et conçues de façon à pouvoir être réutilisés pour tester n’importe quelle sous-classe

Le test en orienté objet • La difficulté et la complexité d’implémentation des contraintes de multiplicité peut facilement conduire à des erreurs quand un élément est ajouté, mis à jour, supprimé. => L’implémentation de la multiplicité doit être systématiquement exercée.

Le test en orienté objet • Des classes avec des contraintes séquencielles sur l’activation des méthodes et leurs clients peuvent avoir des erreurs de séquencement. => Le comportement requis doit être testé en utilisant un modèle de machine à états.