ALD_ISTQB Fondation_Chapitre 4_V1.2.pptx

Aldemia Campus Touch
Formation
ISTQB Niveau Fondation
Chapitre 4
Techniques de test
330 mn
1 | 2018 | ISTQB Fondation – Chapitre 4 / Copyright Aldemia 2018 – reproduction interdite

Notes de lecture
• Des pictos caractéristiques illustrent certains aspects du contenu :
 Point d’attention en vue de la préparation aux QCM
 Point d’attention, niveau de complexité élevé
 Expression issue du syllabus
 Définition extraite du glossaire ISTQB
 Information complémentaire, digression
Glossaire

Sommaire du chapitre 4
« Techniques de test »
1. Catégories de techniques de test
1. Choix des techniques de test
2. Catégories de techniques de test et leurs
caractéristiques
2. Techniques de test boîte-noire
1. Partitions d'équivalence
2. Analyse des valeurs limites
3. Test de tables de décision
4. Test des transitions d'état
5. Test des cas d'utilisation
3. Techniques de test boîte-blanche
1. Test et couverture des instructions
2. Test et couverture des décisions
3. Apport des tests des instructions et décisions
4. Techniques de test basées sur l'expérience
1. Estimation d’erreur
2. Tests exploratoires
3. Tests basés sur des checklists

Chapitre 4 – Les objectifs pédagogiques
| ISTQB Fondation – Chapitre 4 / Copyright Aldemia 2018 – reproduction interdite
5 | 2018
§ Réf. objectifs Objectifs
Niveau
apprentissage
4.1 FL-4.1.1
Expliquer les caractéristiques, les points communs et différences entre les techniques de test
boîte-noire, boîte-blanche et basées sur l'expérience K2
4.2 FL-4.2.1
Appliquer la technique des partitions d'équivalence pour produire des cas de test à partir
d'exigences données K3
4.2 FL-4.2.2
Appliquer l'analyse des valeurs limites pour produire des cas de test à partir d'exigences
données K3
4.2 FL-4.2.3
Appliquer le test de tables de décision pour produire des cas de test à partir d'exigences
données
K3
4.2 FL-4.2.4
Appliquer le test des transitions d'état pour produire des cas de test à partir d'exigences
données
K3
4.2 FL-4.2.5 Expliquer comment produire des cas de test à partir d'un cas d'utilisation K2
4.3 FL-4.3.1 Expliquer la couverture des instructions K2
4.3 FL-4.3.2 Expliquer la couverture des décisions K2
4.3 FL-4.3.3 Expliquer l’intérêt de la couverture des instructions et des décisions K2
4.4 FL-4.4.1 Expliquer l'estimation d’erreur K2
4.4 FL-4.4.2 Expliquer le test exploratoire K2
4.4 FL-4.4.3 Expliquer le test basé sur des checklists K2

Chapitre 4 – Les termes du glossaire
Glossaire

4.1
Catégories de techniques de test

4.1 Catégories de techniques de test
5-
Exécution
6-
Clôture des
tests
1-
Planification
1- Pilotage et contrôle
2-
Analyse
3-
Conception
4-
Implémentation
 Les techniques des test dans le processus de test, participent à l’identification :
 Des conditions de test
 Des cas de test
 Des données de test.
 Les techniques des test sont utilisées dans les activités de :
 Analyse – identification des conditions de test
 Conception – spécifications des cas de test et des données de test
 Implémentation – conception de test lors de tests exploratoires
Le processus de test

 Techniques boîte noire
 Technique 1
 Technique 2
 Technique 3
 Technique 4
 Techniques boîte blanche
 Technique 5
 Technique 6
 Techniques basées sur l’expérience
 Technique 7
 Technique 8
4.1.1 Choix des techniques de test
 Des facteurs déterminants pour le choix des techniques de test :
 Type de composant ou de système
 Complexité du composant ou des système
 Normes réglementaires
 Exigences client ou contractuelles
 Niveaux de risque
 Types de risques
 Objectifs du test
 Documentation disponible
 Connaissances et compétences des testeurs
 Outils disponibles
 Temps et budget
 Modèle de cycle de vie du développement logiciel
 Utilisation prévue du logiciel
 Expérience antérieure
 Types de défauts recherchés

4.1.1 Choix des techniques de test
 Techniques de test et niveaux de test :
 Certaines techniques sont plus applicables à certaines
situations et à certains niveaux de test
 D’autres techniques sont applicables à tous les
niveaux de test
 Techniques de test et niveau de formalité :
 L'utilisation des techniques de test dans les activités d’analyse des tests, de conception des tests et
d’implémentation des tests peut varier de très informel à très formel
 Des critères pour décider d’un niveau de formalité :
• La maturité des processus de test et de
développement
• Les contraintes de temps
• Les exigences de sûreté ou réglementaires
• Les connaissances et les compétences des
personnes impliquées
• Le modèle de cycle de vie du développement
logiciel suivi.

4.1.2 Catégories des techniques de test et leurs caractéristiques
 Catégorie des techniques de test boite-noire :
 Des synonymes :
• Techniques comportementales
• Techniques basées sur le comportement
 Elles sont basées sur une analyse de la base de test appropriée
 Elles s’appliquent aux besoins de test fonctionnels et/ou
non fonctionnels
 Se concentrent sur les entrées et sorties de l'objet de test sans référence à sa structure interne
 Les conditions de test, les cas de test et les données de test sont dérivés de la base de test
 Les cas de test peuvent être utilisés pour détecter les écarts entre les exigences et l'implémentation
