Chapitre 4 : Analyse et conception des tests

Question 1

Que sont les techniques de test boîte noire ? (techniques basées sur les spécifications)

Answer 1

Techniques basées sur une analyse du comportement spécifié de l’objet de test sans référence à sa structure interne. (used in dynamic testing cus we execute n see behaviour). Les cas de test des techniques boîte noire ne dépendent pas de l’implémentation du logiciel. (càd si implementation change mais comportement reste le meme, les cas de tests restent utiles)

Question 2

Que sont les techniques de test boîte blanche ? (techniques basées sur la structure)

Answer 2

Techniques basées sur une analyse de la structure interne et du traitement de l’objet de test. Les cas de test des techniques boîte blanche peuvent être créés après la conception ou l’implémentation de l’objet de test. Ils dépendent bien de la conception du logiciel. (si implementation change -> cas de test inutiles)

Question 3

Que sont les techniques de test basées sur l’expérience ?

Answer 3

Techniques utilisant les connaissances et l’expérience des testeurs pour concevoir et implémenter des cas de test.
L’efficacité de ces techniques dépend fortement des compétences du testeur. Les techniques de test basées sur l’expérience peuvent détecter des défauts qui pourraient échapper aux techniques de test boîte noire et boîte blanche.(ils sont donc complémentaires )

Question 4

Quelles sont les techniques de test boîte noire couramment utilisées?

Answer 4

• Partitions d’équivalence.
• Analyse des valeurs limites.
• Test par tables de décisions.
• Test de transition d’état.

Question 5

Que sont les partitions d’équivalence et quel est leur principe sous-jacent ?

Answer 5

Les partitions d’équivalence divisent les données en partitions traitées de la même manière par l’objet de test. Si un cas de test détecte un défaut dans une valeur d’une partition, ce défaut sera détecté pour toutes les valeurs de cette partition.

Question 6

Pourquoi un test pour chaque partition est-il suffisant et quels éléments de données peuvent être divisés en partitions d’équivalence ?

Answer 6

Un test pour chaque partition est suffisant car tous les éléments d’une partition sont traités de la même manière par l’objet de test. Les éléments de données peuvent inclure les entrées, sorties, éléments de configuration, valeurs internes, valeurs liées au temps et paramètres d’interface.

Question 7

Quelles caractéristiques doivent avoir les partitions d’équivalence ?

Answer 7

Les partitions peuvent être continues ou discrètes, ordonnées ou non, finies ou infinies. Elles ne doivent pas se chevaucher et doivent être des ensembles non vides.

Question 8

Qu’est-ce qu’une partition valide et une partition invalide, et pourquoi le partitionnement doit-il être effectué avec soin ?

Answer 8

Une partition valide contient des valeurs traitées par l’objet de test. Une partition invalide contient des valeurs ignorées ou rejetées. Le partitionnement doit être effectué avec soin car il peut être compliqué de comprendre comment l’objet de test traitera les différentes valeurs.

Question 9

Comment la couverture est-elle mesurée dans la technique des partitions d’équivalence ?

Answer 9

La couverture est mesurée en exerçant toutes les partitions identifiées (y compris les partitions invalides) au moins une fois. Le pourcentage de couverture est le nombre de partitions exercées divisé par le nombre total de partitions identifiées.
Pour atteindre 100 % de couverture, chaque partition identifiée doit être testée au moins une fois.

Question 10

Qu’est-ce que la couverture Each Choice et que signifie-t-elle pour les ensembles multiples de partitions ?

Answer 10

La couverture Each Choice exige que les cas de test exercent chaque partition de chaque ensemble de partitions au moins une fois. Elle ne prend pas en compte les combinaisons de partitions.

Pour un formulaire avec deux champs, âge et revenu :

Âge : Partition 1 (0-17), Partition 2 (18-64), Partition 3 (65+)
Revenu : Partition 1 (0-20,000), Partition 2 (20,001-50,000), Partition 3 (50,001+)

La couverture Each Choice implique qu’au moins une valeur de chaque partition pour chaque champ soit testée. Par exemple, tester (15, 10,000), (30, 30,000), et (70, 60,000) couvrirait chaque partition de chaque champ au moins une fois.

