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

Présentation au sujet: "Techniques de tests Aziz Salah, Professeur, Département d’informatique (Hiver 2005) Guy Tremblay, Professeur, Département d’informatique (Été 2005)"— Transcription de la présentation:

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

2 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 »

3 Processus de test Évaluation Exécution du test Débogage
Cas de test Résultat du test Résultat attendu Défectuosité Correction

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

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

6 Qui doit tester? 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

7 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)?

8 Les principales phases de test
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é

9 Autres types de tests 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.

10 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

11 Donc: on exécute les tests de façon sélective mais judicieuse
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.

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

13 Tests de type boîte blanche
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

14 Pourquoi il est important de faire des tests de type boîte blanche
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

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

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

17 Niveaux de couverture Or:
N0 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)  N1 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 N2 implique N1 

18 Niveaux de couverture 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 N1 et N2 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

19 Graphe de flux de contrôle
Représentation abstraite et simplifiée de la structure du programme 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

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

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

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

23 Cas de test basés sur les chemins indépendants
Suivre le processus suivant: Construire le graphe de flux de contrôle du 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.

24 Complexité cyclomatique
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 N1 et N2). Différentes façons (équivalentes) de la calculer: V(G) = #Arcs - #Noeuds + 2 = = 4 V(G) = #Régions = 4 V(G) = #(Conditions)+1 = 3+1 Graphe de flux de contrôle

25 Exemple d’identification des chemins indépendants
On doit identifier quatre chemins indépendants, par exemple : Chemin 1: 1-11 Chemin 2: 1-2,3-4, Chemin 3: 1-2, Chemin 4: 1-2,

26 Exemple tiré de (Pressman,2001)

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

28 Un ensemble de chemins indépendants
, … , … , …

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

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

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

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

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

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

35 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, …) Boucle Simple Boucles imbriquées

36 Tests de boucles simples
Les différents cas à tester pour une boucle simple, où n = nombre maximum d’itérations: 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

37 Test de boucles imbriquées ou concaténées
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

38 Tests de type boîte noire
Exigences et spécifications Événements Entrées valides et invalides Sorties 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 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 Les types d’erreurs visées sont: 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 Système

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

40 Tests des conditions limites
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 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

41 Tests des conditions limites
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.

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

43 Partitionnement en classes d’équivalence
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: 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

44 Exemple de partitionnement en classes d’équivalence
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): N < 10000 10000 <= N <= 99999 N >= 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: 0, 5000, 9999 10000, , 100000, ,

45 Tests basés sur les pré/post-conditions
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 post-conditions: on construit des cas de tests qui vont produire, de différentes façons, des résultats qui satisfont les post-conditions

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

47 Exemple de cas de tests basés sur les pré/post-conditions
Différents cas de tests qui satisfont la pré-condition, et ce de différentes façons: x = 0 ET precision = x = 0 ET precision = 0.005 x = 0 ET precision = x = 0.1 ET precision = x = 0.1 ET precision = 0.005 x = 0.1 ET precision = x = ET precision = x = ET precision = 0.005 x = ET precision =

48 Références B. Beizer (1990) Software Testing Techniques, 2nd ed. Van Nostrand Reinhold Co. C. Kaner, J. Falk and H.Q. Nguyen (1999) Testing Computer Software, 2nd ed. John Wiley & Sons. I. Sommerville (2004) Software Engineering, 7th 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, 5th ed. McGraw-Hill. S. McConnell (2004) Code Complete, 2nd ed. Microsoft Press.