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

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



3

Erreur, Faute et Panne



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



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.



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



7



8

Tests Boîte Blanche (White-Box)

• Se concentre sur la logique et le fonctionnement interne du système

• Nécessité du code source



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



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



11

Exemple – Couverture d’instructions



12

Exemple – Couverture de branches



13



14

Un autre flowgraph



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



16



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)



18



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



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



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



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



23



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



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?



26


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.



27

Exemple

while(j<maximum){ k=someOperation(j); j++;}if(k==-1) signalAnError();

if (j<maximum) doSomething();if (debug) printDebugMessage();else doSomethingElse();



28


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



29


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


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



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



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



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


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


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


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


● 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

Documents

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