Université de Carthage | Faculté des Sciences de Bizerte

Tests Logiciels
TaReK BeN MeNa
Préparation à la Certification
International Software Testing Qualifications Board
Previously on

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

Cas de test Données de test Outils

2K21 TBM 3
TESTER PENDANT LE CYCLE DE VIE DU
DÉVELOPPEMENT LOGICIEL

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

Analyse Besoins
& Faisabilité

Spécification &
Planification

Conception
Globale

§ Les activités de développement (Analyse Conception

des exigences, conception, codage, test) Détaillée
sont réalisées l'une après l'autre. Codage &
Tests Unitaires

Intégration &
§ Les activités de test ont seulement lieu Tests intégration
une fois que toutes les autres activités de
développement sont terminées. Déploiement &
Maintenance

2K21 TBM 5
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

§ intègre le processus de test tout au

long du processus « Tester tôt ». Concep8on
Tests Unitaires
Détaillée
§ inclut des niveaux de test associés à
chaque phase correspondante
§ L'exécution des tests associés à Codage
chaque niveau de test se déroule
séquentiellement

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

Spécifica2on Fonc2onnelle

Conception du Système
§ Exemple
− Unified Process (2 à 4 mois)
Conception Conception Concep2on
− Scrum (1 à 4 sem)
Incrément #1 Incrément #2 Incrément #3
− Prototypage (Expérimentale)
§ Chaque caractéristique est testée à Codage Codage Codage
plusieurs niveaux de test au fur et Incrément #1 Incrément #2 Incrément #3
à mesure qu'elle se rapproche de la
livraison Tests Tests Tests
Incrément #1 Incrément #2 Incrément #3
2K21 TBM 7
TYPOLOGIE DE TEST

2K21 TBM 8
 Niveaux et Types de Tests
Niveaux de Test

Test d’acceptation

Test Système

Test d’intégration

Test Unitaire
Sélection de Test

Test nominal Test fonctionnel Test structurel Test

Boite Noire Boite blanche Probabiliste
Test de robustesse

Test de performance
Test de non régression
Ce qu’on veut tester
2K21(Objet de Test) TBM 9
TYPOLOGIE DE TEST
NIVEAUX DE TEST

2K21 TBM 10
 Niveaux et Types de Tests
Niveaux de Test

Test d’acceptation

Test Système

Test d’intégration

Test Unitaire
Sélection de Test

Test nominal Test fonctionnel Test structurel Test

Boite Noire Boite blanche Probabiliste
Test de robustesse

Test de performance
Test de non régression
Ce qu’on veut tester
2K21(Objet de Test) TBM 11
Tour d’horizon

d
Investissement

-En
d-2
Tests Fonc*onnels (GUI)
Coût
Développeurs &/ QA Team

En
Fiabilité
Temps Tests API
Développeurs &/ QA Team

ion
Effort

rat
Tests d’intégration
Rapidité
Développeurs
ég
Int

Tests de composants
Boite Noire Développeurs

Boite Blanche Tests Unitaires

ire

Développeurs
ita
Un

A?en*on : Il faut séparer les tests unitaires (rapide) des tests d’intégrations (plus lent)
02/2K20 Formation Softilys University 12
Niveaux de Tests - Introduction
§ Test unitaire consiste à tester des composants isolément
− Test de fonctions, du comportement d’une classe
− Doivent répondre à des scénarios de test préalablement établis
− Généralement effectué dans les environnements de développement (Eclipse+JUnit)
− Facile à mette en œuvre
− Cible : les méthodes et les classes
§ Test d’intégration consiste à tester un ensemble de composants qui viennent
d’être assemblés. Il comporte 2 types de tests
− Les test de validité – le nouveau module répond à ce qui a été demandé lorsqu’on
l’intègre dans le système global
− Les tests de non régression – L’intégration du nouveau module n’induit pas de
régressions
• fonctionnelles : modification du comportement des modules existants ou
• non fonctionnelles : (instabilité) du système dans sa globalité
− Cible : les composants et le système global

2K21 TBM 13
2 Unit Tests, 0 integration Test

2K21 TBM 14
Niveaux de Tests - Introduction
§ Test système consiste à tester le système sur son futur site d’exploitation dans
des conditions opérationnelles et au-delà (surcharge, défaillance matérielle,...)
− Cible : le système global sur l’architecture informatique du client

§ Test d'acceptation est la dernière étape avant l'acceptation du système et sa

