Mise en œuvre des tests logiciels - Nicolas Hernandeze.nicolas.hernandez.free.fr/pub/ens/tdd/TdD08_CM04_SF.pdf · Mise en œuvre des tests logiciels Introduction Plan 1 Introduction

Mise en œuvre des tests logiciels

Mise en œuvre des tests logicielssupport du cours de « Techniques de Développement »

Sébastien Faucou

Université de Nantes

2007-2008


Plan

1 Introduction

2 Test du logicielConcepts de baseLes ciblesLes objectifsLes techniquesExigences pour la mise en œuvre des tests

3 JUnitPrésentationDéfinition d’un cas de testLes tests dans la gestion de configuration

4 TdD Quizz !

5 Références


Introduction

Plan

1 Introduction

2 Test du logiciel

3 JUnit

4 TdD Quizz !

5 Références


Introduction

Une spécification détaillée

public static void sort(int t[]) :

Spécificationpré : t est une référence non null sur un tableau contenant desint

post : les éléments de t ont été triés dans l’ordre croissant


Introduction

Une implémentation possible

1 public static void sort(int tab[]) {2 int i = 1;3 while(i<tab.length || sorted) {4 sorted = true;5 for(int j=1; j<tab.length - 1; j++) {6 if(tab[j] < tab[i-1]) {7 int tmp = tab[j-1];8 tab[j-1] = tab[j];9 tab[j] = tmp;

10 sorted = false;11 }12 }13 i++;14 }15 }

En pratique, utilisation depublic static void sort<T>(T[] a, Comparator<? super T> c) dupackage java.util.Arrays.


Introduction

La question

L’exécution est-elle conforme au comportement attendu ?

Erreurs possibles :erreur lors de la conception (algorithme ou spécificationlogiquement faux)erreur lors de la réalisation (faute de frappe, mauvaisecompréhension du langage de spécification ou deprogrammation)erreur lors de la construction (mauvaise maîtrise de laconfiguration du projet, défaillance du compilateur, de la jvm)etc.

Au fait, pour notre exemple, la réponse est non : le code estvolontairement truffé de fautes. À vous de les débusquer en TP !


Introduction

La question


Erreurs possibles :

erreur lors de la conception (algorithme ou spécificationlogiquement faux)erreur lors de la réalisation (faute de frappe, mauvaisecompréhension du langage de spécification ou deprogrammation)erreur lors de la construction (mauvaise maîtrise de laconfiguration du projet, défaillance du compilateur, de la jvm)etc.



Introduction

La question





Introduction

La question





Introduction

Le moyen

Pour tester la conformité de l’exécution, une seule solution possible :tester le code exécuté

Quel est le problème ?

En supposant que le code s’exécute sur une machine qui code letype int sur 32 bits : il y a 232n tableaux différents de taille nEn supposant que la longueur d’un tableau est comprise entre 0et 232 − 1, il y a donc

∑i=232−1i=0 232i entrées différentes à tester

Ce qui est largement supérieur à 10300 (pour mémoire, le nombreestimé d’atome dans l’univers se situe entre 1078 et 1080)

La force brute n’est pas envisageable. Il va donc falloir sélectionnerdes données de test pertinentes, mettant à mal l’implémentation !


Introduction

Le moyen








Introduction

Le moyen



En supposant que le code s’exécute sur une machine qui code letype int sur 32 bits : il y a 232n tableaux différents de taille n

En supposant que la longueur d’un tableau est comprise entre 0et 232 − 1, il y a donc





Introduction

Le moyen








Introduction

Le moyen








Introduction

Le moyen








Introduction

La mise en œuvre

Une fois les données de test sélectionnées, comment passer à lamise en œuvre des tests ?

Disposer d’un cadre adapté à l’écriture de testcomparaison obtenu / attenducréation d’un environnement virtuel pour le code testé

Disposer d’un cadre adapté à l’exécution des testspouvoir grouper un ensemble de test et les jouer de façonautomatiquepouvoir collecter et synthétiser les résultats des tests

être capable d’identifier et manipuler les tests avec l’outil degestion de configuration du projet


Introduction

La mise en œuvre






Introduction

La mise en œuvre






Introduction

La mise en œuvre






Introduction

Contenu de ce cours

Généralités sur le test logicielRappel du vocabulaire et des principaux concepts

Choix de données de test pertinentes :Mini-rappel, concentré sur le test fonctionnel

Mise en œuvre des tests :Présentation de JUnit, framework pour réaliser des tests delogiciels écrits en Java.


Test du logiciel

Plan

1 Introduction


3 JUnit

4 TdD Quizz !

5 Références


Test du logiciel

Concepts de base

Plan

1 Introduction


3 JUnit

4 TdD Quizz !

5 Références


Test du logiciel

Concepts de base

Erreur, faute, défaillance

Définition (Erreur, faute et défaillance)

Des erreurs peuvent être commises lors des différentes activitésréalisées pour obtenir le code exécutable (spécification, conception,documentation, codage, etc.).

Du fait de certaines de ces erreurs, le code peut exécutable peutcontenir des fautes.

À l’exécution, certaines de ces fautes peuvent entraîner unedéfaillance du programme.

erreur faute défaillance erreur . . .


Test du logiciel

Concepts de base


