Techniques de tests Aziz Salah Professeur Dpartement dinformatique

Techniques de tests Aziz Salah, Professeur, Département d’informatique (Hiver 2005) Guy Tremblay, Professeur, Département d’informatique (Été 2005) 1

Rôle et objectif des tests Le processus de test consiste à exécuter un programme dans le but de trouver les erreurs qu’il contient Observation (E. W. Dijsktra): « Les tests peuvent démontrer la présence d’erreurs, mais pas leur absence » 2

Processus de test Évaluation t t du tes Résulta fec t Co Dé Ca sd s e te tuo sit é Exécution du test rre Ré su lta t att en du cti o n Débogage 3

Que montrent les tests? Présence d’erreurs de programmation? Respect des exigences? Performance satisfaisante? Qualité acceptable? 4

Qui doit tester le logiciel? Le développeur (Tests unitaires, tests d’intégration) Un testeur indépendant (Tests d’intégration, tests de système) 5

Qui doit tester? n n n Il est important que le développeur teste son code (tests unitaires) avant de l’intégrer au reste du système Mais: il est difficile pour un développeur de tester son propre code car il faut tester pour trouver les erreurs dans le code, pas pour montrer que le code fonctionne En d’autres mots, un test réussit à faire son travail lorsqu’il trouve une erreur, pas lorsqu’il montre que le code fonctionne correctement 6

Les principales phases de test Tests d’acceptation Tests de système Tests d’intégration Tests unitaires Aziz: peux-tu corriger les flèches de la figure pour qu’elles relient correctement les boîtes et supprime la dernière (celle qui sort des tests d’acceptation)? 7

Les principales phases de test n n Tests unitaires: tester les modules au fur et à mesure de leur développement Tests d’intégration: tester l’assemblage des modules et composants et leurs interfaces Tests de système: tester les fonctionnalités du système dans son ensemble Tests d’acceptation: confirmer que le système est prêt à être livré et installé 8

Autres types de tests n n n Tests de (non) régression: tests déjà exécutés qu’on exécute à nouveau pour déterminer si le programme (qui vient d’être modifié) fonctionne toujours Tests alpha et beta: tests d’acceptation effectués avec des clients dans l’environnement de développement (alpha) ou dans les sites clients (beta) Autres : tests de performance, tests de stress, tests d’utilisabilité, etc. 9

Fait : il est impossible de faire des tests exhaustifs, qui couvrent toutes les possibilités Boucle avec 20 itérations Si l’exécution d’un cas de test (pour un chemin allant du début à la fin du programme) prend une milliseconde, alors il faudrait plusieurs milliers d’années pour tester tous les chemins possibles de ce programme 10

Donc: on exécute les tests de façon sélective mais judicieuse n n n Identification des chemins indépendants Nombre limité, mais judicieusement choisi, d’exécution des boucles Partitionnement des données en classes d’équivalence Analyse des cas limites Etc. 11

Deux grandes méthodes de tests Tests fonctionnels, de type boîte noire Tests structurels, de type boîte blanche Méthodes Stratégies 12

Tests de type boîte blanche n Tests structurels : basés sur la structure interne du code à tester = on connaît la structure interne du programme et on en tient compte pour développer les cas de test 13

Pourquoi il est important de faire des tests de type boîte blanche n n n Fait: on risque plus facilement de se tromper (erreur de logique, de codage) en traitant un cas peu fréquent -i. e. , probabilité faible d’exécution et probabilité élevée d’erreur vont souvent de paire Fait: certains chemins qui, intuitivement, nous semblent improbables, peuvent quand même être exécutés Fait: les erreurs typographiques sont réparties au peu hasard et il est hautement probable qu’un chemin qui n’a pas été testé en contienne 14

Tests de type boîte blanche Cas de tester Analyser la structure du module et définir les cas de test appropriés Composant ou module Sorties attendues pour chacun des tests 15

