Tests Logiciels (INF4000) PDF

INF4000 Génie Logiciel Tests Logiciels A M I NA TA ZERBO/SA BA NE  Tests Logiciels INF4000-GL (UO1/SEA/DI/SITR) 2 Dr. A. SABANE  Plan üIntroduction üTests Structurels üTests Boite Noire 3...

INF4000 Génie Logiciel Tests Logiciels A M I NA TA ZERBO/SA BA NE  Tests Logiciels INF4000-GL (UO1/SEA/DI/SITR) 2 Dr. A. SABANE  Plan üIntroduction üTests Structurels üTests Boite Noire 3 3 Tests Logiciels : Tests Boite Noire 4 4  Plan üIntroduction üPartitionnement en classes d’équivalence üAnalyse de la valeur limite üAutres Tests 5 5 Tests Boite Noire Introduction  Principes de Base Basés sur la définition de ce qu’est la spécification d’un programme en opposition à sa structure : ◦ On considère le logiciel comme une boite noire du point de vue de ses entrées/sorties; la structure interne (i.e., l’implémentation) n’est pas prise en compte ◦ Les cas de tests sont conçus à partir d'une spécification (i.e., sans tenir compte du code même si celui-ci est disponible) 7 7  Principes de Base Le niveau de rigueur (et de détail) des spécifications est particulièrement important et influe sur la facilité à catégoriser les données d’entrées et anticiper les sorties : è la génération des cas de tests et des oracles 8 8  Tests Intuitifs (ou ad-hoc) Exemple : Un module accepte une donnée d'entrée qui a pour domaine les nombres entiers entre 1 et 100 inclusivement. Quelles valeurs choisir pour le test de ce module? 9 9  Tests Intuitifs (ou ad-hoc) Exemple : Un module accepte une donnée d'entrée dont le domaine de validité est constitué des nombres entiers entre 1 et 100 inclusivement ◦ Le testeur choisit (intuitivement) les valeurs 55, 24 et 6 pour ses tests Préoccupations 1. Ces trois valeurs sont-elles suffisantes pour démontrer que le module répond à ses spécifications? 2. Devrait-on utiliser plus (ou moins) de valeurs pour faire une utilisation optimale des ressources ? 10 10  Tests Intuitifs (ou ad-hoc) Exemple : Un module accepte une donnée d'entrée dont le domaine de validité est constitué des nombres entiers entre 1 et 100 inclusivement ◦ Le testeur choisit (intuitivement) les valeurs 55, 24 et 6 pour ses tests Préoccupations 3. Est-ce qu'il y a d'autres valeurs plus susceptibles de révéler des défauts? 4. Devrait-on utiliser des valeurs de test à l'extérieur du domaine de validité (i.e., pas un entier, zéro, négatif, >100,...) ? 11 11  Tests Intuitifs (ou ad-hoc) Principal avantage: génération rapide des données d'entrée Principal inconvénient: peu susceptible de mener à des données de tests "efficaces" (i.e., à haute probabilité de révéler des défauts). Les tests intuitifs ne sont pas fiables 12 12  Partitionnement en classes d’équivalence  Tests par Partitionnement en Classes d’Equivalence Motivation : Obtenir un jeu de test complet et éviter la redondance Classe d’équivalence : Ensemble d’entrées aboutissant au même comportement fonctionnel de l’ensemble des données Stratégie : Découper le domaine d’entrées en classes d’équivalence Division du domaine d’entrées en classes valides et invalides 14 14  Tests par Partitionnement en Classes d’Equivalence Domaine d’entrées entièrement couvert ◦ un jeu de test complet Cas de tests : Choix d’un représentant dans chacune des classes d’équivalence ◦ évite la redondance ◦ Permet au testeur de passer d’un nombre infini de données à un nombre fini et limité de données de test 15 15  Tests par Partitionnement en Classes d’Equivalence Existence de règles générales de découpage (non uniques) ◦ Entier : a ≤ 0, a> 0 ou a0 ◦ Intervalle : ∅, [a,b] où a < b < ∞, [-∞,+∞] ◦ Ensemble : ∅, {a}, {a,b}, {a,b,c},... Les classes d’équivalence doivent être choisies prudemment Il est nécessaire de comprendre le comportement du système à tester 16 16  Weak Equivalence Class Test - WECT Partitionnement unidimensionnel (Weak Equivalence Class Test - WECT) Considérer une variable à la fois. Ainsi, chaque variable d’entrée du programme conduit à une partition du domaine d’entrée Ce type de partitionnement est le plus utilisé et le plus simple à mettre en œuvre ◦ Néanmoins, il n’exerce pas certaines combinaisons pouvant conduire à détecter des fautes 17 17  Strong Equivalence Class Test - SECT Tests par partitionnement multidimensionnel (Strong Equivalence Class Test - SECT) Considérer le domaine d’entrées comme le produit cartésien des domaines de chaque variable d’entrée ◦ Grand nombre de cas de test, difficiles à gérer manuellement ◦ Cependant, bien que certaines classes créées puissent être invalides, cette méthode offre une grande variété de cas de test 18 18  Nombre de Cas Test - WECT Trois variables d’entrée de domaines A, B, C A se subdivise en 3 classes d’équivalence, B en 4 et C en 2 ◦ A = A1 u A2 u A3 où an in An ◦ B = B1 u B2 u B3 u B4 où bn in Bn ◦ C = C1 u C2 où cn in Cn Test par classes d’équivalence faibles (WECT) : Pour chaque variable, choisir un représentant par classe d’équivalence Le nombre de cas de test est donc max(|A|, |B|, |C|) 19 19 Nombre de Cas Test - WECT Cas de test WECT Cas de test A B C WE1 A1 B1 C1 WE2 A2 B2 C2 WE3 A3 B3 C1 WE4 A1 B4 C2 20 20  Nombre de Cas Test - SECT Trois variables d’entrée de domaines A, B, C : ◦ A = A1 u A2 u A3 où an in An ◦ B = B1 u B2 u B3 u B4 où bn in Bn ◦ C = C1 u C2 où cn in Cn ` Test par classes d’équivalence fortes (SECT) : basé sur le produit Cartésien des sous-ensembles des partitions (A x B x C), i.e., tester toutes les interactions de classes Le nombre de cas de tests est donc |A| x |B| x |C| 21 21  Nombre de Cas Test - SECT Cas de Test A B C SE1 A1 B1 C1 Cas de test SE2 SE3 A1 A1 B1 B2 C2 C1 SECT : 3*4*2 SE4 A1 B2 C2 SE5 A1 B3 C1 SE6 A1 B3 C2 SE7 A1 B4 C1 SE8 A1 B4 C2 SE9 A2 B1 C1 SE10 A2 B1 C2 SE11 A2 B2 C1 SE12 A2 B2 C2 SE13 A2 B3 C1 SE14 A2 B3 C2 SE15 A2 B4 C1 SE16 A2 B4 C2 SE17 A3 B1 C1 SE18 A3 B1 C2 SE19 A3 B2 C1 SE20 A3 B2 C2 SE21 A3 B3 C1 SE22 A3 B3 C2 SE23 A3 B4 C1 SE24 A3 B4 C2 22 22  Valeurs Invalides Deux autres critères permettent d’intégrer le test des valeurs invalides et de rendre les tests plus robustes ◦ Tests par partitionnement unidimensionnel ou Tests par classes d’équivalence faibles robustes (WRECT) ◦ Tests par partitionnement multidimensionnel ou tests par classes d’équivalence fortes robustes (SRECT) 23 23  Tests par Classes d’Equivalence Faibles Robustes (WRECT) ◦ Pour chaque variable, choisir un représentant par classe d’équivalence valide ◦ Utiliser un élément d’une classe d’équivalence invalide à la fois pour un cas de test, i.e., toutes les autres classes d’équivalence sont valides dans le cas de test 24 24  Test par Classes d’équivalence Fortes Robustes (SRECT) Basé sur le produit Cartésien de toutes les classes d’équivalence, i.e., valides et invalides Problème avec les tests par classes d’équivalence robustes ◦Souvent les spécifications ne sont pas explicites pour les données invalides 25 25  Exemple : NextDate NextDate est une fonction avec trois variables : MOIS, JOUR, ANNEE Elle retourne la date du lendemain de la date donnée Années valides: 1812-2012. 26 26  Exemple : NextDate Résumé du traitement : ◦ si ce n’est pas le dernier jour du mois, la fonction date augmente simplement la valeur JOUR ◦ À la fin du mois, le jour suivant est 1 et la valeur du MOIS est augmentée de 1 ◦ À la fin d’une année, les deux valeurs JOUR et MOIS sont remises à 1, et la valeur ANNEE est augmentée ◦ Finalement, le problème de l’année bissextile rend intéressante la détermination du dernier jour d’un mois 27 27  Exemple : NextDate M1 = { MOIS: MOIS à 30 jours} M2 = { MOIS: MOIS à 31 jours} M3 = { MOIS: MOIS est Février} D1 = {JOUR: 1