27/03/2001InfoBase: Techniques de Test1 Informatique de Base (4) Techniques de Tests.

Présentation au sujet: "27/03/2001InfoBase: Techniques de Test1 Informatique de Base (4) Techniques de Tests."— Transcription de la présentation:

1 27/03/2001InfoBase: Techniques de Test1 Informatique de Base (4) Techniques de Tests

2 27/03/2001 InfoBase: Techniques de Test2 Plan n Définitions n Principes n Processus n Classification des méthodes n Méthodes d'élaboration de jeux de tests n Conclusion

3 27/03/2001 InfoBase: Techniques de Test3 Définitions n "Le test est l'activité qui donne confiance dans le fait qu'un programme ou système fait ce qu'il doit", Hetzel 1973. n "Le test est l'activité qui consiste à exécuter un programme ou système dans le but d'y découvrir des erreurs", Myers 1979. n "Le test est l'activité dont les objectifs sont d'évaluer un attribut ou une capacité d'un système et de déterminer s'il produit ses résultats attendus", Hetzel 1983. n CCL: Objectif général d'assurance de qualité

4 27/03/2001 InfoBase: Techniques de Test4 Qualités d'un programme n Fonctionnalité –correction (pas de résultats erronés) –fiabilité (pas de terminaison brutale) –utilisabilité –intégrité (e.g. cohérence des contenu des fichiers) n Autres –efficacité, documentation, structure, réutilisabilité, maintanabilité, … n  Tester non seulement un programme mais aussi une spécification, une découpe en sous-problèmes, une interface utilisateur, … n  L'activité de Test inclut des techniques d'inspection, de révision, de "walkthrough",...

5 27/03/2001 InfoBase: Techniques de Test5 Processus Général 1. Définir la qualité à mesurer 2. Définir des cas de Tests 3. Exécuter ou simuler les cas de Tests 4. Comparer avec les résultats attendus 5. Corriger

6 27/03/2001 InfoBase: Techniques de Test6 Principe 1 Un test exhaustif est impossible n Car: –infinité de valeurs –combinaison de situations n Donc: –bien choisir les tests –décider quand s'arrêter Procédure Chercher(e,liste) trouvé=false; i=1; While (i<=Longueur(liste) AND NOT trouvé) if (e=liste[i]) trouvé=true i:=i+1 end if (NOT trouvé) Write("Non trouvé") else Write("Trouvé")

7 27/03/2001 InfoBase: Techniques de Test7 Principe 2 objectif = empêcher les erreurs de survenir n Test  phase finale quand tout le code est écrit n Test tout au long du processus –spécification –conception (découpe en sous-problèmes) –implémentation

8 27/03/2001 InfoBase: Techniques de Test8 Principe 3 Les tests doivent être planifiés n... et conçus de manière systématique n Pas inventés rapidement quand on essaye le programme n Plan de tests –définir l'objectif des tests (ce qu'on veut mesurer) –l'approche suivie –les tâches à accomplir et documents à produire –quand s'arrêter de tester n Les cas de tests doivent être décrits dans un document pour pouvoir être inspectés et réutilisés

9 27/03/2001 InfoBase: Techniques de Test9 Principe 4 Le testeur doit être indépendant n Pas tendance à voir ses propres erreurs n Idéalement:  de l'auteur n Pratiquement: –essayer d'être le moins biaisé possible –"changer de chapeau": constructeur  destructeur

10 27/03/2001 InfoBase: Techniques de Test10 Niveaux de Tests n Individuel (unit testing) –petits morceaux de programmes (procédures, "modules") n Complet (system testing) –système (programme) complet (assemblage de modules ou procédures) n D'acceptation (acceptance testing) –avant de l'utiliser, par l'utilisateur

11 27/03/2001 InfoBase: Techniques de Test11 Elaboration de cas de tests: Classification des méthodes (1) n Random –Choisis au hasard –A la main –Avec un générateur aléatoire n Basés sur des données existantes –Fichiers –Tests précédents,…