mise en œuvre opérationnelle
− On teste le système dans les conditions définies par le futur utilisateur
− révèlent souvent des omissions ou des erreurs dans la définition de besoins
− Donc des erreurs de validation et non de vérification
− Dans tous les cas, pour assurer la traçabilité et la reproductibilité des tests (lors des
étapes de maintenance), on doit fournir des documents indiquant les modules
testés, les scénarios de test (entrées, environnements, etc.) et les résultats des tests

2K21 TBM 15
Test Unitaires (de Composants)
§ Objectifs : Tester les composants séparément du système pour :
− Vérifier si les comportements fonctionnels (exactitude des calculs) et non-fonctionnels (recherche
de fuites mémoire) du composant sont tels qu'ils ont été conçus et spécifiés
− Empêcher les défauts de passer à des niveaux de test plus élevés
§ Si les changements de code sont continus (incrémental), les tests de régression automatisés
jouent un rôle clé.
§ Nécessiter de mettre en place des objets fictifs, une virtualisation des services, des bouchons
§ Bases de test
− Conception détaillée, Code, Modèle de données, Spécifications des composants
§ Objets de test
− Composants, modules, Classes
− Code et structures de données, Modules de BD
§ Défauts et défaillances courants
− Fonctionnalité incorrecte (non conforme aux spécifications de conception)
− Problèmes de flux de données
− Code et logique incorrects

2K21 TBM 16
Test d’intégration
§ Objectifs : se concentrent sur les interactions entre les composants ou les systèmes. :
− Vérifier si les comportements fonctionnels et non-fonctionnels des interfaces sont tels qu'ils ont
été conçus et spécifiés
− Trouver des défauts dans les interfaces elles-mêmes ou dans les composants ou systèmes
− peuvent également couvrir les interactions avec des entités externes (p. ex. services Web)
• è Risque, l'organisation qui développe ne contrôle pas les interfaces externes,
§ Bases de test
− Conception du logiciel | Diagrammes de séquence | Spécifications des protocoles d'interface et de
communication | Cas d’utilisation | Architecture au niveau du composant ou du système |
Définitions des interfaces externes
§ Objets de test
− Sous-systèmes | Bases de données | Interfaces | APIs | Micro-services
§ Défauts et défaillances courants
− Données incorrectes, données manquantes ou encodage incorrect des données
− Mauvais séquencement ou synchronisation des appels d'interfaces
− Décalages au niveau des interfaces

2K21 TBM 17
Test système
§ Objectifs : se concentrent sur le comportement d'un système, en considérant les tâches de bout en bout que le
système peut exécuter
− Vérifier si les comportements fonctionnels et non-fonctionnels du système sont tels qu'ils ont été conçus et spécifiés
− Valider que le système est complet et fonctionnera comme prévu
§ L'environnement de test devrait idéalement correspondre à la cible finale ou à l'environnement de production.
§ Bases de test
− Spécifications des exigences système et logicielles (fonctionnelles et non-fonctionnelles)
− Cas d’utilisation ou Epics et User Stories
− Modèles de comportement du système (Diagramme d’activité)
− Diagrammes d’états-transition
− Manuels d'utilisation
§ Objets de test
− Applications, Systèmes Matériel/Logiciel, Systèmes d’exploitation, Configuration du système
§ Défauts et défaillances courants
− Calculs incorrects
− Comportement fonctionnel ou non-fonctionnel inattendu
− Flux de contrôle et/ou de données incorrects au sein du système
− Réalisation incorrecte et incomplète des tâches fonctionnelles de bout en bout
− Incapacité du système à fonctionner correctement dans l'environnements de production

2K21 TBM 18
Test d’acceptation
§ Objectifs : se concentrent sur le comportement du système
− Valider que le système est complet et qu'il fonctionnera comme attendu
− Vérifier que les comportements fonctionnels et non-fonctionnels du système sont tels que spécifiés
du point de vu du Client (utilisateur final)
§ Les formes communes de tests d'acceptation comprennent :
− Tests d'acceptation utilisateur (IHM)
− Tests d'acceptation opérationnelle (Backup - Reprise, Performance, Sécurité)
− Tests d'acceptation contractuelle et réglementaire
− Tests alpha et bêta (COTS)
§ Bases de test
− Processus métier | Exigences utilisateur ou métier | Contrats légaux et normes | Cas d’utilisation
§ Objets de test
− Systèmes sous test, données de configuration
§ Défauts et défaillances courants
− Les workflows du système ne répondent pas aux exigences métier ou utilisateurs
− Les règles métier ne sont pas correctement implémentées
− Le système ne satisfait pas aux exigences contractuelles ou réglementaires

