Quatrième partie IV. Test. Test 15 février / 71

Transcription

1 Quatrième partie IV Test Test 15 février / 71

2 Outline Introduction 1 Introduction 2 Analyse statique 3 Test dynamique Test fonctionnel et structurel Test structurel Test fonctionnel 4 Conclusion 5 JUnit Test 15 février / 71

3 Test Introduction Le test n est pas une étape du codage la preuve que le programme est correct montrer que le programme est correct la mise au point Test exécuter un programme pour y trouver des erreurs Examiner : lire, faire lire, ou traîter par un outil d analyse Analyse statique (a.k.a. Test statique) Exécuter : fournir des données au programme, et obtenir le résultat (oracle, boîte noire), comparer au résultat attendu Test dynamique Test 15 février / 71

4 Exemple du triangle Introduction Soit trois entiers représentant les longueurs des cotés d un triangle. Le programme lit ces trois entiers et détermine s il s agit d un triangle scalène (quelconque), isocèle ou équilatéral. Donner les différents cas de tests permettant de tester le programme correspondant (G. J. Myers, The Art of Software Testing, 1979) Test 15 février / 71

5 Exemple du triangle Rappel de géométrie Introduction Etant donnés trois nombres réels positifs a, b et c, il existe un triangle dont les côtés mesurent a, b et c si les trois inégalités suivantes sont vérifiées : a < b + c, b < a + c et c < a + b Il suffit en pratique de vérifier une seule des trois inégalités, celle où le plus long côté est est à gauche de l inégalité, i.e. si max(a, b, c) = a, la seule inégalité à vérifier est a < b + c. Test 15 février / 71

6 Exemple du triangle Cas de tests (1) Introduction Cas scalène valide : 2,4,3 (1,2,3 et 2,5,10 ne sont pas valides) Cas équilatéral valide : 5,5,5 Cas isocèle valide : 6,6,7 (2,2,4 n est pas valide) Cas isocèle valide avec les trois permutations (3,3,4 ; 3,4,3 ; 4,3,3) Cas avec une valeur à 0 Cas avec une valeur négative Test 15 février / 71

7 Exemple du triangle Cas de tests (2) Introduction Cas ou la somme de deux entrées est égale à la troisième entrée Trois cas pour le test 7 avec les trois permutations (1,2,3 ; 2,4,2 ; 5,3,2) Cas ou la somme de deux entrées est inférieure à la troisième entrée Trois cas pour le test 9 avec les trois permutations Cas avec les trois entrées à 0 Cas avec une entrée non entière Cas avec un nombre erroné de valeurs (0, 1, 2, 4,...entrées) Test 15 février / 71

8 Exemple du triangle Analyse Introduction Chaque cas correspond à un défaut constaté dans des implantations Moyenne des résultats obtenus par développeurs expérimentés : 7.8 sur 13 Conception de jeux de tests = activité complexe, a fortiori sur de grandes applications Test 15 février / 71

9 Cycle en V Introduction Modèle de développement normalisé par la RFA. Exigences \ \ Recette Spéc. / fonctionnelles / \ \ Test système Architecture --- / \ \---- Test intégration Conception -- / \ \---- Test unitaire \ / / Code / Test 15 février / 71

10 Types de tests Introduction unitaires : procédures, modules, composants intégration : composition de procédures et de modules conformité : adéquation aux spécifications non-régression (après modifications) : correction et évolution ne créent pas d anomalies nouvelles nominal, bon fonctionnement : cas de tests correspondant à des entrées valides robustesse : cas de tests correspondant à des entrées non valides Et les tests de performance load testing : résistance à la montée en charge stress testing : résistance aux demandes de ressources anormales Test 15 février / 71

11 Test unitaire Introduction test d une unité logicielle, d un «module» ; pour détecter des fautes dans son comportement individuel ; on ne teste pas les comportements dépendants d autres unités ; avant de tester le mur, tester ses briques ; notion d unité : dépend du paradigme de programmation utilisé : fonction, procédure, sous-programme, classe, composant, etc. Test 15 février / 71