12 27/03/2001 InfoBase: Techniques de Test12 Elaboration de cas de tests: Classification des méthodes (2) n Basés sur la spécification –Black-box testing, data driven testing, input-output driven testing –vue externe du programme n Basés sur la logique du programme (enchaînement) –White-box testing, logic-driven testing –Vue interne du programme (code) spec inputsoutputs inputsoutputs code

13 27/03/2001 InfoBase: Techniques de Test13 Elaboration de cas de tests: Méthodes n Black-box –functional testing –equivalence partitioning –boundary/extreme values analysis n White-box –statement coverage –decision coverage –condition coverage –dec./cond. coverage –multiple condition coverage –basis testing

14 27/03/2001InfoBase: Techniques de Test14 Black-box Testing Méthode 1: Functional Testing

15 27/03/2001 InfoBase: Techniques de Test15 Functional Testing: Principes n Identifier des cas de tests –valeurs d'entrée –résultats attendus n A partir de la spécification (Black box) –1 cas pour chaque type de résultat ou fonction du programme identifiée  ensemble de cas minimum –décomposer chaque cas et combiner les sous- cas –éliminer les cas redondant

16 27/03/2001 InfoBase: Techniques de Test16 Functional Testing Exemple - Ensemble Minimum de cas Spécification: Chercher un Vol(orig, dest) Objet utilisé: la liste des vols et places disponibles Entrée: une demande de vol (orig,dest) Sortie: affichage_vols OU message1 OU message2 Post: Si pas de vol pour dest, message 1 = pas de vol Si un vol mais plus de places, message 2 = complet Si un vol avec places, l'afficher Cas de Tests minimum: 1. pas de vol pour dest 2. un vol mais plus de places 3. un vol avec places Résultats attendus: message 1 (pas de vol) message 2 (complet) affichage ligne vol

17 27/03/2001 InfoBase: Techniques de Test17 Functional Testing Exemple - Décomposition des cas et Combinaison Cas de Tests: 1. pas de vol pour dest 2A. un seul vol sans place 2B. plusieurs vols sans place 3A. un seul vol avec places 3B. plusieurs vols avec places 4. un vol sans places, un autre avec Résultats attendus: message 1 (pas de vol) message 2 (complet) affichage une ligne vol affichage plusieurs lignes vol message 2 (complet) et affichage Cas de Tests minimum: 1. pas de vol pour dest 2. un vol mais plus de places 3. un vol avec places Résultats attendus: message 1 (pas de vol) message 2 (complet) affichage ligne vol

18 27/03/2001 InfoBase: Techniques de Test18 Functional Testing Exemple - Elimination des cas redondants Cas de Tests: 1. pas de vol pour dest 2A. un seul vol sans place 2B. plusieurs vols sans place 3A. un seul vol avec places 3B. plusieurs vols avec places 4. un vol sans places, un autre avec Résultats attendus: message 1 (pas de vol) message 2 (complet) affichage une ligne vol affichage plusieurs lignes vol message 2 (complet) et affichage Cas de Tests: 1. pas de vol pour dest 2A. un seul vol sans place 2B. plusieurs vols sans place 3A. un seul vol avec places 3B. plusieurs vols avec places 4. un vol sans places, un autre avec Résultats attendus: message 1 (pas de vol) message 2 (complet) affichage une ligne vol affichage plusieurs lignes vol message 2 (complet) et affichage Le cas 2A est couvert par le cas 2B Le cas 3A est couvert par le cas 4

19 27/03/2001InfoBase: Techniques de Test19 Black-box Testing Méthode 2: Equivalence Partitioning

20 27/03/2001 InfoBase: Techniques de Test20 Equivalence Partitioning: Principe n décomposer l'ensemble des valeurs possibles des entrées du programme en classes d'équivalence (CE) de cas de tests tq: –si une erreur est détectée en utilisant un cas de test d'une CE, les autres tests de cette CE auraient normalement aussi permis de la détecter –si une erreur n'est pas détectée en utilisant un cas de test d'une CE, les autres de cette CE n'auraient normalement pas non plus permis de la détecter n tester seulement un (ou quelques) cas de chaque classe d'équivalence

