CHAPITRE 5: TEST DU LOGICIEL Cours « Génie Logiciel 1 » Niveau II2 RAPPEL : ACTIVITÉS DU CYCLE DE VIE Développement Exploitation & Retrait t Avant-projet Maintenance e n j o o i Initiation Planification, Pilotage & Suivi r ts p e du projet Gestion de qualité Évaluation e G d Analyse Conception s euqi Implémentation n Mise hors h Maintenance c service e Étude t Tests & s préalable é Assistance tiv Installation itc Vérification et Validation (V&V) A Documentation Gestion de la configuration 2 C ours «GL-ACOO» ENSI RAPPEL : MODÈLE EN CASCADE ▪ Présente le développement logiciel comme une suite de phases qui s’enchaînent dans un déroulement linéaire. Analyse V&V Conception globale et détaillée V&V Implémentation C ours «GL-ACOO» ENSI V&V V&V Tests unitaires Intégration et Tests Intégration et Tests V&V 3 Installation RAPPEL : MODÈLE EN V Analyse des besoins 4 Ecriture Validation Spécification Tests d’acceptation Conception Globale Conception Détaillée Codage Tests unitaires Tests d’intégration Tests système C ours «GL-ACOO» ENSI Chapitre 5: Test du logiciel Plan Introduction 2. Définitions 3. Principes des tests 4. Dimensions du test 5. Tests Boîte noire 6. Tests Boîte blanche 7. Outils de l’automatisation du test 6 C ours «GL-ACOO» ENSI INTRODUCTION « Le test est l'exécution ou l'évaluation 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 obtenus. » Définition de l’IEEE (Standard Glossary of Software Engineering Terminology) -STD729 (1983) « Un programme sans spécifications est toujours correct ! » 7 C ours «GL-ACOO» ENSI INTRODUCTION ▪ Il faut distinguer entre le test et la mise au point : ▪ Test : on vérifie la présence d’erreurs. ▪ Mise au point : On localise et corrige les erreurs détectées. ▪ La conception des tests peut être aussi difficile que la conception initiale du produit lui-même. ▪ Test= Activité coûteuse → Optimiser l'investissement ▪ effort minimum avec probabilité max. de détection d'erreur ▪ Les tests exhaustifs sont impossibles ▪ « Tester peut révéler la présence d'erreurs mais jamais leur absence » 8 C ours «GL-ACOO» ENSI OBJECTIFS DES TESTS ▪ Les objectifs de tests peuvent varier : ▪ Trouver des défauts ▪ Prévenir des défauts ▪ Acquérir de la confiance sur le niveau de qualité ▪ Fournir de l’information utile aux prises de décision ▪ Selon Glen Myers ▪ Le avec test l'intention est un processus de trouver de une l'exécution erreur. d'un programme ▪ Un une bon erreur test non est celui encore qui découverte. a une forte probabilité de trouver ▪ Un bon test n'est pas redondant ▪ Un encore test découverte. réussi est celui qui découvre une erreur non 9 C ours «GL-ACOO» ENSI PRINCIPES DES TESTS ▪ Tous clients les tests doivent être traçables aux besoins des ▪ L'objectif du test de logiciel est de découvrir des erreurs. ▪ Les tests tests doivent être planifiées bien avant le début des ▪ Tous génération les tests de code peuvent être planifiés et conçus avant toute ▪ Le dépistage exhaustif n'est pas possible ▪ A chemins combinaisons cause d’exécution, de l’augmentation de chemins il est pendant impossible exceptionnelle le test. d'exécuter du nombre toutes les de ▪ Pour par une être tierce plus partie efficace, indépendante les essais doivent être effectués ▪ L'ingénieur meilleure personne logiciel pour qui effectuer a créé tous le système les tests n'est pas la 10 C ours «GL-ACOO» ENSI TERMINOLOGIE Plan de test : document définissant l'organisation des tests : responsabilités, étapes, environnement de test, enchaînement, planning... Dossier de test : 11 document ou ensemble de documents contenant la description des tests (scénario, cas de test, résultat attendu) puis la trace des sessions de test (résultat obtenu, fiche d'anomalie...). Il existe un dossier de test par niveau de test. Base de référence : base de données de test sur laquelle seront exécutés un ou plusieurs cas de test . C ours «GL-ACOO» ENSI TERMINOLOGIE Cas de test : chemin fonctionnel à mettre en œuvre pour atteindre un objectif de test. Un cas de test se défini par le jeu d'essai à mettre en œuvre, le scénario de test à exécuter et les résultats attendus. Jeu d'essai : données en entrée d'un cas de test : valeurs à saisir, données réelles (base existante ou de test), génération automatique (aléatoire ou à partir de spécifications). Le même jeu d'essai peut servir à plusieurs cas de test. Scénario de test : 12 procédure à suivre par le testeur pour exécuter le cas de test : manipulations à effectuer, dialogue homme/machine... Le même scénario peut être utilisé dans plusieurs cas de test. C ours «GL-ACOO» ENSI TERMINOLOGIE ▪ « Un cas de test est un ensemble d'entrées de test, de conditions d'exécution et de résultats attendus pour un objectif particulier telle que la conformité du programme avec une spécification donnée » ▪ Structure type d’un cas de test 13 C ours «GL-ACOO» ENSI ▪ Deux approches complémentaires : APPROCHES DE TEST Tests dynamiques 15 Tests statiques C ours «GL-ACOO» ENSI APPROCHES DE TEST ▪ Test dynamique : Exécuter un programme à l’aide d’un jeu de tests. Les erreurs sont détectées en comparant les résultats obtenus par l’exécution et ceux attendus ▪ Coût du test dynamique : 30 % à 60 % du coût de développement total Entrée Programme Sortie ▪ Test statique : Analyser les propriétés de l’application sans exécution du code ▪ Selon des études, on peut détecter jusqu'à 60% des erreurs d'un programme par cette technique. 16 Programme C ours «GL-ACOO» ENSI LE TEST STATIQUE Techniques formelles (Génie Logiciel 2) Preuve de théorèmes Model Cheking 2. Techniques informelles: Les éléments à examiner peuvent être inspirés des erreurs de programmation les plus communes toutes les variables du programmes sont-elles initialisées avant d'être utilisées ? pour chaque instruction conditionnelle, la condition est-elle correcte ? est-ce que chaque boucle termine ? lorsque l'on traite des tableaux, la borne inférieur est-elle 0, 1 ou autre valeur ? si on utilise un stockage dynamique, a-t-on alloué l'espace correctement si on modifie une structure chaînée, rétablit-on bien tous les liens ? les instructions composées sont-elles correctement parenthèsées ? etc. 17 C ours «GL-ACOO» ENSI LE TEST DYNAMIQUE ▪ C’est la détection des erreurs à l’exécution dans l’intention d’y trouver des anomalies ou des défauts ▪ Validation fonctionnelle (Test de conformité aux spécifications) ▪ Test de qualité (performance, sécurité, etc.) ▪ Deux méthodes: ➢ méthodes fonctionnelles (boîte noire) ➢ méthodes structurelles (boîte blanche) 18 Données (IN) Résultats attendus Résultats trouvés Conformités ✓✘ Conformités ✓✘ C ours «GL-ACOO» ENSI DIMENSIONS DU TEST 19 C ours «GL-ACOO» ENSI TYPES DE TEST ▪ Tests unitaires ▪ Test d'une fonction, une classe, un module (pendant le développement) ▪ Permettent de vérifier le fonctionnement de chaque composant logiciel modifié ou nouveau dans des cas de fonctionnement normal , aux limites ou dégradé . ▪ Tests d'intégration ▪ Test de l'assemblage des modules (pendant le développement) ▪ Permettent de vérifier progressivement que l'ensemble constitué par les composants logiciels assemblés répond aux spécifications fonctionnelles et techniques. Ils doivent, s'il y a lieu, activer les interfaces avec les applications connexes. 20 C ours «GL-ACOO» ENSI TYPES DE TEST ▪ Tests de validation ▪ Chez le fournisseur, par l'équipe de qualification, puis par le client ▪ Permettent de vérifier que les exigences fonctionnelles et techniques du cahier des charges sont respectées. Ils s'effectuent sans connaissance de la structure interne (tests "boîte noire"). ▪ Tests de réception ▪ Permettent à un client de s'assurer que le cahier des charges a été respecté. ▪ Tests de suivi d'exploitation ▪ Après installation 21 C ours «GL-ACOO» ENSI TYPES DE TEST ▪ Tests de non-régression ▪ Dans le cas de changement de version, ▪ permettent de vérifier que les modifications apportées n'ont pas entraîné d'effets de bord non prévus qui pourraient dégrader le comportement du logiciel antérieurement validé. ▪ portent sur l'exécution de tests déjà joués afin de s'assurer que le système répond toujours aux exigences spécifiées. 22 C ours «GL-ACOO» ENSI NATURE DES TESTS ▪ Tests fonctionnels ▪ Réaction à certaines entrées (sorties produites) ▪ Tests de performance ▪ permettent de vérifier des contraintes de temps de réponse et d'occupation mémoire . ▪ peuvent faire partie des tests de validation ou de non-régression. ▪ Tests de fiabilité ▪ résistance aux pannes ▪ Tests de sécurité, ... ☛ On est pas obligé de faire tous types de test : ça dépend de la criticité du logiciel 23 C ours «GL-ACOO» ENSI VUES INTÉRIEURES ET EXTÉRIEURES DES TESTS ▪ Deux techniques de tests 24 Les tests boite noire Les tests boite blanche C ours «GL-ACOO» ENSI DIMENSIONS DU TEST SELON LES INFORMATIONS ACCÉDÉES ▪ Test boîte noire ▪ évaluation de l'extérieur (sans regarder le code), uniquement en fonction des entrées et des sorties sur le logiciel ou un de ses composants ▪ Sélection des tests à partir d'une spécification du système sans connaissance de l'implantation ▪ Possibilité de construire les tests avant le codage ▪ Test boîte blanche ▪ Sélection des tests à partir de l'analyse du code source du système ▪ Construction des tests uniquement pour du code déjà écrit 25 C ours «GL-ACOO» ENSI Les tests dans la pratique Test Portée catégorie Exécutant Unitaires Petites portions du code source Boite blanche/Noire Développeur machine Intégration Classes/Composants Blanche/Noire Développeur Fonctionnel Produit Boite noire Testeur Système Produit/Environnement simulé Boite noire Testeur Acceptation Produit/Environnement réel Boite noire Client Beta Produit/Environnement réel Boite noire Client Non-Régression N’importe lequel Blanche/ noire N’importe 26 C ours «GL-ACOO» ENSI TEST BOÎTE NOIRE Analyse partitionnelle (classes d’équivalence) Tests aux limites 27 TEST BOITE NOIRE(TBN) ▪ La génération des tests en boîte noire se base sur les ▪ spécifications Aucune connaissance fonctionnelles de la structure d’un programme. interne du programme. Catégories d'erreur: ▪ fonctions incorrectes ou manquantes ▪ erreurs d'interface ▪ des erreurs dans les structures de données ou l'accès de base de données externe ▪ des erreurs de comportement ou de performance ▪ erreurs d’initialisation et erreurs de terminaison. 28 C ours «GL-ACOO» ENSI MÉTHODES TEST BOITE NOIRE(TBN) ▪ Analyse partitionnelle ( Equivalence partitionning ) ▪ Analyse des valeurs limites( Boundary Value Analysis )* 29 C ours «GL-ACOO» ENSI TEST PAR CLASSE D’ÉQUIVALENCE 30 C ours «GL-ACOO» ENSI TEST PAR CLASSE D’ÉQUIVALENCE 31 C ours «GL-ACOO» ENSI TEST PAR CLASSE D’ÉQUIVALENCE (PARTITIONS D’ÉQUIVALENCE ) ▪ Cette méthode consiste à partitionner le domaine d’entrée en plusieurs classes . ▪ Les entrées d’un système sont divisées en groupes qui doivent montrer un comportement similaire → elles auront un traitement identique. ▪ Prendre en compte les données invalides comme les données valides : toutes sont des entrées ▪ Un seul test est nécessaire pour chaque classe. Le test se fait avec un seul représentant par classe. ▪ Idée : chaque représentant d'une classe a une même «probabilité» que les autres de mettre en évidence une erreur ▪ Partition du domaine d'entrées (souvent infini) en un nombre fini de classes d'équivalence → limite le nombre de tests 32 C ours «GL-ACOO» ENSI TEST PAR CLASSE D’ÉQUIVALENCE ▪ Exemple 1: fonction qui attend un numéro de département entre 1 et 95 ▪ Exemple 2 : fonction qui attend une réponse oui/non 33 C ours «GL-ACOO» ENSI EXERCICE ▪ Supposons que nous élaborions un compilateur pour le langage X. Un extrait des spécifications précise : ▪ «L’instruction FOR n’accepte qu’un seul paramètre en tant que variable auxiliaire. Son nom ne doit pas dépasser deux caractères non blancs; Après le signe = on doit préciser aussi une borne supérieure et une borne inférieure. Les bornes sont des entiers positifs et on place entre eux le mot-clé TO. » ▪ Déterminer les jeux de test à produire pour l’instruction FOR en utilisant la technique de test par classe d’équivalence 34 C ours «GL-ACOO» ENSI CORRIGÉ 35 C ours «GL-ACOO» ENSI TEST AUX LIMITES ▪ L'expérience prouve que ☛ Les erreurs se situent très souvent aux frontières ▪ Par exemple : ▪ indice de tableau tout juste trop grand ou trop petit ▪ boucles avec une itération en trop ou en moins ▪ comparaisons stricte au lieu de avec égalité, ou l'inverse ▪ Plusieurs représentants par classe d'équivalence ☛ une valeur « médiane » ordinaire + une ou plusieurs valeurs aux limites ▪ Aussi appelé « test aux bornes » 36 C ours «GL-ACOO» ENSI TEST AUX LIMITES Exemples 37 C ours «GL-ACOO» ENSI MÉTHODE GÉNÉRALE 38 C ours «GL-ACOO» ENSI TEST AUX LIMITES ▪ Exemple : fonction qui attend une réponse oui/non 39 C ours «GL-ACOO» ENSI EXERCICE Algorithme : Recherche dichotomique dans une table d’entiers. R := Recherche (Tab, taille, v) On supposera que la fonction recevra un tableau d’entiers ordonné et une valeur v entière. Préparer un jeu de test en prenant en considération les classes d’équivalence et les tests aux limites. Correction ▪ Table vide Tab=nil; taille=0; v=17 / R=-1 ▪ Table ne contenant qu'une valeur égale à la valeur cherchée : Tab=17; taille=1; v=17 / R=1 ▪ Table ne contenant qu'une valeur différente de la valeur cherchée : Tab=17; taille=1; v=0 / R=-1 ▪ Table de taille paire, la première valeur = valeur cherchée: Tab=17,23; taille=2; v=17 / R=1 ▪ Table de taille paire, la dernière valeur = valeur cherchée: Tab=17,23; taille=2; v=23 / R=2 ▪ Table de taille paire ne contenant pas la valeur cherchée: Tab=17,23; taille=2; v=3 / R=-1 ▪ Table de taille impaire, la première valeur = valeur cherchée: Tab=17,23,29; taille=3; v=17 / R=1 ▪ Table de taille impaire, la dernière valeur = valeur cherchée: Tab=17,23,29; taille=3; v=29 / R=3 ▪ Table de taille impaire ne contenant pas la valeur cherchée: Tab=17,23,29; taille=3; v=4 / R=-1 ▪ Table de taille quelconque contenant la valeur cherchée: Tab=17,23,29,35,41; taille=5; v=23 / R=2 Remarque : pas exhaustif mais raisonnable. 40 C ours «GL-ACOO» ENSI TEST BOÎTE BLANCHE Principe de Graphe flots Complexité Cyclomatique 41 PRINCIPE Etude détaillée de la logique interne et la structure du code. Effectuer des tests boîte blanche Posséder une connaissance du fonctionnement interne du code. 42 C ours «GL-ACOO» ENSI EST-IL POSSIBLE DE FAIRE DES TESTS EXHAUSTIFS? for(int i=0; i<20;i++) { for(int j=0; j<20;j++) { if(exp1){...}else{...} if(exp2){...}else{...} if(exp3){...}else{...} if(exp4){...}else{...} } } Il y a environ 10 ^ 14 chemins possibles qui peuvent être exécutées dans ce programme !!! Que FAIRE ???? 43 C ours «GL-ACOO» ENSI CRITÈRES DE COUVERTURE ▪ Les Critères de Couverture : ▪ Le critère de couverture des instructions : le jeu d’essai doit assurer que toute instruction élémentaire est exécutée au moins une fois ▪ Le critère de couverture des arcs du graphe de contrôle ▪ Le critère de couverture des chemins du graphe de contrôle ▪ Le critère de couverture des conditions : le jeu de tests doit couvrir à vrai et à faux toutes les conditions élémentaires de toutes les conditionnelles ▪ En général, il est conseillé de mélanger différents critères. ▪ Ce type de test structurel ne peut être réutilisé tel quel en cas de modification du code . 44 C ours «GL-ACOO» ENSI GRAPHE DE FLOT DE CONTRÔLE ▪ Représentation du flot de contrôle ▪ Description de la structure du programme ▪ Dans le graphe de flot: ▪ Cercle : nœud ▪ Flèches : arêtes ou liens ▪ Nœud prédicat : un nœud contenant une condition. ▪ Zone délimitée par les nœuds et les arêtes : région . ▪ En comptant les régions, il faut ajouter l’extérieur du graphe comme une région !! 45 C ours «GL-ACOO» ENSI GRAPHE DE FLOT DE CONTRÔLE NOTATION Tout arc doit se terminer vers un nœud !! 46 C ours «GL-ACOO» ENSI GRAPHE DE FLOT DE CONTRÔLE 47 11 10 7 8 1 3 4 5 2 6 9 1 : read(x); 2 : read(y); 3 : if( x<y) then 4 : x++; 5 : else y++ ; 6 : traitement 7 : while (x<y) 8 : x++; 9 : traitement 10 : Repeat x++; 11 : until ( x<y) EXEMPLES SIMPLES C ours «GL-ACOO» ENSI GRAPHE DE FLOT DE CONTRÔLE EXEMPLE ▪ Exemple de graphe de flux de contrôle pour un programme avec des conditions composées if (a || b) then x else y On associe plusieurs chemins à la condition complexe « a || b » 48 C ours «GL-ACOO» ENSI GRAPHE DE FLOT DE CONTRÔLE → EXEMPLE Organigramme Graphe de flot ( flux de contrôle) 49 C ours «GL-ACOO» ENSI CAS DE TEST DÉRIVÉS DES CHEMINS DE BASE ▪ Garantir l’exécution de tous les énoncés du code au moins une fois durant les tests. ▪ ÉTAPE 1: Dessiner le graphe de flot pour représenter la structure de contrôle du code approprié. ▪ ÉTAPE 2: Calculer la complexité cyclomatique. ▪ ÉTAPE 3 : Déterminer les chemins indépendants. ▪ ÉTAPE 4 : Préparer les cas de test pour forcer l'exécution de chaque chemin du code. 50 C ours «GL-ACOO» ENSI CHEMINS INDÉPENDANTS ▪ Un chemins indépendant : ▪ Dans le programme, c’est tout chemin qui introduit au moins un nouvel ensemble d’instructions ou une nouvelle condition: ▪ Pour le graphe de flot , un chemin indépendant doit passer au moins par un arc qui n'a pas été traversée avant que ce chemin ne soit défini ▪ Chemins indépendants pour ce graphe sont: Chemin 1: 1-11 Chemin 2: 1-2-3-4-5-10-1-11 Chemin 3: 1-2-3-6-8-9-10-1-11 Chemin 4: 1-2-3-6-7-9-10-1-11 Mais 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11 n’est pas un chemin indépendant = c’est une combinaison des chemins 1, 2 et 3, et n’introduit aucun arc nouveau. 51 C ours «GL-ACOO» ENSI COMPLEXITÉ CYCLOMATIQUE ▪ Métrique logicielle donnant une mesure quantitative de la complexité logique. ▪ Nombre de chemins indépendants : la valeur calculée pour la complexité cyclomatique ▪ Définition de la borne supérieure : le nombre de tests à effectuer pour s'assurer de l’exécution de toutes les instructions au moins une fois. 52 C ours «GL-ACOO» ENSI COMPLEXITÉ CYCLOMATIQUE 3 Méthodes de calcul de la complexité cyclomatique : 1. Le nombre de régions du graphe de flot. 2. V (G) = E-N + 2. ▪ N : le nombre de nœuds du graphe ▪ E : le nombre d'arêtes. 3. V (G) = P + 1 P : le nombre de nœuds « conditions » 53 C ours «GL-ACOO» ENSI Organigramme V (G) = nombre de décisions + 1 = 3 + 1 = 4 V (G) = Le nombre de régions =4 V (G) = E-N + 2 = 11 - 9 +2 = 4 V (G) = E-N + 2 = 13-11 +2 = 4 54 C ours «GL-ACOO» ENSI COMPLEXITÉ CYCLOMATIQUE COMPLEXITÉ CYCLOMATIQUE : 1 . Région R=4 2 . Nbr de nœuds=8 Nbr d’ arêtes=10 V(G)= E-N+2 =10-8+2=4 3 . Nbr de nœuds prédicats =3 V(G)=p+1=3+1=4 CHEMINS INDÉPENDANTS : path 1 : 1-2-4-7-8 path 2 : 1-2-3-5-7-8 path 3 : 1-2-3-6-7-8 path 4 : 1-2-4-7-2-4-7-8 55 C ours «GL-ACOO» ENSI Automatisation des tests 56 EXEMPLE DES OUTILS DE L’AUTOMATISATION DU TEST ▪ L’offre en outils d’aide au test de logiciels couvre tous les types de test ▪ Plus de 278 outils référencés sur le site spécialisé http://www.stickyminds.com/ ▪ Exemples d’outils pour les tests unitaires: ▪ Junit pour JAVA ▪ Nunit pour .Net ▪ CppUnit pour C++ 57 C ours «GL-ACOO» ENSI CONCLUSION ▪ Le test vise à mettre en évidence les erreurs d’un logiciel ▪ Le test est une méthode de vérification partielle de logiciels=> la qualité du test dépend de la pertinence du choix des données de test ▪ Pour un logiciel critique, le coût du test peut représenter plus de 40% du coût du développement ▪ La mise au point d’une méthode optimale de vérification de programmes, passe par une combinaison judicieuse de l’utilisation de différentes méthodes de tests statiques et dynamiques (boîte noire et boîte blanche). 58 C ours «GL-ACOO» ENSI Chapitre 5: Test du logiciel Principale référence Pressman « Software Engineering A Practitioner’s Approach » Septième édition, 2010 (chapitre 18) 59 C ours «GL-ACOO» ENSI FIN CHAPITRE 5 60 télécharger gratuitement TEST DU LOGICIEL