Structural Testing Tutorial - Hva er strukturell testing

structural testing tutorial what is structural testing

Denne omfattende strukturelle testveiledningen forklarer hva som er strukturell testing, dens typer, hva er kontrollstrømningstest og kontrollflytdiagram, dekningsnivåer osv .:

Et raskt Google-søk på noen av de dyreste programvarefeilene gjorde at tankene mine trakk seg - 500 milliarder dollar. Ja, det er så dyrt en feil kan bli. Å lese alt relatert til tapte liv i transport- og helseindustrien på grunn av en programvarefeil kan også være forferdelig.

Mens kodefeil ikke alltid er så ekstrem der de innebærer tap av store mengder penger og liv, er den eneste viktige takeawayen vi prøver å formidle, at man ikke kan overse testing.

Når testing utføres ofte i hele SDLC, lar det oss fange feil som vil trenge mye mer tid å fikse etter levering av produktet.

Det som er viktig er programvaretestetypene vi velger. Det er flere av disse, inkludert funksjonell, strukturell og endringsbasert testing.

Denne opplæringen forklarer også strukturelle testtyper. Lær hvordan du gjør mutasjonstesting, skivebasert testing, datastrømstesting i detalj med eksempler og forklaringer.

Hva du vil lære:

• Hvorfor er programvaretesting viktig
  • Strukturell testing mot andre testtyper
  • Hva strukturell testing ikke er
• Hva er strukturell testing
  • Hvordan utføre strukturell testing
  • Kontroll av strømningstesting
    • Kontrollflytdiagram
    • Kontroller strømforutsetninger
  • Dekningsnivåer i kontrollflyter
    • # 1) Dekningsdekning
    • # 2) Grendekning
    • # 3) Banedekning
• Strukturelle testtyper
  • Mutasjonstesting
  • Skivebasert testing
    • Hvordan gjøre oppskæring
    • Skivebaserte testtyper
    • # 1) Dynamisk skivebasert testing
    • # 2) Statisk skivebasert testing
  • Dataflytstesting
    • Data Flow Anomalies
    • Dataflytstestprosess
  • Testtyper for datastrøm
• Fordeler og ulemper ved strukturell testing
• Best Practices for strukturell testing
  • Vanlige spørsmål for strukturbasert testing
• Konklusjon
  • Anbefalt lesing

Hvorfor er programvaretesting viktig

I tillegg til å spare penger, og unngå katastrofer som tilfellene nevnt ovenfor, er det flere andre grunner til å rettferdiggjøre viktigheten av testing.

Nedenfor er noen grunner:

# 1) For å sikre at de angitte kravene blir oppfylt før du begynner å bygge et prosjekt. Interessenter (for eksempel utviklere og klienter) må bli enige om alle aspekter av løsningen / produktet / programvaren som kreves for å bygge et prosjekt.

Testing innebærer å verifisere om programvarekravene er oppfylt. Utvikleren eller selskapet som er involvert i å bygge løsningen får også et godt rykte for å designe en slik høykvalitetsløsning som drives av eclat-kode.

# 2) Det verifiserer at kodefunksjonen fungerer som forutsatt. Testing innebærer også å verifisere programvarens funksjonalitet, og i tilfelle feil, bør den løses i de tidlige fasene av SDLC (Software Development Life Cycle).

# 3) Den sjekker for ytelse: For eksempel for å identifisere den totale tiden som har gått mens du kjører kode. Hvis vi bruker flere For løkker i koden vår vil det ta lang tid å få den tiltenkte produksjonen, og kan til og med timeout noen ganger.

# 4) Det hjelper å oppnå en bedre brukeropplevelse. Brukere vil ikke like å bruke programvare som ikke fungerer, er feil eller er for treg. Brukere vil sannsynligvis bli utålmodige og slippe av med programvaren. Testing gir oss et bedre skudd for å sikre at brukerne enkelt kan bruke produktene våre.