Définition (Erreur, faute et défaillance)Des erreurs peuvent être commises lors des différentes activitésréalisées pour obtenir le code exécutable (spécification, conception,documentation, codage, etc.).





Test du logiciel

Concepts de base







Test du logiciel

Concepts de base







Test du logiciel

Concepts de base







Test du logiciel

Concepts de base

Classification des fautes du code source

Nature ExempleCalcul (float)(x/y) au lieu de

((float)x)/((float) y)

Logique if (x < y) au lieu de if(x <= y) ouif(Math.abs(x-y) < epsilon)

E/S erreur d’encodage ou de conversionAccès aux données while(i<=t.length) au lieu de

while(i<t.ength) ou bien x.truc() aulieu de if(x!=NULL) x.truc()

Interface x.truc(a,b) au lieu de x.truc(b,a)

Typage int x au lieu de long x


Test du logiciel

Concepts de base

Exemples de défaillances logicielles

La présence de fautes dans l’exécutable peut entraîner (mais passystématiquement) des défaillances à l’exécution :

l’exécution du programme produit un résultat qui n’est pas le bonl’exécution du programme ne se termine pas (boucle infinie)à l’exécution, le programme consomme trop de ressource etparalyse la machineà l’exécution, une défaillance prévue se produit, un traitementd’exception est réalisé, le programme se termine proprement,sans produire le résultatà l’exécution, une défaillance imprévue se produit, le noyau del’OS arrête immédiatement le programme, aucun résultat n’estproduit


Test du logiciel

Concepts de base



l’exécution du programme produit un résultat qui n’est pas le bon

l’exécution du programme ne se termine pas (boucle infinie)à l’exécution, le programme consomme trop de ressource etparalyse la machineà l’exécution, une défaillance prévue se produit, un traitementd’exception est réalisé, le programme se termine proprement,sans produire le résultatà l’exécution, une défaillance imprévue se produit, le noyau del’OS arrête immédiatement le programme, aucun résultat n’estproduit


Test du logiciel

Concepts de base



l’exécution du programme produit un résultat qui n’est pas le bonl’exécution du programme ne se termine pas (boucle infinie)

à l’exécution, le programme consomme trop de ressource etparalyse la machineà l’exécution, une défaillance prévue se produit, un traitementd’exception est réalisé, le programme se termine proprement,sans produire le résultatà l’exécution, une défaillance imprévue se produit, le noyau del’OS arrête immédiatement le programme, aucun résultat n’estproduit


Test du logiciel

Concepts de base



l’exécution du programme produit un résultat qui n’est pas le bonl’exécution du programme ne se termine pas (boucle infinie)à l’exécution, le programme consomme trop de ressource etparalyse la machine

à l’exécution, une défaillance prévue se produit, un traitementd’exception est réalisé, le programme se termine proprement,sans produire le résultatà l’exécution, une défaillance imprévue se produit, le noyau del’OS arrête immédiatement le programme, aucun résultat n’estproduit


Test du logiciel

Concepts de base



l’exécution du programme produit un résultat qui n’est pas le bonl’exécution du programme ne se termine pas (boucle infinie)à l’exécution, le programme consomme trop de ressource etparalyse la machineà l’exécution, une défaillance prévue se produit, un traitementd’exception est réalisé, le programme se termine proprement,sans produire le résultat

à l’exécution, une défaillance imprévue se produit, le noyau del’OS arrête immédiatement le programme, aucun résultat n’estproduit


Test du logiciel

Concepts de base



l’exécution du programme produit un résultat qui n’est pas le bonl’exécution du programme ne se termine pas (boucle infinie)à l’exécution, le programme consomme trop de ressource etparalyse la machineà l’exécution, une défaillance prévue se produit, un traitementd’exception est réalisé, le programme se termine proprement,sans produire le résultatà l’exécution, une défaillance imprévue se produit, le noyau del’OS arrête immédiatement le programme, aucun résultat n’estproduit


Test du logiciel

Concepts de base

Test du logiciel : définitions

Définition (Test du logiciel (inspiré de [1]))Tester, c’est exécuter un programme dans le but de constater desdéfaillances et de trouver des fautes

Définition (Test du logiciel (inspiré de [2]))Le test du logiciel consiste à vérifier dynamiquement que lecomportement d’un programme est conforme au comportementattendu. Cette vérification est faîte sur un ensemble fini de cas detest, sélectionnés de façon adéquate parmi l’ensemblepotentiellement infini des cas possibles.


Test du logiciel

Concepts de base


Définition (Test du logiciel (inspiré de [1]))Tester, c’est exécuter un programme dans le but de constater desdéfaillances et de trouver des fautes

Définition (Test du logiciel (inspiré de [2]))Le test du logiciel consiste à vérifier dynamiquement que lecomportement d’un programme est conforme au comportementattendu. Cette vérification est faîte sur un ensemble fini de cas detest, sélectionnés de façon adéquate parmi l’ensemblepotentiellement infini des cas possibles.


Test du logiciel

Concepts de base


Définition (Test du logiciel)Le test est un moyen d’assurer la qualité des logiciels, en vérifiant surun ensemble de cas pertinents (car potentiellement capables demettre à jour une faute) que le comportement du code exécuté estconforme au comportement attendu.

Dans cette définition, le test n’est pas restreint à une simplevérification de l’étape de codage :

participe à l’activité de qualité logiciellepeut être vu comme un guide pour l’étape de développement(l’objectif est alors d’écrire du code « qui passe les tests »)


