Vous êtes sur la page 1sur 56

Université de Carthage | Faculté des Sciences de Bizerte

Tests Logiciels
Tarek Ben Mena
Préparation à la Certification
International Software Testing Qualifications Board
Profitez de cette offre

2K21 TBM 2
Quel pirate atteindra la carte au trésor ?

2K21 TBM 3
Aidez ce programme à fonctionner

?!!? Aucun résultat


Il devrait afficher 3

2K21 TBM 4
1ER EXEMPLE

2K21 TBM 5
Test vs Débogage
§ L'exécution de tests peut mettre en évidence des défaillances causées par des
défauts dans le logiciel.

§ Le débogage est l'activité de développement qui trouve, analyse et corrige de


tels défauts.

§ Par la suite, le test de confirmation vérifie si les corrections apportées ont résolu
les défauts.

§ Dans certains cas, les testeurs sont responsables du test initial et du test de
confirmation final,

2K21 TBM 6
Test Initial - Ça ne marche pas

2K21 TBM 7
Débogage

2K21
Fixer des Breakpoint TBM Lancer le débogage 8
Débogage

2K21 TBM 9
Débogage

2K21 TBM 10
Test de confirmation - Ça marche

2K21 TBM 11
CONCEPTS FONDAMENTAUX

2K21 TBM 12
Le Bug le plus cher de l’histoire

Cause : Un simple dépassement d’entier !


Composant : Système d’auto pilotage :
Accéléromètres et de gyroscopes (mesure
de mouvements)
Sauf que une variable qui calcule
l’accélération horizontale est codée sur 8
bits (256 valeurs).
Sur Ariane 4, cette valeur avait pour
maximum 64 (64 < 256),
Mais sur Ariane 5, (plus puissante), cette
variable peut atteindre 300 !
Le problème, 300 > 256 la variable est
Date : 4 Juin 1996 passée à 256, puis non pas à 257, mais à 0,
Objet : Fusée Ariane 5 c’est ce que l’on appelle le passage aux
pôles. Le calcul se basait alors sur la
Durée vol : 36,7 secondes variable d’accélération horizontale = 0 pour
Coût : 475 M€ ce moment du vol.
2K21 TBM 13
Meme

Quand je prends pas au

2K21
sérieux le cours
TBM
« Test Logiciel » 14
Logiciel : Définitions
§ «est défini comme une création intellectuelle rassemblant des
programmes, des procédures, des règles et de la documentation utilisé
pour faire fonctionner un système informatique »
ISO (International Organization for Standardization).

§ «Ensemble des programmes, procédés et règles, et éventuellement de la


documentation, relatifs au fonctionnement d'un ensemble de traitement
de données.»
Journal Officiel du 17 janvier 1986.

19/2K20 TBM 15
Un Bon Logiciel
Caractéristiques qualité
Interne et Externe

Functionnality Usability Reliability Efficiency Serviceability Portability


(Fonctionnalité) (Facilité à l’emploi) (Fiabilité & sûreté) (Performances) Maintenability (Evolutivité)

Adéquation des Capacité et facilité Maturité Temps de réponse Capacité et facilité Capacité et facilité
fonctions de : et comportement de : de :
Tolérance aux dynamique • Analyser des • Adaptation et
Précision et fidélité • Compréhension pannes défaillances évolution
des résultats Utilisation des
• Apprentissage Remise en état de ressources : • Modification • Installation des
Interopérabilité marche après • Mémoire modifications
• Exploitation échec • CPU • Tests
Sécurité • Débit en (automaticité, • Remplacement
• Ergonomie IHM transactionnel non régression)
Conformité aux du point de vue • Cohabitation
exigences métier
fonctionnelles

2K21 TBM 16
Test : Définitions
§ «Le test est l’exécution ou l’évaluation d’un système ou d’un composant
par des moyens automatiques ou manuels, pour vérifier qu’il répond à ses
spécifications ou identifier les différences entre les résultats attendus et
les résultats obtenus »
IEEE (Standard Glossary of Software Engineering Terminology).