# 5) Det sjekker for skalerbarhet. En utvikler bør sikte på å bygge programvare som kan skaleres.

# 6) Det sjekker for sårbarheter i koden. Testing gir oss muligheten til å se etter sikkerhetsproblemer, For eksempel, kode som kan gå på akkord PII (Personlig identifiserbar informasjon) som har høy prioritet for GDPR.

I denne artikkelen skal vi fokusere på en type testing, dvs. Strukturell testing . Som navnet antyder, har det å gjøre med strukturen til koden. Dette er annerledes enn det vi hadde nevnt tidligere, at testing hjelper til med å bestemme aspekter som kodeytelse, funksjonalitet og sikkerhet.

Strukturell testing mot andre testtyper

Det er mange typer programvaretesting. Imidlertid, den STOPPE (International Software Testing Qualifications Board), definerer fire hovedtyper for programvaretesting, nemlig

• Funksjonell
• Ikke-funksjonell
• Strukturell
• Endringsbasert

Forskjellene kan forklares som nedenfor:

Funksjonell testing: Dette innebærer å verifisere programvarens funksjonalitet mot de angitte kravene. Testdata brukes som input. Vi sjekker også at produksjonen som er gitt er som forventet.

Ikke-funksjonell testing : Dette innebærer en testprosess for å analysere hvor godt programvaren fungerer, for eksempel, antall brukere den kan håndtere samtidig.

Strukturell testing: Denne typen testing er basert på kodens struktur. For eksempel, hvis en kode er ment å beregne gjennomsnittet av partall i en matrise, vil strukturbasert testing være interessert i ‘trinnene som fører til at gjennomsnittet blir beregnet’, snarere enn om den endelige utgangen er en riktig numerisk verdi.

Anta at vi må sjekke om vi har definert koden som skiller partall fra oddetall. Vi kan ha en betinget uttalelse her, som hvis et matriseelement er delbart med to uten en rest, hvis (arr (i)% 2 === 0) da kan tallet sies som et partall.

forskjell mellom blackbox og whitebox testing

Strukturell testing utføres av de samme personene som skriver koden slik de forstår den best.

Endringsbasert testing : Dette innebærer å teste effekten av å gjøre endringer i koden og deretter sikre at de endringene som er gjort er implementert. Det sørger også for at endringene i koden ikke bryter den.

Hva strukturell testing ikke er

Vi har nevnt tidligere at strukturbasert testing refererer til strukturen til koden. Merk at vi håndterer den faktiske koden her. Vi sjekker ikke opp mot kravene eller tester innganger mot forventede utganger. Vi er ikke opptatt av funksjonalitet, brukeropplevelse eller ytelse på dette tidspunktet.

Hva er strukturell testing

Strukturbasert testing kan derfor defineres som en type programvaretesting som tester kodens struktur og tiltenkte strømmer. For eksempel, verifisere den faktiske koden for aspekter som riktig implementering av betingede utsagn, og om hver setning i koden er riktig utført. Det er også kjent som strukturbasert testing.

For å utføre denne typen testing, må vi forstå koden grundig. Dette er grunnen til at denne testingen vanligvis gjøres av utviklerne som skrev koden slik de forstår den best.

Hvordan utføre strukturell testing

For å teste forskjellige aspekter av koden, må vi først forstå kontrollflytene.

Kontroll av strømningstesting

Dette stammer tester fra kodens kontrollflyter (rekkefølgen som setninger, funksjoner og forskjellige aspekter av koden er implementert).

Kontroll flyt prosess:

Kontrollflytdiagram

Kontrollflytprosessen begynner med å lage en visuell fremstilling av forskjellige seksjoner av koden som hjelper oss med å definere banene som kan følges under utførelsen.

