Qu'est-ce que le gris Box Essai? Techniques, exemple

⚡ Résumé intelligent

Gris Box Les tests examinent une application avec une connaissance partielle de sa structure interne, combinant la vision utilisateur des tests en boîte noire avec une compréhension architecturale suffisante pour expliquer pourquoi une défaillance s'est produite plutôt que de simplement constater qu'elle s'est produite.

🔍 Niveau de connaissance : La structure interne est partiellement connue, contrairement aux tests en boîte blanche où elle est entièrement connue et aux tests en boîte noire où elle est inconnue.
🧪 Quatre techniques : Les tests matriciels, les tests de régression, les tests de tableaux orthogonaux et les tests de modèles constituent la boîte à outils de base.
🪜 Dix étapes : Identifiez les entrées, les sorties et les principaux chemins, puis décomposez le système en sous-fonctions et vérifiez chacune d'elles.
🔗 Meilleure coupe : Tests d'intégration, tests d'intrusion, flux de travail basés sur des bases de données, services web et APItracts.
️ Compromis : La visibilité partielle réduit l'effort, mais elle limite également la profondeur d'exploration de chaque chemin de code. traced.
📋 Condition préalable: Une documentation de conception précise est essentielle, car un schéma ou une spécification obsolète invalide silencieusement la conception des tests.

Qu'est-ce que le gris Box Essai?

Gris Box Tests (également orthographié Gray) Box Le test de Grey est une technique de test logiciel qui permet de tester un produit ou une application logicielle avec une connaissance partielle de sa structure interne. Box Les tests servent à rechercher et à identifier les défauts causés par une structure de code incorrecte ou une utilisation inappropriée de l'application.

Ce processus permet d'identifier les erreurs contextuelles liées aux systèmes web. Cette technique améliore la prise en charge. Couverture de test en se concentrant sur toutes les couches d'un système complexe plutôt que sur une seule d'entre elles.

Gris Box Les tests sont une méthode de test logiciel qui combine Blanc Box Tests et Noir Box TestsLa distinction entre les trois réside dans la mesure où le testeur peut observer la structure interne :

En blanc Box La structure interne (code) est connue.
En noir Box La structure interne (code) est inconnue.
En gris Box La structure interne (code) est partiellement connue.

Le diagramme ci-dessous place les trois méthodes sur la même échelle de visibilité.

In génie logiciel, Gris Box Les tests permettent de tester les deux aspects d'une application : la couche de présentation et le code sous-jacent. Ils sont particulièrement utiles pour : test d'intégration et tests de pénétration.

Exemple de gris Box Test: Lors du test d'une fonctionnalité d'un site web, comme les liens ou les liens orphelins, si le testeur rencontre un problème avec ces liens, la modification peut être effectuée immédiatement dans le code HTML et vérifiée en temps réel.

Pourquoi le gris Box Tests

Gris Box Les tests sont effectués pour les raisons suivantes :

Il offre les avantages combinés des tests en boîte noire et des tests en boîte blanche.
Il combine les contributions des développeurs et des testeurs et améliore la qualité globale du produit.
Cela réduit les coûts liés au long processus de test des types fonctionnels et non fonctionnels.
Cela laisse au développeur suffisamment de temps libre pour corriger les défauts.
Les tests sont effectués du point de vue de l'utilisateur et non de celui du concepteur.
Une défaillance peut être expliquée plutôt que simplement signalée, car le testeur peut voir la couche où elle s'est produite.

Gris Box Tests contre Noir Box contre Blanc Box Tests

Ces trois méthodes ne sont pas tant des alternatives concurrentes que trois niveaux d'accès, et chacune répond à un type de question différent. Les mettre en parallèle rend le choix concret.

Base	Noir Box Tests	Gris Box Tests	Blanc Box Tests
Connaissance de la structure interne	Aucun	Partiel	Full
Interprété par	Testeurs et utilisateurs finaux	Les testeurs et les développeurs travaillant avec les testeurs	Développeurs et ingénieurs de test
Base de la conception des tests	Exigences et spécifications	Archiarchitecture, algorithmes, structures de données et interfaces	Code source et flux de contrôle
Niveau typique	Tests système et d'acceptation	Tests d'intégration, d'intrusion et de services Web	Test des unités et des composants
Couverture mesurée comme	Couverture des exigences	Couverture de l'interface, des données et du chemin	Couverture des relevés, des succursales et des itinéraires
Principale limitation	La cause d'une défaillance reste cachée	La profondeur est limitée par l'accès accordé.	Coûteux, et il peut passer à côté d'exigences manquantes

