Kodedækningsvejledning: Filial, erklæring, funktionsdækning

code coverage tutorial

Denne omfattende vejledning forklarer, hvad der er kodedækning i softwaretest, dets typer, fordele og ulemper:

Det ultimative mål for ethvert softwareudviklingsselskab er at udvikle software, der er af god kvalitet. For at nå dette mål skal softwaren testes grundigt.

Test er således en integreret del af udviklingen af ​​en softwareapplikation. Derfor er det vigtigt, at den udviklede software gennemgås af udvikleren (som udføres under enhedstestfasen) og derefter sendes til QC-teamet for at blive testet grundigt for at sikre, at den har minimale eller ingen fejl.

Softwaren er enhedstestet, før den frigives til det faktiske testteam til test. Da denne test involverer test på kodeniveau, udføres det af udvikleren. Dette gøres for at sikre, at hver del af koden, der testes, fungerer som forventet.

Her testes små stykker kode, der er udviklet, isoleret for at sikre deres korrekthed. Men spørgsmålet, der ofte vækker i en udviklers sind, er hvor meget af enhedstest, der skal udføres og svaret på dette ligger i kodedækningen.

Denne tutorial giver dig en dyb viden om, hvad kodedækning er, og hvorfor vi har brug for det. Du får at vide, hvordan det adskiller sig fra testdækning.

Vi skal også se på de værktøjer og metoder, der bruges til kodedækning, og mod slutningen af ​​denne tutorial vil vi se fordelene sammen med dens ulemper. Nogle af myterne forbundet med kodedækning vil også blive dækket her.

Hvad du lærer:

• Hvad er kodedækning
  • Hvorfor vi har brug for kodedækning
• Kodedækning Vs Testdækning
  • Metoder
    • Erklæringens dækning
    • Funktionsdækning
    • Tilstandsdækning
    • Filialdækning
  • Værktøjer til kodedækning
  • Fordele
  • Ulemper
  • Myter mod fakta
  • Ofte stillede spørgsmål
• Konklusion
  • Anbefalet læsning

Hvad er kodedækning

Dette er en vigtig måling af enhedstest. Det er praktisk at kende effektiviteten af ​​enhedstest. Det er et mål, der angiver, hvor stor en procentdel af kildekoden der bliver udført under test.

Enkelt sagt i hvilket omfang kildekoden til et softwareprogram eller et program bliver udført under testning, kaldes kodedækning.

Hvis testene udfører hele kodestykket inklusive alle grene, betingelser eller sløjfer, vil vi sige, at der er fuld dækning af alle mulige scenarier, og dermed er kodedækningen 100%. Lad os tage et eksempel for at forstå dette endnu bedre.

Nedenfor er en simpel kode, der bruges til at tilføje to tal og vise resultatet afhængigt af resultatet.

Ovenstående program indeholder to indgange, dvs. 'a' og 'b'. Summen af ​​begge er gemt i variabel c. Hvis værdien af ​​c er mindre end 10, udskrives værdien af ​​'c' ellers udskrives 'Undskyld'.

Nu, hvis vi har nogle tests for at validere ovenstående program med værdierne a & b, således at summen altid er mindre end 10, så bliver den anden del af koden aldrig udført. I et sådant scenario vil vi sige, at dækningen ikke er komplet.

Dette var kun et lille eksempel for at afklare betydningen af ​​kodedækning. Når vi udforsker mere, får du bedre klarhed om det.

Hvorfor vi har brug for kodedækning

(billede kilde )

Forskellige årsager gør kodedækning afgørende, og nogle af dem er anført nedenfor:

java kopier 2d-array til et andet array

• Det hjælper med at fastslå, at softwaren har mindre fejl sammenlignet med den software, der ikke har en god kodedækning.
• Ved at hjælpe med at forbedre kodekvaliteten hjælper det indirekte med at levere en bedre 'kvalitets' software.
• Det er et mål, der kan bruges til at kende testeffektiviteten (effektiviteten af ​​de enhedstest, der er skrevet for at teste koden).
• Hjælper med at identificere de dele af kildekoden, der ikke bliver testet.
• Det hjælper med at afgøre, om den aktuelle test (enhedstest) er tilstrækkelig eller ej, og om der også er behov for nogle flere tests.

Kodedækning Vs Testdækning

For at forstå forskellen mellem kodedækning og testdækning, lad os først forstå betydningen af ​​testdækning.

Test dækning

Det er et mål for, hvor mange dele af den forventede test, der er blevet dækket under test af en software. Ved 'Forventet test' vi mener det komplette sæt testsager, der er skrevet til at blive udført for at teste en given software.