§ «Tester, c’est exécuter le programme dans l’intention d’y trouver des


anomalies ou des défauts»
G. Myers (The Art of Software testing).

19/2K20 TBM 17
Qu’est-ce qu’un test et quel est son coût ?
§ Expérience d’exécution pour mettre en évidence un défaut / erreur
− diagnostic: quel est le problème, l’erreur
− localisation: où est la cause du problème?
− Vérifier que le résultat de l’expérience est conforme aux intentions
§ Les tests à faire et résultats dépendent des spécifications

2K21 TBM 18
Coût des Tests

2K21 TBM 19
MODÈLE DE CYCLES DE VIE LOGICIEL

2K21 TBM 20
Une vraie situation

ISET Charguia
Cycle de vie Logiciel - Définition
§ Comme pour tout produit manufacturé complexe :
− La production est décomposé en « Activités de développement » ou « Phases »
− L’ensemble d’Activités constitue un « cycle de vie »
− Les Activités font apparaître des tâches clés

§ Activités de développement (Phases)


− Analyse des besoins : Pourquoi le Logiciel?
− Spécification : Quoi faire ?
− Conception : Comment le faire ?
− Codage et Intégration
− Tests : Vérification et validation
• Vérification : Développeur
• Validation : Client
− Déploiement & Maintenance

2018/19 TBM 22
Cycle de vie
§ 2 Catégories:
• Modèles de développement séquentiel
• Modèles de développement itératif et incrémental
1. Modèle de développement séquentiel
− Décrit le processus comme un flux linéaire (Phases successives).
− Il est bénéfique d'avoir un retour rapide de la phase suivante.
− Fournit des logiciels qui nécessitent généralement des mois ou des années pour être
livrés aux parties prenantes et aux utilisateurs.
2. Modèle de développement itératif et incrémental
− Décrit le processus comme une série de cycle d’activités (Phases par morceaux)
− Fournit un incrément plus grand à chaque itération (Itération = succession de phase)
− Fournit des parties de logiciels en quelques semaines mais ne peuvent livrer
l'ensemble des exigences que sur une période de mois ou d’années.

2K21 TBM 23
Cycle de vie
§ Modèle de développement séquentiel

Analyse de Besoins Conception Codage Tests

Logiciel

2K21 TBM 24
Cycle de vie
§ Modèle de développement itératif et incrémental

Conception
Conception Conception

Itéra,on Codage
Itération Itération Codage Analyse
Analyse Codage Analyse
#3
#1 #2

Tests
Tests Tests

2K21 TBM 25
Cycle de vie séquentiel – Modèle en Cascade

Analyse Besoins
& Faisabilité

Spécification &
Planification

Conception
Globale

Conception
Détaillée

Codage &
Tests Unitaires

Intégration &
Tests intégration

Déploiement &
Maintenance

2K21 TBM 26
Cycle de vie séquentiel – Modèle en V
Analyse Besoins Tests
& Faisabilité d’acceptation

Spécification & Installation &


Planification Tests Système

Conception Intégration &


Globale Tests intégration

Conception
Tests Unitaires
Détaillée

Codage

2K21 TBM 27
Cycle de vie Spiral : itératif et incrémental
Analyse Besoins
Conception
& Faisabilité

V5 V4 V3 V2 V1

Tests Codage

2K21 TBM 28
Cycle de vie itératif et incrémental
Expression des Besoins

Spécification Fonctionnelle

Conception du Système
§ Exemple
− Unified Process (2 à 4 mois) Conception Conception Conception
− Scrum (1 à 4 sem) Incrément #1 Incrément #2 Incrément #3
− Prototypage (Expérimentale)
Codage Codage Codage
Incrément #1 Incrément #2 Incrément #3

Tests Tests Tests