2K21 TBM 19
Résumé
Objec&f Fait par
Tester les modules, classes,
Le développeur du module
Test unitaire opérations, au fur et à mesure de
(avant ou après écriture)
leur développement
Tester l’assemblage des
le développeur du module
Test d’intégration modules, des composants et
ou un autre développeur
leurs interfaces
Tester les fonctionnalités du
Test de système Développeurs
système dans son ensemble
Confirmer que le système est
Test d’acceptation Client
prêt à être livré et installé

2K21 TBM 20
 Positionnement des niveaux de test dans un cycle en V
Documents de Conception globale
Spécification des Interfaces
conception +
détaillée Composant Plan d’intégration
Tests Unitaires
testé
Composant
Non testé .
. Tests
Documents de . d’intégration
conception
détaillée Composant
Tests Unitaires Application
testé
Composant intégrée
Non testé Spécification
Systèmes
Spécification
Fonctionnelle Tests Système
Environnement
d’exécution
Application
validée
Exigences Contractuelles
Application Normes
Tests Users
acceptée et
2K21 Opérationnelle TBM
d’acceptation 21
TYPOLOGIE DE TEST
TYPES DE TEST

2K21 TBM 22
 Niveaux et Types de Tests
Niveaux de Test

Test d’acceptation

Test Système

Test d’intégration

Test Unitaire
Sélection de Test

Test nominal Test fonctionnel Test structurel Test

Boite Noire Boite blanche Probabiliste
Test de robustesse

Test de performance
Test de non régression
Ce qu’on veut tester
2K21(Objet de Test) TBM 23
Types de Tests – Ce qu’on veut tester
§ Tests nominal ou Test de bon fonctionnement
− Les cas de test correspondent à des données d’entrée valide (Test-to-pass)

§ Tests de robustesse
− Les cas de test correspondent à des données d’entrée invalides (Test-to-fail)
− Règle usuelle : Les tests nominaux sont passés avant les tests de robustesse

§ Tests de performance
− Load Testing (test avec montée en charge)
− Stress Testing (soumis à des demandes de ressources anormales)

§ Tests de Non Régression : Que faire quand le programme a été modifié ?

− Réponse : Rejouer les tests pertinents et prioritaire en utilisant une infrastructure de
gestion de tests

2K21 TBM 24
Type de Tests – Sélection de Test
§ Test fonctionnel (Test boîte noire : BN)
− Aucun accès au code ni à l’architecture
− Utilise la description des fonctionnalités du programme (données choisies selon les
paramètres)
I1 O1
I2
I3 O2

§ Test structurel (test boîte Blanche : BB)

− Structure interne du programme doit être accessible (le code)
I1
O1
I2
I3 O2

§ Tests aléatoires et statistiques données choisies selon :

− Une loi uniforme (test aléatoire)
− Une loi statistique (difficile à obtenir)

2K21 TBM 25
TYPOLOGIE DE TEST
EXEMPLE

2K21 TBM 26
 Possibilité d'effectuer tout type de test à tout niveau de test
Niveaux de Test

Test d’acceptation

Test Système

Test d’intégration

Test Unitaire
Sélection de Test

Test nominal Test fonctionnel Test structurel Test

Boite Noire Boite blanche Probabiliste
Test de robustesse

Test de performance
Test de non régression
Ce qu’on veut tester
2K21(Objet de Test) TBM 27
Exemple : Application bancaire
§ Tests fonctionnels
− Test Unitaire
• Tester la classe Compte qui calcul le débit d’un montant.
− Tests d'intégration de composants
• Tester que les informations saisies au niveau de l'interface utilisateur sont
transmises à la couche métier.
− Tests système
• Tester que les titulaires de comptes peuvent demander une ligne de crédit sur leurs
comptes chèques.
− Test d'intégration au niveau système,
• Tester que le système utilise un micro-service externe pour vérifier le taux de devise
d'un titulaire de compte en devise.
− Test d'acceptation,
• Tester que le banquier gère l'approbation ou le refus d'une demande d’ouverture de
compte.

2K21 TBM 28
Exemple : Application bancaire
§ Tests non-fonctionnels
− Test Unitaire
• Test de performance : évaluer le nombre de cycles CPU nécessaires pour effectuer un
calcul de débit complexe.
− Tests d'intégration de composants
• Tests de sécurité : tester la vulnérabilités de débordement de la mémoire tampon dues
aux données transmises de l'interface utilisateur à la couche métier.
− Tests système
• Tests de portabilité : vérifier si la couche de présentation fonctionne sur tous les
navigateurs et appareils mobiles supportés.
− Test d'intégration au niveau système
• Teste de fiabilité : évaluer la robustesse du système lorsque le micro-service
d’autorisation ne répond pas
− Test d'acceptation
• Tester d’utilisabilité : évaluer l'accessibilité de l'interface de traitement de débit pour les
personnes handicapées.