Antag, for at teste en software er der skrevet et sæt på 500 testsager i alt. Nu, som en del af testaktiviteten, blev kun 300 testsager udført. Lad os antage, at dette skyldes mangel på tid. I dette tilfælde vil nedenstående være testdækningen.

Testdækning = (Udførte testsager / Total testsager) * 100
= (300/500) * 100
= 60%

Lad os sammenligne dette med hvad kodedækning er.

Kodedækning

Det er et mål, der viser, i hvilket omfang en kildekode for en applikation udføres under test af koden. Det viser således i hvilken grad en kildekode ville blive testet.

Antag at for at teste en applikation med 500 linjer kode, bliver kun 400 linjer af koden udført ved test. Lad os antage, at dette skyldes, at en bestemt sløjfe / tilstand ikke bliver udført. I dette tilfælde vil nedenstående være kodedækningen.

Kodedækning = (antal linjer udført kode / samlet antal linjer kode) * 100
= (400/500) * 100
= 80%

Nedenfor er forskellene mellem kodedækning og testdækning:

Metoder

Her skal vi diskutere de forskellige metoder, der er / kan bruges til at måle kodedækningen.

For at forstå disse metoder, lad os se på nedenstående kodestykke:

hvad er en god e-mail-tjeneste

Erklæringens dækning

Denne metode er et mål, der fortæller, om alle mulige eksekverbare kodesætninger i kildekoden er blevet udført mindst én gang. Det er en metode til at sikre, at hver linje i kildekoden er dækket mindst en gang af testene.

Dette lyder måske simpelt, men der skal udvises forsigtighed under måling af erklæringens dækning. Årsagen er, at der i en kildekode kunne være en bestemt tilstand, der muligvis ikke bliver udført afhængigt af inputværdierne.

Dette ville betyde, at alle kodelinjer ikke ville blive dækket af test. Således er vi muligvis nødt til at bruge forskellige inputværdisæt til at dække alle sådanne betingelser i kildekoden.

For eksempel, i ovenstående kildekode, hvis inputværdier tages som 2 & 3, bliver den ellers del af koden ikke udført. Men hvis inputværdierne er af type 3 & 2, bliver 'Hvis' -delen af ​​koden ikke udført.

Dette betyder, at med begge sæt værdier i vores erklæring ville dækningen ikke være 100%. I et sådant tilfælde er vi muligvis nødt til at udføre testene med alle tre ((2, 3), (3, 2), (0, 0))) værdier for at sikre 100% erklæringens dækning.

Funktionsdækning

Som navnet antyder, måler denne metode, i hvilket omfang de funktioner, der findes i kildekoden, er dækket under testningen. Alle funktioner, der er i kildekoden, testes under udførelse af test. Igen skal det sikres, at vi tester disse funktioner for forskellige værdier, så funktionen bliver testet grundigt.

I en kildekode kan der være flere funktioner, og afhængigt af de anvendte inputværdier kaldes en funktion måske eller måske ikke. Formålet med funktionsdækning er således at sikre, at vi har hver funktion, der kræves.

For eksempel, i kildekoden ovenfor, hvis vores tests kalder funktionen 'Tilføj' endnu en gang, så kalder vi dette som en komplet funktionsdækning.

Tilstandsdækning

I en kildekode, uanset hvor vi har en betingelse, ville resultatet være en boolsk værdi af enten sand eller falsk. Betingelsesdækning sigter mod at fastslå, om testene dækker begge værdier, dvs. sande, falske.

I kildekoden, når hver forekommende tilstand vurderes for både sande og falske tilstande, siges betingelsesdækningen for koden at være komplet.

For eksempel, i ovenstående kode, hvis værdisæt (2, 3) og (4, 2) anvendes, ville betingelsesdækningen være 100%. Når datasættet (2, 3) anvendes, evalueres (b> a) til sand og (a> b) evalueres til falsk. Tilsvarende, når datasættet (4, 2) anvendes, evalueres (b> a) til falsk og (a> b) evalueres til sandt.

Således har begge betingelser både værdierne dvs. dækket sandt og falsk. Derfor er betingelsesdækningen 100%.

Filialdækning

Denne metode sigter mod at sikre, at hver gren, der vises i hver betinget struktur, bliver udført i kildekoden. For eksempel i ovenstående kode skal alle 'Hvis' udsagn og enhver ledsagende 'Else' erklæring alle være dækket af testen for en 100% filialdækning.

