Stitesting og basisstitesting i programvare med eksempler

Hva er banetesting i programvaretesting?

Path testing er en strukturell testmetode som innebærer å bruke kildekoden til et program for å finne alle mulige kjørbare stier. Det hjelper å finne alle feil som ligger innenfor et stykke kode. Denne metoden er utformet for å kjøre hele eller valgt bane gjennom et dataprogram.

Ethvert ikke-trivielt program inneholder mange mulige utførelsesbaner. Det er både vanskelig og tidkrevende å teste hver og en av dem, og de fleste av dem overlapper hverandre. Basisbanetesting reduserer denne redundansen ved å identifisere det minste settet med baner som fortsatt utøver hver setning og hver gren minst én gang.

Basis Path Testing i Software Engineering

Grunnleggende banetesting i programvareteknikk er en Hvit Box Testing metode der testtilfeller defineres basert på flyter eller logiske veier som kan tas gjennom programmet. Målet med basisbanetesting er å definere antall uavhengige stier, slik at antall testtilfeller som trengs kan defineres eksplisitt for å maksimere testdekningen.

In software engineering, Basisbanetesting innebærer utførelse av alle mulige blokker i et program og oppnår maksimal banedekning med minst antall testtilfeller. Det er en hybrid metode for grentesting og banetestingsmetoder.

Et enkelt eksempel gjør ideen konkret.

Flytgrafen ovenfor inneholder betingelsessetninger, slik at kontrollen kan nå utgangen via mer enn én rute. Tre uavhengige stier er nødvendig for å dekke den:

• Sti 1: 1,2,3,5,6, 7
• Sti 2: 1,2,4,5,6, 7
• Sti 3: 1, 6, 7

Hvordan tegne en kontrollflytgraf

Hvert trinn i testing av basisbanen avhenger av kontrollflytgrafen, så det er verdt å være presis om hvordan en er bygd opp.

• node: en sekvens av utsagn som alltid utføres sammen, tegnet som en sirkel. En rekke utsagn uten gren kollapser til en enkelt node.
• Kant: en overføring av kontroll fra én node til den neste, tegnet som en pil. Kanter er den eneste måten kontroll beveger seg på.
• Predikatnode: en node som inneholder en betingelse, med to eller flere kanter som forlater den. Disse styrer kompleksitetstellingen.
• Region: et område avgrenset av kanter og noder. Antall regioner pluss én er også lik den syklomatiske kompleksiteten.

Tenk deg en kort modul med to avgjørelser:

if (a > b) {          // node 1, predicate
    max = a;          // node 2
} else {
    max = b;          // node 3
}
if (max > limit) {    // node 4, predicate
    alert();          // node 5
}
return max;           // node 6

Grafen har 6 noder og 6 kanter, noe som gir V(G) = 6 – 6 + 2 = 2 ifølge kantformelen. Predikattellingen gir samme svar raskere: 2 avgjørelser pluss 1 er lik 3 uavhengige baner gjennom de to grenene tatt sammen. Bruk den formen du kan beregne pålitelig, og kryssjekk med den andre.

To regler som forhindrer de fleste feil. Først en sammensatt tilstand som hvis (x > 0 og y > 0) teller som to predikatnoder, ikke én, fordi kortslutningen skaper en andre beslutning. For det andre bidrar en løkke med én predikatnode uavhengig av hvor mange ganger den itererer.

Fremgangsmåte for testing av basisbane

De grunnleggende trinnene involvert i basisbanetesting inkluderer

• Tegn en kontrollgraf (for å bestemme forskjellige programbaner)
• Beregn Syklomatisk kompleksitet (beregninger for å bestemme antall uavhengige stier)
• Finn et basissett med stier
• Generere test tilfeller å utøve hver sti

Fordeler og begrensninger ved basisbanetesting

Fordeler med basisbanetesting

• Det bidrar til å redusere de overflødige testene
• Den fokuserer oppmerksomheten på programlogikk
• Den erstatter vilkårlig utvalg av testtilfeller med et analytisk grunnlag
• Testtilfeller som utøver basissett vil utføre hver setning i et program minst én gang

Begrensninger ved testing av basisstier

• Den kan ikke finne manglende kode. Et krav som aldri ble implementert har ingen bane, så ingen test vil bli generert for det. Basisbanetesting må kobles til kravbasert testing.
• Antall stier vokser raskt. Nestede løkker og sammensatte betingelser øker kompleksiteten raskt, og en modul med V(G) over 20 blir upraktisk å dekke på denne måten.
• Dekning er ikke korrekthet. Å kjøre en sti beviser at koden kjører, ikke at den produserer riktig svar. Hver test trenger fortsatt en meningsfull påstand.
• Dataavhengige stier. Noen stier er bare tilgjengelige med spesifikke inndatakombinasjoner som kan være vanskelige eller umulige å konstruere.

Spørsmål og svar