Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 10: Testing and Inspecting to Ensure High Quality.

Présentation au sujet: "Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 10: Testing and Inspecting to Ensure High Quality."— Transcription de la présentation:

1 Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 10: Testing and Inspecting to Ensure High Quality

2 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality2 Définitions de base Panne: Un comportement inacceptable ou une exécution incorrecte du système La fréquence des pannes mesure la fiabilité du système Lobjetif est datteindre un taux déchec très faible. Une panne résulte de la violation dune exigence explicite ou implicite Faute/Défaut/Bug: Une faille dans un aspect du système qui contribue ou peut contribuer à lapparition dune ou plusieurs pannes. Peut se trouver dans les exigences, le design ou le code Il peut prendre plusieurs défauts pour provoquer une panne particulière Aussi appelé bug Erreur: Dans le contexte du testing, une décision inapproprié prise par un développeur qi a conduit à lintroduction dun défaut (in this context) a slip-up or inappropriate decision by a software developer that leads to the introduction of a defect

3 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality3 Erreur, Faute et Panne

4 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality4 Efficacité et Efficience dans le Testing Pour tester avec efficacité, on doit utiliser une stratégie qui nous permet de découvrir le plus de défauts possibles. Pour tester avec efficience, on doit trouver le plus grand nombre de défauts en utilisant moins de tests. Le testeur doit comprendre comment les programmeurs pensent, afin de trouver des défauts. Le testeur doit également penser comme penser comme un hacker pour trouver toutes les manières possibles qui ménacent lintégrité du système

5 Que sont les tests du logiciel? Examen d'une, de plusieurs unités ou d'un ensemble intégré de composants logiciels par exécution execution basée sur des cas de tests attente – reveler des fautes comme pannes Fautes/défauts résultent d'erreurs humaines erreurs se propagent et amplifient d'activité en activité Panne exécution incorrecte du système généralement conséquence d'une faute © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality5

6 Objectif des tests Détecter des défauts avant qu'ils ne causent une panne du système en production. Amener le logiciel testé à un niveau acceptable de qualité (après la correction des défauts identifiés et retestage). Effectuer les tests requis de façon efficiente et effective dans les limite de temps et budget définis. © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality6

7 Types de tests Tests Unitaires Tests boîte noire basés sur spécification Tests boîte blanche basés sur logique interne Tests boîte grise basés sur modèle de design Tests d'intégration Tests de Système Tests de Fonctionnalité Tests de Performance Tests d'acceptation Tests Alpha Tests Bêta Tests de Régression © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality7

8 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality8 Tests Boîte Blanche (White-Box) Se concentre sur la logique et le fonctionnement interne du système Nécessité du code source

9 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality9 Approche orientée flot de données (Flow graph) Basées sur l'analyse du flot de données à travers le programme Chaque branche dans le code (instructions if, while) crée un nœud dans le graphe

10 Processus en détail 1.Établir l'objectif de couverture 2. Dériver un flowchart du code source 3. Déterminer des chemins pour objectif de couverture 5. Exécuter les cas de tests 6. Vérifier la couverture © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality10

11 Couverture de code dans un flowchart Couverture d'instructions Couverture de branches (inclus couverture d'instructions): couverture minimale Couverture de Conditions – conditions de branches ayant évaluées vrai, faux Couverture Branche/Conditions combine couverture de branches et conditions Couverture Multiple Conditions combinaison de conditions des décisions Couverture de Chemins couverture 100% de chemins impossible en pratique © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality11

12 Exemple – Couverture dinstructions © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality12

13 Exemple – Couverture de branches © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality13

14 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality14 Un autre flowgraph

15 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality15 Tests en Boîte Noire Tests sans la connaissance du code source Tests basés sur la spécification

16 Tests en boîte-noire (Black-Box Testing) AVANTAGES Pas besoin du code source DÉSAVANTAGES Ne test pas les fonctions cachées APPROCHES Partitionnement en Classe déquivalences Tables de décision Analyse de valeurs aux bornes © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality16

17 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality17 Les classes déquivalences Il est généralement impossible de tester chaque valeur possible comme entrée E.g. Chaque entier Au contraire, on divise les entrées possibles dans de groupes que vous croyez qui seront traités de manière similaire par tous les algorithmes. Ces groupes sont appelés classes déquivalence Un testeur doit créer seulement 1-3 tests par classe déquivalence

18 Heuristiques pour identification de Classes déquivalences Pour chaque donnée: si spécifie un intervalle de valeurs valides, définir 1 CE valide (dans l'intervalle) 2 CEs invalides (une à chaque bout de l'intervalle) 2. si spécifie un nombre (N) de valeurs valides, définir 1 CE valide 2 CE invalides (aucune et plus de N) 3. si spécifie un ensemble de valeurs valides, définir 1 CE valide (dans l'ensemble) 1 CE invalide (en dehors de l'ensemble) © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality18