21 27/03/2001 InfoBase: Techniques de Test21 Equivalence Partitioning: Etapes n 1. Définir les classes d'équivalence n 2. Définir les cas de test

22 27/03/2001 InfoBase: Techniques de Test22 Equivalence Partitioning Définir les classes d'équivalence n Pour chaque entrée, essayer d'identifier –des classes d'équivalence valides (CEV) (qui représentent des entrées valides pour le programme) –des classes d'équivalence invalides (CEI) (qui représentent des entrées non valides pour le programme) –ensembles de valeurs disjoints –en se basant sur des heuristiques CEV CEI

23 27/03/2001 InfoBase: Techniques de Test23 Equivalence Partitioning Exemples d'heuristiques n Si la spécification précise que le domaine de valeurs d'une entrée est un intervalle (e.g. de 1 à 100), identifier une CE valide ([1,100]) et deux invalides ( [- ,1[ et ]100,  [ ). n Si la spécification précise un nombre d'entrées (par exemple de 1 à 6 valeurs), identifier une CE valide pour ce nombre de valeurs et deux CE invalides (pas assez ou trop de valeurs). Par exemple: 0 valeurs et plus de 6 valeurs. n...

24 27/03/2001 InfoBase: Techniques de Test24 Equivalence Partitioning Définir les classes d'équivalence - Exemple Spécification: Un programme reçoit une liste de trois nombres L=[l1,l2,l3], les interprète comme les longueurs de côtés d'un triangle et répond si le triangle est scalène, isocèle ou équilatéral. Spécification: Un programme reçoit une liste de trois nombres L=[l1,l2,l3], les interprète comme les longueurs de côtés d'un triangle et répond si le triangle est scalène, isocèle ou équilatéral. l1 l2 l3 ? CEI 1: 0  L CE 2: 0  L CEI 3: #L<3 CEI 4: #L>3 CE 5: #L=3 CE 6: Max(L)<Sum(L\Max(L)) CEI 7: Max(L)>=Sum(L\Max(L)) CE 8: l1=l2=l3 CE 9: l i =l j  l k CE 10: l1  l2  l3

25 27/03/2001 InfoBase: Techniques de Test25 Equivalence Partitioning Identifier les cas de tests n Jeux de tests "valides": Trouver de nouveaux cas de tests qui couvrent le plus possible de CE valides encore non couvertes, jusqu'à couverture de toutes les CE valides n Jeux de tests "invalides": Trouver un cas de test qui couvre une et une seule CE invalide, jusqu'à couverture de toutes les CE invalides (pour éviter que certaines erreurs n'en masquent une autre).

26 27/03/2001 InfoBase: Techniques de Test26 Equivalence Partitioning Identifier les cas de tests - exemple CEI 1: 0  L CE 2: 0  L CEI 3: #L<3 CEI 4: #L>3 CE 5: #L=3 CE 6: Max(L)<Sum(L\Max(L)) CEI 7: Max(L)>=Sum(L\Max(L)) CE 8: l1=l2=l3 CE 9: l i =l j  l k CE 10: l1  l2  l3 Cas de tests valides: 1. (1,1,1) couvre CE2,CE5,CE6,CE8 2. (1,2,2) couvre CE2,CE5,CE6,CE9 3. (2,3,4) couvre CE2,CE5,CE6,CE10 Cas de tests invalides: 1. (0,1,1) couvre CEI1 2. (1,2,3) couvre CEI7 3. (2,3,4,7) couvre CEI4 4. (1,2) couvre CEI3 et CEI7

27 27/03/2001 InfoBase: Techniques de Test27 Equivalence Partitioning Déterminer les résultats attendues - exemple Cas de tests valides: 1. (1,1,1) couvre CE2,CE5,CE6,CE8 2. (1,2,2) couvre CE2,CE5,CE6,CE9 3. (2,3,4) couvre CE2,CE5,CE6,CE10 Cas de tests invalides: 1. (0,1,1) couvre CEI1 2. (1,2,3) couvre CEI7 3. (2,3,4,7) couvre CEI4 4. (1,2) couvre CEI3 et CEI7 Résultats attendus: 1. Equilatéral 2. Isocèle 3. Scalène Résultats attendus: 1. Entrée invalide 2. Entrée invalide 3. Entrée invalide 4. Entrée invalide

28 27/03/2001InfoBase: Techniques de Test28 Black-box Testing Méthode 3: Boundary/Extreme values analysis

29 27/03/2001 InfoBase: Techniques de Test29 Boundary values analysis: Principe n Baser les cas de tests sur des valeurs "limites" ou "extrèmes" –juste en deçà et juste au delà et sur la frontière des classes d'équivalence –sur les entrées et les sorties –sur base d'heuristiques n Complémentaire des autres approches black-box n En pratique cela permet de détecter beaucoup d'erreurs

30 27/03/2001 InfoBase: Techniques de Test30 Boundary value analysis: Exemple d'heuristiques n Valeurs d'entrée valides = intervalle –tests "valides": limites de l'intervalle –test "invalides": juste au delà des limites n Nombre de valeurs d'entrée contraint –tests "valides": nombre min. et max. –test "invalides": un de moins, un de plus n Entrée = Ensemble ordonné –tests valides: premier et dernier éléments n Valeurs –très petites (0,00000001) ou –très grandes (proche de  ou des max. du language de programmation)

31 27/03/2001InfoBase: Techniques de Test31 White-box Testing Principes

32 27/03/2001 InfoBase: Techniques de Test32 White box testing: Principes n Rappel: on ne sait pas tester toutes les exécutions possibles n Objectif: –en se basant sur la "logique" (code) du programme... –définir un ensemble de cas de tests qui couvrent le plus possible d’exécutions du programme n Utilisé en complément de l'approche black- box

33 27/03/2001 InfoBase: Techniques de Test33 White box testing: Etape préliminaire Morceau de programme: 1. Read A,B; cpt:=0 2. If A>0 cpt:=cpt+1 3. If B>0 cpt:=cpt+1 Morceau de programme: 1. Read A,B; cpt:=0 2. If A>0 cpt:=cpt+1 3. If B>0 cpt:=cpt+1 Read A,B cpt:=0 Transformer le programme en un graphe de flux de contrôle: A>0 B>0 cpt:=cpt+1 true false Procéder instruction par instruction Ignorer les instructions séquentielles Ajouter un nœud pour toute décision ou branchement

34 27/03/2001 InfoBase: Techniques de Test34 White box testing: Etape préliminaire C C P2 P1 truefalse P WHILE C DO P false true IF C THEN P1 ELSE P2

35 27/03/2001 InfoBase: Techniques de Test35 Read A,B cpt:=0 A>0 B>0 cpt:=cpt+1 true false Niveaux de couverture d’un jeu de tests: Statement coverage n chaque instruction est exécutée au moins une fois n Exemple: A=1, B=1 n Insuffisant!

36 27/03/2001 InfoBase: Techniques de Test36 Niveaux de couverture d’un jeu de tests: Decision (Branch) coverage n chaque branche (vrai/faux) d'une décision (test ou condition de boucle) est parcourue au moins une fois n Exemple: –1) A=1 et B=1 –2) A=-1 et B=-1 n Insuffisant! Read A,B cpt:=0 A>0 B>0 cpt:=cpt+1 true false 12

37 27/03/2001 InfoBase: Techniques de Test37 Niveaux de couverture d’un jeu de tests: Condition coverage n Dans le cas où une décision comprend plusieurs conditions, une condition peut en cacher une autre n S'assurer que chaque condition est évaluée au moins une fois Read A,B,C cpt:=0 A>0 et B>0 B<0 ou C=5 cpt:=cpt+1 true false

38 27/03/2001 InfoBase: Techniques de Test38 Niveaux de couverture d’un jeu de tests: Multiple Condition coverage n S'assurer que chaque combinaison possible de conditions est évaluée au moins une fois Read A,B,C cpt:=0 A>0 et B>0 B<0 ou C=5 cpt:=cpt+1 true false

39 27/03/2001 InfoBase: Techniques de Test39 White-box testing: Comment définir l'ensemble des cas de tests? n Basée sur les tests obtenus par l’approche Black- box: –ajouter des cas pour obtenir une plus grande couverture n A partir de rien: –Définir un cas –en définir des nouveaux jusqu’à obtenir la couverture désirée n Théorie des graphes: –basis testing: permet d'obtenir le decision/statement coverage

40 27/03/2001 InfoBase: Techniques de Test40 Basis Testing Comment définir l'ensemble des cas de tests? 2. Calculer le nombre de circuits indépendants (=base) = nombre de tests à définir pour avoir la couverture complète Toute exécution du programme est une combinaison de ceux-là Nombre de cas de tests à trouver = # arcs - # sommets + 2 7 - 6 + 2 = 3  3 cas à définir Read A,B cpt:=0 A>0 B>0 cpt:=cpt+1 true false

41 27/03/2001 InfoBase: Techniques de Test41 Decision Coverage: Comment définir l'ensemble des cas de tests? 3. Choisir un cas de test qui représente une exécution quelconque 4. En ajouter un avec au moins un nouvel arc (non encore parcouru par un cas de test précédent 1. A=1, B=1 2. A=1, B= -1 (nouvel arc = false partant de "B>0") 3. A= -1, B= -1 (nouvel arc = false partant de "A>0") Read A,B cpt:=0 A>0 B>0 cpt:=cpt+1 true false 12 3

42 27/03/2001 InfoBase: Techniques de Test42 Decision Coverage: Déterminer les Résultats attendus n Pour chaque cas de test, déterminer le résultat attendu à partir de la spécification –Exemple: Spec="Lire deux entiers, afficher combien parmi eux sont positifs." –Résultats: 1. 2 est affiché 2. 1 est affiché 3. 0 est affiché

43 27/03/2001 InfoBase: Techniques de Test43 Decision Coverage: Exécuter les tests (vérifier) n Exécuter le test et comparer le résultat obtenu avec le résultat attendu 1. A=1, B=1 affiche 2 2. A=1, B= -1 affiche 1 3. A= -1, B= -1 affiche 0 Read A,B cpt:=0 A>0 B>0 cpt:=cpt+1 true false Conclusion: Le programme semble correct.

44 27/03/2001 InfoBase: Techniques de Test44 White-box versus Black box n Black box –peut être utilisé même si pas de code produit (vérifier qu'on a pensé à tous les cas) –peut pas voir les extras (dans le code) –peut pas être sur qu'il n'y a pas une erreur qui traîne n'a peut-être pas essayé tous les chemins d'exécution n White box –peut pas voir les aspects manquants de l'implémentation –peut aussi être utilisé à la main sur du pseudocode –assure une plus grande couverture n  complémentarité: utiliser les deux.

45 27/03/2001 InfoBase: Techniques de Test45 Conclusion n Tester tout au long du processus n Dériver méthodiquement et systématiquement des cas de tests n Les "enregistrer" –pour les réutiliser –pour les inspecter n Améliorer la qualité n Dériver des tests sur un programme mal construit fait ressortir les erreurs (portions de code inatteignables,…)

46 27/03/2001 InfoBase: Techniques de Test46 Références n Glenford J. Myers, The Art of Software Testing, Wiley-Interscience, 1979. n Bill Hetzel, The Complete Guide to Software Testing, Second Edition, QED Information Sciences, Inc., 1988. n http://www.mtsu.edu/~storm