Question 11

Sur quoi consiste l’analyse des valeurs limites (AVL)?

Answer 11

AVL se concentre sur le test des valeurs aux extrémités des partitions d’équivalence. Cela signifie que cette technique ne fonctionne que sur des partitions où les données peuvent être ordonnées (par exemple, de manière croissante ou décroissante).

Considérons une application qui accepte des notes de 0 à 100. Les partitions d’équivalence seraient : 0-49 (échec), 50-100 (réussite). Les valeurs limites seraient 0, 49, 50, et 100. Nous testerions ces valeurs limites pour vérifier si elles sont correctement gérées par le système.

Question 12

Pourquoi AVL se concentre sur les valeurs limites?

Answer 12

L’AVL se concentre sur les valeurs limites parce que les développeurs peuvent souvent faire des erreurs lors de la gestion de ces valeurs spécifiques. Les défauts communs incluent des limites mal placées (par exemple, une limite inférieure ou supérieure mal définie) ou des limites complètement oubliées.

Dans notre exemple de notes, si le développeur a défini la limite de réussite à 51 au lieu de 50, un élève avec une note de 50 serait incorrectement classé comme ayant échoué. L’AVL aiderait à détecter cette erreur en testant précisément ces valeurs limites.

Question 13

En AVL, c quoi la difference entre la technique a 2vals et a 3vals?

Answer 13

Ces variantes diffèrent par le nombre de valeurs testées autour de chaque limite pour atteindre une couverture complète. La technique à 2 valeurs teste la valeur limite et sa voisine la plus proche de la partition adjacente, tandis que la technique à 3 valeurs teste la valeur limite et ses deux voisines.

Exemple:
Pour une limite de 50, la technique à 2 valeurs testerait 50 et 51. La technique à 3 valeurs testerait 49, 50, et 51.

Question 14

Dans la technique à 2 valeurs (Craig 2002, Myers 2011) quels sont les deux éléments de couverture pour chaque valeur limite?

Answer 14

La valeur limite en question et sa voisine la plus proche appartenant à la partition adjacente.

La technique à 2 valeurs implique de tester la valeur limite et la valeur voisine la plus proche dans la partition adjacente. Pour obtenir une couverture complète, toutes les valeurs limites doivent être testées.

Exemple:
Pour une partition de notes, les tests pour la limite de 50 incluraient les valeurs 50 (limite) et 51 (voisin).

Prenons un système qui accepte des valeurs numériques de 0 à 100. Supposons qu’il y a une partition pour les valeurs de 0 à 49 (échec) et une autre partition pour les valeurs de 50 à 100 (réussite). La limite entre ces partitions est 50. Avec la technique à 2 valeurs, nous testerions la valeur limite 50 et sa voisine la plus proche dans la partition adjacente, ici 49 pour la partition d’échec et 50 pour la partition de réussite.

Question 15

Dans la technique à 3 valeurs (Koomen 2006, O’Regan 2019), quels sont les trois éléments de couverture?

Answer 15

• La valeur limite en question et ses deux voisines.
• La technique à 3 valeurs implique de tester la valeur limite ainsi que ses deux voisines. Cela signifie que parfois, les valeurs testées ne sont pas des limites strictes mais des valeurs proches. Pour une couverture complète, toutes les valeurs limites et leurs voisines doivent être testées.

Exemple:
Pour une limite de 50, les tests incluraient les valeurs 49, 50, et 51.

Supposons qu’il y a une partition pour les valeurs de 0 à 49 (échec) et une autre partition pour les valeurs de 50 à 100 (réussite). La limite entre ces partitions est 50. Avec la technique à 3 valeurs, nous testerions 49 (voisin avant la limite), 50 (la valeur limite elle-même) et 51 (voisin après la limite).

Question 16

Quelle est l’avantage de la technique AVL à 3 valeurs par rapport à celle à 2 valeurs ?

Answer 16

Elle peut détecter des défauts que la technique à 2 valeurs pourrait manquer, comme des erreurs de condition.