Test du logiciel

Concepts de base


Définition (Test du logiciel)Le test est un moyen d’assurer la qualité des logiciels, en vérifiant surun ensemble de cas pertinents (car potentiellement capables demettre à jour une faute) que le comportement du code exécuté estconforme au comportement attendu.

Dans cette définition, le test n’est pas restreint à une simplevérification de l’étape de codage :

participe à l’activité de qualité logiciellepeut être vu comme un guide pour l’étape de développement(l’objectif est alors d’écrire du code « qui passe les tests »)


Test du logiciel

Les cibles

Plan

1 Introduction


3 JUnit

4 TdD Quizz !

5 Références


Test du logiciel

Les cibles

Classification selon les cibles

Les techniques de test sont utilisées à différentes étapes dudéveloppement d’un logiciel et sont donc appliquées à des cibles denatures différentes. Selon ce critère, on aboutit aux 3 grandesclasses suivantes :

tests unitairestests d’intégrationtests systèmes


Test du logiciel

Les cibles

Les tests unitaires

Définition (Tests unitaires)Les tests unitaires visent à vérifier le fonctionnement en isolation deportions de code testables séparément.

Exemples d’unité de test :

une méthodeun service offert par un composant


Test du logiciel

Les cibles

Les tests unitaires

Définition (Tests unitaires)Les tests unitaires visent à vérifier le fonctionnement en isolation deportions de code testables séparément.

Exemples d’unité de test :

une méthodeun service offert par un composant


Test du logiciel

Les cibles

Les tests d’intégration

Définition (Tests d’intégration)Les tests d’intégration visent à vérifier le fonctionnement de lacomposition de deux portions de codes (deux unités de test)interagissant l’une avec l’autre.

Exemple de test d’intégration :intégration d’une unité d’affichage d’une table et d’une unité detraitement de table (tri, ajout, retrait, sélection, etc.)intégration d’une unité de connexion et d’une unitéd’identification / authentification

Plusieurs approches :bottom-up (resp. top-bottom) : intégration et test d’intégration enremontant (resp. descendant) l’arbre de décompositionfonctionnellebig-band : intégration et test d’intégration simultanément pourtous les composants


Test du logiciel

Les cibles






Test du logiciel

Les cibles






Test du logiciel

Les cibles

Les tests systèmes

Définition (Tests systèmes)Les tests systèmes visent à vérifier le comportement du systèmecomplet :

test des performances, de la sûreté de fonctionnement dusystème ;test d’intégration du système avec l’environnement d’exploitation(Hardware, OS, librairies, etc.)


Test du logiciel

Les objectifs

Plan

1 Introduction


3 JUnit

4 TdD Quizz !

5 Références


Test du logiciel

Les objectifs

Classification selon les objectifs

Les techniques de test sont utilisées dans buts différents. Selon cecritère, on aboutit aux classes suivantes :

tests de conformité (ou test de correction, ou encore testfoncitonnel)test de régressiontest de performancetest d’utilisabilitétests d’acceptation (ou de qualification, de recette)α-test et β-testetc.


Test du logiciel

Les objectifs

Les tests de conformité

Définition (Tests de conformité)Les tests de conformité ont pour but de vérifier la conformité entre lecomportement à l’exécution et le comportement spécifié.


Test du logiciel

Les objectifs

Les tests de régression

DéfinitionLes tests de régression ont pour but de vérifier que desmodifications/évolutions n’ont pas eu d’effets négatifs inattendus, enmontrant que les tests qui passaient jusqu’alors et non impactés parl’évolution/modification testée, passent toujours.

Il s’agit de rejouer les tests passés précédemment :raison supplémentaire pour intégrer les tests comme élémentssous contrôle de la gestion de configuration


Test du logiciel

Les objectifs

Les tests de régression

DéfinitionLes tests de régression ont pour but de vérifier que desmodifications/évolutions n’ont pas eu d’effets négatifs inattendus, enmontrant que les tests qui passaient jusqu’alors et non impactés parl’évolution/modification testée, passent toujours.

Il s’agit de rejouer les tests passés précédemment :raison supplémentaire pour intégrer les tests comme élémentssous contrôle de la gestion de configuration


Test du logiciel

Les objectifs

Les tests d’acceptation

Définition (Tests d’acceptation)Les tests d’acceptation ont pour but de valider le développementcomplet du logiciel. Il s’agit de vérifier que le logiciel peut être utilisépour mener à bien un certain nombres de scénarios, fixés par leclient.


Test du logiciel

Les techniques

Plan

1 Introduction


3 JUnit

4 TdD Quizz !

5 Références


Test du logiciel

Les techniques

Classification selon les techniques

L’une des difficultés du test réside dans la sélection d’un ensemblefini de données de test pertinentes. Pour surmonter cette difficulté,des approches systématiques ont été proposées. Elles sontgénéralement classées en 2 catégories :

test en boite noire : sélection des cas de test sans rien connaîtrede la façon dont l’entité testée est réalisée.test en boîte blanche : sélection des cas de test basée sur laconnaissance de la façon dont l’entité testée est réalisée.


Test du logiciel

Les techniques

Techniques en boîte noire

Les techniques suivantes relèvent de l’approche « boîte noire » :

analyse partitionnelleétude aux limitesanalyse par table de décisiontest aléatoire