La plupart des équipes utilisent les trois sur l'ensemble du terrain. cycle de vie des tests logicielset c'est au niveau de la couche grise que sont généralement détectés les défauts qui se situent entre l'interface utilisateur et le stockage des données.

Gris Box Stratégie de test

Pour effectuer Grey Box Lors des tests, il n'est pas nécessaire que le testeur ait accès au code source. Un test est conçu à partir de la connaissance des algorithmes, des architectures, des états internes ou d'autres descriptions générales du comportement du programme.

Pour effectuer Grey Box Test:

Elle applique les techniques simples des tests en boîte noire.
Il est basé sur la génération de cas de test pilotée par les exigences, ce qui signifie qu'il prédéfinit toutes les conditions avant que le programme ne soit testé par la méthode d'assertion.

Techniques utilisées pour le gris Box Les tests sont :

Test matriciel : Cette technique consiste à définir toutes les variables présentes dans le programme, ainsi que le risque que chacune comporte, afin de rendre visibles les variables inutilisées et celles présentant un risque élevé.
Les tests de régression: Ce test vérifie si une modification apportée à la version précédente a entraîné une régression d'autres aspects du programme dans la nouvelle version. Il utilise des stratégies telles que le test complet, le test des cas d'utilisation à risque et le test au sein d'un pare-feu.
Tests de réseaux orthogonaux ou OAT : assure une couverture de code maximale avec un nombre minimal de cas de test.
Test de modèle : Effectuée sur des données historiques de défauts système antérieurs. Contrairement aux tests boîte noire, la méthode Grey Box Les tests permettent d'analyser le code et de déterminer la cause de la défaillance.

Gris Box La méthodologie utilise généralement des méthodes automatisées. outils de test de logiciels Pour effectuer les tests, des stubs et des pilotes de modules sont créés afin que le testeur n'ait pas à générer le code manuellement.

Étapes pour réaliser Grey Box Les tests sont :

Étape 1 : Identifier les entrées.
Étape 2 : Identifier les résultats.
Étape 3 : Identifier les principaux axes.
Étape 4 : Identifier les sous-fonctions.
Étape 5 : Développer les entrées pour les sous-fonctions.
Étape 6 : Développer les sorties pour les sous-fonctions.
Étape 7 : Exécuter le cas de test pour les sous-fonctions.
Étape 8 : Vérifiez le résultat correct des sous-fonctions.
Étape 9 : Répétez les étapes 4 à 8 pour les autres sous-fonctions.
Étape 10 : Répétez les étapes 7 et 8 pour les autres sous-fonctions.

Les cas de test pour Grey Box Les tests peuvent porter sur l'interface graphique, la sécurité, les bases de données, les navigateurs et les systèmes d'exploitation, entre autres. Chaque cas généré nécessite toujours la procédure habituelle. cas de test attributs, car un cas qui ne peut être reproduit à partir de sa propre description est de peu d'utilité lors d'une régression.

Là où Grey Box Des tests sont utilisés

Cette technique s'avère pertinente lorsqu'un défaut ne peut être diagnostiqué qu'en examinant simultanément deux couches. Voici les scénarios dans lesquels elle est le plus souvent appliquée :

Flux de travail basés sur des bases de données : Une action est effectuée via l'interface utilisateur, puis les lignes résultantes sont interrogées directement afin de confirmer que les valeurs, les types et les relations ont été stockés comme prévu.
Services Web et API : Une requête est envoyée et le statut de la réponse, les en-têtes et la charge utile sont comparés à la configuration publiée.tract, qui est la forme courante de Test d'API.
Points d'intégration : Les messages franchissant une limite entre deux modules sont inspectés alors que les deux modules sont traités comme des systèmes en cours d'exécution plutôt que comme des fichiers sources.
Évaluation de la sécurité : Un testeur d'intrusion, disposant d'un compte utilisateur normal et d'une vue d'ensemble de l'architecture, reproduit la position d'un initié, ce qui correspond au modèle d'engagement standard en boîte grise.
Applications Web et interfaces graphiques : Les liens brisés, les pages orphelines, la gestion des sessions et la validation côté client sont tous vérifiés avec une visibilité partielle du balisage et du flux de requêtes.

Dans tous ces cas, le coût global des défauts du système est réduit car les problèmes sont détectés et expliqués avant qu'ils ne se propagent plus loin dans la chaîne de traitement. test du système ou production.

Gris Box Outils de test

Aucun outil ne réalise Grey Box Des tests isolés. Cette catégorie a besoin d'une combinaison d'un pilote d'interface, d'un outil d'inspection de la couche sous-jacente et d'un moyen de les automatiser par script.

