Menu

Sådan skriver du komplekse forretningslogiske testscenarier ved hjælp af beslutningstabellen

  • Vigtigste
  • Teststrategi
  • Sådan skriver du komplekse forretningslogiske testscenarier ved hjælp af beslutningstabellen

how write complex business logic test scenarios using decision table technique

Prøv Vores Instrument Til At Fjerne Problemer

Beslutningstabeltestning er en nem og sikker tilgang til at identificere testscenarierne for kompleks forretningslogik .

Der er flere teknikker til test case design. I denne artikel vil vi lære at bruge beslutningstabellen effektivt til skriv testcases til en applikation med kompleks forretningslogik.

Her er en illustration:

Vi ved alle, at reglerne og valideringen af ​​virksomheden optager en stor del af kravene fra kunderne. Mens vi observerer, hvordan disse krav er repræsenteret og kommunikeret til hele projektteamet af forretningsanalytikere eller kunder, lærer vi, at de fleste af sådanne forretningsregler og logik er præsenteret i et logisk procesdiagram.

Skrivning af testscenarie ved hjælp af beslutningstabelteknik

En logisk proces Flowdiagram for et komplekst krav består af mange grene, noder og beslutningsfelter. Forhåbentlig forventes det, at vi testere dækker alle disse grene og rører ved hver krog og hjørne af et så komplekst logisk træ. Jeg har også stået over for så komplekse forretningsstrømme og prøvet mange teknikker til forberedelse af test case / testscenarier for at gøre processen lettere.

Endelig fandt jeg, at beslutningstabeltestteknikken var meget nyttig i dette aspekt. Her er hvordan en Decision Table-teknik kan gøre testscenarieforberedelsen til kompleks forretningslogik lettere.

Eksempel: Skrivning af testsager til en login-skærm ved hjælp af beslutningstabellen:

Lad os tage en Beslutningstabeleksempel af nedenstående forretningskrav til en login-skærm.

Afgørelsestabeltestning

Fig: 1.0 Eksempel på forretningsdiagram

Det første skridt vi gør er at navngive alle grene og forlade med tal eller alfabeter som nedenfor.

1, 2, 3 er bladene og a, b & c er grenene.

sql interview spørgsmål til 5 års erfaring

Derefter skal vi oprette en beslutningstabel som vist nedenfor: (Klik for at forstørre billedet)

Test af beslutningstabel 1

Fig 1.1 Beslutningstabel for forretningsstrøm fig 1.0

Hvad du lærer:

Punkter at huske

  • Alle valideringer, der er specificeret i beslutningsfelterne, skal foretages af kolonnerne på bordet.
  • Alle resultater (blade) nævnt i flowdiagrammet skal dækkes i beslutningstabellen.
  • Alle kombinationer af input, der er nødvendige for at opnå et bestemt resultat, skal nævnes i kombinationskolonnen og kan medtages under skrivning af testcases.
  • Efter at have udfyldt beslutningstabellen skal man bare kontrollere, om alle grene og blade i det logiske træ er dækket.

Fordele ved at bruge beslutningstabelteknik

# 1) Ethvert komplekst forretningsflow repræsenteret som et diagram kan let dækkes i denne teknik.
#to) Det giver hurtig tillid til testsagerne. Man behøver ikke at gennemgå sine egne testsager flere gange for at få tillid.
# 3) Let at forstå. Alle kan foretage testsager fra denne skabelon til beslutningstabel.
# 4) Omarbejdning af testsagerne og testscenarier kan helt undgås, da det giver fuld dækning ved første skud.

Begrænsninger ved brug af beslutningstabelteknik

# 1) Visse forberedelsesteknikker til testsager som grænseværdianalyse, ækvivalenspartitionering kan ikke direkte imødekommes i denne skabelon. Men man kan notere det i kombinationskolonnen og bruge dem, mens man skriver testcases.

Inden jeg forklarer, hvorfor andre test case-skriveteknikker ikke kan sikre så meget nøjagtighed som beslutningstabeller, vil jeg hurtigt minde andre om Sort kasse og Hvid kasse test case skriveteknikker.

Andre teknikker til design af testkasser

# 1) Grænseværdianalyse er en softwaretestteknik, hvor testcases er designet til at omfatte repræsentanter for grænseværdier ind og ud af et givet interval.

#to) Ækvivalenspartitionering også kaldet Partitionering af ækvivalensklasse er en softwaretestteknik, der opdeler den givne tilstand i partitioner, og der kan vælges et inputdata fra hver partition til test.

# 3) Test af statsovergang er en black-box testteknik, som kan bruges til at designe testcases for et system, der erhverver et endeligt antal stater og kan transitere fra en stat til en anden ved specifikke begivenheder.

# 4) Fejl gætte er en teknik, hvor oplevelsen af ​​en tester bruges til at finde fejlene eller en del af en applikation med den højeste mulighed for at finde fejl. Dette er en færdighedsbaseret teknik uden nogen regler.

# 5) Brug sagsprøvning I denne teknik bruges use cases / scenarier til at skrive testcases. Interaktionen mellem brugere og systemer er beskrevet i en brugssag.

Nogle flere testdesignteknikker:

# 6) Erklæring dækning
# 7) Tilstandsdækning
# 8) Undersøgende test

Hvorfor kan andre teknikker til test case design til forretningslogik ikke vise sig at være nyttige som beslutningstabeller?

binært træ c ++ implementering

# 1) Grænseværdi-analyse og partitionering af ækvivalensklasse er beregnet til numeriske intervaller og længde. Begge disse teknikker alene kan ikke sikre 100% testdækning for forretningsregler.

#to) Fejl gætte handler mere om oplevelsen. Selvom erfaring er påkrævet, kan det ikke vise sig at være alt.

# 3) Med State Transition-testteknikken kan man sikre, at alle dele af det logiske træ er dækket, men det antyder ikke dokument eller artefakt, da Decision Table-teknikken sikrer dækning med en beslutningstabel (fig 1.1).

Konklusion

For at skrive testcases til forretningslogik tilrådes det at følge nedenstående trin til at forberede testsager for at sikre maksimal testdækning:

Trin 1) Brug en beslutningstabel test case design teknik for at opnå 100% logisk dækning.
Trin 2) Grænseværdianalyse og ækvivalenspartitionering til dækning af forskellige input-intervaller.
Trin # 3) Kombinationer og permutationer til validering på feltniveau (selvom ikke alle permutationer er påkrævet).
Trin # 4) Fejl gætte (bortset fra de fejl, der kan identificeres fra ovenstående tre trin) med erfaring som et sidste touch

Med den rigtige kombination af alle disse teknikker håber jeg, at du vil være i stand til at opdage næsten alle test scenarier til enhver applikation, der testes.

Om forfatteren: Hari Narayan er softwaretesteprofessionel med mere end 3 års erhvervserfaring i at skrive testscenarier til kompleks forretningslogik. Han arbejder i øjeblikket med Plintron Global Technologies.

Fortæl os hvilken test case design teknik, du bruger oftest på dit projekt? Og hvilken er den bedste metode ifølge din erfaring?

Del gerne dine værdifulde kommentarer / forslag til denne artikel.

Anbefalet læsning

^