Test du logiciel

Les techniques

Analyse partitionnelle : principes

Idée : le domaine d’entrée de l’entité à tester est partitionné enclasses d’équivalence. Pour tester l’implémentation, il suffit de choisirun cas de test par classe d’équivalence, car un cas est représentatifde sa classe.

Comment identifier les classes d’équivalence ?boîte noire pure :

le domaine de chaque paramètre d’entrée est partitionné ensous-domaines valides et invalides (= classes d’équivalence)on choisit un représentant de chaque classe comme cas de test

boîte grise :identification et utilisation du partitionnement réalisé par le code


Test du logiciel

Les techniques

Analyse partitionnelle : principes

Idée : le domaine d’entrée de l’entité à tester est partitionné enclasses d’équivalence. Pour tester l’implémentation, il suffit de choisirun cas de test par classe d’équivalence, car un cas est représentatifde sa classe.

Comment identifier les classes d’équivalence ?boîte noire pure :

le domaine de chaque paramètre d’entrée est partitionné ensous-domaines valides et invalides (= classes d’équivalence)on choisit un représentant de chaque classe comme cas de test

boîte grise :identification et utilisation du partitionnement réalisé par le code


Test du logiciel

Les techniques

Analyse partitionnelle : exemple

Soit à tester la méthodepublic static int nbJoursDansMois(int mois, int annee) (laspécification précise que la méthode ne couvre que le XXIèmesiècle) ?

Boîte noire pure :

mois[−231, 0] [1, 12] [13, 231 − 1]invalide valide invalide

annee[−231, 2000] [2001, 2100] [2101, 231 − 1]

invalide valide invalide

On en déduit par exemple les cas de tests suivants :(mois, annee) ∈ {(−4, 2010), (9, 2010), (15, 2222), (9,−10), (9, 2222)}


Test du logiciel

Les techniques



Boîte noire pure :


annee[−231, 2000] [2001, 2100] [2101, 231 − 1]




Test du logiciel

Les techniques



Boîte noire pure :


annee[−231, 2000] [2001, 2100] [2101, 231 − 1]




Test du logiciel

Les techniques



Boîte noire pure :


annee[−231, 2000] [2001, 2100] [2101, 231 − 1]




Test du logiciel

Les techniques

Analyse partitionnelle : limites

Permet de limiter le nombre des cas de test à 1 cas par classed’équivalence du domaine d’entrée :

permet de déterminer si cette classe est correctement traitée

Mais :

ne permet pas de vérifier si les frontières entre les classes sontcorrectement établiesne tient pas compte des éventuelles différences de traitemententre les éléments appartement à la même classe

nécessite de prendre en compte la relation entrées / sorties


Test du logiciel

Les techniques

Analyse partitionnelle : limites

Permet de limiter le nombre des cas de test à 1 cas par classed’équivalence du domaine d’entrée :

permet de déterminer si cette classe est correctement traitée

Mais :

ne permet pas de vérifier si les frontières entre les classes sontcorrectement établiesne tient pas compte des éventuelles différences de traitemententre les éléments appartement à la même classe



Test du logiciel

Les techniques

Étude aux limites : principes

Idée : de nombreuses erreurs résultent en une faute logique oucalculatoire, qui peut avoir pour conséquence de provoquer unbranchement erroné pour les éléments aux limites des classesd’équivalence du domaine d’entrée. On va donc testerparticulièrement des éléments situés sur ces frontières :

juste avant la frontièresur la frontièrejuste après la frontière

Cette technique s’utilise en complément de l’analyse partitionnelle


Test du logiciel

Les techniques

Étude aux limites : exemple

On établit des cas de test pour la méthodepublic static int nbJoursDansMois(int mois, int annee).

Proposez des cas de test qui permettent de réaliser une étude auxlimites

limite pour le paramètre mois :

entre 0 et 1 (limite basse) et entre12 et 13 (limite haute)

limite pour le paramètre année :

entre 2000 et 2001 (limite basse)et entre 2100 et 2101 (limite haute)

On en déduit par exemple les cas de tests suivants :(mois, annee) ∈

{(0, 2010), (1, 2010), (12, 2010), (13, 2010), (6, 2000), (6, 2001), (6, 2100), (6, 2101)}


Test du logiciel

Les techniques




limite pour le paramètre mois :

entre 0 et 1 (limite basse) et entre12 et 13 (limite haute)

limite pour le paramètre année :

entre 2000 et 2001 (limite basse)et entre 2100 et 2101 (limite haute)


{(0, 2010), (1, 2010), (12, 2010), (13, 2010), (6, 2000), (6, 2001), (6, 2100), (6, 2101)}


Test du logiciel

Les techniques




limite pour le paramètre mois : entre 0 et 1 (limite basse) et entre12 et 13 (limite haute)limite pour le paramètre année : entre 2000 et 2001 (limite basse)et entre 2100 et 2101 (limite haute)


{(0, 2010), (1, 2010), (12, 2010), (13, 2010), (6, 2000), (6, 2001), (6, 2100), (6, 2101)}


Test du logiciel

Les techniques




limite pour le paramètre mois : entre 0 et 1 (limite basse) et entre12 et 13 (limite haute)limite pour le paramètre année : entre 2000 et 2001 (limite basse)et entre 2100 et 2101 (limite haute)