12 Test d intégration Introduction vérifier qu un ensemble d unités coopérent correctement ; pour détecter des erreurs dans leur inter-opérabilité, la mauvaise utilisation d une interface (surtout si interface floue) ; basé sur l architecture de conception ; plusieurs approches pour l intégration : non-incrémentale ou big-bang : les modules sont testés unitairement chacun de leur côté ; puis on les assemble et on teste le tout d un coup ; incrémentale : on assemble un module déjà testé avec un module pas encore testé, puis on teste leur combinaison. Encore deux approches : bottom-up et top-down. pour simuler les modules non encore testés ou non disponibles : «bouchons» ou stubs. Test 15 février / 71

13 Test système Introduction Sur une application complètement intégrée ds son environnement. test de montée en charge ; stress de l application ;... Et aussi... test de régression (ou non-régression) : nouveau test du système après une modification pour vérifier qu elle n a pas apporté d autres fautes. En pratique, les tests fonctionnels d une version n sont des tests de non-régression pour la version n+1 ; Test 15 février / 71

14 Test de recette Introduction Ou test d acceptation, (ou User Acceptance Testing, ou simplement recette) : effectué avec l utilisateur final pour valider le système produit par rapport aux exigences, pour obtenir son approbation avant la livraison. Test 15 février / 71

15 Introduction Analyse statique et test (dynamique) Analyse statique Traitement du code source sans exécution Lectures croisées, inspection Analyse d anomalies : typage impropre, incohérence des interfaces de modules,... Evaluation symbolique : simulation de l exécution sur données symboliques Test dynamique exécution du logiciel sur des entrées choisies (cas de test) sélection de jeux de tests soumission des jeux de test dépouillement des résultats (comparaison avec résultats fournis par l oracle) évaluation de la qualité, de la couverture. Décision d arrêt du test Test 15 février / 71

16 Introduction Considérations générales Connaissance du fonctionnement interne boîte noire (black-box) : aucun accès au code, architecture... boîte transparente (white-box, glass-box) : connaissance du code Debugging vs. testing testing : trouver des bugs debugging : analyser les bugs, et les retirer Test 15 février / 71

17 Introduction Coût / efficacité du test Coût dans la litérature : ± 50 % du temps pris par le test en fait : 50 % du temps pris par le test et le debugging Efficacité développement collaboratif trouve plus d erreur, et coûte moitié moins par erreur le test débusque moins de la moitié des bugs (Source : Code Complete) Test 15 février / 71

18 Introduction Difficultés et limites du test Espace d état gigantesque (exemple : fiche client) : le test n est généralement pas complet Comment choisir les cas de test? Difficulté pour le développeur Buts du test : casser le système But du développeur : éviter que le système se casse Buts opposés ( équipes différentes) Le test n est jamais complet 1000 erreurs trouvées : bonne ou mauvaise nouvelle? aucune erreur trouvée : test insuffisant ou logiciel robuste? Le test n augmente pas la qualité du système, mais mesure la qualité. Augmenter la qualité d un logiciel par l augmentation du test est abérrant. Les procédures de développement déterminent la qualité. Les a priori laissent passer les signes d erreur. Test 15 février / 71

19 Buts du test Introduction Test exécuter un programme pour y trouver des erreurs ou, autrement dit Test Exécuter le logiciel (sur des données choisies) pour évaluer sa qualité Test 15 février / 71

20 Outline Analyse statique 1 Introduction 2 Analyse statique 3 Test dynamique Test fonctionnel et structurel Test structurel Test fonctionnel 4 Conclusion 5 JUnit Test 15 février / 71

21 Analyse statique Lecture croisée, inspection Lecture croisée binôme programmeur, lecteur voir Extreme Programming Inspection relecture en groupe, après préparation individuelle règles et protocole précis Test 15 février / 71