des exigences, ainsi que les défauts au niveau des exigences
 La couverture est mesurée en fonction des éléments de la base de test évalués et de la technique
appliquée à cette base de test
 Documents d'exigences
formelles
 Spécifications
 Cas d'utilisation
 User Stories
 Processus métier
 …….

 Catégorie des techniques de test boite-blanche :
 Des synonymes :
• Techniques structurelles
• Techniques basées sur la structure
 Elles sont basées sur une analyse de l'architecture, de la conception détaillée, de la structure interne
ou du code de l'objet de test.
 Elles se concentrent sur la structure et le traitement à l'intérieur de l'objet de test
 Les conditions de test, les cas de test et les données de test sont dérivés d'une base de test
 La couverture est mesurée en fonction des éléments testés au sein
d'une structure donnée (p. ex. le code ou les interfaces)
 Les spécifications sont souvent utilisées comme source d'information
supplémentaire pour déterminer le résultat attendu des cas de test.
• Le code
• L'architecture logicielle
• La conception détaillée
• Toute autre source d'information
concernant la structure du logiciel

 Catégorie des techniques basées sur l’expérience :
 Elles tirent parti de l'expérience des développeurs, des testeurs et des utilisateurs
 Seule l’exécution des test n’est pas pratiquée, le testeur en profite aussi pour concevoir et
implémenter les test qu’il exécute
 Elles sont souvent combinées à des techniques de test boîte-noire et boite blanche
 Les conditions de test, les cas de test et les données de test sont dérivés d'une base de test qui peut
inclure les connaissances et l'expérience des testeurs, développeurs, utilisateurs et autres parties
prenantes
 L’ISO 29119-4 « Software and systems engineering - Software testing - Part 4: Test techniques » contient des
descriptions des techniques de test et les mesures de couverture correspondantes.

 Les objectifs des techniques de test :
 Identifier les conditions de test
 Identifier les cas de test
 Identifier les données de test

Révisions
 Citer des facteurs qui participent au choix de techniques de test.
 Comment qualifier les techniques de test boîte blanche par leur base de test ?
 Comment qualifier les techniques de test boîte noire par leur base de test ?
 À qui sert une technique de test ?

4.2
Techniques de test boîte-noire

4.2 Techniques de test boîte-noire
 Techniques comportementales ou basées sur le comportement
 Pas d’accès à la structure du composant ou du système
 Les conditions de test et les cas de test sont dérivés de spécifications :
Pas d’accès à la structure
du système
 Ces techniques s’appliquent aux besoins de tests
fonctionnels et/ou non fonctionnels

4.2 Techniques de test boîte-noire
Partitions d'équivalence
• Les partitions d'équivalence divisent les données en partitions de telle sorte que tous les éléments d'une partition donnée sont supposés
être traités de la même manière
• Il y a des partitions d'équivalence pour les valeurs valides et invalides.
Analyse des valeurs limites
• L'analyse des valeurs limites est une extension de la technique par partitions d'équivalence
• Les valeurs minimale et maximale d'une partition sont ses valeurs limites
Test de tables de décision
• Cette technique est appropriée pour analyser des règles métier complexes qui spécifient des combinaisons de conditions
• L’objectif du testeur est d’identifier les conditions en entrée, l’ensemble des combinaisons possibles et les actions résultantes
Test des transitions d’état
• Les composants ou les systèmes peuvent réagir différemment à un événement en fonction des conditions présentes ou de leur historique
• Le test de transitions d'état est utilisé pour les applications basées sur des architecture de menus applicatifs, dans l'industrie du logiciel
embarqué, pour la modélisation d'un scénario métier ayant des états spécifiques ou pour tester la navigation à l'écran
Test des cas d'utilisation
• Les cas d’utilisation sont une façon spécifique de concevoir les interactions avec le logiciel pour représenter des exigences
• Les tests sont conçus pour exercer les comportements définis

« Les enfants mineurs d’un salarié peuvent être affiliés au contrat de mutuelle santé du salarié. »
 La théorie :
 Une partition d’équivalence est un ensemble de données qui doit produire un seul résultat, par exemple,
soit l’énoncé de la règle métier suivante :
La partition d’équivalence :
Âge inférieur à 18 ans
Le résultat attendu par le système :
L’affiliation au contrat de santé
4.2.1 Partitions d’équivalence
 Objectif de la technique :
 Définir un cas de test par partition d’équivalence identifiée

 Valeurs valides et valeurs invalides :
 Les valeurs valides sont des valeurs qui doivent être acceptées par le composant ou le système
 Les valeurs invalides sont des valeurs qui doivent être rejetées par le composant ou le système
 Partitions d’équivalence valide et partition d’équivalence invalide :
 Une partition d'équivalence contenant des valeurs valides est appelée « partition d'équivalence valide »
 Une partition d'équivalence contenant des valeurs invalides est appelée « partition d'équivalence
invalide »

 Focus sur les notions de :
Valeur valide
 Une donnée en entrée d’une règle métier qui
doit produire un résultat attendu par le métier.
 Les valeurs valides et invalides ont leur correspondance en termes de nature de cas de test :
Valeur invalide
 Une donnée en entrée d’une règle métier qui
est exclue de cette règle.
 La vérification d’une valeur valide est couverte
par un cas de test passant.
 La vérification d’une valeur invalide est
couverte par un cas de test non passant.
 Le résultat positif d’un cas de test