{(0, 2010), (1, 2010), (12, 2010), (13, 2010), (6, 2000), (6, 2001), (6, 2100), (6, 2101)}


Test du logiciel

Les techniques

Étude aux limites : limites

Permet de vérifier si les frontières entre les classes d’équivalencesont correctement établies

Mais :

multiplie les cas de tests : à utiliser uniquement aux endroits« utiles »

basés sur l’expérience du développeur / testeur

ne tient pas compte des éventuelles différences de traitemententre les éléments appartement à la même classe



Test du logiciel

Les techniques

Étude aux limites : limites

Permet de vérifier si les frontières entre les classes d’équivalencesont correctement établies

Mais :

multiplie les cas de tests : à utiliser uniquement aux endroits« utiles »

basés sur l’expérience du développeur / testeur

ne tient pas compte des éventuelles différences de traitemententre les éléments appartement à la même classe



Test du logiciel

Les techniques

Table de décisions : principes

Idée : on élargit l’analyse partitionnelle au domaine de sortie del’unité testée. On met ensuite en relation les classes d’équivalence dudomaine d’entrée et celles du domaine de sortie. On choisit alors uncas de test pour chaque nouvelle classe créée.

Les tables de décision sont aussi un moyen (déclaratif) de spécifier lecomportement attendu du système : pour un seul effort intellectuel,on dispose donc

d’une spécification de l’unité testéed’un ensemble de cas de test (à compléter (ou pas) par uneétude aux limites)


Test du logiciel

Les techniques

Table de décisions : principes

Idée : on élargit l’analyse partitionnelle au domaine de sortie del’unité testée. On met ensuite en relation les classes d’équivalence dudomaine d’entrée et celles du domaine de sortie. On choisit alors uncas de test pour chaque nouvelle classe créée.

Les tables de décision sont aussi un moyen (déclaratif) de spécifier lecomportement attendu du système : pour un seul effort intellectuel,on dispose donc

d’une spécification de l’unité testéed’un ensemble de cas de test (à compléter (ou pas) par uneétude aux limites)


Test du logiciel

Les techniques

Table de décisions : exemples

Entrées

mois

[−231, 0]{1, 3, 5, 7, 8, 10, 12}

{4, 6, 9, 11}2

[13, 231 − 1]

année[−231, 2001]

bissextilesbissextiles

[2100, 231 − 1]

Sortie

31302928

entrées invalides

Avec bissextile = {x ∈ [2001, 2100] : (x ≡ 0(mod 4) ∧ x 6≡ 0(mod 100)) ∨ (x ≡ 0(mod 400))} etbissextile = [2001, 2100] \ bissextile


Test du logiciel

Les techniques

Table de décisions : exemples

Entrées

mois

[−231, 0] X{1, 3, 5, 7, 8, 10, 12} X X

{4, 6, 9, 11} X X2 X X

[13, 231 − 1] X

année[−231, 2001] X

bissextiles X X Xbissextiles X X X

[2100, 231 − 1] X

Sortie

31 X X30 X X29 X28 X

entrées invalides X X X X

Avec bissextile = {x ∈ [2001, 2100] : (x ≡ 0(mod 4) ∧ x 6≡ 0(mod 100)) ∨ (x ≡ 0(mod 400))} etbissextile = [2001, 2100] \ bissextile

On en déduit par exemple les cas de test suivants :(mois, anne) ∈

{(−3, 2050), (15, 2050), (3, 1930), (3, 2111), (3, 2010), (4, 2010), (2, 2004), (2, 2005)}


Test du logiciel

Les techniques

Table de décisions : limites

Affine l’analyse partitionnelle, en tenant compte de la relation entreles classes d’équivalence des entrées et celles des sorties

Mais :

ne permet pas de tester les frontières entre les classesd’équivalence : à utiliser conjointement avec une étude auxlimites pour les cas adaptés


Test du logiciel

Les techniques

Table de décisions : limites

Affine l’analyse partitionnelle, en tenant compte de la relation entreles classes d’équivalence des entrées et celles des sorties

Mais :

ne permet pas de tester les frontières entre les classesd’équivalence : à utiliser conjointement avec une étude auxlimites pour les cas adaptés


Test du logiciel

Les techniques

Tests aléatoires : principes

Idée : pour certaines unités testées, il est possible de générerautomatiquement des cas de test. On a donc, gratuitement, lapossibilité de tester massivement l’unité. Deux intérêts :

permet de trouver des fautes non mises à jour par les autrestechniquesoffre une mesure de la qualité des autres cas de test

si les cas de test générés aléatoirement trouvent plus de fautesque les cas de test générés systématiquement, ces derniers sontsans doute à revoir

Par ailleurs, dans certains cas, les techniques systématiques ne sontpas applicables : le test aléatoire est alors la seule possibilitérestante.


Test du logiciel

Les techniques

Tests aléatoires : exemples

1 public OracleTCNbJoursDansMois {2 private int mois;3 private int annee;4 private int nbJours;5 private static Random tirage = new Random(0);6

7 public OracleTCNbJoursDansMois( ) {8 mois = 1 + (tirage.nextInt() % 12);9 annee = 2001 + (tirage.nextInt() % 99);

10 GregorianCalendar gc = new GregorianCalendar(annee, mois, 1);11 nbJours = gc.getActualMaximum(GregorianCalendar.DAY_OF_MONTH);12 }13

14 public int getTCInputMonth() {return mois};15 public int getTCInputYear() {return annee};16 public int getTCResult() {return nbJours};17 }