Incrément #1 Incrément #2 Incrément #3
2K21 TBM 29
PRINCIPES ET TERMINOLOGIE

2K21 TBM 30
7 Principes de Tests
1. Les tests montrent la présence de défauts, pas leur absence
− Si aucun défaut n’est découvert, ce n’est pas une preuve que tout est correct
2. Les tests exhaustifs sont impossibles
− Tester toutes les combinaisons d’entrées et de préconditions n’est pas faisable
3. Tester tôt économise du temps et de l’argent « shift left »
− les activités de tests statiques e dynamiques doivent être lancées ASAP dans le CVL
4. Regroupement des défauts
− Loi Pareto (dans les tests logiciels) : 80% des défauts proviennent des 20% des modules
5. Paradoxe du pesticide
− Pour détecter de nouveaux défauts, il peut être nécessaire de modifier les tests existants et
les données de test existantes
6. Les tests dépendent du contexte
− Par exemple, un logiciel de contrôle industriel, critique au niveau de la sureté, sera testé
différemment d’une application de commerce électronique sur téléphone mobile
7. L’absence d’erreurs est une illusion
− Corriger un grand nombre de défauts ne garanti pas la réussite d’un système (Ariane 5 !).

2K21 TBM 31
Anomalies Logicielles
§ Chaîne de causalité

Erreur Défaut Anomalie

Erreurs humaines :
Différence entre
• Spécification Présence ou absence
comportement attendu
• Conception d’éléments dans le
et comportement
• Développement logiciel
observé
• Etc.

2K21 TBM 32
Problématique
§ But : détecter les défauts le plus tôt possible dans le cycle
− Tester une nouvelle méthode dès qu’on l’écrit
− Répéter les tests à chaque modification du code

§ Mais prouver l’absence d’erreur = problème indécidable


− On ne peut pas tester tout le temps ni tous les cas possibles
− Il faut des heuristiques réalistes
− Critères pour choisir les cas intéressants = Cas de Test (CT)

§ Test Driven Development (TDD)


− Écrire les Cas de Test (CT) avant le programme
− Développer la partie du programme qui fait passer les CT

2K21 TBM 33
Test : une peu de Vocabulaire

Données de Test (DT) : jeux de données d’entrée d’un programme

Cas de Test (CT) : scenario à exécuter

Suite de Tests : ensemble de CTs

2K21 TBM 34
Test : Vocabulaire - exemple
§ Spécification
− Gérer une liste de noms de restaurants par ordre de proximité́

§ Cas de Test (CT) :


− CT1 : Cas limites et valeurs spéciales
• DT : ajout dans une liste vide
− CT2 : Test des cas normaux
• DT : ajout dans une liste à 1 élément
• DT : retrait dans une liste à 2 éléments
− CT3 : est des cas anormaux
• DT : entrée invalide (non respect des pré-conditions)
• DT : retrait dans une liste vide

2K21 TBM 35
EST VOUS UN BON TESTEUR ?

2K21 TBM 36
Jeu : est vous un bon testeur ? – 5 min
§ Exemple
− Un programme prend 3 entiers en entrée, qui sont interprétés comme représentant
les longueurs des côtés d’un triangle. Le programme doit retourner un résultat
précisant s’il s’agit d’un triangle scalène, isocèle ou équilatéral.

− Ecrivez l’ensemble des cas test pour ce programme ?

2K21 TBM 37
Calculer votre score
§ Est ce que vous avez le(s) cas test où vous vérifiez :
1. Cas scalène valide(1, 2, 3 et 2, 5, 10 ne sont pas valides par ex.)
2. Cas équilatéral valide
3. Cas isocèle valide (remarque le cas 2, 2 , 4 n’est pas valide traité après)
4. Cas isocèle valide avec les 3 permutations sur l’ordre des entrées (par ex. 3,3,4 – 3,4,3
– 4,3,3)
5. Cas avec un coté avec une valeur nulle
6. Cas avec une valeur négative
7. Cas où les 3 cotés sont > 0 et la somme de deux entrées est égale à la troisième entrée
8. 3 cas pour le test 7 avec les trois permutations
9. Cas où la somme de deux entrées est inférieure à la troisième
10. 3 cas pour le test 9 avec les 3 permutations
11. Cas avec les 3 entrées nulles
12. Cas avec une entrée non entière
13. Cas avec un nombre erroné d’entrée (2 ou 4)
14. Pour chaque cas test, avez-vous défini le résultat attendu?