passant signifie que le
processus peut continuer.
 Le résultat positif d’un cas de test NON
passant signifie que le processus ne peut
se poursuivre; c’est formalisé par un
message d’erreur.

 Exercice :
« Les enfants mineurs d’un salarié peuvent être affiliés au contrat de mutuelle santé du salarié. »
< 18
> 0
3- Partition d’équivalence invalide 1- Partition d’équivalence valide 2- Partition
d’équivalence valide
 L’application de la technique permet d’identifier les cas de test suivants :
 2 cas de test pour couvrir :
• La partition valide # 1, avec une valeur en entrée comprise entre +0 et -18 ans
• La partition valide # 2, avec une valeur supérieur ou égale à 18 ans
 1 cas de test pour couvrir la partition invalide #3, avec une valeur inférieure ou égale à 0
Le système permet d’affilier les
enfants mineurs
Le système ne permet pas
d’affilier les enfants mineurs
Le système produit un
message d’erreur si l’âge
est =< 0

 Exercice :
Énoncé :
« Les personnes dont l’âge est strictement inférieur à 18 ans ne peuvent souscrire au contrat. Les
personnes dont l’âge est strictement supérieur à 60 ans peuvent souscrire, avec une réduction de 15%. Les
autres personnes peuvent souscrire, sans réduction.»
 Combien de partitions valides et invalides illustrent cette rège métier ?
 Combien de cas de test seront nécessaires pour couvrir cette règle métier ?
À vous de
jouer

 Exercice :
Énoncé :
« Les personnes dont l’âge est strictement inférieur à 18 ans ne peuvent souscrire au contrat xxx. Les
personnes dont l’âge est strictement supérieur à 60 ans peuvent souscrire, avec une réduction de 15%. Les
autres personnes peuvent souscrire, sans réduction.»
 Résultats :
 pas de contrat
 souscription au contrat
 souscription avec réduction
 erreur gérée par le système
< 18
> 0 > 60
D A B
 3 cas de test pour couvrir :
• La partition A valide avec une valeur en entrée comprise entre + 0 et - 18 ans
• La partition B valide avec une valeur supérieur ou égale à 18 ans
• La partition C valide avec une valeur supérieure à 60 ans
 1 cas de test pour couvrir la partition invalide D : âge inférieur ou égal à 0
C

 En complément :
 Toute partition peut être divisée en sous-partitions si nécessaire
 Couverture de test :
 Pour obtenir une couverture de 100% :
• Les cas de test identifiés doivent couvrir toutes les partitions identifiées
• Y compris les partitions invalides
• En utilisant au moins une valeur de chaque partition.
 Les partitions d'équivalence sont applicables à tous les niveaux de test.
 Taux de couverture = X 100 %
Nombre de partitions exercées par des cas de test
Nombre total de partitions d’équivalence

4.2.2 Analyse des valeurs limites
 La théorie :
 C’est une extension des partitions d'équivalence
 Les valeurs minimale et maximale d'une partition sont ses valeurs limites
 Le comportement aux limites des partitions d'équivalence est plus susceptible d'être incorrect que le
comportement à l'intérieur des partitions.
 Une valeur limite pour une partition valide est une valeur limite valide
 Une valeur limite pour une partition invalide est une valeur limite invalide.
 Des tests peuvent être conçus pour couvrir les valeurs limites valides et les valeurs limites invalides.
 Principe :
 La technique consiste à choisir 2 valeurs au sein d’une partition :
1.La limite inférieure de la partition 2. La limite supérieure de la partition
 Elle peut être plus complète en sélectionnant 3 valeurs au sein de la partition :
1.La valeur sous la limite 2. La valeur sur la limite 3. La valeur au dessus
de la limite

 Mise en pratique :
Énoncé :
« Les personnes dont l’âge est strictement inférieur à 18 ans ne peuvent souscrire au contrat. »
 Résultats :
 Méthode des 2 valeurs limites :
• La valeur inférieure et la valeur supérieure à la limite
 Méthode des 3 valeurs limites :
• Les valeurs en-dessous, sur et juste au-dessus de la limite
17 ans et 364 jours 18 ans et 1 jour
18

Énoncé :
Dans le cadre d’un système
d'imposition :
• La première tranche de 10 000 € n'est pas imposée
• La tranche suivante de 7 000 € est imposée à 10%
• La tranche suivante de 4 000 € est imposée à 15 %
• Puis le taux d'imposition est de 25%
Définir les partitions d’équivalence et les valeurs limites valides et
invalides en utilisant 3 valeurs par limite.
 Résultat 1 : Les partitions d’équivalence identifiées :
10 k€
> 0
E A B C
17 k€ 21 k€
D

Énoncé :
Dans le cadre d’un système
d'imposition :
• La première tranche de 10 000 € n'est pas imposée
• La tranche suivante de 7 000 € est imposée à 10%
• La tranche suivante de 4 000 € est imposée à 15 %
• Puis le taux d'imposition est de 25%
Définir les partitions d’équivalence et les valeurs limites valides et
invalides en utilisant 3 valeurs par limite.
 Résultat 2 : Les valeurs limites valides et invalides avec la technique des 3 valeurs par limite :
Suite…
10 k€
> 0
E A B C
17 k€ 21 k€
D
• - 1 €
• 0 €
• 1 €
• 9 999 €
• 10 000 €
• 10 001 €
• 16 999 €
• 17 000 €
• 17 001 €
• 20 999 €
• 21 000 €
• 21 001 €

 En complément :
 Toute partition peut être divisée en sous-partitions si nécessaire
 Pour obtenir une couverture de 100% :
