Object-Oriented Software EngineeringPractical Software Development using UML and Java

Chapter 10: Testing and Inspecting to Ensure High Quality

© Lethbridge/Laganière 2012

Chapter 10: Testing and Inspecting for High Quality

2

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— L’objetif est d’atteindre un taux d’échec très faible.— Une panne résulte de la violation d’une exigence explicite ou implicite

•Faute/Défaut/Bug: Une faille dans un aspect du système qui contribue ou peut contribuer à l’apparition d’une 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 à 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

© Lethbridge/Laganière 2012

Chapter 10: Testing and Inspecting for High Quality

3

Erreur, Faute et Panne

© Lethbridge/Laganière 2012

Chapter 10: Testing and Inspecting for High Quality

4

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 l’intégrité du système

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 Quality

5

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 Quality

6

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 Quality

7

© Lethbridge/Laganière 2012

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

© Lethbridge/Laganière 2012

Chapter 10: Testing and Inspecting for High Quality

9

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

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 Quality

10

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 Quality

11

Exemple – Couverture d’instructions

© Lethbridge/Laganière 2012

Chapter 10: Testing and Inspecting for High Quality

12

Exemple – Couverture de branches

© Lethbridge/Laganière 2012

Chapter 10: Testing and Inspecting for High Quality

13

© Lethbridge/Laganière 2012

Chapter 10: Testing and Inspecting for High Quality

14

Un autre flowgraph

© Lethbridge/Laganière 2012

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

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 Quality

16

© Lethbridge/Laganière 2012

Chapter 10: Testing and Inspecting for High Quality

17

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

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 Quality

18

© Lethbridge/Laganière 2012

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

© Lethbridge/Laganière 2012

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 valeurs possibles, il y aura 54 (i.e. 625) combinations possibles des classes d’équivalence

•Au contraire, on teste:—Chaque classe d’équivalence —On combine seulement lorsqu’une entrée pourrait affecter une autre

—On choisit d’autres combinations au harsad

© Lethbridge/Laganière 2012

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

© Lethbridge/Laganière 2012

Chapter 10: Testing and Inspecting for High Quality

22

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 l’entré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

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 l’exécutions des tests

•Utilisez les tests comme spécification du système

•Quand vous écrivez un test, assurez vous qu’il ne passe pas—Ensuite écrivez le code qui effectue l’opération

—Ensuite assurez vous que le test passe•Pour tester les UI : Selenium

© Lethbridge/Laganière 2012

Chapter 10: Testing and Inspecting for High Quality

23

© Lethbridge/Laganière 2012

Chapter 10: Testing and Inspecting for High Quality

24

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 l’analyse des valeurs aux bornes

—Variez les valeurs de vérité dans les conditions logiques

© Lethbridge/Laganière 2012

Chapter 10: Testing and Inspecting for High Quality

25

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?

© Lethbridge/Laganière 2012

Chapter 10: Testing and Inspecting for High Quality

26

Défauts dans les algorithmes

Effectuer un calcul dans un mauvais endroit d’une structure de contrôle.•Défaut:

— Le programme effectue une action quand il doit pas, ou il ne l’effectue 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 qu’une fois.

© Lethbridge/Laganière 2012

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();

© Lethbridge/Laganière 2012

Chapter 10: Testing and Inspecting for High Quality

28

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 l’arrêt de la boucle se produit

© Lethbridge/Laganière 2012

Chapter 10: Testing and Inspecting for High Quality

29

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

© Lethbridge/Laganière 2012

Chapter 10: Testing and Inspecting for High Quality

30

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 l’efficacité, precision et la performance d’un algorithme

© Lethbridge/Laganière 2012

Chapter 10: Testing and Inspecting for High Quality

31

Exemple d’un mauvaix choix d’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

© Lethbridge/Laganière 2012

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 produit lorsque deux processus concurrents s’attendent mutuellement

— Livelock est similaire, sauf que maintenant le système peut effectuer certains calculs mais reste dans un état indéfiniment

© Lethbridge/Laganière 2012

Chapter 10: Testing and Inspecting for High Quality

33

Example of deadlock

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

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.

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.

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é.

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.

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

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

Graphe de scénariosTitle: User loginActors: UserPrecondition: System is ON1: User inserts a Card2: System asks for Personal Identification Number (PIN)3: User types PIN4: System validates USER identification5: System displays a welcome message to USER6: System ejects CardAlternatives:1a: Card is not regular1a1: System emits alarm1a2: System ejects Card4a: User identification is invalid AND number of attempts < 44a.1 Go back to Step 24b: User identification is invalid AND number of attempts >= 44b.1: System emits alarm4b.2: System ejects CardPostcondition: User is logged in

Scénarios

● Chemin du début à la fin

● Boucles doivent être restreintes pour obtenir un nombre fini de scénarios

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

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

Exemple de cas de TestCas 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