22 Analyse statique Analyse d anomalies règles de typages utilisation de pointeurs expressions abérrantes défauts de portabilité déclaration d arguments non utilisés... de plus en plus intégrée dans les compilateurs (c.f. -Wall) La présence d anomalies révèle souvent des erreurs de logique L analyse statique rejoint les méthodes formelles Test 15 février / 71

23 Outline Test dynamique 1 Introduction 2 Analyse statique 3 Test dynamique Test fonctionnel et structurel Test structurel Test fonctionnel 4 Conclusion 5 JUnit Test 15 février / 71

24 Test dynamique Comment trouver les cas de test? Programme boîte noire aucun accès au code, à l architecture... avantage : beaucoup plus proche de l utilisation normale inconvénient : moins de connaissance pour guider les choix Programme boîte transparente (white-box, glass-box) connaissance du code avantage : se concentrer sur les détails désavantage : être omnubilé par les détails, ne pas agir comme l utilisateur Éviter les tests trop semblables Test 15 février / 71

25 Outline Test dynamique Test fonctionnel et structurel 1 Introduction 2 Analyse statique 3 Test dynamique Test fonctionnel et structurel Test structurel Test fonctionnel 4 Conclusion 5 JUnit Test 15 février / 71

26 Test dynamique Test fonctionnel et structurel Test fonctionnel et structurel Test fonctionnel boîte noire (black-box) données de test engendrées par la spécification Test structurel boîte transparente (glass-box) données de test engendrées par l analyse du code source Test 15 février / 71

27 Test fonctionnel Test dynamique Test fonctionnel et structurel boîte noire données de test engendrées par la spécification Spécification Données de test Oracle Programme Résultat attendu Résultat obtenu Test 15 février / 71

28 Test structurel Test dynamique Test fonctionnel et structurel boîte en verre analyse du code pour produire les Données de Test (DT) Principalement basé sur différents critères de couvertures : tous les chemins toutes les branches toutes les instructions Point d entrée Point de sortie Test 15 février / 71

29 Test dynamique Test fonctionnel et structurel Test fonctionnel et structurel Approche complémentaire : le test fonctionnel détecte les écarts par rapport aux spécifications certaines erreurs ne sont détectées que par le test structurel int sum (int x, int y) { if (x==600 && y==500) return x-y; return x+y; } Test 15 février / 71

30 Test dynamique Difficultés du test dynamique Test fonctionnel et structurel test fonctionnel : entrées dans un ensemble infini (ou de très grande taille) test structurel : graphe très grand oracle : nécessaire pour obtenir le résultat attendu (pour comparaison) En définitive test : méthode de vérification partielle qualité dépendant du choix des jeux de test (couverture) Test 15 février / 71

31 Outline Test dynamique Test structurel 1 Introduction 2 Analyse statique 3 Test dynamique Test fonctionnel et structurel Test structurel Test fonctionnel 4 Conclusion 5 JUnit Test 15 février / 71

32 Test structurel Test dynamique Test structurel Analyse du code source pour produire des Données de Test (DT) Comportement du programme = chemin dans le graphe de contrôle Tests fonction de critères de couverture ( tous les chemins, toutes les branches, toutes les instructions) Test 15 février / 71

33 Graphe de contrôle Test dynamique Test structurel if (x<=0) x = -x; else x= 1 - x; if (x == -1) x = 1; else x++; Entrée : a Sortie : g Chemin correct : acdeg b x = x x == 1 e x = 1 x 0 a d g x > 0 c x = 1 x x 1 f x = x + 1 Test 15 février / 71

34 Graphe de contrôle Chemins de contrôle Test dynamique Test structurel Exécutions possible du code ch1 = abdeg ch2 = acdeg ch3 = abdfg ch4 = acdfg b x = x x == 1 e x = 1 x 0 a x > 0 c x = 1 x d x 1 f x = x + 1 g Sous forme algébrique abdfg + abdeg + acdfg + acdeg ( + désigne le ou logique) a(bdf + bde + cdf + cde)g a(b + c)d(f + e)g (expression factorisée des chemins de contrôle) Test 15 février / 71