• Les cas de test identifiés doivent couvrir toutes les valeurs limites identifiées
• Y compris les limites invalides
 L'analyse des valeurs limites est applicable à tous les niveaux de test.
Nombre de valeurs limites exercées par des cas de test
Nombre total de valeurs limites

4.2.3 Test de tables de décision
 La théorie :
 Les tables de décision sont un bon moyen pour répertorier les règles métier complexes qu'un système
doit mettre en œuvre
 Elles s’appliquent particulièrement au test combinatoire, pour :
 Tester la mise en œuvre des exigences du système qui spécifient comment différentes
combinaisons
de conditions donnent des résultats différents.
 La technique permet d’identifier toutes les combinaisons de conditions possibles
 Elle permet aussi de trouver des lacunes dans les exigences, défauts et/ou omissions

 Principes :
1. Le testeur identifie les conditions et les actions et réponses attendues par le système :
 Conditions et actions forment les lignes du tableau, généralement avec les conditions en haut et les
actions en bas
2. Les colonnes du tableau représentent toutes les combinaisons possibles :
 Chaque colonne correspond à une règle de décision qui définit une combinaison unique de conditions
qui aboutit à l'exécution des actions associées à cette règle.
3. Les valeurs des conditions et des actions sont généralement affichées sous forme de booléens vrai / faux
Comb 1 Comb 2 Comb 3 Comb 4
Condition 1 V V F F
Condition 2 V F V F
Action 1 X X
Action 2 X X
1
 Illustration des principes de création de la table :
3
Méthode de calcul du nombre de combinaisons
1. Nombre de réponses possibles aux conditions
= 2 – Vrai ou Faux
2. Nombre de conditions = 2
3. Nombre de combinaisons = Nb réponses (Nb conditions)
 Soient nb de combinaisons = 22 = 4
2

Énoncé :
Une société propose une prime annuelle à ses commerciaux via le système cumulatif suivant :
• une prime de 3% du CA pour les personnes ayant dépassé 300.000 € de CA
• une prime de 1500 € pour ceux qui ont ouvert au moins 3 nouveaux comptes
• une prime de 300 € pour les personnes qui sont dans l’entreprise depuis 5 ans et plus et
qui ont dépassé 300.000 € de CA
Construire la table de décision qui doit comprendre toutes les combinaisons de conditions
À vous de
jouer

 Résultats :
1. Construction de la table de décisions :
Comb 1 Comb 2 Comb 3 Comb 4 Comb 5 Comb 6 Comb 7 Comb 8
C1 : CA > 300
k€
C2 : 3 nouveaux
comptes
C2 : 5 ans d'ancienneté
A1 : Prime de 3 % du CA
A2 : Prime de 1 500 €
A3 : Prime de 300 €
C1 : CA > 300 k€ V V V V F F F F
C2 : 3 nouveaux comptes V V F F V V F F
C2 : 5 ans d'ancienneté V F V F V F V F
A1 : Prime de 3 % du CA X X X X
A2 : Prime de 1 500 € X X X X
A3 : Prime de 300 € X X
2. Remplissage de la table de décisions :
 Toutes les réponses possibles pour toutes les combinaisons
 3 conditions
 Les actions
 Nombre de combinaisons : 23 = 8

 Le principe de réduction des combinaisons :
 La table de décision contient toutes les combinaisons de conditions – cf. la démonstration précédente
 Toutes les combinaisons de conditions ne sont pas réalisables
1. La table de décision complète :
C1 : CA > 300 k€ V V V V F F F F
C2 : 3 nouveaux comptes V V F F V V F F
V
X
F
X
V
X
F
X
V F V F
A2 : Prime de 1 500 € X X X X
A3 : Prime de 300 € X X
Comb 3 Comb 4 Comb 6 Comb 8
C1 : CA > 300 k€ V V F F
C2 : 3 nouveaux comptes F F V F
V
X
F
X
F F
A2 : Prime de 1 500 € X
A3 : Prime de 300 € X
2. La table de décision
réduite :
 Les entrées de la combinaison 3 permettent de tester des
réponses A3 et A1
 Les entrées de la combinaison 4 permettent de tester
la réponse A1 seule
 Les entrées de la combinaison 6 permettent de tester
la
réponse A2
 Les entrées de la combinaison 8 permettent de tester tous
les rejets (cf. cas non passants)

 Couverture minimale courante  au moins un cas par règle de décision dans la table
 Couvrir toutes les combinaisons de conditions.
 La couverture est mesurée comme le nombre de règles de décision testées par au moins un cas de
test, divisé par le nombre total de règles de décision, généralement exprimé en pourcentage.
 Les tables de décisions sont applicables à tous les niveaux de test.
Nombre de règles de décision testées par au moins un cas de test
Nombre total de règles de décision

4.2.4 Test des transitions d’état
 Contexte :
 Un système peut présenter des réponses différentes selon des évènements déclencheurs particuliers, par
exemples :
 Distributeur de billets, machine à café avec monnayeur
 L’enchainement des écrans (IHM) dans un menu applicatif, la gestion d’un panier d’un site de vente en ligne
 Ces types de systèmes sont régis par le concept d’états :
 Les transitions possibles et logiques entre les états impliquent d’être testées
 Le diagramme et le tableau de transitions d’états illustrent les états possibles du système
 Le principe du test de transitions d’états :
 Vérifier les transitions d’états :
 Une transition est déclenchée par un événement
 Un changement d'état peut entraîner une action du système

 Base de test :
 Un tableau de transition d'état montre toutes les transitions valides et les transitions potentiellement invalides entre
