Menu

Hoe complexe testscenario's voor bedrijfslogica te schrijven met behulp van de beslissingstabeltechniek

  • Hoofd
  • Teststrategie
  • Hoe complexe testscenario's voor bedrijfslogica te schrijven met behulp van de beslissingstabeltechniek

how write complex business logic test scenarios using decision table technique

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Decision Table Testing is een gemakkelijke en betrouwbare benadering om de testscenario's voor complexe Business Logic te identificeren ​

Er zijn verschillende ontwerptechnieken voor testcases. In dit artikel zullen we leren hoe u de Decision Table-techniek effectief naar schrijf testcases voor een applicatie met complexe Business Logic.

Hier is een illustratie:

We weten allemaal dat de regels en validaties van het bedrijfsleven een groot deel van de eisen van de klanten uitmaken. Terwijl we observeren hoe deze vereisten worden weergegeven en gecommuniceerd naar het hele projectteam door Business Analisten of klanten, komen we te weten dat de meeste van dergelijke bedrijfsregels en logica worden gepresenteerd in een logisch processtroomdiagram.

Testscenario schrijven met behulp van de beslissingstabeltechniek

Een logisch proces Stroomdiagram voor een complexe vereiste bestaat uit vele takken, knooppunten en beslissingsboxen. Hopelijk wordt van ons testers verwacht dat we al die takken bedekken en elk hoekje en hoekje van zo'n complexe logische boom raken. Ik heb ook te maken gehad met dergelijke complexe bedrijfsstromen en heb veel voorbereidingstechnieken voor testcases / testscenario's geprobeerd om het proces te vergemakkelijken.

Ten slotte vond ik de techniek van het testen van de beslissingstabel zeer nuttig in dit aspect. Hier ziet u hoe een beslissingstabeltechniek de voorbereiding van het testscenario voor complexe Business Logic eenvoudiger kan maken.

Voorbeeld: testcases schrijven voor een inlogscherm met behulp van de beslissingstabeltechniek:

Laten we een Voorbeeld van een beslissingstabel van onderstaande zakelijke vereisten voor een inlogscherm.

Beslissingstabel testen

Fig: 1.0 Voorbeeld van een bedrijfsstroomdiagram

De eerste stap die we doen is om alle takken een naam te geven en te vertrekken met cijfers of letters zoals hieronder.

1, 2, 3 zijn de bladeren en a, b & c zijn de takken.

oracle plsql interviewvragen voor ervaren

Vervolgens moeten we een beslissingstabel maken zoals hieronder weergegeven: (Klik om afbeelding te vergroten)

Beslissingstabel testen 1

Fig 1.1 Beslissingstabel voor zakenstroom Fig 1.0

Wat je leert:

Punten om te onthouden

  • Alle validaties die in de beslissingsvakken zijn gespecificeerd, moeten worden uitgevoerd op basis van de kolommen op de tafel.
  • Alle resultaten (bladeren) die in het stroomschema worden genoemd, moeten in de beslissingstabel worden opgenomen.
  • Alle combinaties van inputs die nodig zijn om een ​​bepaald resultaat te verkrijgen, worden vermeld in de combinatiekolom en kunnen worden meegenomen tijdens het schrijven van de testcases.
  • Na het invullen van de Beslissingstabel hoeft men alleen maar te verifiëren of alle takken en bladeren in de logische boom bedekt zijn.

Voordelen van het gebruik van de beslissingstabeltechniek

# 1) Elke complexe bedrijfsstroom die als een diagram wordt weergegeven, kan met deze techniek gemakkelijk worden behandeld.
#twee) Het geeft snel vertrouwen in de testgevallen. Je hoeft zijn eigen testcases niet meerdere keren te bekijken om vertrouwen te krijgen.
# 3) Makkelijk te begrijpen. Iedereen kan testcases maken van dit sjabloon voor de beslissingstabel.
# 4) Herwerkzaamheden aan de testcases en testscenario's kunnen volledig worden vermeden, aangezien het volledige dekking geeft bij de eerste opname.

Beperkingen van het gebruik van de beslissingstabeltechniek