Attention : code non compilé, non testé, etc.


Test du logiciel

Les techniques

Tests aléatoires : limites

Permet de mesurer la qualité des tests systématiques, etéventuellement de détecter des fautes « non classiques »

Mais :

ne peut venir qu’en complément des tests systématiques car negarantissent aucun critère de couverturenécessite de disposer d’un oracle pour permettre la générationautomatique des CT

pas applicable dans toutes les situations !


Test du logiciel

Les techniques

Tests aléatoires : limites

Permet de mesurer la qualité des tests systématiques, etéventuellement de détecter des fautes « non classiques »

Mais :

ne peut venir qu’en complément des tests systématiques car negarantissent aucun critère de couverturenécessite de disposer d’un oracle pour permettre la générationautomatique des CT

pas applicable dans toutes les situations !


Test du logiciel

Les techniques

Les techniques en boîte blanche

Les techniques en boîte blanche se basent sur une analyse du codesource de l’unité à tester :

Tests basés sur l’analyse du graphe de flot de contrôlecouverture de toutes les conditionscouverture de tous les chemins

Tests basés sur l’analyse du graphe de flot de donnéescouverture des chaînes définitions / références pour chaquevariable

La génération de cas de test relevant de techniques boîte blanche estautomatisable.


Test du logiciel

Exigences pour la mise en œuvre des tests

Plan

1 Introduction


3 JUnit

4 TdD Quizz !

5 Références


Test du logiciel


Mise en œuvre des tests

Activités relatives aux tests :Définition des cas de testDéveloppement et exécution des testsÉvaluation des résultatsJournalisation du processus de testSuivi des fautes (« bugtracking »)etc.

Elles doivent être :

intégrées dans le processus de développement de l’applicationmanipulables par les outils de gestion de configuration du projetsupportées par des outils spécifiques


Test du logiciel


Définition des cas de test

Plusieurs approches complémentaires :

application des techniques systématiques (cf. ci-dessus)si possible, développement d’un oracle pour la réalisation detests aléatoires (voir exhaustif)ré-utilisation de cas pré-existants, ou adaptation de casdéveloppés pour des pb similaires

Les outils de développement et d’exécution doivent supporter tousces cas d’utilisation


Test du logiciel


Développement et exécution des tests

Développement : l’outil doitêtre intégré à l’environnement de développement de l’applicationpermettre de séparer le code des tests du code applicatifoffrir les abstractions nécessaires pour faciliter l’écriture des CTpermettre la ré-utilisation / spécialisation des CT

Exécution : l’outil doitpermettre la reproductibilité des testspermettre une évaluation claire du résultat (traçabilité entre lecode du test et les résultats)être exécutable à la demande (test/dev d’une unité) ou en batch(test de régression d’une nouvelle version)ne pas s’arrêter sur un test révélant une défaillance (gestion desinterruptions, des crash, etc.)


Test du logiciel


Journalisation du processus

Contexte d’une campagne de test :un testeurune certaine version de l’unité testéedes CTune configuration de l’environnement de dév.une dateetc.

Tous ces facteurs peuvent influer sur les résultats du test (cf. sourcesd’erreur en introduction). Pour permettre le suivi des campagnes detest et la reproductibilité des résultats, il faut donc journaliser toutesces informations.


Test du logiciel


Suivi des fautes

Rôles des tests dans le processus de développement logiciel :détection des fautes

quand est-elle apparue ?quelle type d’erreur en est la cause ?peut-elle être évitée en améliorant le processus de développement

preuve de correction des fautesquand a-t-elle disparue ?quelles mesures correctives ont dues être prises ? quelle quantitéde travail engendrée ?quelle a été la réactivité de l’équipe de développement ?

Les tests sont un outil concret pour le processus de mise en qualitédu logiciel.


JUnit

Plan

1 Introduction

2 Test du logiciel


4 TdD Quizz !

5 Références


JUnit

Présentation

Plan

1 Introduction

2 Test du logiciel


4 TdD Quizz !

5 Références


JUnit

Présentation

JUnit

Framework open-source pour la mise en œuvre des tests unitairesd’applications Java :

développement des CTexécution et évaluation des tests

Open-source extensible / adaptable / documenté :intégré à la majorité des IDEs Java (Eclipse, Netbeans, etc.)manipulable via les outils de gestion de configuration (Ant,Maven, etc.)étendus pour couvrir des domaines fonctionnels spécifiques(appli J2EE, appli HTTP, etc.)


JUnit

Présentation

JUnit

Développé par Kent Beck et Erich Gammabasé sur SUnit de Kent Beck (tests unitaires de programmesSmalltalk)nombreuses variantes : PHPUnit, CPPUnit, NUnit, etc.

Ce cours porte sur la version 4.0.refonte majeure par rapport aux versions précédentes (la 3.8 estaussi largement utilisée)

Le framework, ses sources, et des articles explicatifs sont disponiblesici :

http://www.junit.org



JUnit

Définition d’un cas de test

Plan

1 Introduction

2 Test du logiciel


4 TdD Quizz !

5 Références


JUnit


Exemple