les états, ainsi que les événements, les conditions de garde et les actions résultantes pour les transitions valides
 Un diagramme de transition d'états montrent exclusivement les transitions valides
 Les tests peuvent être conçus pour couvrir une séquence de plusieurs états :
 Pour exercer tous les états
 Pour exercer toutes les transitions
 Pour exercer des séquences spécifiques de transitions
 Pour tester des transitions invalides
 Les mesures de la couverture de test de transitions d’états :
X 100 %
Taux de couverture des états =
Nombre d’états couverts par les tests
Nombre total d’états
X 100 %
Taux de couverture des transitions =
Nombre de transitions couvertes par les tests
Nombre total de transitions

 Exemple du diagramme de transitions d’états d’une montre électronique :
Exercice
 Couvrir les transitions d’états pour changer la date à partir
de l’affichage de l’heure :
Etat de départ Transition Etat d'arrivée
S1 CM - Change mode S2
S2 AD - Change date S4
S4 D - Display date S2
S2 T - Display time S1

 Exercice 1 :
 Un site de ventes en ligne permet de gérer un panier, puis de finaliser ses achats :
 L’état initial est « Panier vide » (S1)
 Ajouter un article permet de remplir son panier, l’état est « Panier en cours » (S2)
 Ajouter d’autres articles ne modifie pas l’état (S2)
 Retirer des articles ne modifie pas l’état (S2)
 Retirer le dernier article du panier renvoie à l’état « Panier vide » (S1)
 Finaliser son achat donne accès au formulaire de récapitulatif de la commande, l’état est « Récapitulatif » (S3)
 Continuer ses achats renvoie à l’état S2
 Valider sa commande donne accès au formulaire de paiement, l’état est « Paiement » (S4)
 Construire le diagramme de transitions d’états

 Exercice 1 :
 Diagramme de transitions d’états pour la gestion d’un panier d’un site de ventes :
 Solution : le diagramme de transitions d’états
Ajouter article
S2
Panier non
vide
S1
Panier vide
S3
Récapitulatif
S4
Paiement
Ajouter article
Retirer
dernier article
Retirer article
 À partir de ce diagramme de transitions d’états, combien de cas de test sont nécessaires pour couvrir la totalité des
transitions d’états ?
Finaliser sa
commande
Reprendre
ses
achats
Payer sa
commande
Se connecter Se déconnecter

 Exercice 2 :
 Étant donné le diagramme de transitions d’états suivant :
Quel ensemble de cas de test offre la série de transitions minimale permettant de couvrir chaque état ?
A. S1 - S2 - S3 - S4 - S5 - S6 - S7
B. S1 - S2 - S3 - S1 - S2 - S4 - S6 - S5 - S7
C. S1 - S2 - S4 - S3 - S6 - S5 - S7
D. S1 - S2 - S4 - S3 - S1 - S2 - S4 - S6 - S5 - S7
S1 S2 S4
S3 S6
S7
S5

4.2.5 Test des cas d'utilisation
 La théorie :
 Des tests peuvent être dérivés de cas d’utilisation
 Le cas d’utilisation décrit les interactions entre les
acteurs et le système
 Les cas d’utilisation sont des représentations :
 De flux de travail
 De diagrammes d'activités
 De modèles de processus métier
Cas d’utilisation
Séquence de transactions dans
un dialogue entre un acteur et un
composant ou un système avec
un résultat concret. L'acteur peut
être un utilisateur ou tout ce qui
peut échanger des informations
avec le système.
Test de cas d’utilisation
Technique de test boîte noire
selon laquelle les cas de tests
sont conçus pour exécuter des
scénarios de cas d’utilisation.
Synonyme : test de scénario
 Un cas d’utilisation spécifie :
 Un scénario nominal – principal
 Des scenarii alternatifs – secondaires
 Des scénarii d’exception – cas de rejets ou d’erreurs
fonctionnelles

Web
Système
d’authentification
 Les composantes d’un cas d’utilisation :
 Des interactions et des activités
 Des préconditions, des postconditions
 Illustration :

 Les tests de cas d’utilisation sont conçus pour exercer les comportements définis – nominaux, alternatifs,
d’exception
 Mesure de la couverture :
 Exemples d’objectifs de couverture :
 Au moins un cas de test pour le couvrir le scénario nominal
 Au moins un cas de test pour chacun des scénarii alternatifs
Nombre de comportements testés
Nombre total de comportements du cas d’utilisation

Révisions
 Quelles sont les techniques de test boîte-noire ?
 Quelle est le type de base de test pour la conception de test boîte-noire ?
 Par la technique des tables de décisions, combien de fois chaque colonne doit être testée au
minimum ?
 À quelle autre technique les partitions d’équivalence peuvent être associées ?

4.3
Techniques de test boîte-blanche

 Techniques comportementales ou basées sur le comportement
 Accès à la structure du composant ou du système
 Les cas de test sont dérivés de la structure interne du système
 Les techniques de test boîte-blanche sont applicables à tous les niveaux de test
4.3 Techniques de test boîte-blanche
Test boîte-blanche
Test basé sur une
analyse de la structure
interne du composant ou
système.

 Les 2 techniques étudiées :
 Utilisées au niveau de test des composants
 Mises en œuvre par le développement