# 1) Bepaalde voorbereidingstechnieken voor testcases, zoals grenswaardeanalyse en gelijkwaardigheidsindeling, kunnen niet rechtstreeks in deze sjabloon worden ondergebracht. Maar men kan het noteren in de combinatiekolom en ze gebruiken tijdens het schrijven van testcases.

Alvorens uit te leggen waarom andere schrijftechnieken voor testcases niet zoveel nauwkeurigheid kunnen garanderen als beslissingstabellen, wil ik de andere er snel aan herinneren Zwarte doos en witte doos testcase-schrijftechnieken.

Andere ontwerptechnieken voor testgevallen

# 1) Grenswaardeanalyse is een Software Testing-techniek waarbij testcases zijn ontworpen om vertegenwoordigers van grenswaarden binnen en buiten een bepaald bereik.

#twee) Equivalentiepartitionering ook wel genoemd Partitionering van gelijkwaardigheidsklassen is een Software Testing-techniek die de gegeven conditie opsplitst in partities en één invoergegevens van elke partitie kan worden gekozen om te testen.

# 3) State Transition testen is een black-box-testtechniek die kan worden gebruikt om testgevallen te ontwerpen voor een systeem dat een eindig aantal toestanden verkrijgt en bij specifieke gebeurtenissen van de ene staat naar de andere kan gaan.

# 4) Fout bij het raden is een techniek waarbij de ervaring van een tester wordt gebruikt om de fouten of een deel van een applicatie met de grootste kans op fouten te vinden. Dit is een op vaardigheden gebaseerde techniek zonder enige regels.

# 5) Gebruik casetesten Bij deze techniek worden use cases / scenario's gebruikt om de testcases te schrijven. De interactie van gebruikers en systemen wordt beschreven in een use case.

Nog enkele testontwerptechnieken:

# 6) Verklaring dekking
# 7) Conditie dekking
# 8) Verkennende toetsing

Waarom kunnen andere testcase-ontwerptechnieken voor bedrijfslogica niet nuttig blijken te zijn als beslissingstabellen?

# 1) Boundary Value Analysis en Equivalentie klasse partitionering is bedoeld voor numerieke bereiken en lengte. Beide technieken alleen kunnen geen 100% testdekking voor bedrijfsregels garanderen.

#twee) Error Guessing gaat meer over de ervaring. Hoewel ervaring vereist is, kan het niet alles blijken te zijn.

# 3) Met de State Transition-testtechniek kan men ervoor zorgen dat alle delen van de logische boom bedekt zijn, maar het suggereert geen document of artefact, aangezien de Decision Table-techniek dekking verzekert met een beslissingstabel (figuur 1.1).

Gevolgtrekking

Voor het schrijven van testcases voor bedrijfslogica is het raadzaam om onderstaande te volgen stappen om testcases voor te bereiden om een ​​maximale testdekking te garanderen:

Stap 1) Gebruik een ontwerptechniek voor een testcase voor een beslissingstabel om 100% logische dekking te bereiken.
Stap 2) Boundary Value Analysis en Equivalentiepartitionering voor het afdekken van verschillende soorten inputs.
Stap 3) Combinaties en permutaties voor validaties op veldniveau (hoewel niet alle permutaties vereist zijn).
Stap 4) Fout raden (afgezien van de fouten die kunnen worden geïdentificeerd uit de bovenstaande drie stappen) met ervaring als laatste hand

Met de juiste combinatie van al deze technieken hoop ik dat je ze bijna allemaal kunt ontdekken test scenario's voor elke toepassing die wordt getest.

goede gratis muziekdownloader voor Android

Over de auteur: Hari Narayan is een softwaretestprofessional met meer dan 3 jaar werkervaring in het schrijven van testscenario's voor complexe Business Logic. Hij werkt momenteel samen met Plintron Global Technologies.

Laat ons weten welke testcase-ontwerptechniek u het meest gebruikt voor uw project? En wat is volgens uw ervaring de beste methode?

Deel gerust uw waardevolle opmerkingen / suggesties over dit artikel.

Aanbevolen literatuur

^