35 Graphe de contrôle Chemins de contrôle (2) Test dynamique Test structurel Composants : ab : séquence a puis b a a+(b+c)d : choix entre b et c a b b c d ab(cb) d : itération a b c d Test 15 février / 71

36 Graphe de contrôle Exercice Test dynamique Test structurel i = 1; found = 0; while (!found) { if (a[i] == E) { found = 1; s = i; } i++; } Test 15 février / 71

37 Graphe de contrôle Exercice Test dynamique Test structurel i = 1; found = 0; while (!found) { if (a[i] == E) { found = 1; s = i; } i++; } i + + a i = 1; found = 0; found b f!found c a[i] == E a[i]! = E found = 1; s = i; d e Test 15 février / 71

38 Graphe de contrôle Exercice (2) Test dynamique Test structurel if (n<=0) n = 1 - n; if ( n % 2 == 0) n = n / 2; else n = 3 * n + 1; Test 15 février / 71

39 Graphe de contrôle Exercice (2) Test dynamique Test structurel if (n<=0) n = 1 - n; if ( n % 2 == 0) n = n / 2; else n = 3 * n + 1; a(1+b)c(e+d)f n > 0 a n 0 b n%2! = 0 c n = 1 n n%2 == 0 e d n = 3 n + 1 f n = n/2 Test 15 février / 71

40 Chemins exécutables Test dynamique Test structurel Sensibiliser un chemin On dit qu une DT sensibilise un chemin, car pour ces valeurs, le code suit le chemin de contrôle en visitant consécutivement ces noeuds Chemin exécutable Un chemin de contrôle est exécutable si il existe une DT qui le sensibilise Test 15 février / 71

41 Chemins exécutables Test dynamique Test structurel ch1 = abdeg ch2 = acdeg ch3 = abdfg ch4 = acdfg DT = {x = 2} sensibilise ch3 DT = {x = 3} sensibilise ch4 DT = {x = 2} sensiblise ch2 b x = x x == 1 e x = 1 x 0 a x > 0 c x = 1 x d x 1 g f x = x + 1 Aucune valeur de x ne sensibilise ch1 chemin non-exécutable Test 15 février / 71

42 Chemins exécutables Test dynamique Test structurel ch1 = abdeg ch2 = acdeg ch3 = abdfg ch4 = acdfg DT = {x = 2} sensibilise ch3 DT = {x = 3} sensibilise ch4 DT = {x = 2} sensiblise ch2 b x = x x == 1 e x = 1 x 0 a x > 0 c x = 1 x d x 1 g f x = x + 1 Aucune valeur de x ne sensibilise ch1 chemin non-exécutable Test 15 février / 71

43 Chemins exécutables Test dynamique Test structurel ch1 = abdeg ch2 = acdeg ch3 = abdfg ch4 = acdfg DT = {x = 2} sensibilise ch3 DT = {x = 3} sensibilise ch4 DT = {x = 2} sensiblise ch2 b x = x x == 1 e x = 1 x 0 a x > 0 c x = 1 x d x 1 g f x = x + 1 Aucune valeur de x ne sensibilise ch1 chemin non-exécutable Test 15 février / 71

44 Chemins exécutables Test dynamique Test structurel ch1 = abdeg ch2 = acdeg ch3 = abdfg ch4 = acdfg DT = {x = 2} sensibilise ch3 DT = {x = 3} sensibilise ch4 DT = {x = 2} sensiblise ch2 b x = x x == 1 e x = 1 x 0 a x > 0 c x = 1 x d x 1 g f x = x + 1 Aucune valeur de x ne sensibilise ch1 chemin non-exécutable Test 15 février / 71

45 Chemins exécutables Test dynamique Test structurel ch1 = abdeg ch2 = acdeg ch3 = abdfg ch4 = acdfg DT = {x = 2} sensibilise ch3 DT = {x = 3} sensibilise ch4 DT = {x = 2} sensiblise ch2 b x = x x == 1 e x = 1 x 0 a x > 0 c x = 1 x d x 1 g f x = x + 1 Aucune valeur de x ne sensibilise ch1 chemin non-exécutable Test 15 février / 71