4.3 Techniques de test boîte-blanche
Test et couverture des instructions
• Les cas de test sont créés pour vérifier la couverture des instructions du code et en améliorer la
couverture
Test et couverture des décisions
•La couverture des décisions vérifie que toutes les sorties possibles d’une condition pourront être
exercées selon les valeurs en entrées de la condition.

 Une instruction est la plus petite unité d’exécution indivisible dans un
programme
 Des commandes simples :
 Action, calcul, affectation…. (print, read, input, put, move, next…)
 Des instructions conditionnelles pour évaluation d’une condition :
 IF … THEN … ELSE … ENDIF, par exemple :
• READ A
• IF A > 2 THEN
PRINT « RED »
ELSE
PRINT «
BLUE »
ENDIF
4.3.1 Test et couverture des instructions
Instruction
Une entité dans un langage
de programmation, qui est
typiquement la plus petite
unité indivisible d’exécution.
Instruction
s

Flot de contrôle :
une représentation abstraite
de toutes les séquences
d’événements (chemins) dans
l’exécution d’un composant
ou système.
 Les instructions peuvent être illustrées dans de flux de contrôle
Instruction
Instruction
IF …
o.u. i
Instruction
Instruction
Instruction
IF
Instruction
Instruction
Glossaire

 Couverture des instructions :
 C’est l’évaluation du nombre d’instructions exécutables ayant été exécutées par une suite de test :
 Exemple, à partir du code suivant : • Read A
• IF A * 2 > 10 THEN print « VERT »
• ENDIF
 Avec A = 9, le cas de test passe par toutes les instructions du code alors, la couverture est de 100
%.
Nombre d’instructions exercées par les tests
Nombre total d’instructions

 Exercices :
Read A
Read B
IF A>B
Print W
1
oui
non
 Combien de cas de test sont nécessaires pour couvrir
toutes les instructions du logigramme ?
toutes les instructions du logigramme ?
non
Read A
Read B
IF
A>o
Bu
i
Print W
Read X
2
oui

 Exercices :
 Soit le code suivant :
READ login
READ password
GET authentification
IF authentification_OK THEN PRINT formulaire_articles
IF articles_selectionnes_OK THEN PRINT « Valider commande »
ELSE PRINT « Panier vide »
ENDIF
ELSE PRINT message_error
ENDIF
non
Read login
Read
password
IF
Oo
Ku
i
ARTICLES
« ERROR »
3
Get
authentif
IF
sélection
OK
oui
Commandes
oui
Panier vide
non
toutes les instructions du code ci-dessus ?

 Une décision est une sortie possible d’une condition :
 Illustration :
4.3.2 Test et couverture des décisions
Décision
Type d'instruction dans lequel
le choix entre deux ou
plusieurs résultats possibles
contrôle l'ensemble des
actions qui en résulte.
Synonyme = branche
Glossaire
Décisions
oui
IF----
Instruction
Instruction
Faux Vrai
 Couverture des décisions :
 C’est l’évaluation du nombre de résultats de décision exécutés par les tests :
Nombre de résultats de décision exercées par les tests
Nombre total de résultats de décisions

 Exercices :
4.3.2 Test et couverture des décisions
Read A
Read B
IF A>B
Print W
4
oui
non
toutes les décisions du logigramme?
non
Read login
Read
password
IF
Oo
Ku
i
ARTICLES
« ERROR »
5
Get
authentif
IF
sélection
OK
oui
Commandes
oui
non
 Combien de cas de test sont
nécessaires pour couvrir
toutes les décisions du
logigramme?

|
58 |
4.3.3 Apport des test des instructions et des décisions
2018
 Constat à partir des exercices précédents :
 Une couverture des instructions de 100 % :
 Garantit que toutes les instructions exécutables du code ont été testées au moins une fois,
 Ne garantit pas que toutes les décisions ont été testées.
 L'obtention d'une couverture à 100 % des décisions garantit une couverture à 100 % des instructions,
l’inverse n’est pas vrai.
Couverture des
décisions à 100 %
Couverture des
instructions à 100 %

Révisions
 Nommer les 2 techniques de couverture étudiées ?
 Quelle technique de test boite blanche propose le meilleur principe de couverture ?
 Comment se nomme la figuration graphique d’un ensemble de lignes de code ?

Révisions
 En possession d’un billet en classe économique, il est possible d’être surclassé en business class, en particulier si vous
possédez la carte gold du programme de fidélité de la compagnie aérienne. Si vous ne possédez pas la carte gold, vous
risquez d’être refusé dans l’avion si vous enregistrez tardivement et que l’avion est plein.
Trois tests ont été exécutés:
1. Un possesseur de carte gold qui est surclassé en
business.
2. Une personne ne possédant pas de carte gold
qui
reste en classe économique.
3. Une personne qui est refusée à l’embarquement.
Quelle est la couverture des instructions
obtenue
par ces 3 tests?
a. 60 %
b. 70 %
c. 80 %
d. 90 %

Révisions
1. Quelle affirmation concernant la relation entre la couverture des instructions et la couverture des
décisions est correcte ?
a) 100% des décisions sont couvertes si la couverture des instructions est supérieure à 90%
b) 100% des instructions sont couvertes si la couverture des décisions est supérieure à 90%
c) Une couverture à 100% des décisions correspond toujours à 100% de couverture des instructions
d) Une couverture à 100% des instructions correspond toujours à 100% de couverture des décisions
2. La fonction suivante prend en entrée 6 entiers : a, b, p, q, x, y
2.1 Quel est le nombre minimum de cas de test
nécessaires pour obtenir une couverture totale
des instructions ?
a. 2
b. 3
c. 4
d. 5
2.2 Quel est le nombre minimum de cas de test
nécessaires pour obtenir une couverture de 100
% des décisions ?
a. 2
b. 3
c. 4
d. 5

