Meny

Kodedekkingsveiledning: Gren, uttalelse, funksjonsdekning

  • Hoved
  • Annen
  • Kodedekkingsveiledning: Gren, uttalelse, funksjonsdekning

code coverage tutorial

Prøv Instrumentet Vårt For Å Eliminere Problemer

Denne omfattende veiledningen forklarer hva som er kodedekning i programvaretesting, dens typer, fordeler og ulemper:

Det endelige målet for ethvert programvareutviklingsselskap er å utvikle programvare av god kvalitet. For å oppnå dette må programvaren testes grundig.

Testing er altså en integrert del av utviklingen av en programvare. Derfor er det viktig at programvaren som utvikles blir gjennomgått av utvikleren (som gjøres i løpet av enhetstestingsfasen) og deretter sendes videre til QC-teamet for å bli grundig testet for å sikre at den har minimale eller ingen feil.

Kodedekning

Programvaren er enhetstestet før den blir utgitt til testteamet. Ettersom denne testingen innebærer testing på kodenivå, gjøres det av utvikleren. Dette gjøres for å sikre at hver del av koden som testes fungerer som forventet.

Her testes små biter av kode som er utviklet isolert for å sikre korrektheten. Men spørsmålet som ofte venter i tankene til en utvikler er hvor mye av enhetstesting som skal gjøres og svaret på dette ligger i kodedekningen.

Denne opplæringen vil gi deg en dyp kunnskap om hva kodedekning er og hvorfor vi trenger det. Du vil bli kjent med hvordan den skiller seg fra testdekning.

Vi vil også se på verktøyene og metodene som brukes til kodedekning, og mot slutten av denne opplæringen vil vi se fordelene sammen med ulempene. Noen av mytene knyttet til kodedekning vil også bli dekket her.

Hva du vil lære:

Hva er kodedekning

Kodedekning

Dette er en viktig måling av enhetstesting. Det er nyttig når du vet effektiviteten av enhetstester. Det er et mål som indikerer hvilken prosentandel kildekoden som blir utført under testing.

For å si det enkelt, i hvilken grad kildekoden til et program eller et program blir utført under testing, er det som kalles kodedekning.

Hvis testene utfører hele kodebiten inkludert alle grener, forhold eller løkker, vil vi si at det er fullstendig dekning av alle mulige scenarier, og dermed er kodedekningen 100%. La oss ta et eksempel for å forstå dette enda bedre.

Nedenfor er en enkel kode som brukes til å legge til to tall og vise resultatet, avhengig av verdien av resultatet.

Input a, b Let c = a + b If c <10, print c Else, print ‘Sorry’

Ovennevnte program tar inn to innganger, dvs. 'a' og 'b'. Summen av begge lagres i variabel c. Hvis verdien av c er mindre enn 10, blir verdien av 'c' skrevet ut, ellers blir 'Sorry' skrevet ut.

Nå, hvis vi har noen tester for å validere ovennevnte program med verdiene til a & b slik at summen alltid er mindre enn 10, så blir den andre delen av koden aldri utført. I et slikt scenario vil vi si at dekningen ikke er fullstendig.

Dette var bare et lite eksempel for å avklare betydningen av kodedekning. Når vi utforsker mer, vil du få bedre klarhet i det.

Hvorfor vi trenger kodedekning

Behov for kodedekning

(bilde kilde )

Ulike årsaker gjør at kodedekning er viktig, og noen av dem er oppført nedenfor:

manuelle tester intervju spørsmål i 4 år erfarne
  • Det hjelper å fastslå at programvaren har mindre feil sammenlignet med programvaren som ikke har god kodedekning.
  • Ved å hjelpe til med å forbedre kodekvaliteten, hjelper det indirekte å levere en bedre ‘kvalitets’ programvare.
  • Det er et mål som kan brukes til å kjenne testeffektiviteten (effektiviteten til enhetstestene som er skrevet for å teste koden).
  • Hjelper med å identifisere de delene av kildekoden som ikke blir testet.
  • Det hjelper å avgjøre om den nåværende testen (enhetstesting) er tilstrekkelig eller ikke, og om det også er behov for noen flere tester.

Kodedekning mot testdekning

CC mot TC

For å forstå forskjellen mellom kodedekning og testdekning, la oss først forstå betydningen av testdekning.

Test dekning

Det er et mål på hvor mange deler av forventet testing som har blitt dekket under testing av en programvare. Av ‘Forventet testing’ vi mener det komplette settet med testtilfeller som er skrevet for å utføres for å teste en gitt programvare.

Anta at for å teste en programvare er det skrevet et sett med totalt 500 testtilfeller. Nå, som en del av testaktiviteten, ble bare 300 testsaker utført. La oss anta at dette skyldes mangel på tid. I dette tilfellet vil nedenstående være testdekning.