46 Test dynamique Chemins non exécutables Test structurel Tous les chemins d un graphe de contrôle ne sont pas exécutables L ensemble des chemins de contrôle contient les chemins exécutables et les chemins non-exécutables Détecter les chemins non-exécutables est un problème indécidable Etant donné un chemin, trouver une DT qui exécute ce chemin? problème très difficile Chemins non-exécutables : casse-tête pour le testeur une erreur de codage du code mort un code pas optimisé du tout Test 15 février / 71

47 Critère de couverture Test dynamique Test structurel Critère Un critère C est une méthode de sélection qui fournit un ensemble de chemins de contrôle à couvrir, ou plus généralement, un ensemble d objets à couvrir. A tout critère C est associé un taux de couverture, exprimant le degré τ de satisfaction de C : τ = nombre d objets dénotés par C nombre d objets effectivement couverts Le problème du testeur est de trouver un ensemble de DT (le plus petit possible) qui satisfont le critère C Test 15 février / 71

48 Test dynamique Hiérarchie des critères Test structurel Nombreux critères : tous les noeuds tous les arcs tous les chemins indépendants basés sur les passages dans les boucles basés sur le flot de données... Ces critères ne sont pas équivalents demandent plus de DT détectent plus d erreurs On dit que le critère C1 est plus fort que le critère C2 si : toute faute détectée par C2 l est par C1 ; toute suite de test qui passe pour C1 passe pour C2 ; un taux de couverture de X pour C1 implique un taux au moins égal à X pour C2 Test 15 février / 71

49 Test dynamique Critère tous les noeuds Test structurel Critère le plus faible, ausi appelé TER1 (Test effectiveness ratio). consiste à couvrir l ensemble des noeuds du graphe. but du testeur : proposer un ensemble de DT qui couvrent l ensemble des noeuds. τ = nombre de noeuds couverts nombre total de noeuds Signifie que toutes les instructions sont été exécutées au moins une fois. Mise en oeuvre directe : compteurs d instructions. Test 15 février / 71

