5 types de techniques de tests boîte noire + exemples

N’oubliez pas que le test de boîte noire ne couvre que les fonctionnalités externes du logiciel et ne vérifie pas le fonctionnement interne du code source. C’est pourquoi on l’appelle parfois « test comportemental ». Il doit donc être utilisé conjointement avec le test de boîte blanche, qui se concentre sur le test interne du code. De cette manière, vous pouvez avoir la certitude que le logiciel est testé de manière complète et est aussi exempt de défauts que possible.

JOIN THE COMMUNITY

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

Sign up with LinkedIn

Or sign up with email:

LinkedIn

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

5 types de techniques de test de boîte noire

Nous utilisons ces techniques de test de boîte noire pour augmenter la couverture des tests tout en réduisant en même temps le nombre de cas de test. En identifiant les bons jeux de données de test, nous pouvons créer le plus petit nombre de tests avec la plus grande couverture.

Les techniques dont je vais parler peuvent être appliquées à tous les niveaux de test — y compris les tests unitaires, les tests d’intégration, et les tests système, aussi bien que pour des tests fonctionnels et non fonctionnels.

1. Partitionnement en classes d’équivalence

Le partitionnement en classes d’équivalence est une technique utilisée en test logiciel pour diviser les entrées possibles en ensembles de classes d’équivalence, ou partitions, dans le but de trouver et de tester un jeu d’entrées représentatif pour chaque classe. Tous les éléments appartenant à une même classe d’équivalence sont supposés donner le même résultat, donc tester une seule valeur de l’ensemble devrait suffire.

Ceci aide à réduire le nombre de tests à créer et à exécuter tout en maintenant une bonne couverture. Les classes sont définies sur la base des exigences fonctionnelles ou non fonctionnelles et peuvent prendre en compte des facteurs tels que les types de données, les plages et les relations entre les valeurs d’entrée.

Lorsque vous définissez les classes d’équivalence, vous devez toujours veiller à inclure également les classes invalides pour couvrir aussi les scénarios de tests négatifs. D’après mon expérience, j’ai constaté que la plupart des défauts sont découverts lors de l’utilisation d’entrées invalides plutôt que positives.

Regardons un exemple :

Vous avez un champ optionnel qui n’autorise que les valeurs entières comprises entre 1 et 10. Vous auriez donc les classes d’équivalence suivantes :

• aucune valeur (partition valide)
• valeurs entre 1 et 10 (partition valide)
• valeurs inférieures à 1 (partition invalide)
• valeurs supérieures à 10 (partition invalide)

Vous n’auriez donc besoin que de 4 cas de test — 1 pour chaque partition. Il n’y a aucune valeur ajoutée à retester la même partition avec plusieurs valeurs — si vous testez la valeur 5, vous obtiendrez les mêmes résultats pour les valeurs 4, 8, et ainsi de suite.   

2. Analyse des valeurs limites

L’analyse des valeurs limites est une technique utilisée lors des tests logiciels pour identifier et tester les valeurs d’entrée situées à ou près de la « limite » du domaine d’entrée du programme. L’idée est que ces valeurs sont plus susceptibles de provoquer des erreurs ou des comportements inattendus, car elles impliquent souvent des cas particuliers ou extrêmes que le programme n’a peut-être pas été conçu pour gérer correctement.

Par exemple, lors du test d’un programme qui accepte une plage entière de 1 à 100, les valeurs limites seraient 1, 100, ainsi que toutes les valeurs juste à l’extérieur de la plage, comme 0 et 101.

Il existe deux types de tests de valeurs limites :

• Test de limite interne : il se concentre sur les valeurs d’entrée juste à l’intérieur de la frontière du domaine d’entrée, telles que les valeurs minimales et maximales autorisées.
• Test de limite externe : il se concentre sur les valeurs d’entrée juste à l’extérieur de la frontière du domaine d’entrée, par exemple les valeurs légèrement supérieures ou inférieures au minimum et au maximum autorisés.

L'analyse des valeurs limites est une technique importante pour détecter les erreurs et s'assurer qu'un programme fonctionne correctement pour toutes les entrées, et pas seulement pour celles situées au centre du domaine d'entrée. Cela peut aider à identifier et corriger des bugs qui seraient autrement passés inaperçus.

3. Test des tables de décision

Lors du test des tables de décision, nous vérifions la logique et le comportement du logiciel lorsqu'il existe plusieurs conditions. Il s'agit d'une façon de représenter les relations entre les entrées et les sorties sous forme de tableau. Le tableau comporte généralement des colonnes pour les conditions et des lignes pour les différentes combinaisons. Pour chaque ligne, il faut créer un cas de test spécifique. Le résultat attendu pour le cas de test doit également figurer dans le tableau.

Imaginons un exemple d'exigence logicielle où cette technique peut être appliquée : une application qui calcule le coût d'un achat en fonction de l'article, de la quantité et du mode de livraison :

Dans cet exemple, l'article, la quantité et le mode de livraison sont les entrées, et le coût est la sortie. Le tableau montre toutes les combinaisons possibles des entrées ainsi que la sortie correspondante dans chaque cas. Grâce à ce tableau, vous pouvez rapidement identifier les cas de test et leurs résultats attendus, ce qui facilite la vérification et les tests des combinaisons disponibles.