Testdekning = (Utførte testtilfeller / Totalt testtilfeller) * 100
= (300/500) * 100
= 60%

La oss sammenligne dette med hva kodedekning er.

Kodedekning

Det er et mål som viser i hvilken grad en kildekode for et program blir utført under testing av koden. Det viser således i hvilken grad en kildekode ville bli testet.

Anta at for å teste et program med 500 kodelinjer, blir bare 400 linjer av koden utført av tester. La oss anta at dette skyldes at en viss sløyfe / tilstand ikke blir utført. I dette tilfellet vil nedenstående være kodedekning.

Kodedekning = (antall linjer med kode som er utført / totalt antall linjer med kode) * 100
= (400/500) * 100
= 80%

Oppført nedenfor er forskjellene mellom kodedekning og testdekning:

Test dekningKodedekning
Det er et mål på hvor stor del av forventet testing som er dekket under testing av en programvare.Det er et mål som viser i hvilken grad en kildekode for et program blir utført under testing av koden.
Testdekning kan beregnes ved hjelp av formelen nedenfor:

Testdekning = (Utførte testtilfeller / Totalt testtilfeller) * 100		Kodedekning kan beregnes ved hjelp av formelen nedenfor:

Kodedekning = (antall linjer med kode som er utført / totalt antall linjer med kode) * 100

Metoder

Her skal vi diskutere de forskjellige metodene som er / kan brukes til å måle kodedekningen.

For å forstå disse metodene, la oss ta en titt på kodebiten nedenfor:

Add (int a, int b) { If (b > a) { b = b - a Print b } If (a > b) { b = a – b Print b } Else Print ‘0’ }

Uttalelsesdekning

Denne metoden er et mål som forteller om alle mulige kjørbare setninger av kode i kildekoden har blitt utført minst en gang. Det er en metode for å sikre at hver linje i kildekoden dekkes minst en gang av testene.

Dette høres kanskje enkelt ut, men det må utvises forsiktighet når du måler uttalelsen. Årsaken er at i en kildekode kan det være en viss tilstand som kanskje ikke blir utført avhengig av inngangsverdiene.

Dette vil bety at alle kodelinjene ikke blir dekket under testing. Dermed kan det hende vi må bruke forskjellige inngangsverdisett for å dekke alle slike forhold i kildekoden.

For eksempel, i ovennevnte kildekode hvis inngangsverdiene blir tatt som 2 og 3, vil ikke 'Else' -delen av koden ikke bli utført. Imidlertid, hvis inngangsverdiene er av type 3 og 2, vil ikke 'Hvis' -delen av koden bli utført.

Dette betyr at med begge verdisettene til vår uttalelse ville dekning ikke være 100%. I et slikt tilfelle kan det hende vi må utføre testene med alle tre ((2, 3), (3, 2), (0, 0)) verdisett for å sikre 100% uttalelsesdekning.

Funksjonsdekning

Som navnet antyder, måler denne metoden i hvilken grad funksjonene i kildekoden dekkes under testing. Alle funksjoner som er i kildekoden blir testet under utførelse av test. Igjen, det må sikres at vi tester disse funksjonene for varierende verdier, slik at funksjonen blir testet grundig.

I en kildekode kan det være flere funksjoner, og avhengig av inngangsverdiene som brukes, kan en funksjon kalles eller ikke. Dermed er formålet med funksjonsdekning å sikre at vi har hver funksjon som kreves.

For eksempel, i kildekoden ovenfor hvis testene våre kaller “Legg til” -funksjonen enda en gang, så vil vi kalle dette som en fullstendig funksjonsdekning.

prioritetskø c ++ implementering

Tilstandsdekning

I en kildekode uansett hvor vi har en tilstand, vil resultatet være en boolsk verdi av enten true eller false. Tilstandsdekning har som mål å fastslå om testene dekker begge verdiene, dvs. sanne, falske.

I kildekoden, når hver forekommende tilstand blir evaluert for både sanne og falske tilstander, sies betingelsesdekningen for koden å være fullført.

For eksempel, i koden ovenfor hvis verdisett (2, 3) og (4, 2) brukes, vil tilstandsdekning være 100%. Når datasett (2, 3) brukes, vurderes (b> a) til true og (a> b) evalueres til false. Tilsvarende, når datasett (4, 2) brukes, så (b> a) evalueres til falsk og (a> b) evalueres til sant.

Dermed har begge forhold både verdiene, dvs. sanne og falske dekket. Derfor vil tilstandsdekningen være 100%.

Grendekning

Denne metoden tar sikte på å sikre at hver gren som vises i hver betinget struktur blir utført i kildekoden. For eksempel, i ovennevnte kode, skal alle 'Hvis' -uttalelsene og eventuelle tilhørende 'Annet' -uttalelser dekkes av testen for 100% avgrensningsdekning.