Disse visuelle representasjonene er kjent som Control Flow Graphs (CFGs) og har flere komponenter som noder, kanter, baner, veikryss og beslutningspunkter. Grafen kan opprettes manuelt eller automatisk, der programvare brukes til å trekke ut grafen fra kildekoden.

La oss se på disse komponentene nedenfor:

# 1) Prosessblokk

Denne delen brukes til å representere en del av koden som utføres sekvensielt. Dette betyr at den blir utført på samme måte hver gang, og det er ingen beslutninger eller ‘forgrening’ som må gjøres. Den består av noder med en inn- og utgangsbane.

Eksempel på en prosessblokk:

(bilde kilde )

Prosessblokken er ikke en vesentlig del av kontrollflyten, og må derfor testes bare en gang.

# 2) Avgjørelsespoeng

Dette er noen viktige komponenter i kodens kontrollflyt. Innenfor disse nodene blir avgjørelser tatt. Dette gjøres vanligvis via sammenligning og kontrollflyten endres, avhengig av avgjørelsen. Denne delen av CFG består av en node med minst 2 utganger.

Beslutningen som tas her, kan være betingede uttalelser som if-else-uttalelser (som har to mulige utdata) og saksuttalelser (som kan ha mer enn to utganger).

(bilde kilde )

I diagrammet ovenfor er det et avgjørelsespunkt (fra den betingede 'alder = 18') som blir fulgt av 'ja' eller 'nei' alternativer.

# 3) Krysspunkter

Fra diagrammet ovenfor kan vi enkelt identifisere krysspunkter for hvor avgjørelsespunktene blir med. Krysspunkter kan ha mange inngangsstier, men kan bare ha én utfartsbane.

Beste fremgangsmåter for kontrollflytdiagrammer:

Det er noen få ting å merke seg når du lager kontrollflytgrafer:

• Prøv så mye som mulig for å holde CFG enkel. Vi kan gjøre dette ved å kombinere deler som kan betraktes som 'mindre signifikante', for eksempel, prosessblokker.
• Sørg for at det bare fattes en beslutning på avgjørelsespunktene. I mer komplekse CFG er det ‘konsekvenser’ som kommer etter at avgjørelsen er tatt. I eksemplet vårt ovenfor kan vi også legge til at hvis en person er 18 år eller eldre, er de kvalifisert og må betale for en billett. Hvis de ikke er det, er inngangen gratis. Beslutningen om 'annet' må 'hoppe over' noen noder, og alle disse trinnene må vises i CFG.

Når vi har definert CFG, er det nå på tide å gå videre til neste trinn i kontrollflytprosessen, dvs. definere i hvilken grad vi skal teste koden.

Definere hvor mye du skal teste:

Hvor mye av kildekoden skal testes? Bør vi teste hver mulig vei? Å prøve å dekke alle veier i testene våre er praktisk talt umulig. Vi må finne en mellomvei for å bestemme hvor mye testing vi kan gjøre.

Hvis vi sier at vi tar sikte på å teste 50% av koden vår, kan dette bety at vi vil definere alle kjørbare kodeuttalelser og sikte på å teste minst halvparten av dem. Spørsmålet som oppstår her er imidlertid 'trenger vi da å definere alle mulige kjørbare baner?'

Dette igjen kan være praktisk umulig. En bedre tilnærming kan være å sikte på å teste 50% av banene vi kan identifisere i hver del av koden.

Det er forskjellige nivåer av dekning, nemlig uttalelse, gren og banedekning. Vi vil kort se på dem senere.

Opprette testsaker:

Det neste trinnet er å lage testsaker som vi skal bruke. Testtilfellene i strukturbasert testing er basert på følgende faktorer:

• De kjørbare uttalelsene.
• ‘Beslutningene’ som må tas.
• De mulige stiene som kan følges.
• Vilkårene som må oppfylles (disse kan være flere eller boolske).