2K21 TBM 38
Positionner vous

“ Highly qualified professional programmers


score, on the average, only 7.8 out of a
possible 14.
If you’ve done better, congratulations !”
The Art Of Software Testing,
3rd Ed G. J. Myers, T. Badgett, C. Sandler

2K21 TBM 39
Etat d’esprit des testeurs et des développeurs

§ Les testeurs doivent avoir de


§ Identifier les défauts peut être bonnes compétences
perçu comme une critique du interpersonnelles pour bien
produit et de ses auteurs. communiquer sur les défauts

§ Les développeurs attendent de § Mettre l'accent sur les bénéfices


leur code qu'il soit correct, ils ont du test.
un biais de confirmation pour
accepter qu'il est incorrect. § Communiquer les résultats des
tests sans critiquer la personne
§ On blâme toujours le porteur de la qui a créé l’item défectueux.
mauvaise nouvelle
§ Rédiger des rapports objectifs et
§ le test est perçu comme une factuels sur les défauts et les
activité destructrice constats des revues.

§ Essayer de comprendre ce que


ressent l'autre personne
2K21 TBM 40
PROCESSUS DE TEST

2K21 TBM 41
Processus de Test
§ Pas de processus unique mais ensemble d’activités de test à faire pour atteindre
l’objectif.
§ Ce processus peut être influencé par des facteurs contextuels
CVL Risques du projets EXEMPLE Outsider
Modèle V
Domaine
Types de Tests d’activité Gestion
Processus Test e2e de Stock
Processus
Activité Test #1
Planifica8on Test

Activité Test #2
Analyse Test

Activité Test #3
Conception Test

Politiques & Pratiques Contraintes :


• Budgets Feedback Contraintes :
Organisationnelle
• Délai Comité de pilotage • 20M
Normes de qualité • Complexité • 3 mois
• Contrat ISO/IEC/IEEE 29119-2 • medium
2K21 TBM • 3 livrables
42
Processus de Test Simplifié
§ Exemple : Trier un ensemble de données en supprimant les doublons
− Interface : int[] montri(int[] tab)
§ Etape 1 : Définir un Cas test (CT) à exécuter, (un “scénario” à appliquer)
− tableau de N entiers non redondants
§ Etape 2 : Concrétiser le CT en lui fournissant des Données de Test (DT)
− DT : Le tableau [1,0,12,4,43,5,21]
§ Etape 3 : Indiquer le résultat attendu pour ce CT (prédiction de l’Oracle)
− DT : [1,0,12,4,43,5,21] Oracle : [0,1,4,5,12,21,43]
§ Etape 4 : Exécuter le script de test testant le CT sur les DT
− DT : [1,0,12,4,43,5,21] Résultat : [0,1,4,5,12,21,43]
− Oracle : [0,1,4,5,12,21,43]
§ Etape 5 : Compare le Résultat obtenu à la prédiction de l’Oracle (verdict)
− Oracle Résultat
§ Etape 6 : Rapporter le résultat : = succès | ≠ échec
2K21 TBM 43
Processus de test- Activités

Planification des Tests

Pilotage et contrôle des Tests

Analyse de Test

Conception des tests

Implémentation des Tests

Exécutions des Tests

Clôture des Tests

2K21 TBM 44
Processus de test- Activités

Planification des Tests