Les tests des tables de décision sont utiles lorsqu'un programme possède de multiples entrées et conditions qui interagissent de manière complexe. En détaillant les entrées et conditions dans un tableau, il devient plus facile d’identifier et de tester toutes les combinaisons et variations possibles.

4. Test de transition d'état

Le test de transition d'état est une technique de test en boîte noire où l'on vérifie le comportement d'un programme lors de ses transitions entre différents états ou modes. Un état est une condition ou un ensemble de conditions dans lesquelles le programme peut exister, et une transition est un passage d'un état à un autre. L'idée derrière le test de transition d'état est d'identifier tous les états possibles et les transitions que le programme peut connaître, puis de créer des cas de test pour vérifier que le programme réagit correctement dans chaque état et effectue des transitions valides entre eux.

Un exemple de test de transition d'état pourrait concerner un site e-commerce où les clients peuvent ajouter des articles à leur panier, passer à la caisse, saisir leurs informations de paiement et de livraison, et enfin passer commande. Les états dans cet exemple seraient :

• Consulter les produits
• Ajouter des articles au panier
• Passer à la caisse
• Saisie des informations de paiement et de livraison
• Confirmation de commande

Les transitions entre ces états seraient :

• Consulter les produits -> Ajouter des articles au panier
• Ajouter des articles au panier -> Passer à la caisse
• Passer à la caisse -> Saisie des informations de paiement et de livraison
• Saisie des informations de paiement et de livraison -> Confirmation de commande

Cette technique aide à identifier et tester tous les parcours qu’un utilisateur peut emprunter dans le système, et à détecter et corriger les bugs liés à certains enchaînements spécifiques. Le test de transition d'état est particulièrement utile pour tester des systèmes aux interactions complexes, tels que les systèmes financiers, les boutiques en ligne ou les systèmes qui pilotent des appareils physiques.

5. Test par paires

Le test par paires est une technique de test en boîte noire utilisée pour créer des cas de test couvrant toutes les paires possibles de combinaisons de valeurs d’entrée pour un ensemble donné de paramètres. Elle s’utilise lorsque le nombre d’entrées disponibles est élevé, ce qui rendrait pratiquement impossible de tester toutes les combinaisons entre elles.

Supposons que nous ayons une application avec 3 champs : A, B et C. Chaque champ peut accepter 3 valeurs possibles : 1, 2 ou 3.

Avec des méthodes de test traditionnelles, il faudrait tester individuellement 27 (3^3) combinaisons possibles d’entrées afin de tout valider, ce qui serait extrêmement chronophage et inefficace.

Avec le test par paires, vous pouvez identifier des scénarios qui couvrent toutes les associations uniques possibles d’entrées. Cela ressemblerait à ceci :

Comme on peut le voir, le nombre de tests a été drastiquement réduit, passant de 27 à 9. La couverture des tests n’a pas changé, nous continuons à vérifier que toutes les combinaisons possibles de valeurs sont prises en compte.

Il existe plusieurs outils de génération de tests par paires disponibles. J’en liste ci-dessous quelques exemples :

• AllPairs : Un outil pour créer des cas de test par paires à partir de listes de paramètres et de contraintes spécifiées par l'utilisateur. Il est disponible en versions open source et commerciale.
• PICT (Pairwise Independent Combinatorial Testing) : Un outil qui utilise un algorithme génétique pour générer des cas de test par paires. Il est disponible en tant qu’outil open source.
• SmartBear TestComplete : Un outil commercial d’automatisation de tests qui inclut la prise en charge native des tests par paires.
• Générateur de Cas de Test Pairwise : Un outil open source disponible sur GitHub permettant de générer des cas de test par paires.
• Il est également possible de générer des tests par paires avec Excel ou OpenOffice Calc en utilisant des macros ou des plugins pour créer vos cas de test.

Ceci n'est qu'une sélection d'exemples, il se peut qu'il existe d'autres outils également. Je vous recommande de faire des recherches et d'évaluer les différentes options disponibles afin de voir quel outil est le mieux adapté à vos besoins et exigences spécifiques.

Dernières réflexions

Utiliser ces techniques est un excellent moyen d'obtenir une bonne couverture à n'importe quelle étape du cycle de vie du développement logiciel. Il est encore préférable d'ajouter d'autres types dans votre processus de test, comme l’exploration, le test par devinette d’erreurs, le test de compatibilité, le test d’utilisabilité, etc.

De plus, si les cas de test obtenus sont intégrés dans la suite de tests de régression, vous devriez envisager de les automatiser : pour les tests UI, vous pouvez utiliser des outils comme Selenium, Cypress et Appium ; pour les tests d’API, vous pouvez avoir des tests d’intégration écrits par l’équipe de développement, ou utiliser des outils comme Postman. 

Si vous avez trouvé cet article utile, je vous suggère de vous abonner à la newsletter QA Lead pour ne rien manquer des nouveaux contenus et tutoriels sur l’assurance qualité et le test.