50 Test dynamique Critère tous les noeuds Exemple Test structurel int sum(int x, int y) { (a) int res = 0; (a) if (x == 0) (b) (b) res = x // erreur! (c) x=0 / \ x!= 0 else (c) (d) res = x+y; (d) \ / return res; (e) (e) } {abce, abde} donne un taux de couverture de 100% (= satisfait le critère) + détecte l erreur, avec DT = {{x=2,y=5},{x=0,y=4}} Test 15 février / 71

51 Test dynamique Critère tous les noeuds Exemple Test structurel int sum(int x, int y) { (a) int res = 0; (a) if (x == 0) (b) (b) res = x // erreur! (c) x=0 / \ x!= 0 else (c) (d) res = x+y; (d) \ / return res; (e) (e) } {abce, abde} donne un taux de couverture de 100% (= satisfait le critère) + détecte l erreur, avec DT = {{x=2,y=5},{x=0,y=4}} Test 15 février / 71

52 Test dynamique Critère tous les noeuds Exemple (2) Test structurel } int div(x) { int res = 0 ; (i) (i)--(a) if (x!= 0) (a) \ x = 1; (b) (b) res = 1 / x; (c) / return res; (d) (c)---(d) DT = {x=2} satisfait le critère tous les noeuds : {iabcd} Erreur non détectée, chemin révélélateur : {iacd} Il aurait fallu couvrir les deux branches du if : critère tous les arcs. Test 15 février / 71

53 Test dynamique Critère tous les noeuds Exemple (2) Test structurel } int div(x) { int res = 0 ; (i) (i)--(a) if (x!= 0) (a) \ x = 1; (b) (b) res = 1 / x; (c) / return res; (d) (c)---(d) DT = {x=2} satisfait le critère tous les noeuds : {iabcd} Erreur non détectée, chemin révélélateur : {iacd} Il aurait fallu couvrir les deux branches du if : critère tous les arcs. Test 15 février / 71

54 Test dynamique Critère tous les noeuds Exemple (2) Test structurel } int div(x) { int res = 0 ; (i) (i)--(a) if (x!= 0) (a) \ x = 1; (b) (b) res = 1 / x; (c) / return res; (d) (c)---(d) DT = {x=2} satisfait le critère tous les noeuds : {iabcd} Erreur non détectée, chemin révélélateur : {iacd} Il aurait fallu couvrir les deux branches du if : critère tous les arcs. Test 15 février / 71

55 Critère tous les arcs Test dynamique Test structurel ou TER2 : tous les arcs du graphe de contrôle sont couverts toutes les branches conditionnelles ont été couvertes τ = nombre des arcs couverts nombre total des arcs chaque prédicat a pris au moins une fois la valeur vrai et la valeur faux ; attention aux prédicats composés. Tous les arcs tous les noeuds. L inverse n est pas vrai. Test 15 février / 71

56 Critère tous les arcs Exemple Test dynamique Test structurel } int div(x) { int res = 0 ; (i) (i)--(a) if (x!= 0) (a) \ x = 1; (b) (b) res = 1 / x; (c) / return res; (d) (c)---(d) DT = {{x=0},{x=2}} satisfait le critère tous les arcs Test 15 février / 71

57 Critère tous les arcs Exemple Test dynamique Test structurel } int div(x) { int res = 0 ; (i) (i)--(a) if (x!= 0) (a) \ x = 1; (b) (b) res = 1 / x; (c) / return res; (d) (c)---(d) DT = {{x=0},{x=2}} satisfait le critère tous les arcs Test 15 février / 71

58 Critère tous les arcs Exemple Test dynamique Test structurel if ((a < 2) && (b == a)) (a) (a) x = 2 - a; (b) / \ else / \ x = a - 2; (c) (b) (c) DT = {{a = 1, b = 1}, {a = 3, b = 3}} Test 15 février / 71

59 Critère tous les arcs Exemple Test dynamique Test structurel if ((a < 2) && (b == a)) (a) (a) x = 2 - a; (b) / \ else / \ x = a - 2; (c) (b) (c) DT = {{a = 1, b = 1}, {a = 3, b = 3}} Test 15 février / 71

60 Test dynamique Critère tous les chemins (1) Test structurel Tous les chemins tous les arcs tous les noeuds Problème des boucles : Chemin limite : traversée de la boucle sans itération Chemin intérieur : itération de la boucle une seule fois Impossible à obtenir en général test exhaustif = tous les chemins avec toutes les valeurs possibles. Test 15 février / 71

61 Test dynamique Test structurel : exercice (1) Test structurel /* Input: n */ if (n<=0) n = 1 - n; if (n%2 == 0) n /= 2; else n = 3 * n + 1; /* Output: n */ Donnez des DT pour atteindre le critère tous les noeuds tous les arcs tous les chemins Test 15 février / 71

62 Test dynamique Test structurel : exercice (2) Test structurel /* Entrée: E, a[0],..., a[4] */ int found = 0; int i = 0; while (i < 5) { if (a[i]==e) found = 1; else found = 0; i++; } /* Sortie: found */ Donnez des DT pour atteindre le critère tous les noeuds tous les arcs tous les chemins Test 15 février / 71

63 Outline Test dynamique Test fonctionnel 1 Introduction 2 Analyse statique 3 Test dynamique Test fonctionnel et structurel Test structurel Test fonctionnel 4 Conclusion 5 JUnit Test 15 février / 71

64 Test fonctionnel Test dynamique Test fonctionnel Test fonctionnel Tester le comportement fonctionnel du logiciel et la conformité avec sa spécification boîte noire données de test engendrées par la spécification Spécification Données de test Oracle Programme Résultat attendu Résultat obtenu Test 15 février / 71

65 Test dynamique Test fonctionnel : methodes Test fonctionnel Analyse partition des domaines des données d entrée test aux limites Test combinatoire (algorithmes pairwise) Test aléatoire Génération automatique de test (à partir des spécifications) Test 15 février / 71

66 Test dynamique Test fonctionnel Partition des domaines des données Critères pour guider le choix de valeurs pertinentes. Les erreurs sont souvent dûes aux opérateurs de comparaison ou de tests aux limites < et modification de comportement pour certains domaines de valeurs Mauvaise détermination d une condition limite Comportement dépend d une partition de domaine des données Changement de omportement est fonction de classes de valeurs Classe d équivalences Test 15 février / 71

67 Classe d équivalence Test dynamique Test fonctionnel Classe d équivalence Ensemble de données de tests, impliquant le même comportement du logiciel Les classes d équivalences partitionnent les domaines des données à tester. Test 15 février / 71

68 Test dynamique Conception d un jeu de test Test fonctionnel Trois phases Pour chaque entrée, calcul de classes d équivalence sur les domaines de valeur Choix d un représentant par classe Composition par produit cartésien sur l ensemble des représentants Test 15 février / 71

69 Test dynamique Test fonctionnel Classe d équivalence Exemple trois nombres réels correspondant à la longueur des cotés d un triangle en entrée si cela ne correspond pas à un triangle, imprimer un message approprié sinon, vérifier s il s agit d un triangle isocèle, équilatéral ou scalène de plus, vérifier si son plus grand angle est aigu, droit ou obtus Classes d équivalence et Données de Test : Aigu Obtus Droit Scalène 6,5,3 5,6,10 3,4,5 Isocèle 6,1,6 7,4,4 2, 2, 2 Équilatéral 4,4,4 impossible impossible cas ne correspondant pas à un triangle : - 1,2,8 Test 15 février / 71

70 Test dynamique Partition des domaines (2) Test fonctionnel Si la valeur à tester appartient à un intervalle, construire une classe pour les valeurs inférieures une classe pour les valeurs supérieures n classes valides Si la donnée est un ensemble de valeurs, construire une classe avec l ensemble vide une classe avec trop de valeurs n classes valides Si la donnée est une contrainte/condition, construire une classe avec la contrainte respectée une classe avec la contrainte non-respectée Test 15 février / 71

71 Test aux limites Test dynamique Test fonctionnel Test aux limites Utilisation des valeurs extrêmes du domaine dans les données de test Si x appartient à un intervalle [a, b], prendre les deux valeurs aux limites (a, b) les quatre valeurs a ± ε, b ± ε, où ε est le plus petit écart possible (Ex : 1 pour les entiers) une valeur dans l intervalle Par exemple : x [3..15] valeurs aux limites : 3, 15 limites ±ε : 2, 4, 14, 16 valeur dans l intervalle : 7 Test 15 février / 71

72 Test aux limites Test dynamique Test fonctionnel Test aux limites Utilisation des valeurs extrêmes du domaine dans les données de test Si x appartient à un intervalle [a, b], prendre les deux valeurs aux limites (a, b) les quatre valeurs a ± ε, b ± ε, où ε est le plus petit écart possible (Ex : 1 pour les entiers) une valeur dans l intervalle Par exemple : x [3..15] valeurs aux limites : 3, 15 limites ±ε : 2, 4, 14, 16 valeur dans l intervalle : 7 Test 15 février / 71

73 Test aux limites (2) Test dynamique Test fonctionnel Si x appartient à un ensemble ordonné de valeurs, prendre les première, deuxième, avant-dernière, et dernière valeurs Si un certain nombre de valeurs doivent être rentrées, prendre le nombre minimum acceptable le nombre maximum acceptable des cas pour des nombres hors limites Par exemple : un fichier d entrée pouvant contenir jusqu à 255 enregistrements nombre maximum : 255 nombre minimum : 0-1 hors limites : (0), 256 Test 15 février / 71

74 Test aux limites (2) Test dynamique Test fonctionnel Si x appartient à un ensemble ordonné de valeurs, prendre les première, deuxième, avant-dernière, et dernière valeurs Si un certain nombre de valeurs doivent être rentrées, prendre le nombre minimum acceptable le nombre maximum acceptable des cas pour des nombres hors limites Par exemple : un fichier d entrée pouvant contenir jusqu à 255 enregistrements nombre maximum : 255 nombre minimum : 0-1 hors limites : (0), 256 Test 15 février / 71

75 Reflexion... Test dynamique Test fonctionnel Classes d équivalence? diminuer le nombre de cas de tests? méthodes heuristiques Partition des domaines Test aux limites le choix des classes est critique l identification des problèmes dépend de ce choix classes hors limites : tests de robustesse classes dans limites : tests nominaux Test 15 février / 71

76 Reflexion...(2) Test dynamique Test fonctionnel Soit n données d entrées, et 5 classes (tests aux limites). Test 15 février / 71

77 Reflexion...(2) Test dynamique Test fonctionnel Soit n données d entrées, et 5 classes (tests aux limites). 5 n cas de tests Test 15 février / 71

78 Test combinatoire Test dynamique Test fonctionnel Explosion combinatoire dûe à la combinaison des valeurs Défauts dépendent de l interaction d au plus 2 paramètres, pas de la combinaison de tous les paramètres Exemple (simplifié) : OS Résolution Application Affichage Windows x600 WMP 2 Ecrans Windows x768 Doom LCD Windows XP 1280x1024 IE CRT 3 4 = 81 combinaisons 9 paires Test 15 février / 71

79 Test combinatoire (2) Test dynamique Test fonctionnel 75 options binaires : Windows x600 WMP 2 écrans Windows x768 Doom LCD Windows x1024 IE CRT Windows x600 IE LCD Windows x768 WMP CRT Windows x1024 Doom 2 écrans Windows XP 800x600 Doom CRT Windows XP 1024x768 IE 2 écrans Windows XP 1280x1024 WMP LCD 2 75 cas ( ) 28 cas pour toutes les paires! Test 15 février / 71

80 Test dynamique Test combinatoire - Outils Test fonctionnel -n a 2a 3c 1a 2b 3a 1a 2c 3b 1b 2a 3b 1b 2b 3c 1b 2c 3a 1c 2a 3a 1c 2b 3b 1c 2c 3c tous les triplets, quadruplets Test 15 février / 71

81 Test dynamique Test aléatoire ou statistique Test fonctionnel Fonction de calcul pour selection des données de test fonction aléatoire dans le domaine de la donnée d entrée loi statistique sur le domaine (Ex. loi de Gauss) Avantages génération automatique des cas de test objectivité Inconvénients fonctionnement en aveugle comportements spécifiques oracle? Test 15 février / 71

82 Outline Conclusion 1 Introduction 2 Analyse statique 3 Test dynamique Test fonctionnel et structurel Test structurel Test fonctionnel 4 Conclusion 5 JUnit Test 15 février / 71

83 Réflexions (1) Conclusion Test-first vs. test-last : conception des test avant le code n est pas plus onéreux détection des défauts plus rapidement, correction précoce test-first implique réflexion approfondie sur les besoins et le design. Détection des problèmes dans l expression des besoins. test-first et test-last Tests propres et sales : test propre : le code fonctionne-t-il? test sale : le code est-il robuste observation : 5 tests sales pour un test propre Test 15 février / 71

84 Réflexions (2) Conclusion Développeur et test il pense atteindre 95% de la couverture il atteint 60% en moyenne au pire : 30% il pense que 100% du code testé est bien en fait, il faudrait 100% des branches Test 15 février / 71

85 Outline JUnit 1 Introduction 2 Analyse statique 3 Test dynamique Test fonctionnel et structurel Test structurel Test fonctionnel 4 Conclusion 5 JUnit Test 15 février / 71