Clients API et services Web comme Postman et SoapUI, utilisé pour émettre des requêtes et vérifier les codes d'état et les corps de réponse.
Clients de bases de données et outils de requête SQL, utilisé pour vérifier l'état persistant après une action d'interface.
Outils de développement du navigateur et proxys HTTP comme Burp Suite, utilisé pour inspecter et modifier les requêtes lors de sessions axées sur la sécurité.
cadres d'automatisation de l'interface utilisateur comme Selenium, utilisé pour piloter la couche de présentation à l'intérieur d'un tests d'automatisation suite.
Outils de journalisation et de surveillance, utilisé pour corréler une défaillance observée avec ce que l'application a enregistré en interne à ce moment-là.

Le choix importe moins que le câblage : à moins que le pilote d’interface et l’étape d’inspection ne s’exécutent dans le même flux scripté, le résultat est deux vérifications manuelles distinctes plutôt qu’un seul test en boîte grise.

Gris Box Défis de test

La visibilité partielle introduit des problèmes que les méthodes pures ne présentent pas, et voici ceux que les équipes rencontrent le plus souvent :

Lorsqu'un composant testé rencontre une défaillance quelconque, il peut interrompre l'opération en cours et laisser le reste de la séquence inexécutée.
Un test peut s'exécuter intégralement alors que le contenu du résultat est incorrect ; l'étape de vérification doit donc contrôler les valeurs plutôt que l'achèvement.
Une couverture complète du chemin d'exécution du code n'est pas possible, car le testeur ne voit jamais toutes les branches que les tests en boîte blanche atteindraient.
La documentation de conception sur laquelle s'appuient les tests peut être obsolète, et un schéma ou une spécification d'interface périmés invalide silencieusement la conception des tests.
Les testeurs ont besoin à la fois d'une compréhension du domaine et d'une expertise technique approfondie, ce qui correspond à un profil de compétences plus restreint à rechercher.
Réparti et fortement absorbétracLes architectures de type Ted rendent difficile l'attribution d'une panne observée à un composant interne spécifique.

Ces limitations plaident en faveur du traitement de Grey Box Les tests constituent une couche parmi d'autres plutôt qu'un remplacement des autres, ce qui est le point soulevé dans l'ensemble plus large des techniques de test de logiciels et types de tests logicielsIl s'intègre naturellement aux côtés test fonctionel et les approches axées sur les spécifications telles que tests basés sur un modèle.

FAQ

Les deux termes désignent la même technique. « Grey » est l'orthographe britannique et « gray » l'orthographe américaine ; ils sont utilisés indifféremment dans la documentation technique des outils et les programmes de certification. Leur signification technique reste la même.

Suffisant pour comprendre le fonctionnement interne sans lire chaque ligne : diagrammes d’architecture, modèle de données, interfacestracUn compte en lecture seule sur la base de données de test est requis. L'accès complet au dépôt transforme l'exercice en test en boîte blanche.

Il s'agit généralement d'un ingénieur de test ayant une expérience en développement, ou d'un testeur travaillant en binôme avec un développeur pour la session. Les missions de sécurité sont menées par des testeurs d'intrusion qui reçoivent un compte utilisateur standard et une présentation de l'architecture.

Contre les interfaces et les données plutôt que les instructions : chaque point de terminaison et code d’état utilisé, chaque table et transition d’état consultée, chaque chemin d’intégration parcouru. Les pourcentages d’instructions et de branches relèvent de la mesure en boîte blanche.

Un stub remplace un composant appelé par le module testé ; un pilote remplace le composant qui l’appellerait. Ensemble, ils permettent d’exécuter une sous-fonction de manière isolée avant même que le système complet ne soit opérationnel.

Lorsqu'un avis indépendant du point de vue de l'utilisateur est requis, car une connaissance partielle biaise le testeur en faveur des comportements attendus, les tests d'acceptation et d'utilisabilité restent confidentiels. Le code critique pour la sécurité nécessite toujours une analyse complète en boîte blanche.

L'apprentissage automatique exploite l'historique des défauts pour l'étape de test des modèles, classe les interfaces en fonction du risque prédit afin que l'accès limité soit bien utilisé et regroupe les journaux pour relier une défaillance observée au composant interne qui l'a produite.

Oui, pour les parties répétitives : générateurs de requêtes, assertions de réponse, requêtes de vérification, stubs et pilotes issus d’une définition d’interface. Le choix de l’état interne qui prouve la validité du comportement reste du ressort de l’ingénieur concepteur.