19 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality19 Exemples de classes déquivalence Entrée valide pour le mois (1-12) Les CE sont: [-..0], [1..12], [13.. ] Entrée valide pour une chaîne de caractères représentant 10 marques différentes de voiture (Mazda, Nissan,…etc) Les CE sont -10 classes, une pour chaque marque -1 classe pour une autre marque

20 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality20 Combinations de classe déquivalence Explosion combinatoire: vous ne pouvez pas tester chaque combination possible des classes déquivalence Sil y a 4 entrées avec 5 valeurs possibles, il y aura 5 4 (i.e. 625) combinations possibles des classes déquivalence Au contraire, on teste: Chaque classe déquivalence On combine seulement lorsquune entrée pourrait affecter une autre On choisit dautres combinations au harsad

21 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality21 Exemple – Combination de classes déquivalence Une entrée valide est soit Metric ou US/Imperial Les CE sont: -Metric, US/Imperial, Autre Une autre entrée valide est vitesse maximale: 1 to 750 km/h ou 1 to 500 mph La validité dépend si lon choisit Metric ou US/Imperial Les CE sont: -[-..0], [1..500], [501..750], [751.. ] Quelque combination des tests -Metric, [1..500]valide -US/Imperial, [1..500]valide -Metric, [501..750]valide -US/Imperial, [501..750]invalide

22 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality22 Analyse des Valeurs Aux Bornes Erreurs ont tendance à survenir vers las valeurs extrêmes (bornes) Sélectionner les éléments juste à et autour des bornes de chacunes des CEs E.g. Le numéro 0 cause souvent des problèmes Ex: Si lentrée valide est un mois (1-12) Testez 0, 1, 12 et 13 Testez avec un gros chiffre positif et un très petit chiffre négatif

23 Développement centré sur les Tests (Test- driven development) Pratique courante: Écrire tous les tests avant décrire le code qui effectue les opérations (i.e. test-first) Utilisez des outils comme junit pour exécuter les tests Ant pour automatiser lexécutions des tests Utilisez les tests comme spécification du système Quand vous écrivez un test, assurez vous quil ne passe pas Ensuite écrivez le code qui effectue lopération Ensuite assurez vous que le test passe Pour tester les UI : Selenium © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality23

24 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality24 Défauts dans les algorithmes Condition logiques incorrectes Défaut: La condition logique qui contrôle une boucle ou une déclaration if-else sont mal formulées Stratégie lors du testing: Utilisez les classes déquivalence et lanalyse des valeurs aux bornes Variez les valeurs de vérité dans les conditions logiques

25 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality25 Défauts dans les conditions logiques if(!landingGearDeployed && (min(now-takeoffTime,estLandTime-now))< (visibility < 1000 ? 180 :120) || relativeAltitude < (visibility < 1000 ? 2500 :2000) ) { throw new LandingGearException(); } Difficile à tester?

26 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality26 Défauts dans les algorithmes Effectuer un calcul dans un mauvais endroit dune structure de contrôle. Défaut: Le programme effectue une action quand il doit pas, ou il ne leffectue pas quand il doit le faire. Stratégie de testing: Écrire de tests qui exécutent les boucles zéro fois, exactement une fois et plus quune fois.

27 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality27 Exemple while(j<maximum) { k=someOperation(j); j++; } if(k==-1) signalAnError(); if (j<maximum) doSomething(); if (debug) printDebugMessage(); else doSomethingElse();

28 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality28 Défauts dans les algorithmes Une boucle ou une recursion qui ne se termine pas Défaut: Une boucle infinie Stratégie de testing: Créer de tests qui vérifient que la condition causant larrêt de la boucle se produit

29 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality29 Défauts dans les algorithmes Erreurs concernant la priorité des opérateurs Défaut: Une erreur se produit lorsque le programmer omet les parenthèses nécessaires ou met des parenthèses dans un mauvais endroit Ce sont des erreurs très faciles à trouver Ex. Si x*y+z devrait être x*(y+z) Testing: Créer de tests qui anticipent les erreurs de priorité des opérateurs

30 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality30 Défauts dans les algorithmes Utilisation des algorithmes standards inappropriés Defect: Un algorithme inapproprié est innefficace Testing strategies: Créer des tests qui déterminent lefficacité, precision et la performance dun algorithme

31 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality31 Exemple dun mauvaix choix dalgorithme Un algorithme de triage Bubble sort est un mauvaix choix dans beaucoup de cas. Un algorithme inefficace de recherche Sassurer que le temps de recherche naugmente pas considérablement quand la liste sallonge

