CCI Génie Logiciel UFR - IMA 1 Génie Logiciel Validation par le test

Transcription

CCI Génie Logiciel UFR - IMA 1 Génie Logiciel Validation par le test
CCI
Génie Logiciel
UFR - IMA
Objectifs du cours d'aujourd'hui
Génie Logiciel
Validation par le test
ƒ Donner des réponses aux questions suivantes :
ƒ Qu’est-ce que « tester un programme » ?
ƒ Pourquoi tester ?
Lydie du Bousquet
UJF – Grenoble I
ƒ Quand tester ?
ƒ Comment tester ?
ƒ Quand s’arrêter de tester ?
2
UJF – Grenoble I
Qu’est-ce que tester un programme ?
ƒ Tester un programme, c'est :
Qu’est-ce que tester un programme ?
ƒ l’exécuter
ƒ en maîtrisant les données en entrée
ƒ en s’assurant que le comportement est celui attendu
Exercice 1 :
Inscrivez sur une feuille ce que
« tester un programme » signifie
pour vous.
ƒ Exécution du programme sous test => exécutable
ƒ Maîtrise des entrées
ƒ Sélectionner = choisir
ƒ assez de données, mais pas trop
ƒ Vérification du comportement
ƒ pouvoir observer le comportement
ƒ adopter une vision critique
4
UJF – Grenoble I
Pourquoi tester ?
Pourquoi tester ?
ƒ Parce que programmer est une activité où l’on commet
des erreurs
ƒ Parce que les autres techniques de validation (relecture
de code, preuves formelles ou autres)
ƒ C’est une question clé
ƒ Pourquoi est-ce que vous testez ?
ƒ Pas toujours possibles
ƒ Pas toujours complètement convaincantes
ƒ Est-ce que vous accepteriez de monter dans un avion qui n’a
jamais été testé en vol mais dont les fabricants vous garantissent
qu’ils ont «!prouvé!» que tout allait bien se passer ?
Exercice 2 :
Inscrivez sur une feuille
« pourquoi est-ce que vous
testez (pourquoi faire) ?».
ƒ Réponse de Myers 1979
« Tester pour rechercher des erreurs »
5
UJF – Grenoble I
6
UJF – Grenoble I
1
CCI
Génie Logiciel
UFR - IMA
Quel type d’erreur recherche-t-on ?
Pourquoi tester ?
ƒ On attend du logiciel certaines propriétés
ƒ On teste pour rechercher des erreurs
ƒ Quels types d’erreur ?
ƒ
ƒ
ƒ
ƒ
Exercice 3 :
Inscrivez sur une feuille « quel
type d’erreur peut-on chercher ?».
absence d’erreur (correction fonctionnelle),
robustesse,
performances,
utilisabilité, ...
ƒ Caractérisation des tests selon l’objectif
7
UJF – Grenoble I
ƒ Test de conformité
ƒ Test de robustesse
ƒ Test de performances, de montée en charge
8
UJF – Grenoble I
Quel type d’erreur recherche-t-on ?
Objectifs du cours d'aujourd'hui :
ƒ donner des réponses aux questions suivantes :
ƒ A votre niveau, objectif principal :
ƒ Qu’est-ce que « tester un programme » ?
ƒ correction fonctionnelle
S’assurer que le programme satisfait
ƒ Pourquoi tester ?
ce que l’on attend de lui
= ses spécifications
ƒ Quand tester ?
ƒ Comment tester ?
ƒ Quand s’arrêter de tester ?
9
UJF – Grenoble I
10
UJF – Grenoble I
Quand tester ?
Quand tester un programme ?
Exercice 4 :
Inscrivez sur une feuille votre
réponse à la question « quand
teste-t-on un programme ? »
ƒ On peut tester à différents moments
ƒ
ƒ
ƒ
ƒ
Au cours du développement de chaque fonction
Quand on intègre les modules entre eux
Avant et pendant la livraison
Après les modifications (maintenance, évolution…)
ƒ Caractérisation des tests par rapport à la
« phase » de développement
ƒ
ƒ
ƒ
ƒ
ƒ
Test
Test
Test
Test
Test
unitaire
d’intégration
système
d’acceptation (ou de recette)
de non-régression
12
UJF – Grenoble I
2
CCI
Génie Logiciel
UFR - IMA
Quand tester ?
Analyse
des besoins
Quand tester ?
ƒ A votre niveau, objectif principal :
Test d’acceptation
Spécification
ƒ Test unitaire
ƒ (Test d’intégration)
ƒ Test système
Tests système
Conception
globale
Tests
d’intégration
Conception
détaillée
Tests
unitaires
Codage
13
UJF – Grenoble I
14
UJF – Grenoble I
Objectifs du cours d'aujourd'hui :
Comment choisir des données ?
ƒ Donner des réponses aux questions suivantes :
Qu’est-ce que « tester un programme » ?
Pourquoi tester ?
Quand tester ?
Comment tester ?
ƒ Comment choisir les données ?
ƒ Comment exécuter les tests ?
ƒ Comment décider de la correction ?
ƒ Quand s’arrêter de tester ?
ƒ
ƒ
ƒ
ƒ
Exercice 5 :
Inscrivez sur une feuille votre
réponse à la question « comment
choisir des données de test ? »
15
UJF – Grenoble I
Comment choisir les données ?
Exemple : longueur d’un mot est-elle paire ?
Comment choisir les données ?
ƒ Tester = rechercher des erreurs
ƒ Ici, on s’intéresse à la correction fonctionnelle
On cherche à tester un programme dont on attend
le comportement suivant (spécification informelle)
ƒ Il existe deux grandes stratégies de test
Le programme lit un mot à partir du clavier.
Si le mot a un nombre pair de lettres, le
programme écrit
“L contient un nombre pair de lettres”
Sinon le programme écrit
“L contient un nombre impair de lettres”
ƒ En utilisant la spécification du programme
ƒ En utilisant le code
17
UJF – Grenoble I
18
UJF – Grenoble I
3
CCI
Génie Logiciel
UFR - IMA
Comment choisir les données ?
Exemple : longueur d’un mot est-elle paire ?
Quels tests pour ce programme ?
ƒ Produire les tests à partir de la spécification
ƒ « Couverture des fonctionnalités »
ƒ « Couverture des cas d’utilisation »
ƒ Ici, la spécification décrit explicitement 2 cas
généraux
Exercice 6 :
Proposez des tests pour cet
exemple.
ƒ Mot avec nombre de lettres pair
ƒ Mot avec nombre de lettres impair
ƒ On peut imaginer des cas limites :
ƒ Mot vide
ƒ Mot très long
ƒ Mot avec un ou deux caractères
20
UJF – Grenoble I
Comment choisir les données ?
Exemple : longueur d’un mot est-elle paire ?
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Mot
Mot
Mot
Mot
Mot
Mot
Comment choisir les données ?
Exemple : longueur d’un mot est-elle paire ?
avec nombre de lettres pair
« impair » (p)
avec nombre de lettres impair
« mot » (i)
vide
« »
(p)
comprenant un caractère
« h » (i)
à deux caractères
« kw » (p)
très long
« anticonstitutionnellement » (i)
ƒ Mot avec des majuscules
« Essai » « essAI » « ESSAI »
(i)
« AmsTramGramm » (p)
ƒ Mot avec des espaces « test unitaire » (i)
ƒ Mot avec des caractères spéciaux
« test_d’intégration » (p)
« β-tests » (i)
ƒ Mot avec des chiffres
« test44 » (p)
ƒ Qu’est-ce qu’un mot ?
ƒ Majuscules ? Espaces ? Caractères spéciaux ? Chiffres ?
Tests de robustesse ?
21
UJF – Grenoble I
Comment choisir les données ?
Exemple : longueur d’un mot est-elle paire ?
Comment choisir les données ?
Exemple : longueur d’un mot est-elle paire ?
Mot : séquence de caractères + marque de fin
rangé dans un tableau de [0..N]
1.
2.
3.
4.
5.
M <- LireMot
L=0
Tant que M[L] != MarqueDeFin faire
L=L+1
Fin
6.
7.
8.
9.
Si (L mod 2) = 0
Alors Ecrire(“L contient un nombre pair”)
Sinon Ecrire(“L contient un nombre impair”)
Ecrire(“de lettres”)
10.
11.
12.
13.
Si (L==23)
Alors Ecrire(“.”)
Sinon Ecrire( “…”)
Fin
22
UJF – Grenoble I
ƒ Produire les tests à partir du code
ƒ Graphe de flot de contrôle
ƒ Représentation intermédiaire du code
ƒ Nœuds et transitions représentent les exécutions
possibles
ƒ On s’assure que l’on est passé « partout » selon
certains critères
ƒ
ƒ
ƒ
ƒ
23
UJF – Grenoble I
Toutes les instructions exécutées
Toutes les branches
Toutes les conditions
Tous les chemins
24
UJF – Grenoble I
4
CCI
Génie Logiciel
UFR - IMA
Comment choisir les données ?
Exemple : longueur d’un mot est-elle paire ?
1.
2.
3.
4.
5.
M <- LireMot
L=0
Tant que M[L] != MarqueDeFin faire
L=L+1
Fin
6.
7.
8.
9.
Si (L mod 2) = 0
Alors Ecrire(“L contient un nombre pair”)
Sinon Ecrire(“L contient un nombre impair”)
Ecrire(“de lettres”)
10.
11.
12.
13.
1-2
M[L] != MDF
4,5
3
!(M[L] != MDF)
!(L mod 2)
6
(L mod 2)
7
Si (L!=23)
Alors Ecrire(“.”)
Sinon Ecrire( “…”)
Fin
Comment choisir les données ?
Exemple : longueur d’un mot est-elle paire ?
8
=> Graphe de flot de contrôle
ƒ Couvrir les branches
ƒ Couvrir les transitions
aCertains non exécutables
!(L!=23)
10
11
impair » (p)
mot » (i)
»
(p)
h » (i)
kw » (p)
anticonstitutionnellement » (i)
6
7
8
9
10
!(L!=23)
12
13
26
A propos des objectifs de couverture
1-2
M[L] != MDF
4
3
!(M[L] != MDF)
(L mod 2)
6
7
8
9
ƒ Il faut un test avec un mot
de 23 lettres
(L!=23)
10
!(L!=23)
11
12
13
ƒ Couverture de tous les chemins
exécutables est souvent infaisable
ƒ Couverture des instructions est différente
de la couverture des branches
Exercice 8 :
Proposez des exemples de
programme simple pour illustrer
ces 2 affirmations.
27
UJF – Grenoble I
28
UJF – Grenoble I
A propos des objectifs de couverture
A propos des objectifs de couverture
ƒ Rappel : on teste pour découvrir des erreurs
ƒ Tous les moyens sont bons pour générer les
données
ƒ Couverture des chemins exécutables est souvent
infaisable
ƒ Reprenons l’exemple précédent
ƒ La couverture des chemins exécutables = tester un
mot au moins de chaque longueur entre 0 et l’infini
ƒ Spécification
ƒ Code
ƒ Aucune méthode ne peut garantir l’absence
d’erreur
ƒ Stratégies complémentaires
ƒ A propos de la couverture
ƒ Couverture des instructions est différente de la
couverture des branches
10 Si (L!=23)
11 Alors Ecrire(“.”)
12 Sinon Ecrire( “…”)
10 Si (L!=23)
11 Alors Ecrire(“.”)
(L!=23)
ƒ Indicateur : le test n’est pas fini !
ƒ Ne garantit pas l’absence d’erreur
10
!(L!=23)
11
13
UJF – Grenoble I
(L mod 2)
UJF – Grenoble I
Comment choisir les données ?
Couverture des instructions
«
«
«
«
«
«
4
3
!(M[L] != MDF)
11
25
UJF – Grenoble I
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
M[L] != MDF
(L!=23)
12
13
1-2
ƒ Couvrir les états
ƒ Couvrir les chemins
9
(L!=23)
ƒ Couvrir les instructions
29
30
UJF – Grenoble I
5
CCI
Génie Logiciel
UFR - IMA
Objectifs du cours d'aujourd'hui :
Exécuter des tests
ƒ Donner des réponses aux questions suivantes :
Qu’est-ce que « tester un programme » ?
Pourquoi tester ?
Quand tester ?
Comment tester ?
ƒ Comment choisir les données
ƒ Comment exécuter les tests
ƒ Comment décider de la correction
ƒ Quand s’arrêter de tester ?
ƒ
ƒ
ƒ
ƒ
Exercice 9 :
Comment faites-vous ou feriezvous pour exécuter des tests ?
31
UJF – Grenoble I
Comment exécuter les tests ?
JUnit
ƒ Framework open source pour :
ƒ Exécuter le système sous test en
ƒ les tests unitaires
ƒ des classes Java
ƒ Automatisation de l’exécution
ƒ fournissant les données de tests « à la main »
ƒ observant les sorties
ƒ Programmes de test / batch
ƒ Utilisation d’outils spécialisés
ƒ Existe comme un plug-in Eclipse
ƒ Exemple : porte-monnaie
ƒ J-unit, Cpp-unit
ƒ Watij (pour le test de site web)
ƒ 3 opérations : getBalance(), credit(), débit()
ƒ Maximum Balance : 100 euros
ƒ Projet Java développé sous Eclipse, Purse.java
33
UJF – Grenoble I
34
UJF – Grenoble I
Utiliser JUnit
1. ajouter le JUnit.jar dans le classpath
Utiliser JUnit
1. ajouter le JUnit.jar dans le classpath
35
UJF – Grenoble I
36
UJF – Grenoble I
6
CCI
Génie Logiciel
UFR - IMA
Utiliser JUnit
2. Créer un fichier de test JUnit
2. Créer un fichier de test JUnit
37
UJF – Grenoble I
38
UJF – Grenoble I
2. Créer un fichier de test JUnit
2. Créer un fichier de test JUnit
ƒ Des méthodes de la classe de test
ƒ setUp()
ƒ Pour initialiser les éléments utiles pour tous les tests
ƒ Exemple : initialiser une instance de la classe sous test
ƒ tearDown()
ƒ Pour effectuer des traitements à la fin de tous les tests
ƒ Exemple : libérer l’instance de la classe sous test
ƒ Il faut ajouter des méthodes = cas de tests
ƒ Nom des méthodes doit commencer par test
39
UJF – Grenoble I
40
UJF – Grenoble I
3. Exécuter un fichier de test JUnit
3. Exécuter un fichier de test JUnit
41
UJF – Grenoble I
42
UJF – Grenoble I
7
CCI
Génie Logiciel
UFR - IMA
4. Compléter un fichier de test JUnit
Objectifs du cours d'aujourd'hui :
ƒ Pour le porte-monnaie, on a
ƒ Donner des réponses aux questions suivantes :
ƒ Maximum balance = 100 euros
ƒ On essaie le cas où l’on crédite 101 euros
Qu’est-ce que « tester un programme » ?
Pourquoi tester ?
Quand tester ?
Comment tester ?
ƒ Comment choisir les données ?
ƒ Comment exécuter les tests ?
ƒ Comment décider de la correction ?
ƒ Quand s’arrêter de tester ?
ƒ
ƒ
ƒ
ƒ
Pourquoi ce test passe-t-il ?
43
UJF – Grenoble I
44
UJF – Grenoble I
Comment décider de la correction ?
5. Oracle du test dans JUnit
Comment décider de la correction ?
ƒ Différent type d’assertions :
ƒ Une exécution d’un programme est un test si on
juge le résultat
ƒ « problème de l’oracle »
ƒ Pour testCredit(),
ƒ assertTrue(“message",condition) / (condition)
ƒ assertEquals(“message", arg1,arg2) / (arg1,arg2)
ƒ assertNull, assertNotNull, assertSame, …
ƒ Pour notre exemple
ƒ on exécute la procédure crédit
ƒ on ne juge pas le résultat
ƒ On s’attend à ce que credit(101) ne modifie pas la
balance.
ƒ Pour tout test automatisé,
ƒ Il faut automatiser le jugement de la correction
45
UJF – Grenoble I
46
UJF – Grenoble I
Comment décider de la correction ?
5. Oracle du test dans JUnit
Objectifs du cours d'aujourd'hui :
ƒ Donner des réponses aux questions suivantes :
Qu’est-ce que « tester un programme » ?
Pourquoi tester ?
Quand tester ?
Comment tester ?
ƒ Comment choisir les données ?
ƒ Comment exécuter les tests ?
ƒ Comment décider de la correction ?
ƒ Quand s’arrêter de tester ?
ƒ
ƒ
ƒ
ƒ
47
UJF – Grenoble I
48
UJF – Grenoble I
8
CCI
Génie Logiciel
UFR - IMA
Quand s’arrêter ?
Quand s’arrêter ?
ƒ On n’a jamais fini de tester
ƒ On peut juste savoir quand on n’a pas
assez testé
ƒ Ici : critère =
couverture des instructions
ƒ Un critère d’arrêt signifie
ƒ si le critère n’est pas couvert, on
n’a pas fini de tester
ƒ Couverture de code
ƒ Couverture de spécification
ƒ Un critère d’arrêt NE signifie PAS
ƒ Quand on a atteint le critère on a
fini de tester
ƒ Pour Eclipse, Java et JUnit,
ƒ Quand on a atteint le critère on a
trouvé toutes les erreurs
ƒ EclEmma est un plug-in de mesure de
couverture de code
49
UJF – Grenoble I
50
UJF – Grenoble I
En résumé
Résumé / Conclusions
ƒ Tester : rechercher des erreurs
ƒ Difficultés et grandes stratégies
ƒ Choix des données
ƒ Arrêt du test
ƒ Problème de l’oracle
52
UJF – Grenoble I
Tester, c’est difficile : (2)
Quelles données choisir ?
Tester, c’est difficile (1)
ƒ Difficultés théoriques
ƒ Test exhaustif impossible
ƒ Choisir des données pour découvrir des erreurs
ƒ On ne peut pas tout tester (test exhaustif)
ƒ Infinité de données et/ou pas le temps/argent
ƒ Quelles données pour trouver des erreurs ?
ƒ Quelles données pour trouver toutes les erreurs ?
ƒ Chaque programme est particulier = aucune technique
générale
ƒ Démarches classiques, basées sur l’expérience
ƒ Quelles données choisir ?
ƒ Comment décider que le résultat est correct ?
ƒ Quand peut-on / doit-on s’arrêter ?
ƒ Difficulté psychologique
ƒ
ƒ
ƒ
ƒ
ƒ Programmation : activité constructive
ƒ Test : activité « destructive »
ƒ Il est difficile de détruire ce que l’on a construit
53
UJF – Grenoble I
Étude de la spécification
Etude du code
Couvrir l’ensemble des cas (spécification, parties de code)
Tests aux limites (domaine des entrées, cas particuliers)
54
UJF – Grenoble I
9
CCI
Génie Logiciel
UFR - IMA
Tester, c’est difficile : (3)
Le résultat est-il correct ?
Tester, c’est difficile : (4)
Quand s’arrêter ?
ƒ Décider si le comportement du programme est
correct
ƒ Problème de l’oracle
ƒ Pouvoir observer
ƒ Le test n’a pas révélé d’anomalies
ƒ Absence d’erreur ?
ƒ Mauvais choix de données ?
ƒ Le test a révélé des anomalies
ƒ quelles sont les sorties du logiciel
ƒ Existe-t-il d’autres erreurs ?
ƒ Savoir décider
ƒ Comment décide-t-on que le comportement est OK ?
ƒ Exple : Soit un programme de tri alphabétique
Lagaf G.
La Poste
La Poste
Lagaf G.
55
UJF – Grenoble I
56
UJF – Grenoble I
Références
ƒ Plug-in
ƒ http://www.junit.org/
ƒ http://www.eclemma.org/
ƒ Utiliser JUnit
ƒ http://junit.sourceforge.net/
ƒ http://jmdoudoux.developpez.com/java/eclipse/?page
=Chap_010
ƒ http://open.ncsu.edu/se/tutorials/junit/
ƒ http://www.cs.umanitoba.ca/~eclipse/10-JUnit.pdf
57
UJF – Grenoble I
10