Object-Oriented Software Engineering Practical Software Development using UML and Java

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

2. Définitions de base • Panne: Un comportement inacceptable ouuneexécutionincorrecte du système • La fréquence des pannesmesure la fiabilité du système • L’objetifestd’atteindre un tauxd’échectrèsfaible. • Unepannerésulte de la violation d’uneexigenceexpliciteouimplicite • Faute/Défaut/Bug:Une faille dans un aspect du système qui contribueoupeutcontribuer à l’apparitiond’uneouplusieurspannes. • Peut se trouverdans les exigences, le design ou le code • Il peutprendreplusieursdéfauts pour provoquerunepanneparticulière • Aussiappelébug • Erreur: Dans le contexte du testing, unedécisioninapproprié prise par un développeurqi a conduit à l’introduction d’un défaut • (in this context) a slip-up or inappropriate decision by a software developer that leads to the introduction of a defect Chapter 10: Testing and Inspecting for High Quality

3. Erreur, Faute et Panne Chapter 10: Testing and Inspecting for High Quality

4. Efficacité et Efficience dans le Testing • Pour tester avec efficacité, on doitutiliserunestratégie qui nous permet de découvrir le plus de défautspossibles. • Pour tester avec efficience, on doittrouver le plus grand nombre de défauts en utilisantmoins de tests. • Le testeurdoitcomprendre comment les programmeurspensent, afin de trouver des défauts. • Le testeurdoitégalementpensercommepensercomme un ‘hacker’ pour trouvertoutes les manièrespossibles qui ménacentl’intégrité du système Chapter 10: Testing and Inspecting for High Quality

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 Chapter 10: Testing and Inspecting for High Quality

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. Chapter 10: Testing and Inspecting for High Quality

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 Chapter 10: Testing and Inspecting for High Quality

8. Tests Boîte Blanche (White-Box) • Se concentre sur la logique et le fonctionnement interne du système • Nécessité du code source Chapter 10: Testing and Inspecting for High Quality

9. Approcheorientéeflot 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 Chapter 10: Testing and Inspecting for High Quality

10. Processus en détail • É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 Chapter 10: Testing and Inspecting for High Quality

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 Chapter 10: Testing and Inspecting for High Quality

12. Exemple – Couverture d’instructions Chapter 10: Testing and Inspecting for High Quality

13. Exemple – Couverture de branches Chapter 10: Testing and Inspecting for High Quality

14. Un autre flowgraph Chapter 10: Testing and Inspecting for High Quality

15. Tests en Boîte Noire • Tests sans la connaissance du code source • Tests basés sur la spécification Chapter 10: Testing and Inspecting for High Quality

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 Chapter 10: Testing and Inspecting for High Quality

17. Les classes d’équivalences • Il estgénéralementimpossible de tester chaquevaleur possible comme entrée • E.g. Chaqueentier • Au contraire, on divise les entrées possiblesdans de groupesquevouscroyez qui seronttraités de manièresimilaire par tous les algorithmes. • Cesgroupessontappelésclasses d’équivalence • Un testeurdoitcréerseulement 1-3 tests par classe d’équivalence Chapter 10: Testing and Inspecting for High Quality

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) Chapter 10: Testing and Inspecting for High Quality

19. 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 Chapter 10: Testing and Inspecting for High Quality

20. Combinations de classe d’équivalence • Explosion combinatoire: vous ne pouvez pas tester chaque combination possible des classes d’équivalence • S’il y a 4 entrées avec 5 valeurspossibles, il y aura 54 (i.e. 625) combinations possibles des classes d’équivalence • Au contraire, on teste: • Chaqueclasse d’équivalence • On combineseulementlorsqu’une entrée pourrait affecter uneautre • On choisitd’autres combinations au harsad Chapter 10: Testing and Inspecting for High Quality

21. 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 l’on 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 Chapter 10: Testing and Inspecting for High Quality

