Test Black Box

Chaque logiciel, avant de se lancer sur le marché, est testé pour sa fonctionnalité à fond. Et il faut aussi, comme beaucoup d'argent est en rouleau, pour chaque logiciel qui est faite pour des applications diversifiées, qu'il s'agisse de banques, compagnies aériennes, les chemins de fer ou d'un système éducatif même. C'est là que l'essai de logiciels entre en image, afin de vérifier si oui ou non une application fonctionne correctement, en utilisant toutes les permutations et les combinaisons de possibilités qui peuvent ou non se produire. Une fois qu'une application est développée avec un logiciel particulier, il existe de nombreux types de tests qui sont effectués sur le logiciel. Une des méthodologies de test de logiciels est noir boîte de tests de logiciels. Donc, cet article vous aidera à comprendre, ce sont les tests boîte noire dans le détail.

Noir Définition Test Box

Noir tests de logiciels boîte peut être définie comme une méthode de conception de test, ce qui aide à vérifier les exigences fonctionnelles d'une application, sans utiliser explicitement la connaissance de la structure de base de l'application. Un ensemble de cas de test sont créés avec une combinaison d'entrées correctes et incorrectes, en fonction de la conception, les exigences et les spécifications de l'application développée. Ce test commence généralement dès que le code de l'application est développée sous une forme brute. D'autres noms pour cette méthode d'essai sont les suivantes:

* Les tests fonctionnels

* Test boîte fermée

* Test boîte opaque

* Test comportemental

Noir Box techniques d'essai

Il ya certain ensemble de techniques utilisées dans les tests de boîte noire qui spéculent les différentes sorties possibles, dont les entrées et les fonctionnalités du logiciel d'application peuvent être validés. Passez en revue les techniques mentionnées ci-dessous pour comprendre ce sujet mieux.

Table de décision

Une table de décision comme son nom l'indique, est une stratégie de test boîte noire, qui donne sorties de vos cas de test, fondée sur la décision. Il comprend une table contenant 4 quadrants, les conditions, les entrées de la situation, des déclarations d'action et les entrées d'action. Précisément, toutes les conditions possibles sont testées pour vérifier si le résultat souhaité est atteint après avoir essayé différentes entrées. Alors comment faire une table de décision? Suivez les points ci-dessous pour en créer un.

* Tout d'abord, avant de concevoir une table de décision, d'éliminer toutes les situations impossibles, les redondances et les incohérences qui pourraient être une partie des données d'entrée.

* Déterminer le nombre de conditions qui ont une incidence sur la décision.

* Déterminer toutes les actions possibles qui pourraient être prises, et le nombre de solutions de rechange condition pour toutes les conditions. Considérant une table simple décision, les alternatives sont «oui» ou «non».

* Maintenant, essayez d'imaginer les combinaisons possibles uniques / possibilités qui peuvent être calculées par la recherche de valeurs possibles pour chaque état et à les multiplier ensemble. Cela permettra également de vous donner le nombre total de colonnes à insérer dans le tableau.

* Entrez toutes les combinaisons possibles dérivés, dans les colonnes de haut de la table de décision.

* Pour chaque possibilité unique, marquer un X dans le quadrant inférieur droit dans la ligne d'action appropriée. Ce symbole indique l'intersection de l'action requise et la combinaison unique.

* Une fois que le tableau est complet, vérifier toutes les contradictions et les supprimer. Réorganiser le contenu du tableau en conséquence.

Prenons un exemple simple noire test boîte en utilisant cette méthode: Soit une société de marketing qui a décidé de marché 4 produits (A, B, C et D), en fonction de trois caractéristiques: Sexe (Homme - M ou Femme - F), groupe et l'âge (60 (Z)) citadin (N Oui - - Y ou Non). Ainsi, le nombre total de colonnes sont les suivantes: 2 (Sexe) x 2 (citadin) x 3 (Groupe d'âge) = 12 colonnes. Maintenant ensemble de règles dit:

* Un produit pour les femmes qui habitent dans la ville

B * Produit pour les jeunes femmes

* Produit C pour les acheteurs masculins d'âge moyen qui ne sont pas des citadins

* Produit D pour tous, sauf les femelles âgées

Condition alternativesProcess1

2

3

4

5

6

7

8

9

10

11

12

Sexe

Fa

M

Fa

M

Fa

M

Fa

M

Fa

M

Fa

M

Ville

Y

Y

N

N

Y

Y

N

N

Y

Y

N

N

Âge

X

X

X

X

Y

Y

Y

Y

Z

Z

Z

Z

EntriesMarketing action Produit1

2

3

4

5

6

7

8

9

10

11

12

Un produit

X

-

-

-