Ovennevnte faktorer gir oss en ide om hvilke typer testtilfeller vi trenger å lage. Vi kan også bruke et strukturelt testgenereringsverktøy. Hvis koden vår er i C-programmeringsspråket, kan vi bruke PathCrawler til å generere testkode. Et annet verktøy vi kan bruke er fMBT.

Gjennomføring av prøvesakene:

Her får vi kjøre testene. Vi kan legge inn input eller data for å sjekke hvordan koden utfører det, og deretter verifisere om vi får de forventede resultatene. For eksempel, skriv inn en matrise i en funksjonsanrop for å observere at resultatene vi får etter å ha gått gjennom den, eller for å sjekke om beslutningspunkter tar de riktige beslutningene.

Analysere resultatene:

I denne delen er alt vi gjør å sjekke om vi får de riktige resultatene etter utførelse. For eksempel, hvis vi går inn i en matrise der alle verdiene er over 18, bør vi ha alle avgjørelsespunktene som resulterer i 'kvalifisert'.

Kontroller strømforutsetninger

Det er viktig å merke seg at det er noen forutsetninger som blir gjort for å utføre kontrollflytstesting. Disse inkluderer:

• De eneste feilene som er til stede er de som kan påvirke kontrollflyten.
• Alle variabler, funksjoner og elementer er nøyaktig definert.

Dekningsnivåer i kontrollflyter

Som vi har nevnt tidligere, er det forskjellige nivåer av dekning i kontrollflytprøving.

La oss se på dem kort.

# 1) Dekningsdekning

I strukturell testing spiller kjørbare kodeuttalelser en viktig rolle når det gjelder å bestemme metodene for å designe testene.

Vi tar sikte på å oppnå 100% dekning, noe som betyr at hver kjørbar uttalelse er testet minst en gang. Jo høyere dekning, desto mindre er det sannsynligheten for at du går glipp av feil og feil.

Det kreves å bruke testsaker her. Dataene vi trenger for å være, er å sikre at hver kjørbar setning i en kodeblokk blir utført minst en gang.

# 2) Grendekning

Dette dekningsnivået innebærer å teste poengene i CFG-grenene (der avgjørelser blir tatt). Resultatene er boolske. Selv om en bryteruttalelse brukes og det er flere utfall, er hver sakblokk egentlig en sammenligning av et par verdier.

Akkurat som med uttalelsesdekning, bør vi sikte på 100% filialdekning. For å oppnå dette må vi teste hvert utfall på hvert beslutningsnivå minst en gang. Siden vi har å gjøre med boolske resultater, bør vi sikte på å kjøre minst to tester per seksjon av koden.

# 3) Banedekning

Dette dekningsnivået er grundigere sammenlignet med beslutnings- og uttalelsesdekning. Målet her er å 'oppdage' alle mulige stier og teste dem minst en gang. Dette kan være ekstremt tidkrevende. Det kan imidlertid hjelpe til med å oppdage feil eller feil i koden vår, eller til og med aspekter som vi trenger å definere, for eksempel, brukerinngang.

Strukturelle testtyper

(bilde kilde )

Mutasjonstesting

Mutasjonstesting er en feilbasert testteknikk der forskjellige varianter av en programvare blir testet mot testdatasettet.

>> Se denne veiledningen for en grundig titt på Mutasjonstesting.

som ikke er et eksempel på data mining?

Skivebasert testing

Slice Based Testing (SBT) kan defineres som en teknikk for testing av programvare som er basert på skiver - kjørbare deler av programmet eller grupper av utsagn som påvirker noen verdier på bestemte interessepunkter i programmet, for eksempel, deler der variabler er definert eller utdata fra en gruppe utsagn.

Hvordan gjøre oppskæring

Skjæreeksempel i SBT: Kode for å skrive ut partall og oddetall (Python)

Det er to måter å se på et stykke: Ved å følge banen til en variabel av interesse eller den delen av koden som påvirker utdataene.