32 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality32 10.5 Défauts dans la coordination Interblocage et évitement (Deadlock and livelock) Défaut: Un deadlock se produit lorsque deux processus concurrents sattendent mutuellement Livelock est similaire, sauf que maintenant le système peut effectuer certains calculs mais reste dans un état indéfiniment

33 © Lethbridge/Laganière 2012 Chapter 10: Testing and Inspecting for High Quality33 Example of deadlock

34 Dérivation de cas de tests d'exigences fonctionnelles Implique la clarification et reformulation des exigences tel qu'elles soient testables – Obtenir une formulation testable (sous forme point) énumérer les exigences uniques grouper les exigences liées – Pour chaque exigence - développer Un cas de test montrant le fonctionnement de l'exigence Un cas de test essayant de la falsifier – ex: en essayant quelque-chose non permis Tester les bornes et contraintes lorsque possible

35 Dérivation de cas de tests d'exigences fonctionnelles Exemple: Exigences d'un système de location de films 1. Le système permettra la location et retour de films – 1.1. Si un film est disponible pour location, il peut être prêté à un client. 1.1.1 Un film est disponible pour la location jusqu'à ce que toutes les copies aient été simultanément empruntées. – 1.2. Si un film était non-disponible pour la location, alors le retour du film le rend disponible. – 1.3. La date de retour est établie quand un film est prêté et doit être montrée quand le film est retourné. – 1.4. Il doit être possible de déterminer l'emprunteur courant d'un film loué par une requête sur celui-ci. – 1.5. Une requête sur un membre indiquera tous les films que celui-ci à en location.

36 Dérivation de cas de tests d'exigences fonctionnelles Situations de tests pour l'exigence 1.1 Essayer d'emprunter un film disponible. Essayer d'emprunter un film non-disponible. Situations de tests pour l'exigence 1.1.1 Essayer d'emprunter un film pour lequel il y a plusieurs copies, toutes empruntées. Essayer d'emprunter un film pour lequel toutes les copies sauf une ont été empruntées.

37 Dérivation de cas de tests d'exigences fonctionnelles Situations de tests pour l'exigence 1.2 Emprunter un film non-disponible. Retourner un film et l'emprunter Situations de tests pour l'exigence 1.3 Emprunter un film, le retourner et vérifier les dates. Vérifier la date d'un film non-retourné.

38 Dérivation de cas de tests d'exigences fonctionnelles Situations de tests pour exigence 1.4 Requête sur un film emprunté. Requête sur un film retourné. Requête sur un film venant d'être retourné. Situations de tests pour exigence 1.5 Requête concernant un membre sans films. Requête concernant un membre avec 1 film. Requête concernant un membre avec plusieurs films.

39 Dérivation de Cas de Tests à partir de Cas d'utilisations Pour tous les cas d'utilisations 1. Développer un Graphe de Scénarios 2. Déterminer tous les scénarios possibles 3.Analyser et ordonner les scénarios 4.Générer des cas de tests à partir des scénarios pour atteindre l'objectif de couverture 5.Exécuter les cas de tests

40 Graphe de Scénarios Généré d'un cas d'utilisation Noeuds correspondent à des points d'attente d'événements – de l'environnement, réaction système Il y a un noeud de départ unique Fin du cas d'utilisation est un noeud de terminaison Arcs correspondent à l'occurrence des événements – Peut inclure des conditions – Arc de boucle spécial Scénario: – chemin de noeud de départ à noeud de terminaison

41 Graphe de scénarios Title: User login Actors: User Precondition: System is ON 1: User inserts a Card 2: System asks for Personal Identification Number (PIN) 3: User types PIN 4: System validates USER identification 5: System displays a welcome message to USER 6: System ejects Card Alternatives: 1a: Card is not regular 1a1: System emits alarm 1a2: System ejects Card 4a: User identification is invalid AND number of attempts < 4 4a.1 Go back to Step 2 4b: User identification is invalid AND number of attempts >= 4 4b.1: System emits alarm 4b.2: System ejects Card Postcondition: User is logged in

42 Scénarios Chemin du début à la fin Boucles doivent être restreintes pour obtenir un nombre fini de scénarios

43 Ordonnancement des Scénarios Sil l y a trop de scénarios pour tout tester Ordonnancement peut-être basé sur criticalité et fréquence Inclure toujours le scénario primaire – devrait être testé en premier

44 Génération de Cas de Tests Selon l'objectif de couverture. Ex: – Toutes les branches du graphe de scénarios (objectif minimal) – Tous les Scénarios – n scénarios les plus critiques

45 Exemple de cas de Test Cas de Test: TC1 Objectif: Test the main course of events for the ATM system. Reférence Scénario: 1 Setup: Create a Card #2411 with PIN #5555 as valid user identification, System is ON Cours des événements Critère de succès: User is logged in