For eksempel, i ovenstående kode, hvis værdisæt (2, 3), (4, 2), (1, 1) anvendes, ville grenafdækningen være 100%. Når datasættet (2, 3) bruges, så (b> a) og den første 'Hvis' gren bliver udført. Tilsvarende, når datasættet (4, 2) bruges, evalueres (a> b) til sand, og den anden 'Hvis' gren bliver udført.

Derefter med datasættet (1, 1) evalueres 'Else' -grenen til sand og bliver udført. Derved sikres 100% filialdækning.

Filialdækning Vs Tilstandsdækning

Grenafdækning forveksles ofte med betingelsesdækning, men de to er forskellige.

Lad os forstå dette med et simpelt eksempel.

Lad os nedskrive det datasæt, der er nødvendigt for komplet Filialdækning:

(1, 1) - I dette tilfælde er 'a' og 'b' begge rigtige, så hvis betingelsen bliver udført.
(1, 0) - I dette tilfælde er 'a' sandt og 'b' ville være forkert, så den anden del af koden udføres.

Som vi ved, er formålet med filialdækning at få hver filial udført mindst én gang, og dette formål er nået.

Tilstandsdækning:

(1, 0) - I dette tilfælde er 'a' sandt og 'b' ville være falsk.
(0, 1) - I dette tilfælde er 'a' falsk, og 'b' ville være sandt.

Formålet med betingelsesdækning er at få hver af sande og falske for hver tilstand, der udføres, og dette formål opnås her.

Har du bemærket, at den anden del ikke bliver udført i tilstandsdækning? Det er her, betingelsesdækning adskiller sig fra filialdækning.

Værktøjer til kodedækning

For at måle kodedækningen af ​​enhver software er der flere værktøjer til rådighed på markedet.

Nedenfor er nogle af værktøjerne til din reference:

• Parasoft JTest
• Testwell CTC ++
• Dækning
• JaCoCo
• CodeCover
• BullseyeCoverage
• EMMA
• OpenCover
• NCover
• Squish COCO
• Dækningsmåler
• GCT
• TCAT C / C ++
• Gretel
• JCov

Anbefalet læsning => Kodedækningsværktøjer

Ovenstående link inkluderer følgende oplysninger om disse værktøjer:

• Nøglefunktioner
• Licenstype
• Officiel URL
• Fordele og ulemper
• Nyeste version

Fordele

Som det ses ovenfor, er det en meget nyttig testmåling af nedenstående grunde:

• Det hjælper med at identificere de områder i en kildekode, der forbliver uprøvet / afdækket af testene.
• Det kommer praktisk til at identificere brugt / død kode og derved forbedre kodekvaliteten.
• Effektiviteten af ​​enhedstestene kan kendes ved hjælp af kodedækning.
• Software med bedre kvalitet kan leveres ved hjælp af disse målinger.

Ulemper

• At forsøge at sigte mod en 100% kodedækning medfører undertiden manglende robusthed i testene, hvilket resulterer i at gå glip af at opfange de udsatte defekte scenarier.
• I modsætning til den almindelige opfattelse kan den ikke garantere, om den designede software opfylder alle kravene.

Myter mod fakta

Ofte stillede spørgsmål

Spørgsmål nr. 1) Hvad er en acceptabel kodedækning?

Svar: At opnå 100% kodedækning bør ikke være målet, mens enhedstest softwarekode. Men hvorfor ikke? For at forstå årsagen kan det være nødvendigt at dykke lidt dybere for at forstå den underliggende betydning.

Når vi målretter mod en dækning på 100%, sker det oftere, at alt fokus i design af testene går i at sikre, om hver udsagn, løkke, gren eller tilstand bliver testet. Så vi lander med at gøre for mange bestræbelser, som måske ikke er værd at overveje den brugte tid.

Desuden resulterer fokusering på høj dækning også i at gå glip af de vigtige scenarier, der sandsynligvis vil have manglerne, fordi alt det, vi sigter mod, er at sikre, at hver kodelinje testes.

Fokus på en høj kodedækning er ikke altid så vigtigt, og det kan hverken være et fast tal at målrette mod at teste forskellige koder. Generelt bør en dækning på 75-80% dog være et ideelt tal.

Mens vi tester vores kode, skal hovedfokus ligge på at sikre, at de kritiske og sandsynlige fejludsatte scenarier dækkes. Hvis disse går glip af, ville vores test på trods af en 100% kodedækning simpelthen have dårlig testeffektivitet.

Q # 2) Hvordan kontrollerer jeg min kodedækning?

