Menu

Comment rédiger des scénarios de test de logique métier complexes à l'aide de la technique de table de décision

  • Principal
  • Stratégie De Test
  • Comment rédiger des scénarios de test de logique métier complexes à l'aide de la technique de table de décision

how write complex business logic test scenarios using decision table technique

Essayez Notre Instrument Pour Éliminer Les Problèmes

Le test de table de décision est une approche simple et fiable pour identifier les scénarios de test pour la logique métier complexe .

Il existe plusieurs techniques de conception de cas de test. Dans cet article, nous allons apprendre à utiliser la technique de la table de décision efficacement pour écrire des cas de test pour une application avec une logique métier complexe.

Voici une illustration:

Nous savons tous que les règles et les validations des affaires reprennent une part importante des exigences données par les clients. Tout en observant comment ces exigences sont représentées et communiquées à toute l'équipe de projet par les analystes commerciaux ou les clients, nous apprenons que la plupart de ces règles et logiques métier sont présentées dans un diagramme de flux de processus logique.

Rédaction d

Un diagramme de flux de processus logique pour une exigence complexe comprend de nombreuses branches, nœuds et boîtes de décision. Espérons que nous, les testeurs, sommes censés couvrir toutes ces branches et toucher tous les coins et recoins d'un arbre logique aussi complexe. J'ai également été confronté à des flux commerciaux aussi complexes et j'ai essayé de nombreuses techniques de préparation de cas de test / scénario de test pour faciliter le processus.

Enfin, j'ai trouvé que la technique de test de table de décision était très utile dans cet aspect. Voici comment une technique de table de décision peut faciliter la préparation du scénario de test pour une logique métier complexe.

Exemple: rédaction de cas de test pour un écran de connexion à l'aide de la technique de table de décision:

Prenons un Exemple de table de décision ci-dessous les exigences commerciales pour un écran de connexion.

Test de la table de décision

Fig: 1.0 Exemple de diagramme de flux commercial

La première étape que nous faisons est de nommer toutes les branches et de partir avec des nombres ou des alphabets comme ci-dessous.

1, 2, 3 sont les feuilles et a, b et c sont les branches.

qu'est-ce que le qa et le qc dans les tests logiciels

Ensuite, nous devons créer une table de décision comme indiqué ci-dessous: (Cliquez pour agrandir l'image)

Test de la table de décision 1

Fig 1.1 Tableau de décision pour le flux d'affaires Fig 1.0

Ce que vous apprendrez:

Points à retenir

  • Toutes les validations spécifiées dans les cases de décision doivent être effectuées à partir des colonnes du tableau.
  • Tous les résultats (feuilles) mentionnés dans le diagramme de flux doivent être couverts dans le tableau de décision.
  • Toutes les combinaisons d'entrées nécessaires pour obtenir un certain résultat doivent être mentionnées dans la colonne des combinaisons et peuvent être incluses lors de l'écriture des cas de test.
  • Après avoir rempli le tableau de décision, il suffit de vérifier si toutes les branches et feuilles de l'arbre logique sont couvertes.

Avantages de l'utilisation de la technique de table de décision

#1) Tout flux métier complexe représenté sous forme de diagramme peut être facilement couvert dans cette technique.
#deux) Il fournit une confiance rapide sur les cas de test. Il n'est pas nécessaire de revoir ses propres cas de test plusieurs fois pour gagner en confiance.
# 3) Facile à comprendre. Tout le monde peut créer des cas de test à partir de ce modèle de tableau de décision.
# 4) Les retouches sur les cas de test et les scénarios de test peuvent être totalement évitées, car elles donnent une couverture complète dès le premier coup.

Limitations de l'utilisation de la technique de table de décision

#1) Certaines techniques de préparation de cas de test comme l'analyse de la valeur limite, le partitionnement d'équivalence ne peuvent pas être directement intégrées dans ce modèle. Mais, on peut le noter dans la colonne des combinaisons et les utiliser lors de l'écriture des cas de test.

entreprises qui proposent des tests de produits à domicile

Avant d'expliquer pourquoi d'autres techniques d'écriture de cas de test ne peuvent pas assurer autant de précision que les tables de décision, je voudrais rappeler rapidement aux autres Boîte noire et boîte blanche techniques d'écriture de cas de test.

Autres techniques de conception de cas de test

#1) Analyse de la valeur limite est une technique de test de logiciel dans laquelle les cas de test sont conçus pour inclure des représentants de valeurs limites dans et hors d'une plage donnée.

#deux) Partitionnement d'équivalence aussi appelé Partitionnement des classes d'équivalence est une technique de test logiciel qui divise la condition donnée en partitions et une donnée d'entrée de chaque partition peut être choisie pour le test.

# 3) Test de transition d'état est une technique de test boîte noire, qui peut être utilisée pour concevoir des cas de test pour un système qui acquiert un nombre fini d'états et peut transiter d'un état à un autre lors d'événements spécifiques.

# 4) Erreur de devinette est une technique dans laquelle l'expérience d'un testeur est utilisée pour trouver les erreurs ou une partie d'une application avec la plus grande possibilité de trouver des erreurs. C'est une technique basée sur les compétences sans aucune règle.

# 5) Test de cas d'utilisation Dans cette technique, des cas d'utilisation / scénarios sont utilisés pour écrire les cas de test. L'interaction des utilisateurs et des systèmes est décrite dans un cas d'utilisation.

Quelques autres techniques de conception de test:

# 6) Couverture du relevé
# 7) Couverture de l'état
# 8) Essais exploratoires

Pourquoi d'autres techniques de conception de cas de test pour la logique métier ne peuvent-elles pas s'avérer utiles en tant que tables de décision?

#1) L'analyse des valeurs limites et le partitionnement des classes d'équivalence sont destinés aux plages numériques et à la longueur. Ces deux techniques ne peuvent à elles seules garantir une couverture de test à 100% pour les règles métier.

#deux) L'estimation des erreurs concerne davantage l'expérience. Bien que l'expérience soit requise, elle ne peut pas être tout.

# 3) Avec la technique de test de transition d'état, on peut s'assurer que toutes les parties de l'arbre logique sont couvertes, mais cela ne suggère pas de document ou d'artefact car la technique de table de décision assure la couverture avec une table de décision (fig 1.1).

Conclusion

Pour écrire des cas de test pour la logique métier, il est conseillé de suivre les instructions ci-dessous étapes pour préparer les cas de test afin d'assurer une couverture de test maximale:

Étape 1) Utilisation une technique de conception de cas de test de table de décision pour atteindre une couverture logique de 100%.
Étape 2) Analyse de la valeur limite et partitionnement d'équivalence pour couvrir diverses gammes d'entrées.
Étape 3) Combinaisons et permutations pour les validations au niveau du terrain (bien que toutes les permutations ne soient pas nécessaires).
Étape 4) Erreur de devinette (à part les erreurs qui peuvent être identifiées à partir des trois étapes ci-dessus) avec l'expérience comme touche finale

Avec la bonne combinaison de toutes ces techniques, j'espère que vous pourrez découvrir presque toutes scénarios de test pour toute application testée.

A propos de l'auteur: Hari Narayan est un professionnel des tests de logiciels avec plus de 3 ans d'expérience professionnelle dans la rédaction de scénarios de test pour la logique métier complexe. Il travaille actuellement avec Plintron Global Technologies.

Faites-nous savoir quelle technique de conception de cas de test vous utilisez le plus souvent sur votre projet? Et quelle est la meilleure méthode selon votre expérience?

N'hésitez pas à partager vos précieux commentaires / suggestions sur cet article.

lecture recommandée

^