Planification des Tests
Pilotage et contrôle des Tests • Définir les objectifs du test
• Retenir une approche pour atteindre les
Analyse de Test objectifs (respect des contraintes)
• Spécifier les techniques et tâches de
test appropriées,
Conception des tests
• Produire un calendrier de test pour
respecter une date limite).
Implémentation des Tests • Revoir les plans de test en fonction des
retours sur les activités de pilotage et de
Exécutions des Tests contrôle

Clôture des Tests

2K21 TBM 45
Processus de test- Activités

Planification des Tests Pilotage et contrôle des Tests


• Comparer régulièrement l’avancement réel p/p
au plan (métriques)
Pilotage et contrôle des Tests • Prendre les mesures nécessaires pour
satisfaire les objectifs du plan de test
• Evaluer les critères de sortie (dod):
Analyse de Test • Vérifier les résultats (R) et logs (L) des
tests (p/p critères de couverture)
Conception des tests • Évaluer niveau de qualité des composants
(selon L et R)
• Identifier et Ecrire d'autres tests (ex.
Implémentation des Tests
niveau de couverture des risques Produit
non atteint)
Exécutions des Tests • Communiquer aux parties prenantes les écarts
par rapport au plan et les informations utiles à
toute décision d’arrêter les tests.
Clôture des Tests

2K21 TBM 46
Processus de test- Activités

Planification des Tests Analyse de Test – « Quoi tester ?»


• Déterminer « Quoi tester" en termes de critères
de couverture mesurables.
Pilotage et contrôle des Tests • Analyser les bases de test :
• les exigences fonctionnelles (Use cases), la
conception (Diagrammes UML),
Analyse de Test L’implémentation (code, requêtes BD) , Les
rapports de risques
Conception des tests • Evaluer les bases de test pour identifier des
défauts :
• Ambiguïtés, Omissions, Incohérences, Bruit
Implémentation des Tests • Identifier les caractéristiques à tester
• Définir et prioriser les conditions de test pour
chaque caractéristique
Exécutions des Tests • Capturer la traçabilité bidirectionnelle entre
chaque élément des bases de test et les
Clôture des Tests conditions de test associées

2K21 TBM 47
Processus de test- Activités

Planification des Tests

Pilotage et contrôle des Tests Conception des Tests – « How test ? »


• Décliner les conditions de test en cas de test
de haut niveau.
Analyse de Test • Concevoir et prioriser les cas de test et les
ensembles de cas de test (Suites)
Conception des tests • Identifier les données de test nécessaires pour
les conditions de test et les cas de test
• Identifier l'infrastructure et les outils
Implémentation des Tests nécessaires
• Etablir la traçabilité bidirectionnelle entre les
Exécutions des Tests bases de test, les conditions de test, les cas de
test et les procédures de test

Clôture des Tests

2K21 TBM 48
Processus de test- Activités

Planification des Tests Implémentation des Tests


• Développer et prioriser les procédures de test
(PT) créer des scripts de test (ST) automatisés
Pilotage et contrôle des Tests • Créer des suites de tests à partir PT et ST
• Positionner les suites de tests dans un
calendrier d'exécution des tests
Analyse de Test • Construire l'environnement de test (les harnais
de test, la virtualisation des services, les
Conception des tests simulateurs et d'autres éléments
d'infrastructure)
• Préparer les données de test et les chargées
Implémentation des Tests
dans l'environnement de test
• Vérifier et mettre à jour la traçabilité
Exécutions des Tests bidirectionnelle entre les bases de test, les
conditions de test, les cas de test, les
procédures de test et les suites de tests
Clôture des Tests

2K21 TBM 49
Processus de test- Activités

Planification des Tests Exécution des Tests