I vårt eksempel, hvis vi ser på oddetallsutgangen, kan vi spore den delen av koden som fører oss til denne utgangen.

I skivekriteriene gitt av Mark Weiser (som introduserte SBT), defineres et stykke ved hjelp av denne formelen: S (v, n) , hvor, v refererer til den aktuelle variabelen ( for eksempel, der en variabel er definert), og n er interesseanmeldelsen ( for eksempel, hvor produksjonen er gitt), og S står for stykket.

I eksemplet ovenfor, for å få stykket, starter vi fra produksjonen vår på linje 10, som blir vår n . Vår variabel er hvor .

Så våre skivekriterier er:

Vår bekymring er uttalelsene som fører oss til produksjonen.

Disse er:
10,9,8,4,3,1

Så, vår del i denne koden er:

Skivebaserte testtyper

Det er to typer SBT: Statisk og Dynamisk

# 1) Dynamisk skivebasert testing

SBT-eksemplet forklart ovenfor hvor vi så på utsagnene som påvirker utskriften av oddetallene, er dynamisk SBT. Vår bekymring er veldig spesifikk. Vi får bare fokusere på det som direkte påvirker den spesielle produksjonen.

Vi utfører koden og bruker testdata for å sikre at den fungerer som den skal. Vi kan øke rekkevidden til området (1,50), for eksempel, for å se om den fremdeles bare genererer oddetall. Dynamisk SBT er også kjent som valideringstesting.

# 2) StatiskSkivebasert testing

I motsetning til Dynamic SBT, fokuserer statisk testing på en bestemt variabel. Hvis vi tenker på produksjonen vår i eksemplet ovenfor som hvor , kan vi spore skiven som påvirker den som 10,9,8,7,6,5,4,3,2,1

Det er i utgangspunktet hele kodeblokken! Her bekrefter vi at koden er riktig når det gjelder syntaks og krav, og vi utfører den ikke. Statisk SBT er også kjent som verifiseringstesting.

Det er viktig å merke seg at dynamisk SBT er 'mindre' sammenlignet med dets statiske motstykke. Det er også mer spesifikt.

Slice Based Testing Best Practices / Guidelines

Skivekriterier bør bestemmes av:

• Uttalelser der verdier er definert eller tildelt verdi, samt omdelt verdi.
• Uttalelser hvor verdier mottas utenfor programmet, for eksempel, via brukerinngang.
• Uttalelser som skriver ut output / return output.
• Programmets siste uttalelse, for eksempel, en funksjonsanrop som kan definere verdier, eller gi verdier til argumenter

Fordelene med skivebasert testing inkluderer:

• Siden vi i SBT bare arbeider med spesifikke interesseområder, gjør det det enklere å effektivt generere testsuiter.
• Banen er definert av avhengigheter i koden, noe som er bedre enn å bruke stidekning.
• Med SBT er det lettere å finne feil i kildekoden.

Ulemper med skivebasert testing inkluderer:

• Hvis vi bruker dynamisk testing når vi tester en stor kodebase, trenger vi mange beregningsressurser.
• Hvis vi bruker statisk testing, kan vi gå glipp av feil.

Dataflytstesting

Dataflytstesting kan defineres som en programvaretesteteknikk som er basert på dataverdier og deres bruk i et program. Den verifiserer at dataverdiene har blitt brukt riktig, og at de genererer de riktige resultatene. Dataflytstesting hjelper med å spore avhengighetene mellom dataverdiene på en bestemt kjøringsbane.

Data Flow Anomalies

Dataflytanomalier er ganske enkelt feil i et program. De er klassifisert i henholdsvis type 1, 2 og 3.

La oss fordype oss i dem nedenfor:

Type 1: En variabel er definert og en verdi tildeles den to ganger.

Eksempelkode: Python

Lst_1 er definert, og to forskjellige verdier er tilordnet den. Den første verdien blir rett og slett ignorert. Type 1-avvik fører ikke til at programmet mislykkes.