1 import static org.junit.Assert.assertEquals;2 import org.junit.Test;3 import tdd.undertest.MonCalendrier;4 public class TestNbJoursDansMois {5 @Test6 public void testMois31j () {7 MonCalendrier cal = new MonCalendrier();8 assertEquals("Mois 31j",31,cal.nbJoursDansMois(3,2010));9 }

10 @Test11 public void testMois30j () {12 MonCalendrier cal = new MonCalendrier();13 assertEquals("Mois 30j",30,cal.nbJoursDansMois(4,2010));14 }15 ...16 }


JUnit


La classe org.junit.Assert

Une classe contenant des méthodes de tests réalise une importationstatique des méthodes de la classe org.junit.Assert

Elle définie entre autre les méthodes publiques statiques suivantes :assertEquals(String msg, Object expected, Object actual)

assertSame(String m, Object exp, Object act)

assertEquals(String m, Object exp[], Object act[])

assertEquals(String m, float exp, float act, float delta)

assertTrue(String m, boolean b)

assertNotNull(String m, Object o)

fail(String m)

+ de détails :http://junit.sourceforge.net/javadoc_40/index.html

http://junit.sourceforge.net/javadoc_40/index.html


JUnit


Suite de l’exemple

1 import static org.junit.Assert.assertEquals;2 import org.junit.Test;3 import tdd.undertest.MonCalendrier;4 public class TestNbJoursDansMois {5 @Test(expected=IllegalArgumentException.class)6 public void testMoisInvalide1 {7 MonCalendrier cal = new MonCalendrier();8 cal.nbJoursDansMois(-3,2010);9 fail("Mois invalide : inf ou egal 0");

10 }11 @Test(expected=IllegalArgumentException.class)12 public void testMoisInvalide2 {13 MonCalendrier cal = new MonCalendrier();14 cal.nbJoursDansMois(15,2010);15 fail("Mois invalide : sup ou egal 13");16 }17 }

> java org.junit.runner.JUnitCore TestNbJoursDansMois


JUnit


Limites

Pour qualifier JUnit de framework de test « mature », il faudrait pallierles défauts suivants :

répétition du code : obligation de construire l’unité testée danschaque méthoderéutilisation des mêmes patrons de code pour les classes detest : on voudrait automatiser celaproblème des boucles infinieslancement classe de test par classe de test : pas adapté auxtests de non régression

JUnit apporte des réponses à toutes ces questions. Reprenonsl’exemple ...


JUnit


Limites

Pour qualifier JUnit de framework de test « mature », il faudrait pallierles défauts suivants :

répétition du code : obligation de construire l’unité testée danschaque méthoderéutilisation des mêmes patrons de code pour les classes detest : on voudrait automatiser celaproblème des boucles infinieslancement classe de test par classe de test : pas adapté auxtests de non régression

JUnit apporte des réponses à toutes ces questions. Reprenonsl’exemple ...


JUnit


1 import static org.junit.Assert.assertEquals;2 import org.junit.Before;3 import org.junit.Test;4 import org.junit.runner.RunWith;5 import org.junit.runners.Parameterized;6 import org.junit.runners.Parameterized.Parameters;7

8 import tdd.undertest.MonCalendrier;9