Si la condition “si (x ≤ 10)” est implémentée incorrectement comme “si (x = 10)”, tester 10 et 11 ne révélerait pas le défaut, mais tester 9 (comme dans la technique à 3 valeurs) le détecterait.

Question 17

À quoi consistent les tables de décision?

Answer 17

Les tables de décision sont utilisées pour tester l’implémentation des exigences du système qui spécifient comment différentes combinaisons de conditions aboutissent à des résultats différents. Les tables de décision constituent un moyen efficace d’enregistrer une logique complexe, telle que les règles de gestion.
Imaginons un système de calcul de primes d’assurance où les primes varient en fonction de l’âge du conducteur et de son historique de conduite (sans accident, un accident, plusieurs accidents). Une table de décision pourrait représenter les différentes combinaisons de ces conditions (âge et historique de conduite) et les résultats correspondants (montant de la prime).

Question 18

Comment sont créés les tables de décision?

Answer 18

Pour créer une table de décision, on liste toutes les conditions et les actions possibles. Les conditions et actions deviennent les lignes de la table, tandis que chaque colonne représente une règle de décision spécifique avec une combinaison unique de ces conditions et les actions associées. Dans les tables à entrée limitée, les valeurs sont booléennes (vrai ou faux). Dans les tables à entrée étendue, les valeurs peuvent être multiples.

Exemple:
Continuons avec notre exemple de primes d’assurance. Les conditions pourraient être:

+ Âge du conducteur (jeune, adulte, senior)
+ Historique de conduite (sans accident, un accident, plusieurs accidents)
… others in line
- Une colonne de la table pourrait représenter une combinaison comme “jeune” et “sans accident” avec une prime spécifique comme résultat. regle 1 regle 2 -> see wp

Question 19

Comment est la couverture mesurée dans les tables de décision?

Answer 19

Dans les tests par tables de décisions, les éléments de couverture sont les colonnes contenant les combinaisons de conditions réalisables. Pour atteindre une couverture de 100 % avec cette technique, les cas de test doivent exercer toutes ces colonnes. La couverture est mesurée comme le nombre de colonnes exercées, divisé par le nombre total de colonnes réalisables, et est exprimée en pourcentage.
Si notre table a 8 colonnes représentant des combinaisons réalisables et que nous en testons 8, la couverture est de 100 %. Si nous n’en testons que 4, la couverture est de 50 %.

Question 20

Quelle est la notation utilisée dans les tables de décision ?

Answer 20

“V” pour vrai, “F” pour faux, “-“ pour non pertinent, “N/A” pour irréalisable, “X” pour l’action à exécuter et blanc pour l’action non exécutée.

Question 21

Quels sont les avantages et les défis des tests par tables de décision ?

Answer 21

Ils permettent d’identifier systématiquement toutes les combinaisons de conditions et de trouver des lacunes dans les exigences, mais le nombre de règles croît de manière exponentielle avec le nombre de conditions, nécessitant parfois une table réduite ou une approche basée sur les risques.

Question 22

C quoi un test de transition d’etat?

Answer 22

Un diagramme de transition d’états modélise le comportement d’un système en montrant ses états possibles et les transitions d’états valides. Une transition est initiée par un événement, qui peut être qualifié par une condition de garde. Les transitions sont supposées être instantanées et peuvent parfois entraîner une action du logiciel.
syntax:
événement [condition de garde] / action
ex:
Monnaie insérée [monnaie suffisante] / afficher sélection

Question 23

C quoi la table d’état dans le test de transition d’état?

Answer 23

Une table d’états est un modèle équivalent à un diagramme de transition d’états. Ses lignes représentent les états et ses colonnes les événements (ainsi que les conditions de garde si elles existent). Les entrées de la table (cellules) représentent les transitions et contiennent l’état cible, ainsi que les conditions de garde et les actions résultantes, si elles sont définies. Contrairement au diagramme de transition d’états, la table d’états montre explicitement les transitions non valides, qui sont représentées par des cellules vides. (voir wp)

Question 24

C quoi un cas de test dans le contexte des transitions d’état?

Answer 24