Type 2: Verdien til en variabel brukes eller refereres før den defineres.

Eksempelkode: Python

Sløyfen ovenfor har ingen verdier å gjenta. Type 2 avvik fører til at programmet mislykkes.

Type 3: A dataverdien genereres, men brukes den aldri.

Eksempelkode: Python

Variabelen lst_2 har ikke blitt referert til. Type 3-avvik kan ikke forårsake programfeil.

Dataflytstestprosess

For å definere avhengighetene mellom dataverdiene, må vi definere de forskjellige banene som kan følges i et program. For å effektivt gjøre dette, må vi låne fra en annen strukturell testingstype kjent som kontroll-flyt-testing .

Trinn 1) Tegn en graf for kontrollflyt

Vi må tegne en kontrollflytegraf, som er en grafisk fremstilling av banene vi kan følge i programmet vårt.

Eksempelkode: Python

I ovennevnte kodeeksempel skal et medlem få rabatt hvis de inviterer en besøkende.

Kontrollflytgraf (CFG):

Steg 2) Utforsk definisjonen og bruken av variabler og dataverdier.

En variabel i et program er enten definert eller brukt. I CFG har vi variabler ved hver node. Hver node er navngitt i henhold til variabeltypen den huser. Hvis en variabel er definert på en bestemt node, oppretter den en definerende node. Hvis en variabel brukes i en node, oppretter den en bruksnode.

Hvis vi vurderer den variable kostnaden i CFG, er dette definerings- og bruksnodene:

Trinn 3) Definer definisjonsbruk.

Det er to typer definisjonsbruk: du stier og likestier. du-stier er definisjonsstier som begynner med en definisjonsnode og slutter med en bruksnode. Dette er tilfelle for stien med referanse til de variable kostnadene ovenfor.

Et eksempel på en likestrømsvei, en klar avgjørelsesbane, er banen med hensyn til regningsvariabelen som nedenfor:

DC-bane har mer enn en definisjonsnode, selv om den fremdeles slutter ved en bruksnode.

Trinn 4) Lag testpakken.

Dette legger til innspill. Merk at vi må ha en annen testpakke for hver variabel. Testpakken vil hjelpe oss med å identifisere dataflytanomalier.

Testtyper for datastrøm

Det er to typer - Statisk og dynamisk .

Statisk betyr at vi går gjennom koden og CFG for å identifisere dataavvik, uten å utføre den. Dynamisk betyr at vi faktisk identifiserer de spesifikke banene og deretter lager testpakker for å teste den i et forsøk på å ‘fange’ anomalier som vi kanskje har gått glipp av under statisk testing.

Fordeler og ulemper ved datastrømstesting:

• Dataflytstesting er ideell for å identifisere dataflytanomalier, noe som gjør den til en veldig effektiv strukturell testmetode.
• Dens ulempe er at det er behov for å være godt kjent med språket som brukes til å skrive koden for å bruke dataflytstesting. Det er også tidkrevende.

Fordeler og ulemper ved strukturell testing

La oss nå finne årsakene til at strukturell testing er en god tilnærming, og også utforske noen av dens ulemper.

Fordeler:

• Tillater grundig kodetesting, noe som resulterer i minimale feil. Strukturbasert testing gir rom for at programvare kan testes grundig. De forskjellige dekningsnivåene - uttalelse for uttalelse, hvert avgjørelsespunkt og vei har som mål å oppnå 100% dekning som reduserer sjansen for at feil blir uoppdaget.
• Evnen til å automatisere . Det er flere verktøy vi kan bruke til å automatisere testing. Dette vil hjelpe oss med å oppnå maksimal kodedekning og innen kortere tid sammenlignet med å gjøre testene manuelt.
• Det resulterer i høyere kvalitetskode . Utviklerne har en sjanse til å studere kodens struktur og implementering og fikse eventuelle feil, samt forbedre disse aspektene. Det lar oss holde den flotte strukturen i tankene når vi skriver påfølgende deler av koden eller implementerer gjenværende funksjoner.
• Det kan gjøres gjennom hver fase av SDLC - Strukturell testing kan gjøres i hver fase av SDLC uten å vente på at utviklingen skal fullføres 100%. Dette gjør det enkelt å identifisere feil i tidlig fase, og sparer dermed mye tid sammenlignet med testing etter at utviklingen er fullført.
• Det hjelper å bli kvitt død kode . Dette kan sees på som 'ekstra' eller unødvendig kode, for eksempel, kode som vil beregne et resultat, men som aldri bruker det i noen av de følgende beregningene.
• Effektivitet - Siden utviklerne som skriver koden er de samme som tester den, er det ikke nødvendig å involvere andre mennesker som QAer.

Ulemper:

• Utviklerne som utfører strukturbasert testing, må ha en grundig forståelse av språket . Andre utviklere og kvalitetssikringsmenn som ikke er godt kjent med språket, kan ikke hjelpe med testing.
• Det kan bli ganske dyrt når det gjelder tid og penger . Det kreves mye tid og ressurser for å gjøre testing effektivt.
• Det medfører forsinkelser i funksjoner . Dette er fordi utviklere blir hentet fra å bygge programvare for å gjøre testing.
• Skalering er et problem, spesielt der store applikasjoner er involvert . En stor applikasjon tilsvarer et for høyt antall ruter å dekke. Å oppnå 100% dekning blir umulig.
• Det kan være savnede saker og ruter , for eksempel, i et tilfelle der funksjonene ikke er fullt utviklet eller ennå ikke skal utvikles. Dette betyr at det må kombineres med andre testtyper som kravtesting (hvor vi sjekker opp mot de spesifiserte funksjonene som måtte bygges).

Best Practices for strukturell testing

Noen av faktorene som krever oppmerksomhet når du utfører strukturbasert testing er som følger:

• Merk testene tydelig . Hvis noen andre trenger å kjøre testene, må de være i stand til å finne dem enkelt.
• Før du forbedrer koden, dvs. ved å omforme den og optimalisere den til bruk i forskjellige miljøer, må du sørge for at dens struktur og flyt er ideell.
• Kjør tester hver for seg . På denne måten er det enkelt å identifisere feil og fikse dem. På den annen side er det mindre sannsynlig at vi savner feil eller stier som et resultat av overlapp i kodeseksjoner, blokker eller stier.
• Generer tester før du gjør endringer . Testene kreves for å kjøre som forventet. På denne måten, hvis noe går i stykker, er det lett å spore og fikse problemet.
• Hold testene for hver seksjon eller kodeblokk atskilt . På denne måten, hvis det er endringer på linjen, trenger vi ikke endre mange tester.
• Løs feil før du går videre med testing . Hvis vi identifiserer feil, er det bedre å fikse dem før vi fortsetter å teste neste del eller kodeblokk.
• Aldri hopp over strukturell testing med antagelsen om at en kvalitetssikring vil 'fortsatt gjøre testing uansett'. Selv om feilene først kan virke ubetydelige, kumulativt, kan de resultere i buggy-kode som aldri kan oppnå det tiltenkte formålet.

Vanlige spørsmål for strukturbasert testing

Her vil vi utforske de ofte stilte spørsmålene når det gjelder strukturbasert testing.

Q # 1) Hva er forskjellen mellom funksjonstesting og strukturell testing?

Svar: Funksjonstesting er en type programvaretesting basert på fastsatte krav i SRS (Software Requirements Specifications). Det gjøres vanligvis i et forsøk på å finne forskjeller mellom spesifikasjonene i SRS og hvordan koden fungerer. Strukturell testing er basert på kodens interne struktur og implementering. Det kreves en grundig forståelse av koden.