Niveaux de couverture n Chemin complet dans un programme = séquence spécifique d’instructions allant du début du programme jusqu’à la fin n Différents objectifs possibles de tests (différents niveaux de couverture du code) n n n N 0: Exécuter tous les chemins possibles au moins une fois (couverture exhaustive) N 1: Exécuter toutes les instructions du programme au moins une fois (couverture des instructions) N 2: Exécuter toutes les branches des conditions, dans chaque direction, au moins une fois (couvertures des branchements et conditions) 16

Niveaux de couverture n Or: n n n N 0 est impossible en présence de boucles : on ne peut pas tester tous les chemins distincts dans le cas d’une boucle avec un grand nombre (possiblement variable) d’itérations (chaque façon de terminer la boucle est un chemin distinct) N 1 n’est pas suffisant : si une instruction if ne possède pas de branche else, on peut avoir exécuté toutes les instructions, mais sans avoir testé ce qui arrive lorsque la condition est fausse Si le programme est bien structuré (pas de goto), alors N 2 implique N 1 17

Niveaux de couverture n n n Objectif = définir suffisamment (mais pas trop) de cas de tests pour générer des chemins d’exécution à travers le programme qui assureront que les niveaux de couverture N 1 et N 2 seront atteints Stratégie possible = examiner la structure du code, via le graphe de flux de données du programme (voir plus loin), pour identifier un ensemble de chemins indépendants Note: Un chemin indépendant permet d’introduire au moins une nouvelle instruction ou une nouvelle condition dans l’ensemble des instructions et conditions qui sont couvertes 18

Graphe de flux de contrôle n Représentation abstraite et simplifiée de la structure du programme n n Décrit le flux de contrôle du programme Chaque nœud représente un segment de code strictement séquentiel (sans choix ou boucle) Chaque arc dénote un lien de contrôle (possibilité d’aller d’un nœud à l’autre) Utile pour calculer la complexité cyclomatique et déterminer le nombre de cas de tests à définir pour assurer une couverture acceptable 19

Les graphes de flux pour diverses structures de contrôle if-then-else while do … while switch 20

Exemple de graphe de flux de contrôle pour un programme avec des conditions simples Région = suite d’instructions toujours strictement consécutives Programme représenté par un organigramme Graphe de flux de contrôle Conditions simples: variables booléennes ou relations entre variables (=, !=, <, <=, >, >=) 21

Exemple de graphe de flux de contrôle pour un programme avec des conditions composées a V F if (a || b) then x else y F b x V y x On associe plusieurs chemins à la condition complexe « a || b » 22

Cas de test basés sur les chemins indépendants n Suivre le processus suivant: 1. Construire le graphe de flux de contrôle du 2. 3. 4. programme. Calculer la complexité cyclomatique à partir du graphe de flux de contrôle résultant (page suivante). Identifier un ensemble chemins complets (du début à la fin du programme) indépendants. Construire des cas de test qui vont forcer l’exécution de chacun des chemins identifiés. 23

Complexité cyclomatique n n n Graphe de flux de contrôle La complexité cyclomatique est une mesure de la complexité logique d’un programme Dans le contexte des tests, la complexité cyclomatique indique le nombre maximum des chemins complets indépendants, ce qui donne le nombre de cas de tests nécessaires pour assurer une bonne couverture du code (niveaux N 1 et N 2). Différentes façons (équivalentes) de la calculer: n V(G) = #Arcs - #Noeuds + 2 = 11 -9+2 = 4 n V(G) = #Régions =4 n V(G) = #(Conditions)+1 = 3+1 24

Exemple d’identification des chemins indépendants n On doit identifier quatre chemins indépendants, par exemple : n n Chemin 1: 2: 3: 4: 1 -11 1 -2, 3 -4, 5 -10 -1 -11 1 -2, 3 -6 -8 -9 -10 -1 -11 1 -2, 3 -6 -7 -9 -10 -1 -11 25

