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.

Slides:



Advertisements
Présentations similaires
Mustapha EL FEDDI Tests Mustapha EL FEDDI
Advertisements

EPITECH 2009 UML EPITECH 2009
Applications N-Tiers Rappels: architecture et méthodologie
Mathilde VINCENT - Olivier JOURDAN Paris - le 7/2/2012
1 Modéliser Ou comment RE-présenter sa connaissance.
La Gestion de la Configuration
Plate-forme Magicien d’Oz
Systèmes en temps réel Modélisation du comportement en temps réel avec UML.
Quelles sont les composantes principales d ’une activité de formation?
XML - Henry Boccon-Gibod 1 XML, Langage de description La question du choix de formalismes Les entités et leur représentations modalités de modèles et.
Les tests et les logiciels de gestion de tests
Organiser des Tests dans un projet
Test de logiciel GLG101 AP.TELLE & S.MILOVANOVIC MAI 2007.
Tests et Validation du logiciel
Rational Unified Process (RUP)
Modélisation orientée objet UML
Langage SysML.
La revue de projet.
Validation de logiciel
MIAGE MASTER 1 Cours de gestion de projet
Démarche Analyse des OGL et des Méthodes Objectifs : Activités :
Méthodes symboliques pour la génération de tests de systèmes réactifs comportant des données Eléna Zinovieva Leroux novembre 2004 Membres du jury:
Les Cas d’utilisation.
Analyse et Conception des Systèmes d’Informations
Cours #8 Flot de conception d’un circuit numérique
SÉMINAIRE DE LANCEMENT DES COURS EN LIGNE
IFT1025, Programmation 2 Jian-Yun Nie
Modèle, Méthode et Conception
Techniques de test Boulanger Jean-Louis.
TDD : avec ou sans Mocks ? Par Anthony Dahanne, Yannick Ameur,
IGL301 - Spécification et vérification des exgiences 1 Chapitre 1 Introduction (ref : Bray chapitre 1)
IGL301 - Spécification et vérification des exgiences 1 Chapitre 2 Le processus dingénierie des exigences (ref : Bray chapitre 2)
Unified Modeling Langage
P. Van Roy, LINF1251 LINF1251: Le Langage Java Peter Van Roy Département dIngénierie Informatique, UCL
Présentation du mémoire
© Petko ValtchevUniversité de Montréal Janvier IFT 2251 Génie Logiciel Notions de Base Hiver 2002 Petko Valtchev.
Tolerance Manager Un concept métier
Démarche de développement
Outils de test fonctionnel et non fonctionnel
99 Réutilisation du code grâce à l'héritage. 9-2 Objectifs À la fin de ce cours, vous serez capables de : Définir l'héritage Utiliser l'héritage pour.
Sensibilisation a la modelisation
Introduction Un test sur les tests Ce que n’est pas le test
Test logiciel Xavier Baril.
Outil de volumétrie pour Quadrige² 20 mars 2009 – O. CatryDUT Informatique.
Banc d’essai pour un circuit combinatoire
Supports de formation au SQ Unifié
Réalisé par : Mr IRZIM Hédi Mr JRAD Firas
GENIE LOGICIEL
Vérification dans le cycle de vie GEF492A 2014 Référence: [HvV §14.2, 14.9] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et.
1 Emeric ROLLIN 1 Génie Logiciel GENIE LOGICIEL
Introduction au Génie Logiciel
Les outils de la vérification statiquedynamique unitaires intégration vérificateur de syntaxe vérificateur de syntaxe étenduABAP débogueur inspecteur de.
BEWITCHED 12/10/2006 Soutenance GLAO #5 slide 1 Soutenance GLAO #5 AGL & SYGIME Bewitched Team 12 Octobre 2006.
Initiation à la conception des systèmes d'informations
1 Emeric ROLLIN 1 Génie Logiciel GENIE LOGICIEL
Présentation AICHA REVEL INGENIEUR D’ÉTUDE STERIA DEPARTEMENT TRD
MOCK.
Power AMC-Rational Rational Rose, Étude comparative
Année 2006 – 2007 ENSEA © Emeric Rollin
La programmation par objets Principes et concepts Etude de Smalltalk.
INF3500 : Conception et implémentation de systèmes numériques Pierre Langlois Flot de conception de.
L’enseignement de spécialité SLAM
Chapitre 2 Rappels objet et Présentation des diagrammes UML
Chapitre 2 Rappels objet et Présentation des diagrammes UML
Thème 4 : Les éléments naturels. Cours 2 : L’eau dans la nature et chez les êtres vivants. Mathématiques Guide du Maître Thème 4 : Géométrie. Cours 2 :
TP D’UML Groupe N° 3.
INTRODUCTION AUX BASES DE DONNEES
Document de spécification d’exigences Normes IEEE et 29148:2011
PRÉSENTATION AGL LES TESTS LOGICIELS LES TEST LOGICIELS 1 Mickael BETTINELLI Brandon OZIOL Gaétan PHILIPPE Simon LUAIRE.
Jenkins, votre serviteur C. Loomis (CNRS/LAL) Journée LoOPS 11 décembre 2012.
Transcription de la présentation:

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

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 Rappels du cours de l ’année dernière Comparaison proc/ objet Objet avec exemple Médiathèque

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

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 Exemple plus tard 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 1) Test = exécution => préparation des tests de validation au moment de la spécification

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