Un cas de test dans le contexte des transitions d’état consiste en une séquence d’événements qui provoquent une séquence de changements d’états. Un seul cas de test peut inclure plusieurs transitions d’états pour vérifier que le système se comporte correctement à chaque étape.
un cas de test pourrait être :

1- Insérer monnaie.
2- Sélectionner produit.
3- Délivrer produit.
Cela couvrirait les transitions : “Attente de monnaie” -> “Monnaie insérée” -> “Produit sélectionné” -> “Produit délivré”.

Question 25

Quels sont les critères de couverture pour les tests de transition d’état?

Answer 25

** La couverture de tous les états: Dans la couverture de tous les états, les éléments de couverture sont les états. Pour obtenir une couverture de 100 %, les cas de test doivent garantir que tous les états sont visités. (états_visités/total)%

** La couverture des transitions valides (0 switch): Pour obtenir une couverture de 100% des transitions valides, les cas de test doivent exercer toutes les transitions valides. (valide_exerces/total)%

** La couverture de toutes les transitions (valides et non valides): les éléments de couverture sont toutes les transitions figurant dans une table d’état. Pour obtenir une couverture de 100 % de toutes les transitions, les cas de test doivent exercer toutes les transitions valides et tenter d’exécuter des transitions non valides. Le fait de ne tester qu’une seule transition non valide dans un seul cas de test permet d’éviter le masquage des défauts, c’est-à-dire une situation dans laquelle un défaut empêche la détection d’un autre.

(transitions valides et non valides exercées ou tentées d’être exercées par les cas de test exécutés / le nombre total de transitions valides et non valides)%

Question 26

Lequel des trois critères de couverture pour les tests de transition d’état est le plus utilisé?

Answer 26

La couverture de tous les états est plus faible que la couverture des transitions valides, car elle peut généralement être obtenue sans exercer toutes les transitions. La couverture des transitions valides est le critère de couverture le plus largement utilisé. L’obtention d’une couverture complète des transitions valides garantit une couverture complète de tous les états.
L’obtention d’une couverture complète de toutes les transitions garantit à la fois une couverture complète de tous les états et une couverture complète des transitions valides et devrait constituer une exigence minimale pour les logiciels critiques en termes de mission et de sécurité.

Question 27

Quelles sont les techniques de test boîte blanche ?

Answer 27

• Le test des instructions.
• Le test des branches.

Question 28

Qu’est-ce que le test des instructions? (BB)

Answer 28

Le test des instructions consiste à vérifier chaque instruction exécutable dans le code pour s’assurer qu’elle fonctionne correctement. Le but est de créer des cas de test qui utilisent ces instructions autant que possible jusqu’à atteindre un niveau de couverture souhaité. La couverture des instructions : le nombre d’instructions testées / le nombre total d’instructions dans le code.

Obtenir une couverture des instructions de 100 % signifie que chaque instruction exécutable du code a été testée au moins une fois. Cela aide à identifier les instructions avec des défauts, car une instruction défectueuse pourrait provoquer une erreur. Toutefois, cela ne garantit pas que tous les défauts seront détectés, en particulier ceux qui dépendent de valeurs spécifiques des données, comme une division par zéro. div(4,2) checks all instructions but doesnt mean test is correct if i div(4,0) so that should be taken into cons as well.

Question 29

Qu’est-ce qu’une branche dans le test de code?

Answer 29

Une branche représente un point dans le code où le flux de contrôle peut changer, ce qui est visualisé dans un graphe de flux de contrôle. Ce changement peut être inconditionnel (sans condition, le flux continue simplement) ou conditionnel (dépend d’une décision comme un “if” ou “switch”).

if x > 0:
print(“x est positif”) # Branch 1
else:
print(“x est négatif ou zéro”) # Branch 2

C=(le nombre de branches exercées par les cas de test / par le nombre total de branches)%
la couverture des branches à 100 % ne garantit pas l’absence de défauts, car elle peut ne pas détecter les défauts nécessitant l’exécution d’un chemin spécifique.

Pour détecter un défaut lié à une condition spécifique comme if (x > 0 and y == 5), il faut tester toutes les combinaisons pertinentes de x et y.