Exemple tiré de (Pressman, 2001) 26

Graphe de flux de contrôle pour la procédure average 27

Un ensemble de chemins indépendants n Ensemble de chemins indépendants: n n n 1 -2 -10 -11 -13 1 -2 -10 -12 -13 1 -2 -3 -10 -11 -13 1 -2 -3 -4, 5 -8 -9 -2 -3 -… 1 -2 -3 -4, 5 -6 -7 -8 -9 -2 -3 -… 28

Cas de test du chemin 1 n Spécification des entrées n n n Value (k) = entrée valide, avec k < i Value (i) = -999 avec 2 i 100 Spécification des sorties: Résultats attendus n Une moyenne correctes des k valeurs ainsi que leur somme n Note: Le chemin 1 ne peut être testé tout seul: il sera testé avec les chemins 4, 5, et 6. 29

Cas de test du chemin 2 n Entrée n n Value (1) = -999 Résultats attendus n average = -999; les autres champs de total restent à leur valeur initiale 30

Cas de test du chemin 3 n Entrée n n n Essayer de traiter 101 valeurs ou plus Les première 100 valeurs devraient être valides Résultats attendus n Moyenne correcte des 100 premières valeurs 31

Cas de test du chemin 4 n Entrée n n n Value (i) = entrée valide, i < 100 Value (k) < minimum avec k<i Résultats attendus n Moyenne valide 32

Cas de test du chemin 5 n Entrée n n n Value (i) = entrée valide avec i < 100 Value (k) > maximum avec k i Résultats attendus n Une moyenne correcte des n valeurs ainsi que leur somme 33

Cas de test du chemin 6 n Entrée n n Value (i) = entrée valide avec i< 100 Résultats attendus n Une moyenne correcte des n valeurs ainsi que leur somme 34

Tests des boucles Boucle Simple Boucles imbriquées Les tests basés sur les chemins indépendants vont assurer de couvrir toutes les instructions et conditions. Toutefois, ce n’est pas suffisant pour assurer le bon fonctionnement d’une boucle puisqu’elle peut être exécutée un nombre variable de fois (0, 1, 2, …) 35

Tests de boucles simples n Les différents cas à tester pour une boucle simple, où n = nombre maximum d’itérations: n n n Ne pas exécuter la boucle (exécuter 0 fois) Exécuter la boucle une seule fois Exécuter la boucle deux fois Exécuter la boucle m fois avec 2 < m < n Exécuter la boucle n-1, n, n+1 fois 36

Test de boucles imbriquées ou concaténées n Boucles imbriquées n n Commencer à la boucle la plus profonde et lui appliquer le test de la boucle simple en maintenant les boucles extérieures à leurs valeurs minimales Avancer d’une boucle vers l’extérieur et lui appliquer le test de la boucle simple en maintenant les autres boucles extérieures à leurs valeurs minimales et les boucles intérieures à leurs valeurs typiques jusqu’à ce que la boucle extérieure soit testée 37

Tests de type boîte noire. Exigences et spécifications n n Appelés aussi tests fonctionnels Les tests de type boîte noire représentent une approche complémentaire de test, donc les deux approches devraient être utilisées e Avantages des tests fonctionnels : leur planification et conception peut commencer tôt dans le processus de développement du logiciel, i. e. , aussitôt que les spécifications sont disponibles Entrées Les types d’erreurs visées sont: n n Fonctionnalité incorrecte ou manquante Erreur d’interface Erreur de structure de données ou d’accès aux bases de données externes Erreur d’initialisation ou de terminaison valides et invalides m è t s Sy Sorties Événements 38

Techniques de tests de type boîte noire (tests fonctionnels) n n n Tests des conditions limites Tests basés sur le partitionnement en classes d’équivalence Tests basés sur les pré/post-conditions 39