Quand « tester » ? Ressources pour corriger les fautes 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?)? User Java? UML? System ?? verification Validation

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

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

Types de tests Tests fonctionnels Tests structurels Tests de (non) régression Tests de robustesse Tests de performance Fonctionnels = boite noire Structurels = boite blanche

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 Hypothèse : écran 1024x768 2,37 1035 possibilités Quest: % valid?

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; } Itérations Nb Chemins 1 3 2 5 9 10 1025 20 1048577 60 >1,15 1018

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 Itérations Nb Chemins 1 3 2 5 9 10 1025 20 1048577 60 >1,15 1018 3 Chemins a tester

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 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 est 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 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 E1 S2 E2 V V S3 E3 S1 E4

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

Table de décision E1 1 X E2 E3 E4 S1 S2 S3 X E2 E3 E4 S1 S2 S3 Expliquer les entrées/ sorties

Table de décision: incoherence 1 X E2 E3 E4 S1 S2 S3 Expliquer les entrées/ sorties

Table de décision: redundancy 1 X E2 E3 E4 S1 S2 S3 Expliquer les entrées/ sorties

Table de décision: incomplete 1 ? E1 1 X E2 E3 E4 S1 S2 S3 Expliquer les entrées/ sorties

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

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

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 ci-dessus, 32 sont dûs à la programmation objet)

FIGURE FERMEE OUVERTE SEGMENT POLYGONE ELLIPSE MULTI-SEG CERCLE TRIANGLE QUADRILATERE ….. ….. Hierarchie dépendances

TRIANGLE SEGMENT POINT

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?

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 Type de document : Livre = 6 semaines CD audio = 4 semaines K7 vidéo = 2 semaines Type de client : Tarif normal = 100% Tarif réduit = 50% Abonné = 200% 1 – 9 tests 2 – fiche d’emprunt règle le problème 3 – destruction de la fiche d’emprunt (en java destruction de toute référence à la fiche)

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 Existence LettreRappel par FicheEmprunt. Pas de lettre de rappel, fiche emprunt existe tout de meme.

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

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 1et 2 : Constructeur FicheEmprunt() 3 :

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. Classe détaillée Utilisation d’un bouchon (stub)

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

FicheEmprunt

FicheEmprunt Test de validation (traçage) Création 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) Visu

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

FicheEmprunt

FicheEmprunt Tester la chronologie des actions dn = document.dureeEmprunt() dateLimite = client.dateRetour(dateEmprunt, dn) document.emprunter () Client.emprunter () tn =document.tarifEmprunt() Tarif = client.sommeDue(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ébutCas 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 = 4I +J; cas (J + 1) < I et I >= 0 et I /= 5 alors M = 5I + 2 cas (J + 1) >= I et J < 2 alors M = 2I + 3J - 4; cas (J + 1) >= I et J>= 2 et I /= 5 alors M = 3I +2J –2; finCas écrire M; lire I,J; si I <= J + 1 alors K = I + J -1 sinon K = 2I + 1 finsi si K >= I+1 alors L = I + 1 sinon L = J - 1 si I = 5 alors M = 2L + K sinon M = L + 2K - 1 é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.