Question 30

Quelle est la relation entre la couverture des branche et la couverture des instructions?

Answer 30

La couverture des branches inclut la couverture des instructions, ce qui signifie que si toutes les branches sont couvertes à 100 %, toutes les instructions le sont aussi. Cependant, couvrir toutes les instructions ne garantit pas que toutes les branches sont couvertes.
if x > 0:
print(“x est positif”)
else:
print(“x est négatif ou zéro”)
print(“Fin du test”)

Tester juste x = 5 couvre toutes les instructions, mais pas toutes les branches. Tester x = 5 et x = -3 couvre à la fois toutes les instructions et toutes les branches.

Question 31

Quels sont les avantages et les limitations des tests boîte blanche, et comment complètent-ils les tests boîte noire?

Answer 31

Les tests boîte blanche prennent en compte l’implémentation entière du logiciel, facilitant la détection des défauts même lorsque la spécification est vague ou incomplète. Cependant, ils peuvent ne pas détecter les défauts résultant de l’absence d’exigences non implémentées. Ils peuvent être utilisés pour les tests statiques, tels que l’exécution à blanc du code et la révision du pseudocode. Les tests boîte noire ne permettent pas de mesurer la couverture réelle du code car ils se concentrent uniquement sur les entrées et sorties sans examiner le code interne. Les tests boîte blanche complètent les tests boîte noire en fournissant des mesures objectives de la couverture et en aidant à identifier les parties non testées du code, permettant ainsi la génération de tests supplémentaires pour améliorer la couverture et la confiance dans le code.

Question 32

Quelles sont les techniques de tests basés sur l’expérience?

Answer 32

• Estimation d’erreurs.
• Test exploratoire.
• Test basé sur des checklists

Question 33

Sur quoi consiste l’estimation d’erreurs dans les tests basés sur l’expérience?

Answer 33

L’estimation d’erreurs consiste à prédire les problèmes potentiels dans un logiciel en se basant sur l’expérience du testeur, y compris comment l’application a fonctionné par le passé, les types d’erreurs habituelles des développeurs, et les défaillances observées dans des applications similaires. Les erreurs, défauts et défaillances peuvent découler de divers aspects du logiciel tels que l’entrée, la sortie, la logique, le calcul, les interfaces ou les données.

Les attaques de fautes constituent une approche méthodique de la mise en œuvre de l’estimation d’erreurs. Cette technique exige du testeur qu’il crée ou acquière une liste d’erreurs, de défauts et de défaillances possibles, et qu’il conçoive des tests qui identifieront les défauts associés aux erreurs,
exposeront les défauts ou provoqueront les défaillances. Ces listes peuvent être construites sur la base de l’expérience, des données relatives aux défauts et aux défaillances, ou des connaissances communes sur les raisons des défaillances des logiciels.

Question 34

Sur quoi consiste le test exploratoire dans les tests basés sur l’expérience?

Answer 34

Le test exploratoire implique la conception, l’exécution et l’évaluation des tests simultanément pendant que le testeur explore l’objet de test. Il permet d’apprendre davantage sur l’objet de test, d’explorer en profondeur avec des tests ciblés et de créer des tests pour les domaines non encore explorés. Ce type de test peut être structuré à l’aide de sessions de test, où le testeur suit une charte de test avec des objectifs définis, puis effectue un débriefing pour discuter des résultats avec les parties prenantes.

Question 35

Sur quoi consiste le test basé sur des checklists dans les tests basés sur l’expérience?

Answer 35

Le test basé sur des checklists consiste à concevoir, implémenter et exécuter des tests en se basant sur une liste de contrôle préétablie. Ces listes peuvent être créées à partir de l’expérience, de la compréhension des besoins des utilisateurs ou de la connaissance des échecs logiciels passés. Les éléments de la liste sont souvent formulés sous forme de questions et doivent être vérifiables individuellement. Les checklists peuvent couvrir différents types de tests, y compris les tests fonctionnels et non fonctionnels, et doivent être régulièrement mises à jour pour tenir compte des nouvelles découvertes et des évolutions du logiciel.