For eksempel, i koden ovenfor hvis verdisett (2, 3), (4, 2), (1, 1) blir brukt, vil avgrensningsdekningen være 100%. Når datasettet (2, 3) brukes, blir (b> a) og den første 'Hvis' grenen utført. Tilsvarende, når datasett (4, 2) brukes, så (a> b) evalueres til sant, og den andre 'Hvis' grenen blir utført.

Så med datasettet (1, 1) evaluerer 'Else' -grenen til sann og blir henrettet. Dermed sikrer du 100% grendekning.

Grendekning mot tilstandsdekning

Grendekning forveksles ofte med tilstandsdekning, men de to er forskjellige.

La oss forstå dette med et enkelt eksempel.

If (a >0) & (b >0) Then Print “Hello” Else Print “Bye”

La oss skrive ned datasettet som er nødvendig for å fullføre det Gren dekning:

(1, 1) - I dette tilfellet er ‘a’ og ‘b’ sanne, så Hvis-tilstanden blir utført.
(1, 0) - I dette tilfellet er ‘a’ sant og ‘b’ ville være usant, så den andre delen av koden utføres.

Som vi vet er formålet med filialdekning å få alle filialer henrettet minst en gang, og dette formålet er oppnådd.

Tilstandsdekning:

(1, 0) - I dette tilfellet er 'a' sant og 'b' ville være falskt.
(0, 1) - I dette tilfellet er ‘a’ feil og ‘b’ ville være sant.

Hensikten med tilstandsdekning er å få hvert sant og usant for hver tilstand utført, og dette formålet oppnås her.

Har du lagt merke til at den andre delen ikke blir utført i tilstandsdekning? Det er her Tilstandsdekning avviker fra avdeling.

Verktøy for kodedekning

For å måle kodedekningen for hvilken som helst programvare, er det flere verktøy tilgjengelig i markedet.

Nedenfor er noen av verktøyene for din referanse:

  • Parasoft JTest
  • Testwell CTC ++
  • Dekning
  • JaCoCo
  • CodeCover
  • BullseyeCoverage
  • EMMA
  • OpenCover
  • NCover
  • Squish COCO
  • CoverageMeter
  • GCT
  • TCAT C / C ++
  • Gretel
  • JCov

Anbefalt lesing => Kode Dekningsverktøy

Ovenstående lenke vil inneholde følgende informasjon om disse verktøyene:

  • Nøkkelegenskaper
  • Lisens Type
  • Offisiell URL
  • Fordeler og ulemper
  • Siste versjon

fordeler

Som vist ovenfor er det en veldig nyttig testmåling av årsakene nedenfor:

  • Det hjelper med å identifisere de områdene i en kildekode som vil forbli uprøvd / avdekket av testene.
  • Det er nyttig når du skal identifisere brukt / død kode og dermed forbedre kodekvaliteten.
  • Effektiviteten til enhetstestene kan være kjent ved hjelp av kodedekning.
  • Programvare med bedre kvalitet kan leveres ved hjelp av disse beregningene.

Ulemper

  • Å prøve å sikte på en 100% kodedekning fører noen ganger til manglende robusthet i testene, noe som resulterer i at du går glipp av å fange feilutsatte scenarier.
  • I motsetning til den vanlige oppfatningen, kan den ikke garantere om den designede programvaren tilfredsstiller alle kravene.

Myter mot fakta

MyteFaktum
Å ha 100% kodedekning sikrer at programvaren ikke har noen feil.Nei, 100% kodedekning kan ikke garantere en feilfri programvare. En god kodedekning kombinert med god innsats fra QC-teamet kan sikre en programvare med minimale eller ingen feil.
Å ha 100% kodedekning betyr at den skrevne koden er perfekt.Nei, faktisk, hvis viktige krav ikke først er fanget av koden, kan ikke koden betegnes som perfekt til tross for at kodedekningen er 100%.
Kodedekning måler effektiviteten av tester utført på et programvareprodukt.Nei, kodedekning er bare et mål som brukes til å teste effektiviteten av enhetstester, dvs. testene som bare er utført på kildekoden til en programvare.

FAQ's

Q # 1) Hva er akseptabel kodedekning?

Svar: Å oppnå 100% kodedekning bør ikke være målet mens du tester programvarekode for enhet. Men hvorfor ikke? For å forstå grunnen til at du kanskje må dykke litt dypere for å forstå den underliggende betydningen.

Når vi målretter 100% dekning, skjer det oftere at alt fokuset i utformingen av testene går til å sikre om hver uttalelse, løkke, gren eller tilstand blir testet. Så vi legger opp for mye innsats som kanskje ikke er verdt å vurdere tiden som brukes.