4.4
Techniques de test basées sur l’expérience

 Contexte de mise en œuvre :
 Les tests sont basés sur les compétences et l'intuition du testeur
 Le testeur utilise son expérience sur des applications, des projets ou des technologies similaires.
 Objectifs :
 Identifier les tests qui n'ont pas été facilement identifiés par d'autres techniques plus systématiques
 Techniques recommandées dans les cas suivants :
 Spécifications rares ou inadéquates
 Contraintes de temps pour réaliser les activités d’analyse, conception et implémentation
 Testeurs expérimentés sur le contexte du projet
4.4 Techniques de test basées sur l’expérience

 Les 3 techniques étudiées :
4.4 Techniques de test basées sur l’expérience
Estimation d’erreurs
Technique de test qui consiste à
dériver les tests sur la base de la
connaissance des défaillances
passées ou de la connaissance
générale des modes de défaillance.
Test exploratoire
Une approche des tests par laquelle les
testeurs conçoivent et exécutent
dynamiquement des tests en fonction de
leurs connaissances, de l'exploration de
l'élément testé et des résultats des tests
précédents.
Test basé sur les checklists
Une technique de conception de tests
basée sur l'expérience selon laquelle le
testeur expérimenté utilise une liste de
haut niveau d'éléments à noter, à vérifier,
ou à se rappeler, ou un ensemble de
règles ou de critères en fonction
desquels un produit doit être vérifié.

 Objectif de la technique :
 Anticiper l'apparition d'erreurs, de défauts et de défaillances, sur la base des connaissances du testeur
 Nature de l’expérience des testeurs :
 Les modes de fonctionnements antérieurs de l'application
 Les types d'erreurs faites par les développeurs
 Les défaillances qui se sont produites dans d'autres applications
 Principes de mise en œuvre :
 Créer une liste d'erreurs, de défauts et de défaillances possibles, à partir de :
• De l’expérience du testeur
• Des données sur les défauts et les défaillances passés
• Des connaissances sur les causes des défaillances logicielles
 Concevoir des tests qui provoqueront les défaillances et les défauts qui les ont causées.
4.4.1 Estimation d’erreurs

 Exemple de mise en œuvre dans le cadre des tests de régression :
4.4.1 Estimation d’erreurs
1.Préparation
 Lors de projets de test précédents, la capitalisation sur les défauts identifiés a
permis de formaliser un regroupement des défauts par fonction majeures de
l’application
 L’analyse du regroupement des défauts montre une estimation d’erreurs
potentielle
sur les fonctions D et E.
2.Exécution
 Conformément à l’analyse faite du regroupement des défauts, l’exécution des tests
de régression cible principalement les fonctions D et E.

 Objectifs :
 Compléter d’autres méthodes de tests plus formelles
 Réaliser des tests lorsque les spécifications sont rares ou non adéquates ou si des contraintes de
temps impactent les tests
 Le test exploratoire comprend plusieurs tâches :
 L’exécution des tests
 La conception des tests exécutés
 L’enregistrement des résultats de tests
 L’apprentissage de l’application sous test
 Principes :
 Une charte de test décrit :
 Le temps imparti pour les sessions de test exploratoires
 Des objectifs pour guider les tests
4.4.2 Tests exploratoires
Charte de test
Documentation des activités
de test dans le cadre de
tests exploratoires basés sur
des sessions.
Session
Laps de temps continu passé à exécuter
des tests. En test exploratoire, chaque
session de test se focalise sur une
charte, mais les testeurs peuvent aussi
explorer de nouvelles opportunités ou
problèmes durant une session. Le
testeur crée et exécute des cas de test à
la volée et enregistre leurs évolutions.

4.4.2 Tests exploratoires
 Exemple de mise en œuvre :
Contexte du projet
• La migration iso fonctionnelle de l’application comptable, soit le remplacement d’une application éditeur par un
ERP
• La nouvelle solution sert, à minima, les mêmes fonctionnalités que l’ancienne application
Stratégie de test décidée
• Les tests d’intégration du module comptable de l’ERP dans le SI de l’organisation sont réalisés par
l’ESN
intégrateur de l’ERP
• Les tests d’acceptation utilisateur sont réalisés par l’équipe comptable assistée par un test manager
• Ils seront exécutés sur le principe du « test dos à dos », c’est-à-dire que pour des entrées identiques les
2
solutions, l’ancienne et la nouvelle, doivent produire les mêmes sorties, les mêmes résultats
• Le type de test choisi est le test exploratoire
La charte de test, en support à la stratégie de test
• La description du principe de test « dos à dos », incluant
les environnements à utiliser
• Les sessions de test qui décrivent les périodes de test
pour chacun des acteurs de test selon leur disponibilité
• Les objectif d’apprentissage de la nouvelle solution à
réaliser pendant les sessions de test
• Par acteur de test, les fonctions et services à tester
en précisant dans une checklist :
 Les objectifs de vérification à constater
 Les données à utiliser en entrée
 Les données en sortie à vérifier – cf. le test « dos à dos »
 Les moyens de notification des résultats de test et