X

-

-

-

X

-

-

-

Produit B

X

-

X

-

-

-

-

-

-

-

-

-

Produit C

-

-

-

-

-

-

-

X

-

-

-

-

Produit D

X

X

X

X

X

X

X

X

-

X

-

X

Ici, la table peut être simplifié davantage. Comment? Si vous observez le tableau, les règles de la colonne 2, 4, 6, 7, 10 et 12 ont les mêmes points d'action. De même, les règles 2, 6 et 10 répondent 2 sur les trois entrées de la situation des femmes et citadin. Règles pour les 4 et 12, même si ont tendance même action ne peut pas être fusionnées en raison des critères d'âge. Et enfin, le groupe d'âge Y ne sont pas couverts. Ainsi, la table de décision modifié comme suit:

Condition alternativesProcess1

2

3

4

5

6

7

8

9

10

Sexe

Fa

M

Fa

M

Fa

Fa

M

Fa

Fa

M

Ville

Y

Y

N

N

Y

N

N

Y

N

N

Âge

X

-

X

-

X

Y

Y

Y

Z

Z

EntriesMarketing action Produit1

2

3

4

5

6

7

8

9

10

Un produit

-

X

-

-

X

-

-

X

-

-

Produit B

X

-

X

-

-

-

-

-

-

-

Produit C

-

-

-

-

-

-

X

-

-

-

Produit D

X

X

X

X

X

X

X

-

-

X

Le partitionnement d'équivalence

Partitionnement d'équivalence est encore une autre méthode de test boîte noire qui vise à réduire le nombre total de cas de test pour les tests logiciels en divisant les données d'entrée en partitions. Cette méthode est utile pour déterminer les entrées valides et non valides de test d'applications. En outre, les cas de test sont préparés sur chaque partition afin de s'assurer que l'application traite correctement les données d'entrée lors de l'entrée valide est entré et jette sinon un message d'erreur. Basé sur les intrants, dont les résultats sont identiques, les cas de test sont regroupés en une classe d'équivalence. Laissez-moi vous expliquer avec un exemple de test boîte noire pour cette technique: Il ya une compagnie qui offre notamment des privilèges différents pour les appartenances diverses, en fonction du nombre de vols sont prévalus de l'air par un client régulier.

Nombre de FlightsMembership5-10

Argent

11-15

Or

16-20

Platine

21-40

Diamant

Ainsi, à partir des données ci-dessus, on peut en déduire que les conditions mentionnées s'appliquent pour le nombre de vols qui varient entre 5-40. Tout nombre est inférieur à 5 ou supérieur à 40 est une entrée invalide pour le programme. Donc, ici, les rendements de partitionnement équivalence 7 partitions qui incluent les 4 ci-dessus mentionnés cas de test valides et 3 cas de test supplémentaires qui sont inclus des entrées invalides tels que, 40 et non des valeurs numériques. La raison pour laquelle les entrées invalides sont également envisagée consiste à calculer la couverture de test absolu de l'application testée.

Analyse des valeurs limites

Comme son nom l'indique, cette méthode vise à définir et à revérifier les limites définies dans la méthode de partitionnement d'équivalence. Voici les cas de test sont spécialement conçus pour inclure les valeurs limites pour localiser les erreurs dans le logiciel d'application. Donc, la première étape consiste à identifier les entrées et les sorties possibles, à la fois valides et non valides. Il a été observé que la plupart des erreurs relevées lors de tests boîte noire se produisent aux frontières du domaine d'entrée. Par exemple, nous allons jeter un coup d'oeil à l'exemple ci-dessous où les tests boîte noire qui est fait pour une boîte de saisie qui accepte les numéros entre 1-1000. Les cas de test possibles avec des variations dans les limites suivantes:

Cas de test avec 1 * des données de test - 1000 (à la fois les valeurs limites d'entrée inclus)

Cas de test avec des données test * 0 à 999 (en commençant par un de moins que les limites extrêmes)

Cas de test * avec les données de test 2 - 1001 (à partir de plus l'un que les limites extrêmes)

Test de l'application avec la combinaison de données de test ci-dessus est également une partie des tests négatifs ou le stress qui vous aidera à évaluer les aspects positifs et négatifs de la couverture des tests de précision.

Représentation graphique des causes et des effets

Cause et Effet graphique comme méthode l'indique, consiste à identifier une cause et d'anticiper l'effet, la conversion de la procédure profane à un algorithme logiciel basé en énumérant d'abord les causes et les effets, puis les graphiques, la conversion du graphique pour une table de décision et puis enfin à tester cas. Ainsi, cette méthode permet d'identifier les bonnes entrées pour la méthode de partitionnement d'équivalence. Maintenant, suivez les étapes ci-dessous pour représenter la cause et l'effet et de le convertir à une table de décision tel que mentionné ci-dessus.

* Identifier les besoins de l'application et de les découper en sous-ensembles de fonctionnalités de petite taille.

* Identifier la cause et l'effet de l'ensemble des exigences.

* Maintenant, créez un lien logique entre les sous-ensembles d'exigences.

* Tirer les combinaisons possibles et impossibles de cause à effet duo, et les graphes.

* Convertir le graphique dans une table de décision, avec la colonne signifiant le cas de test et rangée comme la cause / effet.

* Maintenant, les colonnes peuvent être convertis en cas de test qui disposent d'une certaine d'entrées valides et non valides, ce qui aide à déterminer la couverture de test.

Diagramme de transition d'état

Pour comprendre le comportement d'une application système, les diagrammes de transition d'état sont nécessaires. Cette méthode représente graphiquement une série d'événements qui se produisent dans différents états / conditions. Grâce à cette technique de test boîte noire, on arrive à comprendre la conception du système interne et les exigences. Si vous avez une compréhension claire des diagrammes, un diagramme de transition serait une promenade de gâteau pour vous. Ce diagramme comporte quatre états:

* L'état actuel

* Événement

* Action

* Suivant l'état

Événements qui se déroulent dans l'état actuel portent toujours 2 possibilités, oui ou non. Donc, sur cette base, des actions sont aussi différentes et en fonction de ces actions, l'état suivant est identifié. Après avoir représenté graphiquement ce schéma, on peut facilement créer une table de transition d'état qui aide à dénicher certaines combinaisons non détectées qui n'auraient pas été identifiés ou documentés dans d'autres techniques comme indiqué ci-dessus. Ainsi, lors de la création des cas de test, il faut s'assurer que tous les événements de l'application sont déclenchés au moins une fois, et les voies qui relient les événements et les actions sont fouler au moins une fois. Si il ya des boucles internes créées lors de la conception d'un diagramme de transition d'état, il ya une possibilité de blocages, fuites de mémoire, etc, qui ont besoin d'être travaillé. Cette méthode est recommandée pour les applications en temps réel. Par exemple, prenons un exemple simple de remplir une bouteille.

* Vous avez une bouteille vide qui doit être comblé. Il s'agit d'un événement qui appelle immédiatement à l'action de remplissage de la bouteille.

* Maintenant que la bouteille est en cours de vérification, pour savoir s'il est complet ou non. Si elle est pleine, l'action suivante consiste à le sceller. Si elle n'est pas pleine, l'événement sera redirigé vers le remplissant d'abord.

* Une fois que la bouteille est remplie avec de l'eau. Il faut contrôler l'étanchéité. S'il ya une fuite, il est alors rompu et est redirigé vers le premier événement de vide.

* Sinon l'action de sceller la bouteille apparaît comme la dernière étape.

Il s'agissait d'un exemple simple illustrant le comportement d'un système. Pour mieux comprendre ce concept, il faut être bien familiarisés avec le sujet de l'UML (Unified Modeling Language).

White Box Testing contre Black Box

Maintenant que nous connaissons certaines des techniques de test noir boîte, il faut bien comprendre la différence entre les tests boîte blanche et tests de boîte noire. Eh bien, contrairement tests boîte noire où le testeur n'a pas besoin d'avoir une connaissance sur le fonctionnement du code déployé dans l'application, pour les tests boîte blanche, c'est un must. Spécialement, lorsque l'interface utilisateur graphique ne cesse de changer pendant les fusions de code et des déploiements dans la phase de test du logiciel, le testeur doit introspecter les changements effectués chaque maintenant et puis. En outre, si l'on suit la méthode du diagramme de transition d'état pour les tests de boîte noire, alors le test boîte blanche aidera à évaluer les possibilités de réutilisation des cas de test générés et aidera également à vérifier si toutes les voies reliant les actions et les événements ont été parcourue au moins une fois. Mais en ce qui concerne l'essai de logiciels, ces deux techniques de test sont très importants pour le contrôle non seulement l'ensemble des fonctionnalités de l'application, mais aussi la qualité du code et de l'application.

Espérons que cet article était très instructif sur les tests de boîte noire. Logiciel de test est une partie intégrante du cycle de vie du développement logiciel. Sans la partie test, une demande est incomplète. Il existe de nombreux outils de tests, disponibles sur Internet, à la fois pour les tests boîte noire et tests boîte blanche qui aident à générer des cas de test pour vos applications. Mais assurez-vous que vous comprenez les techniques de tests boîte noire bien, avant de les mettre en œuvre dans votre application. Bonne chance!