Videre resulterer fokusering på høy dekning også i at du går glipp av viktige scenarier som sannsynligvis vil ha feilene, fordi alt vi satser på er å sikre at hver kodelinje blir testet.

Å fokusere på høy kodedekning er ikke alltid så viktig, og det kan verken være et fast tall å målrette for å teste forskjellige koder. Generelt sett bør en dekning på 75-80% imidlertid være et ideelt tall.

Mens du tester koden vår, bør hovedfokuset ligge på å sørge for å dekke de kritiske og sannsynlige feilutsatte scenariene. Hvis disse blir savnet, vil testene våre ganske enkelt ha dårlig testeffektivitet til tross for at de har 100% kodedekning.

Q # 2) Hvordan sjekker jeg kodedekningen min?

Svar: For å teste prosentandelen av kodedekning som du kanskje har oppnådd ved testene designet for å teste koden, har vi flere verktøy i markedet. Avhengig av hvilket programmeringsspråk vi bruker, har vi forskjellige verktøy.

Noen av dem er oppført nedenfor:

  • Java - Dekning, JaCoCo
  • Javascript - Blanket.js, Istanbul
  • Python - Coverage.py
  • Rubin - SimpleCov

Ved hjelp av disse verktøyene kan vi få en fullstendig dekningsrapport om testene våre som hjelper oss å vite hvilken del av koden som vil bli utført og hvilken som vil bli savnet av testene våre.

Q # 3) Er kodedekning en god beregning?

Svar: I virkelige scenarier er dette nyttig til en viss grad og på noen spesielle måter.

Ser vi først på begrensningene, vet vi veldig godt at å ha 100% dekning ikke garanterer at koden er feilfri, og det garanterer heller ikke at alle kravene er dekket i koden, dvs. til tross for 100% kodedekning vi er veldig sannsynlig å ha feil i koden, årsaken er at dekning ikke sikrer at alle scenarier er testet.

Videre, hvis krav har blitt hoppet over mens du skriver koden, er det ingen kartlegging av krav med koden som blir ivaretatt som en del av kodedekningen.

Når det er sagt, kan vi ikke nekte for at når vi bruker kodedekning som beregninger, gir det oss en ide om vi har dekket de grunnleggende kravene for å teste hver linje i koden vår. Denne dekningsprosenten gir oss en ide om hvor mange deler av koden vår som blir utført med enhetstestene våre.

Vi blir kjent med hvor mye av koden vår som ikke blir utført. Dette hjelper oss igjen å bestemme hvor mye flere enhetstester som trengs og for hvilke deler av koden.

Vi kan således konkludere med at dårlig dekning gir oss en ide om ineffektiviteten til enhetstestene. Samtidig er det ikke en garanti for en feilfri kode å sikre en 100% dekning. Dermed må man ha en balansert tilnærming der vi ikke understreker viktigheten av å målrette en høy Kodedekningsprosent.

Q # 4) Hvordan kan jeg forbedre kodedekningen min?

Svar: Kodedekkingsrapporten som er levert av dekningsverktøy som JaCoCo, Istanbul, etc. viser områdene som dekkes av testene, og også de som ville bli uprøvd.

hvordan man erklærer en strengmatrise i java

Ved å kjenne de uprøvde delene av koden, kan tester skrives enten manuelt eller ved hjelp av et hvilket som helst automatiseringsverktøy for å dekke områdene som ellers ville blitt uprøvd og dermed øke kodedekningen.

En viktig ting å merke seg her er at mens vi kan skrive hundrevis av kodelinjer for å teste en funksjon i kode, men fortsatt kan dekningen være veldig mindre. Årsaken er at å bli for dyp til å teste en del av den enorme koden ikke vil hjelpe til med å øke kodedekning.

Dermed, hvis målet er å øke dekningen, må det tas hensyn til å dekke alle funksjonene, forholdene og løkkene i stedet for å dykke dypt i en enkelt funksjon og skrive store tester for den enkelt funksjonen.

Konklusjon

Et programvare av høy kvalitet er det som kreves i dagens raske internettverden.

Å sikre programvare av god kvalitet er ikke bare en QA-ingeniørs ansvar, men det er også utviklerens ansvar. Kodedekning er altså til stor nytte når det gjelder å levere et kvalitetsprodukt til QA-teamet av utvikleren (e).

Denne opplæringen forklarte alt om kodedekning og bruken. Vi gravde også litt dypere inn i å forstå forskjellen mellom kodedekning og testdekning. I tillegg til dette fikk vi en forståelse av metodene som ble brukt sammen med en rekke verktøy for kodedekning.

Fordeler og ulemper ble orientert her. Til slutt sprengte vi noen av mytene og ofte stilte spørsmål knyttet til kodedekning

Glad lesning !!

Anbefalt lesing

^