Question 36

Quelles approches de test sont basées sur la collaboration ?

Answer 36

• Rédaction collaborative de User Stories.
• Critères d’acceptation.
• Développement piloté par les tests d’acceptation (ATDD).

Question 37

C quoi le principe de la rédaction collaborative de User Stories?

Answer 37

Une User Story est une représentation d’une fonctionnalité qui sera utile à l’utilisateur ou à l’acheteur d’un système ou d’un logiciel. Elle se compose de trois éléments principaux, appelés les “3 C” : la Carte, la Conversation et la Confirmation. La Carte représente le support décrivant la User Story, la Conversation explique comment le logiciel sera utilisé, et la Confirmation détaille les critères d’acceptation. Les User Stories suivent généralement un format spécifique, décrivant le rôle de l’utilisateur, l’objectif à atteindre et la valeur métier résultante. La rédaction collaborative des User Stories implique souvent des techniques comme le brainstorming et la cartographie mentale, et elles doivent respecter les principes INVEST (Indépendantes, Négociables, apportant de la Valeur, Estimables, Petites et Testables) pour être efficaces.

“En tant que [rôle], je veux que [objectif à
atteindre], afin de pouvoir [valeur métier résultante pour le rôle]”

Question 38

Quels sont les critères d’acceptation d’une User Story?

Answer 38

Les critères d’acceptation d’une User Story sont les conditions que doit remplir une implémentation de cette User Story pour être acceptée par les parties prenantes. Ils sont dérivés des discussions entre les membres de l’équipe et les parties prenantes, et peuvent être considérés comme les conditions de test à vérifier lors des tests. Les critères d’acceptation définissent le périmètre de la User Story, obtiennent un consensus parmi les parties prenantes, décrivent les scénarios positifs et négatifs, servent de base aux tests d’acceptation des utilisateurs et permettent une planification et une estimation précises.

• BDD: orienté-scénario:
• Given l’utilisateur est connecté à son compte,
• When il clique sur le bouton “Ajouter un commentaire” sous un article,
• Then un champ de saisie de commentaire s’affiche.
• Scénario orienté vers les règles:
• Vérifier que le champ de commentaire accepte un minimum de 10 caractères.
• Vérifier que les utilisateurs non connectés ne peuvent pas ajouter de commentaires.

Question 39

C quoi l’approche ATDD?

Answer 39

Le développement piloté par les tests d’acceptation (ATDD) est une approche dans laquelle les cas de test sont créés avant même l’implémentation de la User Story. Ces cas de test sont élaborés lors d’un atelier de spécification, où la User Story et ses critères d’acceptation sont discutés et rédigés par les membres de l’équipe. Les cas de test sont basés sur ces critères et servent d’exemples du comportement attendu du logiciel. Ils aident l’équipe à mettre en œuvre correctement la User Story en garantissant que les fonctionnalités sont correctement développées et testées.

Exemple:
Prenons l’exemple d’une User Story concernant l’ajout de produits au panier dans une application de commerce électronique. Avant même de commencer le développement, l’équipe organise un atelier de spécification où ils définissent les critères d’acceptation, tels que la possibilité d’ajouter un produit au panier, de modifier la quantité et de supprimer des produits. Ensuite, ils créent les cas de test correspondants, comme “L’utilisateur peut ajouter un produit au panier en cliquant sur le bouton d’ajout”, ou “L’utilisateur peut modifier la quantité d’un produit dans son panier”. Ces cas de test, exprimés dans un langage naturel compréhensible pour tous les membres de l’équipe, servent de guide pour le développement et la validation de la fonctionnalité. Une fois les cas de test réalisés, l’équipe peut automatiser leur exécution pour garantir une validation continue au fur et à mesure de l’implémentation.
Lorsqu’ils sont définis dans un format pris en charge par un framework d’automatisation des tests, les
développeurs peuvent automatiser les cas de test en écrivant le code correspondant au fur et à mesure
qu’ils implémentent la caractéristique décrite dans une User Story. Les tests d’acceptation deviennent alors des exigences exécutables.