Tests Logiciels (INF4000) PDF
Document Details
Uploaded by RightPeridot8225
ISSOUFOU NIKIEMA
Tags
Summary
This document contains lecture notes on software testing, including topics such as testing methods, software testing techniques, and testing types. It also contains example test cases and concepts.
Full Transcript
INF4000 Génie Logiciel Tests Logiciels ISSOUFOU NIKIEM A Tests Logiciels INF4000-GL (UVBF/GL/DI/PD) 2 I. NIKIEMA Plan Introduction Tests Structurels Tests Boite Noire 3 3...
INF4000 Génie Logiciel Tests Logiciels ISSOUFOU NIKIEM A Tests Logiciels INF4000-GL (UVBF/GL/DI/PD) 2 I. NIKIEMA Plan Introduction Tests Structurels Tests Boite Noire 3 3 Tests Logiciels : Tests Boite Noire 4 3 Plan Introduction Partitionnement en classes d’équivalence Analyse de la valeur limite Autres Tests 5 3 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 1 0 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 1 0 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 1 0 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 suffi santes 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 1 0 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 1 0 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 "effi caces" (i.e., à haute probabilité de révéler des défauts). Les tests intuitifs ne sont pas fiables 12 1 0 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 1 4 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 1 4 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 1 4 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 1 4 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, diffi ciles à gérer manuellement ◦ Cependant, bien que certaines classes créées puissent être invalides, cette méthode off re une grande variété de cas de test 18 1 4 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 1 4 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 1 4 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 1 4 Nombre de Cas Test - SECT Cas de Test A B C Cas de test SECT : 3*4*2 SE1 A1 B1 C1 SE2 A1 B1 C2 SE3 A1 B2 C1 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 22 A3 B3 C2 1 4 SE23 A3 B4 C1 SE24 A3 B4 C2 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 1 4 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 1 4 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 1 4 Test aux Limites Test aux Limites Les classes d’équivalence regroupent les données avec l’hypothèse que le programme a le même comportement avec tous les éléments d’une classe d’équivalence donnée L’expérience montre que les programmeurs font souvent des erreurs aux bornes des classes d’équivalence ◦Exemple: Traduire une spécification par x