• Exécuter les suites de tests conformément au
calendrier d'exécution des tests.
Pilotage et contrôle des Tests • Enregistrer les versions des éléments de test,
des outils de test et des Testware
• Exécuter les tests manuellement / avec outils
Analyse de Test • Comparer les résultats obtenus avec les
résultats attendus
Conception des tests • Analyser les anomalies identifier leurs causes
• Signaler les défauts sur la base des défaillances
• Enregistrer les résultats (ok, échec, blocage)
Implémentation des Tests • Répéter certaines activités de test : exécution
d'un test corrigé, et/ou test de régression)
Exécutions des Tests • Vérifier et mettre à jour la traçabilité
bidirectionnelle entre les bases de test, les
conditions de test, les cas de test, les
Clôture des Tests procédures de test et les résultats des tests

2K21 TBM 50
Processus de test- Activités

Planification des Tests Clôture des Tests


• Collecter les données des activités de test
terminées afin de consolider l'expérience,
Pilotage et contrôle des Tests • Vérifier si tous les rapports de défauts sont
clôturés,
• Saisir des demandes de modification pour tous
Analyse de Test les défauts non résolus
• Créer un rapport de synthèse de test le
Conception des tests communiquer
• Finaliser et archiver l’environnement de test, les
données de test, et autres Testware pour une
Implémentation des Tests
réutilisation ultérieure
• Analyser le retour sur expérience afin de
Exécutions des Tests déterminer les changements nécessaires pour
les itérations, versions et projets futurs

Clôture des Tests

2K21 TBM 51
Produits d’Activité

Planification des Tests Objectifs du test Techniques Plans de test

Pilotage et contrôle des Tests

Analyse de Test Bases de test Caractéristiques Conditions de test

Conception des tests Cas de test Données de test + Outils

Procédures Scripts Suites Environnement


Implémentation des Tests de test + de test de Tests de test

Exécutions des Tests Résultats = Rapports + Log

Clôture des Tests Rapport de synthèse

2K21 TBM 52
Produits d’Activité
Bases de test Scénarios de Test Conditions de test du Scénario ST1
ST1: Vérifiez si l’admin peut TCd1.1: Entrez le nom du pays valide et vérifiez
ajouter un nouveau l'ajout du pays
ST2: Validez si un pays existant TCd1.2: Entrez un espace et vérifiez si le pays est
peut être supprimé par l'admin ajouté.
ST3: Validez si un pays existant TCd1.x: Dans chaque cas, les données spécifiques
peut être mis à jour sont décrites et le but du test est plus précis.

Cas de test Données de test Outils

2K21 TBM 53
Exemple d’un Template de Test Case
Project Name: <Name>
Test Case
Test Case ID: TC_Fun_10 Test Designed by: <Name>
Module Name: Manage Countries Test Designed date: <Date>
Requirements : REQ_Fun_10 Test Executed by: <Name>
Test Title: Verify add country with valid data Test Execution date: <Date>
Description: Test Admin add country Test Priority (Low/Medium/High): Med

Pre-conditions: Admin is logged


Dependencies:
Step Test Steps Test Data Expected Result Actual Result Status Notes
(Pass/Fail)
1 Navigate to Countries Page Manage User is navigated to
Url = https://site/country/add Pass
page Country loaded page with successful
2 Provide valid Country
Name = Tunisia
name
Provide valid country
3 Area = 163 610
area
4 Click on Add button

2K21
Post-conditions : a Country is added to the DB TBM 54
Autre Exemple d’une fiche de cas de test

19/2K20 TBM 55
Glossaire
Base de test : L'ensemble des connaissances utilisées comme base pour
l'analyse et la conception des tests.
Analyse

Condition de test : Un aspect des bases de test qui est pertinent pour
atteindre des objectifs de test spécifiques. (Situation de test)
Implémentation Conception

Cas de test : Un ensemble de conditions préalables, de données d'entrée,


d'actions (le cas échéant), de résultats attendus et de post-conditions,
élaboré sur la base des conditions de test. (Scénario)

Procédure de test : Une séquence de cas de test dans l'ordre d'exécution, et


toutes les actions associées qui peuvent être nécessaires pour mettre en
place les préconditions initiales et toutes les activités de bouclage après
l'exécution.
2K21 TBM 56