Svar: For at teste den procentdel af kodedækning, som du muligvis har opnået ved testene designet til at teste koden, har vi flere værktøjer på markedet. Afhængigt af det programmeringssprog man bruger, har vi forskellige værktøjer.

Nogle af dem er anført nedenfor:

• Java - Dækning, JaCoCo
• Javascript - Blanket.js, Istanbul
• Python - Coverage.py
• Rubin - SimpleCov

Ved hjælp af disse værktøjer kan vi få en komplet dækningsrapport om vores tests, der hjælper os med at vide, hvilken del af koden der bliver udført, og hvilken der bliver gået glip af vores tests.

Q # 3) Er kodedækning en god værdi?

gør mens loop i shell script

Svar: I virkelige scenarier er dette nyttigt til en vis grad og på nogle bestemte måder.

Ser vi først på dets begrænsninger, ved vi meget godt, at det at have en dækning på 100% ikke garanterer, at koden er fejlfri, og det garanterer heller ikke, at alle kravene er dækket i koden, dvs. på trods af en dækning på 100% kode er vi meget sandsynligt at have bugs i koden, grunden er, at dækning ikke sikrer, at alle scenarier er testet.

Desuden, hvis krav er sprunget over, mens du skriver koden, er der ingen kortlægning af krav med den kode, der er taget hånd om som en del af kodedækningen.

Når det er sagt, kan vi ikke benægte, at når vi bruger kodedækning som metrics, giver det os en idé, hvis vi har dækket de grundlæggende krav til at teste hver linje i vores kode. Denne dækningsprocent giver os en idé om, hvor mange dele af vores kode der bliver udført med vores enhedstest.

Vi kommer til at vide, hvor meget af vores kode der ikke vil blive udført. Dette hjælper os igen med at beslutte, hvor meget flere enhedstest der er behov for, og for hvilke dele af koden.

Vi kan således konkludere, at det at have dårlig dækning giver os en idé om ineffektiviteten af ​​enhedstestene. På samme tid er det ikke en garanti for en fejlfri kode at sikre en 100% dækning. Man skal således have en afbalanceret tilgang, hvor vi ikke overvægter vigtigheden af ​​at målrette mod en høj procentdel af kodedækning.

Q # 4) Hvordan kan jeg forbedre min kodedækning?

Svar: Kodedækningsrapporten, der leveres af dækningsværktøjer som JaCoCo, Istanbul osv., Viser de områder, der er dækket af testene, og også dem, der ikke bliver testet.

Ved at kende de uprøvede dele af koden kan test skrives enten manuelt eller ved hjælp af ethvert automatiseringsværktøj til at dække de områder, der ellers ville blive uprøvede og derved øge kodedækningen.

En vigtig ting at bemærke her er, at selvom vi måske skriver hundreder af linjer med kode for at teste en funktion i kode, men stadig kan dækningen være meget mindre. Årsagen er, at det at komme for dybt til at teste en del af den enorme kode ikke hjælper med at øge kodedækningen.

Således, hvis målet er at øge dækningen, skal der sørges for at dække alle funktioner, betingelser og sløjfer i stedet for at dykke dybt ned i en enkelt funktion og skrive store tests for den enkelte funktion.

Konklusion

Et softwareprodukt af høj kvalitet er det, der kræves i nutidens hurtige internetverden.

Det er ikke kun en QA-ingeniørs ansvar at sikre software af god kvalitet, men det er også udviklerens ansvar. Kodedækning er således til stor nytte, når det drejer sig om at levere et kvalitetsprodukt til QA-teamet af udvikleren (e).

Denne vejledning forklarede alt om kodedækning og dens anvendelser. Vi gravede også lidt dybere ned i forståelsen af ​​forskellen mellem kodedækning og testdækning. Udover dette fik vi en forståelse af de anvendte metoder sammen med en række forskellige kodedækningsværktøjer.

Fordele og ulemper blev beskrevet her. Endelig sprængte vi nogle af myterne og ofte stillede spørgsmål i forbindelse med kodedækning

God læselyst!!

Anbefalet læsning

• Top 15 kode dækningsværktøjer (til Java, JavaScript, C ++, C #, PHP)
• 15 Bedste JAVA-værktøjer til udvikling, opbygning, profilering, kodedækning og gennemgang
• C # Funktioner / Metoder Vejledning med kodeeksempler
• C # Exception Handling Tutorial med kodeeksempler
• Tortoise SVN Tutorial: Revisions In Code Repository
• Java Array Length Tutorial med kodeeksempler
• AWS CodeBuild-vejledning: Uddrag af kode fra Maven Build
• SVN Tutorial: Kildekodestyring ved hjælp af Subversion