10 @RunWith (value = Parameterized.class)11 public class NbJoursDansMoisNominal {12

13 private int mois;14 private int annee;15 private int resultat;16 private MonCalendrier cal;17

18 public NbJoursDansMoisNominal(int m, int a, int r) {19 mois = m ; annee = a; resultat = r;20 }


JUnit


1 @Before2 public void creeCalendrier() {3 cal = new MonCalendrier();4 }5 @Parameters6 public static Collection casDeTest () {7 Object[][] casDeTest = {{3, 2010, 31}, {4,2010,30} ,8 {2,2004,29},{2,2005,28}};9 return Arrays.asList(casDeTest);

10 }11 @Test(timeout=500)12 public doIt() {13 assertEquals("Test cas nominal", resultat,14 cal.nbJoursDansMois(mois,annee);15 }16 }


JUnit


1 import static org.junit.Assert.assertEquals;2 import org.junit.Before;3 import org.junit.Test;4 import org.junit.runner.RunWith;5 import org.junit.runners.Parameterized;6 import org.junit.runners.Parameterized.Parameters;7

8 import tdd.undertest.MonCalendrier;9

10 @RunWith (value = Parameterized.class)11 public class NbJoursDansMoisIllegalArg {12

13 private int mois;14 private int annee;15 private MonCalendrier cal;16

17 public NbJoursDansMoisNominal(int m, int a) {18 mois = m ; annee = a;19 }


JUnit


1 @Before2 public void creeCalendrier() {3 cal = new MonCalendrier();4 }5 @Parameters6 public static Collection casDeTest () {7 Object[][] casDeTest = {{-3, 2050}, {15,2050} ,8 {3,1930},{3,2111}};9 return Arrays.asList(casDeTest);

10 }11 @Test(timeout=500, expected=IllegalArgumentException.class)12 public doIt() {13 cal.nbJoursDansMois(mois,annee);14 }15 }


JUnit


1 import org.junit.runner.RunWith;2 import org.junit.runners.Suite;3 import org.junit.runners.Suite.SuiteClasse;4

5 @RunWith(value=Suite.class)6 @SuiteClasses({NbJoursDansMoisNominal.class,7 NbJoursDansMoisIllegalArg.class})8 public class AllTests {}


JUnit


Autres fonctionnalités de JUnit

Quelques annotations supplémentaires :@After : pendant de @Before

@BeforeClass (resp. @AfterClass) : méthode exécuté auchargement (resp. déchargement) de la classe de test@Ignore : annule temporairement l’annotation @Test d’uneméthode

Plus d’infos :http://www.junit.org

http://junit.sourceforge.net/doc/faq/faq.htm


http://junit.sourceforge.net/doc/faq/faq.htm


JUnit

Les tests dans la gestion de configuration

Plan

1 Introduction

2 Test du logiciel


4 TdD Quizz !

5 Références


JUnit


Où placer les tests ?

1 Il faut séparer les classes de tests des classes applicatives :contrôle du nombre de fichiers par répertoire, pour une meilleurelisibilitéfacilite l’écriture des règles de construction

construction des tests pour les versions de développementnon inclusion des tests pour les distributions

2 Pour faciliter l’écriture des tests, les classes de test doivent avoiraccès aux attributs et méthodes de visibilité publique et packagedes classes testées

Peut-on trouver une solution qui remplisse ces deux contraintes ?


JUnit


Où placer les fichiers de test ?

src|- lpsil

|- tdd|- tp

test|- lpsil

|- tdd|- tp

Les deux répertoires sont à mettre dans le CLASSPATH. Ainsi, lemême package est séparé en deux répertoires.


JUnit


Tests et gestion de configuration

Tests = moyen de contrôler la qualité du développementavant chaque commit

construction des tests, de l’application puis exécution des testssi les tests ne sont pas validés, commit annulé

idem pour la construction des distributionsmise en place de scripts pour l’exécution régulières des tests

checkout d’une version précise de l’applicationconstruction des tests, de l’application, puis exécution des testsjournalisation de cette exécutionmise à jour du suivi de fautes


TdD Quizz !

Plan

1 Introduction

2 Test du logiciel

3 JUnit

4 TdD Quizz !

5 Références


TdD Quizz !

Donnez un exemple de cycle erreur faute défaillance erreur

Supposons qu’on développe un logiciel de comptabilité1 erreur : lors du codage, le programmeur ne tient pas compte de

la précision finie de la machine pour stocker et manipuler lesnombres flottants

2 faute : lorsque le logiciel est sollicité, des erreurs d’arrondis sontcommises

3 défaillance : le bilan comptable ne correspond pas à la réalité(surévalués ou sousévalués)


TdD Quizz !

Donnez un exemple de cycle erreur faute défaillance erreur

Supposons qu’on développe un logiciel de comptabilité1 erreur : lors du codage, le programmeur ne tient pas compte de

la précision finie de la machine pour stocker et manipuler lesnombres flottants

2 faute : lorsque le logiciel est sollicité, des erreurs d’arrondis sontcommises

3 défaillance : le bilan comptable ne correspond pas à la réalité(surévalués ou sousévalués)


TdD Quizz !

Que conclure lorsqu’une campagne de test qui ne détecte aucunedéfaillance ?

La réponse dépend du contexte dans lequel cette campagne a étéexécutée :

s’il s’agit d’une campagne qui vient analyser un incrémentimportant du projet, il faut remettre en question la pertinence descas de test : les bugs sont là, les cas de tests auraient dupermettre d’en détecter un grand nombres’il s’agit d’une campagne qui est rejouée pour valider une phasede débuggage, il faut valider cette phase : tous les bugs détectésont été corrigés.

Pour info :une unité : la densité de bug (nombre d’erreurs par 1000 lignesde code)une réalité : si elle varie selon l’expérience du programmeur, lelangage et l’environnement utilisé, la complexité du projet, etc. ...elle est toujours supérieure à 0 !


TdD Quizz !






TdD Quizz !






TdD Quizz !

Dans JUnit, quelle est la différence entre assertEquals etassertSame ?

assertEquals teste si deux objets sont égaux au sens de l’égalitélogique. Elle utilise pour cela la méthodepublic boolean equals(Object o).

Pensez à redéfinir equals pour les objets testés !

assertSame teste si deux objets sont égaux au sens de l’égalitélogique. Plus concrètement, elle teste si les deux références passéesen argument désignent le même objet physique (la même adressemémoire)


TdD Quizz !

Dans JUnit, quelle est la différence entre assertEquals etassertSame ?

assertEquals teste si deux objets sont égaux au sens de l’égalitélogique. Elle utilise pour cela la méthodepublic boolean equals(Object o).

Pensez à redéfinir equals pour les objets testés !

assertSame teste si deux objets sont égaux au sens de l’égalitélogique. Plus concrètement, elle teste si les deux références passéesen argument désignent le même objet physique (la même adressemémoire)


Références

Plan

1 Introduction

2 Test du logiciel

3 JUnit

4 TdD Quizz !

5 Références


Références

Références

[1] G. J. MyersThe Art of Software Testing, 2nd Edition.Wiley, 2004.

[2] IEEE Computer SocietyGuide to the Software Engineering Body of KnowledgeIEEE, 2004.

Documents

Mise en œuvre des tests logiciels - Nicolas Hernandeze.nicolas.hernandez.free.fr/pub/ens/tdd/TdD08_CM04_SF.pdf · Mise en œuvre des tests logiciels Introduction Plan 1 Introduction