Techniques de tests

1
Techniques de tests

• Aziz Salah, Professeur, Département
  dinformatique (Hiver 2005)
• Guy Tremblay, Professeur, Département
  dinformatique (É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
quil contient
Observation (E.W. Dijsktra)  Les tests peuvent
démontrer la présence derreurs, mais pas leur
absence 
3
Processus de test
4
Que montrent les tests?
Présence derreurs de programmation?
Respect des exigences?
Performance satisfaisante?
Qualité acceptable?
5
Qui doit tester le logiciel?
Le développeur
Un testeur indépendant
(Tests dintégration, tests de système)
(Tests unitaires, tests dintégration)


6
Qui doit tester?

• Il est important que le développeur teste son
  code (tests unitaires) avant de linté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 dautres mots, un test réussit à faire son
  travail lorsquil trouve une erreur, pas
  lorsquil montre que le code fonctionne
  correctement

7
Les principales phases de test
Aziz peux-tu corriger les flèches de la figure
pour quelles relient correctement les boîtes et
supprime la dernière (celle qui sort des tests
dacceptation)?
8
Les principales phases de test

• Tests unitaires tester les modules au fur et à
  mesure de leur développement
• Tests dintégration tester lassemblage des
  modules et composants et leurs interfaces
• Tests de système tester les fonctionnalités du
  système dans son ensemble
• Tests dacceptation 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
  quon exécute à nouveau pour déterminer si le
  programme (qui vient dêtre modifié) fonctionne
  toujours
• Tests alpha et beta tests dacceptation
  effectués avec des clients dans lenvironnement
  de développement (alpha) ou dans les sites
  clients (beta)
• Autres tests de performance, tests de stress,
  tests dutilisabilité, etc.

10
Fait il est impossible de faire des tests
exhaustifs, qui couvrent toutes les possibilités
Boucle avec 20 itérations
Si lexécution dun cas de test (pour un chemin
allant du début à la fin du programme) prend une
milliseconde, alors il faudrait plusieurs
milliers danné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,
  dexé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
  dexécution et probabilité élevée derreur 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 quun
  chemin qui na 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 dinstructions 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 dune boucle avec un grand nombre
  (possiblement variable) ditérations (chaque
  façon de terminer la boucle est un chemin
  distinct) ?
• N1 nest 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
  dexé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 dintroduire
  au moins une nouvelle instruction ou une nouvelle
  condition dans lensemble 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 nud représente un segment de code
  strictement séquentiel (sans choix ou boucle)
• Chaque arc dénote un lien de contrôle
  (possibilité daller dun nud à lautre)
• 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 dinstructions toujours
strictement consécutives
Conditions simples variables booléennes ou
relations entre variables (, !, lt, lt, gt, gt)
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
a
V
F
if (a b) then x else y
x
b
F
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
  lexécution de chacun des chemins identifiés.

24
Complexité cyclomatique

• La complexité cyclomatique est une mesure de la
  complexité logique dun 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
• 11-92 4
• V(G) Régions
• 4
• V(G) (Conditions)1
• 31

Graphe de flux de contrôle
25
Exemple didentification des chemins indépendants

• On doit identifier quatre chemins indépendants,
  par exemple
• 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

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

• Ensemble de chemins indépendants
• 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-8-9-2-3-
• 1-2-3-4,5-6-7-8-9-2-3-

29
Cas de test du chemin 1

• Spécification des entrées
• Value (k) entrée valide, avec k lt 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
• Value (1) -999
• Résultats attendus
• average -999 les autres champs de total
  restent à leur valeur initiale

31
Cas de test du chemin 3

• Entrée
• 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
• Value (i) entrée valide, i lt 100
• Value (k) lt minimum avec klti
• Résultats attendus
• Moyenne valide

33
Cas de test du chemin 5

• Entrée
• Value (i) entrée valide avec i lt 100
• Value (k) gt 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
• Value (i) entrée valide avec ilt 100
• Résultats attendus
• Une moyenne correcte des n valeurs ainsi que leur
  somme

35
Tests des boucles
Les tests basés sur les chemins indépendants vont
assurer de couvrir toutes les instructions et
conditions. Toutefois, ce nest pas suffisant
pour assurer le bon fonctionnement dune boucle
puisquelle 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 dité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 lt m lt n
• Exécuter la boucle n-1, n, n1 fois

37
Test de boucles imbriquées ou concaténées

• Boucles imbriqué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 dune boucle vers lexté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

• 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 derreurs visées sont
• Fonctionnalité incorrecte ou manquante
• Erreur dinterface
• Erreur de structure de données ou daccès aux
  bases de données externes
• Erreur dinitialisation 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 didentifier 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, a1, b-1, b, b1
• 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, n1 (?) 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
Système
Sorties valides
43
Partitionnement en classes déquivalence

• Objectif minimiser le nombre de cas de tests
  tout en sassurant 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 dune 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 à lentré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 lentrée)
• N lt 10000
• 10000 lt N lt 99999
• N gt 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
• 0, 5000, 9999
• 10000, 50000, 99999
• 100000, 100001, 200000

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 quelles 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 gt 0 0.0001 lt precision lt 0.01
• PRECONDITION
• x precision lt res2 lt 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 0.0002
• x 0 ET precision 0.005
• x 0 ET precision 0.0099
• x 0.1 ET precision 0.0002
• x 0.1 ET precision 0.005
• x 0.1 ET precision 0.0099
• x 1000.0 ET precision 0.0002
• x 1000.0 ET precision 0.005
• x 1000.0 ET precision 0.0099

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.