22. Analyse des Valeurs Aux Bornes • Erreursonttendance à survenirverslasvaleursextrêmes (bornes) • Sélectionner les élémentsjuste à et autour des bornes de chacunes des CEs • E.g. Le numéro 0 cause souvent des problèmes • Ex: Si l’entrée valide est un mois (1-12) • Testez 0, 1, 12 et 13 • Testez avec un groschiffrepositif et un très petit chiffrenégatif Chapter 10: Testing and Inspecting for High Quality

23. Développementcentrésur les Tests (Test-driven development) • Pratique courante: • Écriretous les tests avantd’écrire le code qui effectue les opérations (i.e. test-first) • Utilisez des outilscomme • junit pour exécuter les tests • Ant pour automatiserl’exécutions des tests • Utilisez les tests commespécification du système • Quandvousécrivez un test, assurezvousqu’il ne passe pas • Ensuiteécrivez le code qui effectue l’opération • Ensuiteassurezvousque le test passe • Pour tester les UI : Selenium Chapter 10: Testing and Inspecting for High Quality

24. Défautsdans les algorithmes • Condition logiques incorrectes • Défaut: • La condition logique qui contrôleune boucle ouunedéclaration if-else sont mal formulées • Stratégielors du testing: • Utilisez les classes d’équivalence et l’analyse des valeurs aux bornes • Variez les valeurs de véritédans les conditions logiques Chapter 10: Testing and Inspecting for High Quality

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

26. Défautsdans les algorithmes • Effectuer un calculdans un mauvaisendroitd’une structure de contrôle. • Défaut: • Le programme effectueune action quandildoit pas, ouil ne l’effectue pas quandildoit le faire. • Stratégie de testing: • Écrire de tests qui exécutent les boucles zérofois, exactementunefois et plus qu’unefois. Chapter 10: Testing and Inspecting for High Quality

27. Exemple while(j<maximum) { k=someOperation(j); j++; } if(k==-1) signalAnError(); if (j<maximum) doSomething(); if (debug) printDebugMessage(); else doSomethingElse(); Chapter 10: Testing and Inspecting for High Quality

28. Défautsdans 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 l’arrêt de la boucle se produit Chapter 10: Testing and Inspecting for High Quality

29. Défautsdans les algorithmes • Erreursconcernant la priorité des opérateurs • Défaut: • Uneerreur se produitlorsque le programmer omet les parenthèsesnécessairesou met des parenthèsesdans un mauvaisendroit • Cesont des erreurstrèsfaciles à trouver • Ex. Si x*y+zdevraitêtre x*(y+z) • Testing: • Créer de tests qui anticipent les erreurs de priorité des opérateurs Chapter 10: Testing and Inspecting for High Quality

30. Défautsdans les algorithmes • Utilisation des algorithmes standards inappropriés • Defect: • Un algorithme inapproprié est innefficace • Testing strategies: • Créer des tests qui déterminent l’efficacité, precision et la performance d’un algorithme Chapter 10: Testing and Inspecting for High Quality

31. Exemple d’un mauvaixchoixd’algorithme • Un algorithme de triage • Bubble sort est un mauvaix choix dans beaucoup de cas. • Un algorithme inefficace de recherche • S’assurer que le temps de recherche n’augmente pas considérablement quand la liste s’allonge Chapter 10: Testing and Inspecting for High Quality

32. 10.5 Défauts dans la coordination • Interblocage et évitement • (Deadlock and livelock) • Défaut: • Un deadlock se produitlorsquedeuxprocessusconcurrentss’attendentmutuellement • Livelockestsimilaire, saufquemaintenant le systèmepeuteffectuercertainscalculsmaisrestedans un étatindéfiniment Chapter 10: Testing and Inspecting for High Quality

33. Example of deadlock Chapter 10: Testing and Inspecting for High Quality

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 Développer un Graphe de Scénarios Déterminer tous les scénarios possibles Analyser et ordonner les scénarios Générer des cas de tests à partir des scénarios pour atteindre l'objectif de couverture 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 S’il 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 islogged in