des éventuels défauts

 Objectif :
 Couvrir les conditions de test figurant dans une checklist
 Augmenter la couverture des tests structurés
 Principes :
 Utiliser une checklist existante ou en concevoir une nouvelle
 Concevoir les tests
 Implémenter les tests
 Exécuter les tests
 Types de test couverts :
 Non fonctionnels
 Fonctionnels
4.4.3 Tests basés sur des checklists
 Des exemples de checklists :
 La liste de profils des utilisateurs d’une application, pour prévoir et
organiser les vérifications de la navigation dans les menus de
l’application selon les profils des utilisateurs
 La liste des composants graphiques et ergonomiques d’un site, par
page du site à vérifier
 Les caractéristiques non fonctionnelles d’un produit en se basant sur
le standard de l’ISO 25010

4.4.3 Tests basés sur des checklists
Préparation
 Exemples et principes des checklists :
• Les objectifs de test à réaliser sont spécifiés dans la checklist pour préparer la phase de test
exploratoire
• La checklist participe à la charte de test
• Les objectifs de test peuvent aussi être qualifiés d’informations de type : niveau de criticité,
estimation
de charge ou délais
Exécution
Résultats
• Toutes les informations sur la réalisation des objectifs de test sont reportées dans la checklist.
• Par exemples, pour chaque objectif de test, on pourra notifier :
• Les cas de test créés, les données de test et environnement utilisés, les résultats d’exécution et les
défauts identifiés pour les résultats non satisfaisants, le niveau d’apprentissage obtenu
• Les objectifs de test peuvent être répartis par testeur, selon l’expertise requise pour concevoir et
exécuter les tests attendus
• En se basant sur la checklist, chaque objectif de test est réalisé :
Conception Exécution Apprentissage

Révisions
 Nommer les 3 techniques basées sur l’expérience ?
 Quelles activités sont réalisées quand des tests exploratoires sont exécutés ?
 Dans quel document sont précisés les tests exploratoires ?

Q
C
M

QCM de fin de chapitre
 Q1 : Laquelle des options suivantes est classée comme technique de test boîte-noire ?
a. Techniques basées sur l'analyse de l'architecture.
b. Techniques vérifiant que l'objet de test fonctionne conformément à la conception technique.
c. Techniques basées sur l'utilisation prévue du logiciel.
d. Techniques basées sur des exigences formalisées.
 Q2 : Comment les tests boîte-blanche peuvent-ils être appliqués pendant les tests d'acceptation ?
a. Vérifier si de grands volumes de données peuvent être transférés entre systèmes intégrés.
b. Vérifier si toutes les instructions du code et tous les chemins de décision du code ont été exécutés.
c. Vérifier si l’ensemble des structures et valeurs de données et de flux métier ont été couverts.
d. Couvrir toutes les navigations des pages Web.

 Q3 : Sachant que pour ouvrir un compte épargne il faut un dépôt minimum de 500 € et que le
plafond est fixé à 20 000 € :
Combien de cas de test faut-il pour couvrir l'exigence ?
a. 4
b. 3
c. 5
d. 2
 Q4 : Quels tests permettent de déterminer la couverture du code – 2 réponses attendues ?
a. Les tests des instructions
b. Les tests des partitions d'équivalence
c. Les tests basés sur des checklists
d. Les tests des décisions

 Q5 : Qu’est-ce que le test exploratoire ?
a. Le processus consistant à anticiper ou à deviner où les défauts peuvent apparaître
b. Une approche systématique permettant d’identifier des plages d’entrées équivalentes
c. Le test mené par un ingénieur qualifié
d. Une mise en œuvre concurrente des activités de conception des tests, d’exécution, d’analyse des logs
et d’apprentissage
 Q6 : Quelle est la signification de l’obtention d’une couverture de 90% des instructions par un
ensemble de tests ?
a. 9 résultats de décisions sur 10 ont été exercés par cet ensemble de tests
b. 9 instructions sur 10 ont été exercées par cet ensemble de tests
c. 9 tests sur 10 ont été exécutés sur cette version du logiciel
d. 9 exigences sur 10 concernant le logiciel sont correctes

 Q7 : Soit le code suivant.
IF A > B
THEN C = A
– B ELSE
C = A + B
ENDIF
Read D
IF C = D Then
Print “Error”
ENDIF
Quelle proposition
est vraie ?
a. 1 test pour la
couverture des
instructions, 3
pour la couverture
des branches
b. 2 tests pour la

 Q8 : Étant donné le diagramme de transition d’états suivant, laquelle parmi les séries de
transitions d’états suivantes, contient une transition invalide qui pourrait provoquer un défaut de
conception du système ?
a. Login, naviguer, panier, caisse, panier, caisse, payer, logout
b. Login, naviguer, panier, caisse, payer, logout
c. Login, naviguer, panier, caisse, panier, logout
d. Login, naviguer, panier, naviguer, panier, caisse, payer, logout
 Q9 : Un champ de texte accepte des valeurs alpha numériques, parmi les propositions suivantes
identifier la meilleure partition d’équivalence valide :
a. BOOK
b. Book
c. Boo01k
d. book

Aldemia Campus Touch
Fin du chapitre 4

ALD_ISTQB Fondation_Chapitre 4_V1.2.pptx

Contenu connexe

Tendances

Similaire à ALD_ISTQB Fondation_Chapitre 4_V1.2.pptx

ALD_ISTQB Fondation_Chapitre 4_V1.2.pptx