structural testing tutorial what is structural testing
Denne omfattende strukturelle testvejledning forklarer, hvad der er strukturel testning, dens typer, hvad der er Control Flow Testing og Control Flow Graph, dækningsniveauer osv .:
En hurtig Google-søgning på nogle af de dyreste softwarefejl lod mig tænke - 500 milliarder dollars. Ja, det er så dyrt en fejl kan blive. At læse noget relateret til mistede liv i transport- og sundhedsindustrien på grund af en softwarefejl kan også være skræmmende.
Mens kodefejl ikke altid er så ekstrem, hvor de involverer tab af store mængder penge og liv, er den eneste vigtige takeaway her, vi prøver at formidle, at man ikke kan overse test.
Når test udføres ofte i hele SDLC'en, giver det os mulighed for at fange bugs, der har brug for meget mere tid til at rette efter forsendelsen af produktet.
Hvad der er vigtigt er de softwaretesttyper, vi vælger. Der er flere af disse, herunder funktionel, strukturel og ændringsbaseret test.
Denne tutorial forklarer også strukturelle testtyper. Lær hvordan man udfører mutationstest, skivebaseret testning, dataflowtestning i detaljer med eksempler og forklaringer.
Hvad du vil lære:
- Hvorfor er softwaretest vigtig
- Hvad er strukturel testning?
- Strukturelle testtyper
- Fordele og ulemper ved strukturel testning
- Best Practices for strukturel test
- Konklusion
Hvorfor er softwaretest vigtig
Ud over at spare penge og undgå katastrofer som de ovennævnte tilfælde, er der flere andre grunde til at retfærdiggøre vigtigheden af at teste.
Nedenfor er nogle årsager:
# 1) For at sikre, at de fastsatte krav er opfyldt inden du begynder at bygge et projekt. Interessenter (for eksempel udviklere og klienter) skal være enige om alle aspekter af løsningen / produktet / softwaren, der er nødvendige for at opbygge et projekt.
Test involverer at kontrollere, om softwarekravene er opfyldt. Udvikleren eller firmaet, der er involveret i opbygningen af løsningen, får også et godt ry for at designe en sådan løsning af høj kvalitet, der drives af eclat-kode.
# 2) Det verificerer, at kodefunktionen fungerer efter hensigten. Test involverer også verificering af softwarens funktionalitet, og i tilfælde af fejl skal det rettes i de tidlige faser af SDLC (Software Development Life Cycle).
# 3) Det kontrollerer for ydeevne: For eksempel for at identificere den samlede forløbne tid, mens koden køres. Hvis vi bruger flere Til sløjfer i vores kode tager det lang tid at få den tilsigtede output og kan endda timeout nogle gange.
# 4) Det hjælper med at opnå en bedre brugeroplevelse. Brugere kan ikke lide at bruge software, der fungerer forkert, buggy eller 'for langsom'. Brugere bliver sandsynligvis utålmodige og afleverer ved hjælp af softwaren. Test giver os et bedre skud på at sikre, at brugerne let kan bruge vores produkter.
# 5) Det kontrollerer for skalerbarhed. En udvikler skal sigte mod at opbygge software, der kan skaleres.
# 6) Det kontrollerer for sårbarheder i koden. Test giver os mulighed for at se efter sikkerhedssårbarheder, For eksempel, kode, der kan gå på kompromis PII (Personligt identificerbare oplysninger), som har høj prioritet for GDPR.
I denne artikel vil vi fokusere på en type test, dvs. Strukturel testning . Som navnet antyder, har det at gøre med kodens struktur. Dette er anderledes end det, vi tidligere har nævnt, at test hjælper med at bestemme aspekter som kodeydelse, funktionalitet og sikkerhed.
Strukturel testning mod andre testtyper
Der er mange typer softwaretest. Men den HOLD OP (International Software Testing Qualifications Board) definerer 4 store softwaretesttyper, nemlig
- Funktionel
- Ikke-funktionel
- Strukturel
- Ændringsbaseret
Forskellene kan forklares som nedenfor:
Funktionel test: Dette indebærer verifikation af softwarens funktionalitet i forhold til de fastsatte krav. Testdata bruges som input. Vi kontrollerer også, at den angivne output er som forventet.
Ikke-funktionel test : Dette involverer en testproces for at analysere, hvor godt softwaren fungerer, for eksempel, antallet af brugere, den kan håndtere samtidigt.
Strukturel testning: Denne type test er baseret på kodens struktur. For eksempel, hvis en kode er beregnet til at beregne gennemsnittet af lige tal i en matrix, ville strukturbaseret test være interesseret i 'trinene, der fører til, at gennemsnittet beregnes', snarere end om den endelige output er en korrekt numerisk værdi.
Antag, at vi skal kontrollere, om vi har defineret den kode, der adskiller lige tal fra ulige tal. Vi kan have en betinget erklæring her, som hvis et array-element kan deles med to uden en rest, hvis (arr (i)% 2 === 0) så kan tallet siges som et lige tal.
Strukturel test udføres af de samme mennesker, der skriver koden, som de forstår den bedst.
Ændringsbaseret test : Dette indebærer at teste virkningerne af at foretage ændringer i koden og derefter sikre, at de foretagne ændringer er blevet implementeret. Det sikrer også, at ændringer af koden ikke bryder den.
Hvad strukturel testning ikke er
Vi har tidligere nævnt, at strukturbaseret test henviser til kodens struktur. Bemærk, at vi behandler den aktuelle kode her. Vi kontrollerer ikke kravene og tester ikke engang input mod de forventede output. Vi er ikke bekymrede over funktionalitet, brugeroplevelse eller endda ydeevne på dette tidspunkt.
Hvad er strukturel testning?
Strukturbaseret test kan derfor defineres som en type softwaretest, der tester kodens struktur og tilsigtede strømme. For eksempel, verificering af den faktiske kode for aspekter som korrekt implementering af betingede udsagn, og om hver sætning i koden udføres korrekt. Det er også kendt som strukturbaseret test.
For at udføre denne type test er vi nødt til at forstå koden grundigt. Dette er grunden til, at denne test normalt udføres af udviklerne, der skrev koden, som de forstår den bedst.
Sådan udføres strukturel test
For at teste forskellige aspekter af koden skal vi først forstå kontrolstrømmene.
Kontrol af flowtest
Dette stammer test fra kodens kontrolstrømme (rækkefølgen, i hvilken udsagn, funktioner og forskellige aspekter af koden implementeres).
Control Flow Testing Process:
Kontrol af flowdiagram
Kontrolflowprocessen begynder med at skabe en visuel repræsentation af forskellige sektioner af koden, der hjælper os med at definere de stier, der kan følges under udførelsen.
Disse visuelle repræsentationer er kendt som Control Flow Graphs (CFGs) og har flere komponenter som noder, kanter, stier, kryds og beslutningspunkter. Grafen kan oprettes manuelt eller automatisk, hvor software bruges til at udtrække grafen fra kildekoden.
Lad os se på disse komponenter nedenfor:
# 1) Procesblok
Denne del bruges til at repræsentere en sektion af kode, der udføres sekventielt. Dette betyder, at det udføres på samme måde hver gang, og der er ingen beslutninger eller 'forgrening', der skal gøres. Den består af noder med en ind- og udgangssti.
Eksempel på en procesblok:
rodårsagsanalyse i softwaretest
(billede kilde )
Procesblokken er ikke en væsentlig del af kontrolflowet og skal derfor kun testes en gang.
# 2) Beslutningspunkter
Dette er nogle nøglekomponenter i kodens kontrolflow. Inden for disse knudepunkter træffes beslutninger. Dette gøres normalt ved sammenligning, og kontrolflowet ændres afhængigt af beslutningen. Denne del af CFG består af en node med mindst 2 udgange.
Beslutningen, der træffes her, kunne være betingede udsagn som if-else-udsagn (som har to mulige output) og sagserklæringer (som kan have mere end to output).
(billede kilde )
I ovenstående diagram er der et beslutningspunkt (fra den betingede 'alder = 18'), der efterfølges af 'ja' eller 'nej' muligheder.
# 3) Knudepunkter
Fra ovenstående diagram kan vi let identificere knudepunkter for, hvor beslutningspunkterne slutter sig. Knudepunkter kan have mange indgangsstier, men kan kun have en udgangssti.
Bedste fremgangsmåder til kontrol af flowgrafer:
Der er et par ting at bemærke, når der konstrueres kontrolgrafer:
- Prøv så meget som muligt for at holde CFG enkel. Vi kan gøre dette ved at kombinere dele, der kan betragtes som 'mindre signifikante', for eksempel, procesblokke.
- Sørg for, at der kun træffes én beslutning på beslutningspunkter. I mere komplekse CFG'er er der 'konsekvenser', der kommer efter beslutningen er truffet. I vores ovenstående eksempel kan vi også tilføje, at hvis en person er 18 år eller ældre, er de berettigede og skal betale for en billet. Hvis de ikke er det, er adgangen gratis. Beslutningen om 'andet' skal 'springe over' et par noder, og alle disse trin skal vises i vores CFG.
Når vi først har defineret vores CFG, er det nu tid til at gå til næste trin i kontrolflow-testprocessen, dvs. definere, i hvilket omfang vi skal teste koden.
Definere, hvor meget der skal testes:
Hvor meget af kildekoden skal testes? Skal vi teste hver mulig sti? Det er praktisk taget umuligt at forsøge at dække alle veje i vores tests. Vi er nødt til at finde en mellemvej til at bestemme, hvor meget test vi kan udføre.
Hvis vi siger, at vi sigter mod at teste 50% af vores kode, så kan det betyde, at vi definerer alle eksekverbare kodesætninger og sigter mod at teste mindst halvdelen af dem. Imidlertid er spørgsmålet, der opstår her, 'skal vi så definere alle mulige eksekverbare stier?'
Dette kan igen være praktisk umuligt. En bedre tilgang kan sigte mod at teste 50% af de stier, som vi kan identificere i hvert afsnit af koden.
Der er forskellige niveauer af dækninger, nemlig udsagn, gren og stigdækning. Vi vil kort se på dem senere.
Oprettelse af testsager:
Det næste trin er at oprette de testsager, som vi vil bruge. Testcases i strukturbaseret test er baseret på følgende faktorer:
- De eksekverbare udsagn.
- De 'beslutninger', der skal træffes.
- De mulige stier, der kan følges.
- De betingelser, der skal opfyldes (disse kan være flere eller boolske).
Ovenstående faktorer giver os en idé om, hvilke typer testsager vi skal oprette. Vi kan også bruge et strukturelt testgenereringsværktøj. Hvis vores kode er på C-programmeringssproget, kan vi bruge PathCrawler til at generere testkode. Et andet værktøj, som vi kan bruge, er fMBT.
Udførelse af testsagerne:
Her får vi kørt testene. Vi kan indtaste input eller data for at kontrollere, hvordan koden udfører det, og derefter kontrollere, om vi får de forventede resultater. For eksempel, indtast en matrix i et funktionsopkald for at observere, at de resultater, vi får efter at have løbt igennem det, eller for at kontrollere, om beslutningspunkterne tager de rigtige beslutninger.
Analyse af resultaterne:
I denne del er alt, hvad vi gør, at kontrollere, om vi får de korrekte resultater efter udførelse. For eksempel, hvis vi går ind i en matrix, hvor alle værdier er over 18, skal vi have alle beslutningspunkter, der resulterer i 'kvalificerende'.
Kontroller flowforudsætninger
Det er vigtigt at bemærke, at der er nogle få antagelser, der foretages for at udføre kontrolflowtest. Disse inkluderer:
- De eneste fejl, der er til stede, er dem, der kan påvirke kontrolflowet.
- Alle variabler, funktioner og elementer er nøjagtigt defineret.
Dækningsniveauer i kontrolstrømme
Som vi har nævnt tidligere, er der forskellige niveauer af dækning i test af kontrolflow.
Lad os se kort på dem.
# 1) Erklæringens dækning
I strukturel test spiller eksekverbare kodesætninger en vigtig rolle, når det kommer til at beslutte metoderne til at designe testene.
Vi sigter mod at opnå 100% dækning, hvilket betyder, at hver eksekverbar erklæring er testet mindst en gang. Jo højere dækningen er, desto mindre er der sandsynligheden for at gå glip af fejl og fejl.
Det er nødvendigt at bruge testcases her. De data, vi går efter, er at sikre, at hver eksekverbar sætning i en kodeblok udføres mindst en gang.
# 2) Filialdækning
Dette dækningsniveau indebærer at teste punkterne i CFG-filialerne (hvor der træffes beslutninger). Resultaterne er boolske. Selvom der anvendes en switch-sætning, og der er flere resultater, er hver caseblok i virkeligheden en sammenligning af et par værdier.
Ligesom med erklæring dækning, bør vi sigte mod 100% filialdækning. For at opnå dette er vi nødt til at teste hvert resultat på hvert beslutningsniveau mindst en gang. Da vi har at gøre med boolske resultater, skal vi sigte mod at køre mindst 2 tests pr. Sektion med kode.
# 3) Sti-dækning
Dette dækningsniveau er mere grundigt sammenlignet med dækning af beslutninger og udsagn. Målet her er at 'opdage' alle mulige stier og teste dem mindst én gang. Dette kan være ekstremt tidskrævende. Det kan dog hjælpe med at opdage fejl eller fejl i vores kode eller endda aspekter, som vi skal definere, for eksempel, brugerinput.
Strukturelle testtyper
(billede kilde )
Mutationstest
Mutationstest er en fejlbaseret testteknik, hvor forskellige variationer af en softwareapplikation testes mod testdatasættet.
>> Se denne vejledning for et grundigt kig på Mutationstest.
Skivebaseret test
Slice Based Testing (SBT) kan defineres som en softwaretestteknik, der er baseret på skiver - eksekverbare dele af programmet eller grupper af udsagn, der påvirker nogle værdier på bestemte interessepunkter i programmet for eksempel, dele, hvor variabler er defineret eller output fra en gruppe udsagn.
Sådan gør du udskæring
Udskæring af eksempel i SBT: Kode til udskrivning af lige og ulige tal (Python)
num_list = range(1,12) even_nums = () odd_nums = () for var in num_list: if var%2==0: even_nums.append(var) print(f'Even numbers: {even_nums}') elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')
Der er to måder at se på et udsnit på: Ved at følge stien til en variabel af interesse eller den del af koden, der påvirker output.
I vores eksempel, hvis vi ser på de ulige tal output, kan vi spore den del af koden, der fører os til denne output.
I udskæringskriterierne givet af Mark Weiser (der introducerede SBT) defineres et udsnit ved hjælp af denne formel: S (v, n) , hvor, v henviser til den pågældende variabel ( for eksempel, hvor en variabel er defineret) og n er interessetilkendegivelsen ( for eksempel, hvor output er givet), og S står for skiven.
I ovenstående eksempel starter vi fra vores output på linje 10, som bliver vores for at få skiven n . Vores variabel er hvor .
Så vores udskæringskriterier er:
S(v,n) = S(var,10)
Vores bekymring er udsagnene, der fører os til produktionen.
Disse er:
10,9,8,4,3,1
Så vores udsnit i denne kode er:
num_list = range(1,12) odd_nums = () for var in num_list: elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')
Skivebaserede testtyper
Der er to typer SBT: Statisk og Dynamisk
# 1) Dynamisk skivebaseret test
SBT-eksemplet forklaret ovenfor, hvor vi så på udsagnene, der påvirker udskrivningen af de ulige tal, er dynamisk SBT. Vores bekymring er meget specifik. Vi får kun fokusere på, hvad der direkte påvirker den bestemte produktion.
Vi udfører koden og bruger testdata for at sikre, at den fungerer, som den skal. Vi kunne øge området til området (1,50), for eksempel, for at se om det stadig kun genererer ulige tal. Dynamisk SBT er også kendt som valideringstest.
# 2) StatiskSkivebaseret test
I modsætning til Dynamic SBT er statisk test fokus på en bestemt variabel. Hvis vi tænker på vores output i ovenstående eksempel som hvor , kan vi spore det udsnit, der påvirker det som 10,9,8,7,6,5,4,3,2,1
sæbeinterviewspørgsmål og svar til erfarne
Det er dybest set hele kodeblokken! Her bekræfter vi, at koden er korrekt med hensyn til syntaks og krav, og vi udfører den ikke. Statisk SBT er også kendt som verifikationstest.
Det er vigtigt at bemærke, at dynamisk SBT er 'mindre' sammenlignet med dets statiske modstykke. Det er også mere specifikt.
Skivebaseret testning af bedste praksis / retningslinjer
Udskæringskriterier skal bestemmes af:
- Erklæringer, hvor værdier er defineret eller tildelt værdi samt omfordelt værdi.
- Erklæringer, hvor værdier modtages uden for programmet, for eksempel, via brugerinput.
- Udsagn, der udskriver output / returnerer output.
- Programmets sidste erklæring, for eksempel, et funktionsopkald, der kan definere værdier eller give værdier til argumenter
Fordele ved skivebaseret test inkluderer:
- Da vi i SBT kun arbejder med specifikke interesseområder, gør det det lettere at effektivt generere testsuiter.
- Stien er defineret af afhængigheder inden for koden, hvilket er bedre end at bruge stigdækning.
- Med SBT er det lettere at finde fejl i kildekoden.
Ulemper ved skivebaseret test inkluderer:
- Hvis vi bruger dynamisk test, når vi tester en stor codebase, har vi brug for en masse beregningsressourcer.
- Hvis vi bruger statisk test, går vi måske glip af fejl.
Test af dataflow
Test af datastrøm kan defineres som en softwaretestteknik, der er baseret på dataværdier og deres anvendelse i et program. Det verificerer, at dataværdier er blevet brugt korrekt, og at de genererer de korrekte resultater. Test af datastrøm hjælper med at spore afhængighederne mellem dataværdier på en bestemt eksekveringssti.
Dataflytningsanomalier
Data flow anomalier er simpelthen fejl i et softwareprogram. De klassificeres i henholdsvis type 1, 2 og 3.
Lad os dykke ned i dem nedenfor:
Type 1: En variabel defineres, og en værdi tildeles den to gange.
Eksempel kode: Python
lst_1 = (1,2,3,4) lst_1 = (5,6,7,8) for var in lst_1: print(var)
Lst_1 er defineret, og der tildeles to forskellige værdier. Den første værdi ignoreres simpelthen. Type 1 anomalier får ikke programmet til at mislykkes.
Type 2: Værdien af en variabel bruges eller henvises til, før den defineres.
Eksempel kode: Python
for var in lst_1: print(var)
Loopen ovenfor har ingen værdier at gentage. Type 2 anomalier får programmet til at mislykkes.
Type 3: A dataværdien genereres, men bruges den aldrig.
Eksempel kode: Python
lst_1 = (1,2,3,4) lst_2 = (5,6,7,8) for var in lst_1: print(var)
Variablen lst_2 er ikke henvist til. Type 3 anomalier kan ikke medføre programfejl.
Process for test af dataflow
For at definere afhængighederne mellem dataværdier er vi nødt til at definere de forskellige stier, der kan følges i et program. For effektivt at gøre dette er vi nødt til at låne fra en anden strukturel testtype kendt som kontrol-flow test .
Trin 1) Tegn en kontrolflowdiagram
Vi er nødt til at tegne en kontrolflowdiagram, som er en grafisk repræsentation af de stier, som vi kunne følge i vores program.
Eksempel kode: Python
cost = 20 y = int(input('How many visitor seats did you reserve? ')) x = int(input('How many member seats did you reserve? ')) if y>x: bill = cost -1 else: bill = cost print(bill)
I ovenstående kodeeksempel skal et medlem få rabat, hvis de inviterer en besøgende.
Kontrolflowdiagram (CFG):
Trin 2) Udforsk definitionen og brugen af variabler og dataværdier.
En variabel i et program er enten defineret eller brugt. I CFG har vi variabler ved hver node. Hver node er navngivet i henhold til den variable type, den huser. Hvis en variabel er defineret ved en bestemt node, opretter den en definerende node. Hvis en variabel bruges på en node, opretter den en brugsknude.
Hvis vi overvejer de variable omkostninger i CFG, er disse definerings- og brugsknudepunkterne:
Node | Type | Kode |
---|---|---|
1 | Definere knude | omkostning = 20 |
5 | Brugsknude | regning = omkostning -1 |
7 | Brugsknude | regning = pris |
Trin # 3) Definer definition-brugsstier.
Der er to typer definitionsbrugsstier: du stier og dc stier. du stier er definitionsstier, der begynder med en definitionsknude og slutter med en brugsknude. Dette er tilfældet for stien i forhold til ovenstående variable omkostninger.
Et eksempel på en dc-sti, en beslutning-klar sti, er stien med hensyn til regningsvariablen som nedenfor:
Node | Type | Kode |
---|---|---|
5 | Definere knude | regning = omkostning -1 |
7 | Definere knude | regning = pris |
8 | Brugsknude | udskrive (regning) |
DC-stien har mere end en definitionsknude, selvom den stadig ender ved en brugsknude.
Trin # 4) Opret testpakken.
Dette tilføjer input. Bemærk, at vi skal have en anden testpakke til hver variabel. Testpakken hjælper os med at identificere anomalier i datastrømme.
Typer af dataflowstest
Der er to typer - Statisk og dynamisk .
Statisk betyder, at vi gennemgår koden og CFG for at identificere dataafvigelser uden at udføre den. Dynamisk betyder, at vi faktisk identificerer de specifikke stier og derefter opretter testpakker til at teste det i et forsøg på at 'fange' anomalier, som vi måske har gået glip af under statisk test.
Fordele og ulemper ved datastrømstest:
- Data flow test er ideel til at identificere data flow anomalier, hvilket gør det til en meget effektiv strukturel testmetode.
- Dens ulempe er, at der er behov for at være velbevandret i det sprog, der bruges til at skrive koden for at bruge datastrømstest. Det er også tidskrævende.
Fordele og ulemper ved strukturel testning
Lad os nu finde årsagerne til, at strukturel test er en god tilgang, og også udforske nogle af dens ulemper.
Fordele:
- Tillader grundig kodetest, hvilket resulterer i minimale fejl. Strukturbaseret test giver plads til software, der skal testes grundigt. De forskellige dækningsniveauer - udsagn for erklæring, hvert beslutningspunkt og sti sigter mod at opnå 100% dækning, hvilket i høj grad reducerer chancerne for, at fejl bliver uopdaget.
- Evnen til at automatisere . Der er flere værktøjer, som vi kan bruge til at automatisere test. Dette hjælper os med at opnå maksimal kodedækning og inden for kortere tid sammenlignet med manuel testning.
- Det resulterer i højere kvalitetskode . Udviklerne har en chance for at studere kodens struktur og implementering og rette eventuelle fejl samt forbedre disse aspekter. Det giver os mulighed for at holde den store struktur i tankerne, når vi skriver efterfølgende dele af koden eller implementerer de resterende funktioner.
- Det kan gøres gennem hver fase af SDLC - Strukturel test kan udføres i hver fase af SDLC uden at vente på, at udviklingen er afsluttet 100%. Dette gør det let at identificere fejl i den tidlige fase og sparer således meget tid sammenlignet med test, når udviklingen er afsluttet.
- Det hjælper med at slippe af med død kode . Dette kan ses som 'ekstra' eller unødvendig kode, for eksempel, kode, der beregner et resultat, men aldrig bruger det i nogen af de følgende beregninger.
- Effektivitet - Da udviklerne, der skriver koden, er de samme, der tester den, er det ikke nødvendigt at involvere andre mennesker som QA'er.
Ulemper:
- Udviklerne, der udfører strukturbaseret test, skal have en grundig forståelse af sproget . Andre udviklere og QA'er, der ikke er velbevandrede i sproget, kan ikke hjælpe med testning.
- Det kan blive ret dyrt med hensyn til tid og penge . Der kræves meget tid og ressourcer til at udføre test effektivt.
- Det forårsager forsinkelser i leveringen af funktioner . Dette skyldes, at udviklere trækkes fra at bygge software til at udføre test.
- Skalering er et problem, især hvor store applikationer er involveret . En stor applikation svarer til et for stort antal ruter, der skal dækkes. At opnå 100% dækning bliver umulig.
- Der kan være savnede tilfælde og ruter , for eksempel, i et tilfælde hvor funktioner ikke er fuldt udviklet eller endnu ikke er udviklet. Dette betyder, at det skal kombineres med andre testtyper som kravtest (hvor vi kontrollerer mod de specificerede funktioner, der skulle bygges).
Best Practices for strukturel test
Nogle af de faktorer, der kræver opmærksomhed under udførelse af strukturbaseret test, er som følger:
- Mærk og navngiv testene tydeligt . Hvis en anden har brug for at køre testene, skal de være i stand til let at finde dem.
- Inden du forbedrer koden, dvs. ved at omlægge den og optimere den til brug i forskellige miljøer, skal du sikre dig, at dens struktur og flow er ideel.
- Kør tests separat . På denne måde er det let at identificere fejl og rette dem. På den anden side er det mindre sandsynligt, at vi går glip af bugs eller stier som et resultat af overlapninger i kodeafsnit, blokke eller stier.
- Generer tests, inden du foretager ændringer . Testene kræves for at køre som forventet. På denne måde, hvis noget går i stykker, er det let at spore og løse problemet.
- Hold testene for hver sektion eller kodeblok adskilt . På denne måde, hvis der er ændringer nede på linjen, behøver vi ikke ændre mange tests.
- Ret fejl, inden du går videre med test . Hvis vi identificerer eventuelle fejl, er det bedre for os at rette dem, inden vi fortsætter med at teste næste afsnit eller blok af kode.
- Spring aldrig over strukturel test med den antagelse, at en kvalitetssikring 'stadig foretager testning alligevel'. Selvom fejlene i starten kan virke ubetydelige, kumulativt, kan de resultere i fejlkode, der aldrig kan nå det tilsigtede formål.
Ofte stillede spørgsmål til strukturbaseret test
Her vil vi undersøge de ofte stillede spørgsmål, når det kommer til strukturbaseret test.
Q # 1) Hvad er forskellen mellem funktionel test og strukturel test?
Svar: Funktionel test er en type softwaretest baseret på fastsatte krav i SRS (Specifikationer for softwarekrav). Det gøres normalt i et forsøg på at finde forskelle mellem specifikationer i SRS og hvordan koden fungerer. Strukturel testning er baseret på kodens interne struktur og dens implementering. En grundig forståelse af koden er påkrævet.
Q # 2) Hvad er typerne af strukturel test?
hvad er en god mp3 downloader
Besvare typer inkluderer:
- Test af datastrøm
- Mutationstest
- Kontrol flow test
- Skivebaseret test
Q # 3) Hvad er et eksempel på strukturel testning?
Svar: Her er et eksempel, der viser udsagnsdækning:
const addNums = (num) => { let sum = num.reduce ((a,b) => a+b); if (sum > 0) { alert(sum); } else { alert(‘please enter positive numbers’); } }; addNums();
Mængden af dækning, vi får, afhænger af de testdata, vi leverer som input (om de opfylder summen> 0 betingelser).
Spørgsmål nr. 4) Hvad er forskellen mellem dataflowtest og kontrol af flowtest?
Svar: Både datastrømstestning og kontrolflowtest bruger kontrolgrafer. Den eneste forskel er, at vi i kontrolflowtest fokuserer på de stier, der genereres fra koden, mens vi i datastrømstest fokuserer på dataværdierne, deres definition og anvendelse inden for de stier, der er identificeret i et program.
Spørgsmål nr. 5) Hvad bruges dataflytstest til?
Svar: Test af datastrøm er ideel til at identificere uregelmæssigheder i brugen af dataværdier inden for stier i en kontrolflowdiagram, for eksempel, en variabel, der er tildelt værdi to gange, en variabel, der er defineret og ikke brugt, eller en variabel, der er blevet brugt eller henvist til og ikke defineret.
Q # 6) Hvad er forskellen mellem udskæring og udskæring i softwaretest?
Svar: Udskæring betyder at fokusere på bestemte interessetilkendegivelser i et program og ignorere resten. Dicing er, når vi identificerer et udsnit, der har forkert input, og derefter skærer det yderligere for at spore korrekt opførsel.
Q # 7) Hvad er forskellen mellem mutationstest og kodedækning?
Svar: I mutationstestning betragter vi antallet af dræbte mutanter som en procentdel af de samlede mutanter. Kodedækning er simpelthen den mængde kode, der er testet i et program.
Konklusion
I denne vejledning så vi dybtgående på strukturel test - hvad det er, hvad det ikke er, hvordan man skal gøre det, dækningstyper, fordele og ulemper, bedste praksis og endda nogle ofte stillede spørgsmål vedrørende denne softwaretesttype.
Der er stadig så meget mere, som vi kan lære om strukturbaseret test. I fremtidige tutorials vil vi udforske kodedækning (erklæring, beslutning, gren og sti), strukturelle testtyper (mutation, datastrøm og skivebaseret) og endda de værktøjer, vi kan bruge til at automatisere disse testprocesser.
Det er vigtigt at bemærke, at der ikke er nogen softwaretesttype eller fremgangsmåde, der er 100% effektiv. Det tilrådes altid at kombinere forskellige testtyper og tilgange.
For eksempel, strukturel test suppleres i høj grad med kravstest, da der kan være funktioner, der muligvis ikke er blevet udviklet på det tidspunkt, hvor strukturbaseret test blev udført.
Strukturelle testteknikker er baseret på de fejl, som menneskelige programmører laver, når de skriver kode. Antagelsen er, at programmøren er ekspert og ved, hvad han eller hun koder, men fejler fra tid til anden.
De forskellige strukturelle testtyper, som vi har set på - mutationstest, skivebaseret testning og datastrømstestning kan spores tilbage til fejl som ved at bruge den forkerte operatør (mutationstest) eller henvise til en variabel, før den bruges (datastrømstest) .
Anbefalet læsning
- Destruktiv test og ikke-destruktiv testvejledning
- Funktionel testning mod ikke-funktionel testning
- Hvad er defektbaseret testteknik?
- Soak Testing Tutorial - Hvad er Soak Testing
- SOA Testing Tutorial: Test Methodology For a SOA Architecture Model
- Load Testing med HP LoadRunner-vejledninger
- Hvad er gammatestning? Det sidste teststadium
- DevOps Testing Tutorial: Hvordan DevOps vil påvirke QA Testing?
- Hvad er overensstemmelsestest (overensstemmelsestest)?