Q # 2) Hva er typene strukturelle tester?

forskjell mellom testplan og testtilfelle

Svar: The typer inkluderer:

• Dataflyt testing
• Mutasjonstesting
• Kontroll av flytesting
• Skivebasert testing

Q # 3) Hva er et strukturelt testeksempel?

Svar: Her er et eksempel som viser utsagnsdekning:

Hvor mye dekning vi får, avhenger av testdataene vi gir som input (om de oppfyller summen> 0 betingelser).

Spørsmål nr. 4) Hva er forskjellen mellom datastrømstesting og kontrollflyttesting?

Svar: Både datastrømstesting og kontrollflytprøving bruker kontrollflytdiagrammer. Den eneste forskjellen er at i kontrollflyt-testing fokuserer vi på banene som genereres fra koden, mens vi i datastrømstesting fokuserer på dataverdiene, deres definisjon og bruk innenfor banene som er identifisert i et program.

Sp # 5) Hva brukes dataflytstesting til?

Svar: Dataflytstesting er ideell for å identifisere avvik i bruken av dataverdier i baner i en kontrollflytgraf, for eksempel, en variabel som er tildelt verdi to ganger, en variabel som er definert og ikke brukt, eller en variabel som har blitt brukt eller referert til og ikke definert.

Sp # 6) Hva er forskjellen mellom kutting og terning i programvaretesting?

Svar: Slicing betyr å fokusere på spesielle interessetilkendegivelser i et program og ignorere resten. Dicing er når vi identifiserer et stykke som har feil input, og deretter ytterligere skjærer det for å spore riktig oppførsel.

Q # 7) Hva er forskjellen mellom mutasjonstesting og kodedekning?

Svar: I mutasjonstesting vurderer vi antall drepte mutanter som en prosentandel av total mutanter. Kodedekning er ganske enkelt mengden kode som er testet i et program.

Konklusjon

I denne opplæringen så vi på strukturelle tester i dybden - hva det er, hva det ikke er, hvordan vi skal gjøre det, dekningstyper, fordeler og ulemper, beste praksis og til og med noen vanlige spørsmål angående denne programvaretestetypen.

Det er fortsatt så mye mer vi kan lære om strukturbasert testing. I fremtidige opplæringsprogrammer vil vi utforske kodedekning (uttalelse, beslutning, gren og bane), strukturelle testtyper (mutasjon, dataflyt og skivebasert), og til og med verktøyene vi kan bruke til å automatisere disse testprosessene.

Det er viktig å merke seg at det ikke er noen programtesttype eller tilnærming som er 100% effektiv. Det anbefales alltid å kombinere forskjellige testtyper og tilnærminger.

For eksempel, strukturell testing kompletteres sterkt med kravtesting, da det kan være funksjoner som kanskje ikke ble utviklet på det tidspunktet da strukturbasert testing ble utført.

Strukturelle testteknikker er basert på feilene som menneskelige programmerere gjør når de skriver kode. Antagelsen er at programmereren er ekspert og vet hva han eller hun koder, men tar feil fra tid til annen.

De forskjellige strukturelle testtypene vi har sett på - mutasjonstesting, skivebasert testing og datastrømstesting kan spores tilbake til feil som å bruke feil operator (mutasjonstesting) eller referere til en variabel før du bruker den (datastrømstesting) .

Anbefalt lesing

• Destruktiv testing og ikke-destruktiv testing
• Funksjonstesting mot ikke-funksjonell testing
• Hva er feilbasert testteknikk?
• Soak Testing Tutorial - Hva er Soak Testing
• SOA Testing Tutorial: Testing Methodology For a SOA Architecture Model
• Lastetesting med HP LoadRunner-opplæringsprogrammer
• Hva er gammatesting? Den siste testfasen
• DevOps Testing Tutorial: Hvordan DevOps vil påvirke QA-testing?
• Hva er Compliance Testing (Conformance testing)?