2K21 TBM 29
Exemple : Application bancaire
§ Tests structurels : Boîte Blanche
− Test Unitaire
• Tester la couverture complète des instructions et des décisions pour tous les
composants qui effectuent des calculs financiers.
− Tests d'intégration de composants
• Vérifier comment chaque écran de l'interface du navigateur transmet les données à
l'écran suivant et à la couche métier
− Tests système
• Couvrir les séquences de pages Web qui peuvent se succéder pendant une demande
d’ouverture d’un compte.
− Test d'intégration au niveau système
• Exercer tous les types de requête possibles envoyés au micro-service de calcul de
conversion monétique .
− Test d'acceptation
• Couvrir toutes les structures de fichiers de données financières prises en charge et les
plages de valeurs pour les transferts de banque à banque.

2K21 TBM 30
Exemple : Application bancaire
§ Tests de non-régression
− Test Unitaire
• Tests de régression automatisés sont construits pour chaque composant et inclus
dans le framework d’intégration continue
− Tests d'intégration de composants
• Confirmer les corrections des défauts liés à l'interface au fur et à mesure que ces
corrections sont intégrées dans le référentiel de code.
− Tests système
• Ré-exécuter tous les tests d’un workflow si un écran de ce workflow change.
− Test d'intégration au niveau système,
• Ré-exécuter quotidiennement les tests du micro-services dans le cadre du
déploiement continu
− Test d'acceptation
• Tous les tests échoués précédemment sont ré-exécutés après la correction d'un
défaut constaté lors des tests d'acceptation.

2K21 TBM 31
 Let tests get your feature from point A to point B!

BEHAVIOR DRIVEN DEVELOPMENT

Exemple de test fonctionnels

2K21 TBM 32
BDD : Principe
§ L'objectif principal de la BDD est de résoudre le problème de communication
entre l'entreprise (y compris le chef de produit), l'équipe d'ingénierie et les
machines.
§ Principes
− BDD encourage l'utilisation de langues simples dans les équipes (ubiquitous
Language)
− Les tests sont souvent écrits du point de vue du client; l'accent est mis sur les
clients et les utilisateurs qui interagissent avec le produit
§ Avantages
− Les scénarios sont des exigences, des critères d'acceptation, des cas de test et des
scripts de test tout en un; il n'est pas nécessaire d'écrire un autre artefact.
− Les Frameworks BDD facilitent la transformation de scénarios en tests automatisés.
• Les étapes sont déjà données par les scénarios - l'ingénieur en automatisation a
simplement besoin d'écrire une méthode / fonction pour effectuer les opérations de
chaque étape.

2K21 TBM 33
Scénario BDD : Syntaxe
§ Format simple, 3 éléments clés (descripteur) dans un scénario BDD
GIVEN (describ ing the context
),

WHEN (describing actor and

action),

THEN (describ ing the outcom

e)

§ Si besoin de plus d’informations dans un scénario, un «AND» peut être utilisé

après l’un des descripteurs:
G I V E N ( c o n text ) ,
A N D ( fu rt h e r c o n text
),
n/event),
W H E N ( a cto r + a ct io
A N D ( fu rt h e r a ct io n /
event),

THEN (outco m e)
tco m e)
A N D ( f u r t h e r o u TBM
2K21 34
BDD et User Story
§ Soit l’user story suivant

2K21 TBM 35
Exemples dans un User Story
§ Scénario Simple US #001
eates a LinkedIn Account
Scenario 1: User successfu lly cr
Registration page
GIVEN Ta rek is on the LinkedIn
istration fields
WHEN he enters all required reg
eated
THEN a LinkedIn account is cr

§ Scénario Détaillé
1: User su cc essfu lly cr eates a LinkedIn Account
US #001 - Scenar io
gistration page
GIVEN Ta rek is on LinkedIn Re
reg istration information
WHEN he enters all the required
crire’
AN D he hits ‘Accepter et S’ins
created
THEN his LinkedIn account is
creation page
AN D he is directed to the profile
AN D his confirmation email is
sent
2K21 TBM 36
BDD : Tool - exemple

2K21 TBM 37