Tests des conditions limites n n Motivation: très souvent, les erreurs surviennent dans le traitement des cas limites (par exemple, erreur «off-by-1» dans les boucles) Donc: il est important d’identifier les cas limites, tant sur les entrées que sur les résultats, et de spécifier des cas de tests appropriés n n Note: tester sur les sorties signifie tenter de produire un résultat qui satisfait certaines conditions spécifiques Remarque: les tests des conditions limites sont aussi applicables pour les tests de type boîte blanche 40

Tests des conditions limites n n Valeurs numériques définies par un intervalle [a. . b]: on teste avec a-1, a, a+1, b-1, b, b+1 Chaînes de caractères (avec au plus n caractères): chaîne vide, chaîne avec un seul caractère, chaîne avec n-1, n, n+1 (? ) caractères Tableaux: tableau vide, avec un seul élément, avec n-1 ou n éléments Fichiers: fichier vide, avec une seule ligne, etc. 41

Partitionnement en classes d’équivalence Sorties invalides Entrées invalides Système Entrées valides Sorties valides 42

Partitionnement en classes d’équivalence n n Objectif = minimiser le nombre de cas de tests tout en s’assurant de couvrir tous les cas importants On suppose que des entrées équivalentes vont être traitées de façon similaire, donc on va grouper les entrées en classes d’équivalence: n n Le programme se comporte de manière semblable pour chaque élément d’une même classe d’équivalence parce que ces données obéissent aux mêmes conditions Ensuite, on choisit un nombre limité de cas de test dans chacune des classes d’équivalence 43

Exemple de partitionnement en classes d’équivalence n n Supposons que la donnée à l’entrée est un entier naturel qui doit contenir cinq chiffres, donc un nombre compris entre 10, 000 et 99, 999. Le partitionnement en classes d’équivalence identifierait alors les trois classes suivantes (trois conditions possibles pour l’entrée): a. b. c. n N < 10000 <= N <= 99999 N >= 100000 On va alors choisir des cas de test représentatif de chaque classe, par exemple, au milieu et aux frontières (cas limites) de chacune des classes: a. b. c. 0, 5000, 9999 10000, 50000, 99999 100000, 100001, 200000 44

Tests basés sur les pré/post-conditions n n On construit des cas de test qui vont assurer que les pré-conditions seront vérifiées de différentes façons, et aussi qu’elles ne seront pas vérifiées Si possible, on fait de même pour les postconditions: on construit des cas de tests qui vont produire, de différentes façons, des résultats qui satisfont les post-conditions 45

Exemple de cas de tests basés sur les pré/post-conditions n n Soit la fonction suivante : float racine. Carre( float x, float precision ) PRECONDITION n x >= 0 && 0. 0001 < precision < 0. 01 PRECONDITION n x – precision <= res^2 <= x + precision 46

Exemple de cas de tests basés sur les pré/post-conditions n Différents cas de tests qui satisfont la pré-condition, et ce de différentes façons: n n n n n x x x x x = = = = = 0 ET precision = 0. 0002 0 ET precision = 0. 005 0 ET precision = 0. 0099 0. 1 ET precision = 0. 0002 0. 1 ET precision = 0. 005 0. 1 ET precision = 0. 0099 1000. 0 ET precision = 0. 0002 1000. 0 ET precision = 0. 005 1000. 0 ET precision = 0. 0099 47

Références n n n B. Beizer (1990) Software Testing Techniques, 2 nd ed. Van Nostrand Reinhold Co. C. Kaner, J. Falk and H. Q. Nguyen (1999) Testing Computer Software, 2 nd ed. John Wiley & Sons. I. Sommerville (2004) Software Engineering, 7 th ed. Addison-Wesley. M. L. Hutcheson (2003) Software Testing Fundamentals-Methods and Metrics. John Wiley & Sons. R. S. Pressman (2001) Software Engineering: A Practitioner's Approach, 5 th ed. Mc. Graw-Hill. S. Mc. Connell (2004) Code Complete, 2 nd ed. Microsoft Press. 48