Kodtäckningshandledning: Filial, uttalande, funktionstäckning

code coverage tutorial

Denna omfattande handledning förklarar vad som är kodtäckning vid programvarutestning, dess typer, fördelar och nackdelar:

Det slutgiltiga målet för alla programvaruutvecklingsföretag är att utveckla programvara av god kvalitet. För att uppnå detta mål måste programvaran testas grundligt.

Testning är således en integrerad del av utvecklingen av en programvara. Därför är det viktigt att den utvecklade programvaran granskas av utvecklaren (som görs under enhetstestningsfasen) och sedan skickas till QC-teamet för att testas grundligt för att säkerställa att den har minimala eller inga buggar.

Programvaran är enhetstestad innan den släpps till testgruppen för testning. Eftersom denna testning innefattar testning på kodnivå görs det av utvecklaren. Detta görs för att säkerställa att varje del av koden som testas fungerar som förväntat.

Här testas små bitar av kod som har utvecklats isolerat för att säkerställa att de är korrekta. Men frågan som ofta väcks hos en utvecklare är hur mycket av enhetstester som ska göras och svaret på detta ligger i kodtäckningen.

Denna handledning ger dig en djup kunskap om vad kodtäckning är och varför vi behöver det. Du skulle få veta hur det skiljer sig från testtäckning.

Vi tar också en titt på verktygen och metoderna som används för kodtäckning och mot slutet av denna handledning skulle vi se fördelarna tillsammans med dess nackdelar. Några av de myter som är förknippade med kodtäckning skulle också behandlas här.

Vad du kommer att lära dig:

• Vad är kodtäckning
  • Varför vi behöver kodtäckning
• Kodtäckning mot testtäckning
  • Metoder
    • Uttalande täckning
    • Funktionstäckning
    • Skyddstäckning
    • Filialtäckning
  • Verktyg för kodtäckning
  • Fördelar
  • Nackdelar
  • Myter mot fakta
  • Vanliga frågor
• Slutsats
  • Rekommenderad läsning

Vad är kodtäckning

Detta är ett viktigt mått för enhetstestning. Det är praktiskt att veta effektiviteten av enhetstester. Det är ett mått som anger vilken procentandel av källkoden som skulle köras under testningen.

I enkla termer, i vilken utsträckning källkoden för ett program eller ett program kommer att köras under testningen är vad som kallas kodtäckning.

Om testerna utför hela koden inklusive alla grenar, villkor eller slingor, skulle vi säga att det finns fullständig täckning av alla möjliga scenarier och därmed är kodtäckningen 100%. Låt oss ta ett exempel för att förstå detta ännu bättre.

Nedan följer en enkel kod som används för att lägga till två siffror och visa resultatet beroende på resultatet.

Ovanstående program tar in två ingångar, dvs 'a' och 'b'. Summen av båda lagras i variabel c. Om värdet på c är mindre än 10, så skrivs värdet av 'c' ut annars 'Tyvärr' skrivs ut.

Nu, om vi har några tester för att validera ovanstående program med värdena a & b så att summan alltid är mindre än 10, så körs den andra delen av koden aldrig. I ett sådant scenario skulle vi säga att täckningen inte är fullständig.

Detta var bara ett litet exempel för att klargöra innebörden av kodtäckning. När vi utforskar mer kommer du att få bättre klarhet i det.

Varför vi behöver kodtäckning

(bild källa )

Olika skäl gör kodtäckning väsentlig och några av dem listas nedan:

hitta kommando i unix med exempel

• Det hjälper till att säkerställa att programvaran har mindre fel jämfört med programvaran som inte har en bra kodtäckning.
• Genom att hjälpa till att förbättra kodkvaliteten hjälper det indirekt att leverera en bättre ”kvalitet” -programvara.
• Det är ett mått som kan användas för att känna till testets effektivitet (effektiviteten för enhetstesterna som skrivs för att testa koden).
• Hjälper till att identifiera de delar av källkoden som skulle gå oproverade.
• Det hjälper till att avgöra om den nuvarande testningen (enhetstestning) är tillräcklig eller inte och om det behövs några fler tester också.

Kodtäckning mot testtäckning

För att förstå skillnaden mellan kodtäckning och testtäckning, låt oss först förstå innebörden av testtäckning.

Test täckning

Det är ett mått på hur många delar av den förväntade testningen har täckts under testning av en programvara. Förbi ”Förväntad testning” vi menar hela uppsättningen testfall som är skrivna för att köras för att testa en viss programvara.

Antag att för att testa en programvara har en uppsättning på totalt 500 testfall skrivits. Nu som en del av testaktiviteten utfördes endast 300 testfall. Låt oss anta att detta beror på tidsbrist. I det här fallet skulle testet täckas nedan.

Testtäckning = (Exekverade testfall / Totalt testfall) * 100
= (300/500) * 100
= 60%

Låt oss jämföra detta med vad kodtäckning är.

Kodtäckning

Det är ett mått som visar i vilken utsträckning en källkod för en applikation körs under testning av koden. Det visar således i vilken grad en källkod skulle testas.

Antag att för att testa en applikation med 500 rader kod, bara 400 rader av koden körs av tester. Låt oss anta att detta beror på att en viss slinga / tillstånd inte körs. I det här fallet skulle nedan täcka kodtäckningen.

Kodtäckning = (antal kodrader som körs / totalt antal rader kod) * 100
= (400/500) * 100
= 80%

Nedan listas skillnaderna mellan kodtäckning och testtäckning:

Metoder

Här ska vi diskutera de olika metoderna som används / kan användas för att mäta kodtäckningen.

För att förstå dessa metoder, låt oss ta en titt på nedanstående kodavsnitt:

Uttalande täckning

Denna metod är ett mått som berättar om alla möjliga körbara uttalanden av kod i källkoden har utförts minst en gång. Det är en metod för att säkerställa att varje rad i källkoden täcks åtminstone en gång av testerna.

Detta kan låta enkelt men försiktighet måste iakttas när man mäter uttalandet. Anledningen är att i en källkod kan det finnas ett visst tillstånd som kanske inte körs beroende på ingångsvärdena.

Detta skulle innebära att alla kodrader inte skulle täckas under testning. Således kan vi behöva använda olika ingångsvärden för att täcka alla sådana villkor i källkoden.

Till exempel, i ovannämnda källkod om ingångsvärden tas som 2 & 3, så skulle 'Else' -delen av koden inte köras. Men om ingångsvärdena är av typ 3 & 2 kommer inte 'If'-delen av koden att köras.

Detta innebär att med vardera uppsättningen värden i vårt uttalande skulle täckningen inte vara 100%. I ett sådant fall kan vi behöva utföra testerna med alla tre ((2, 3), (3, 2), (0, 0)) värden för att säkerställa 100% uttalande täckning.

Funktionstäckning

Som namnet antyder mäter denna metod i vilken utsträckning funktionerna i källkoden täcks under testningen. Alla funktioner som finns i källkoden testas under testkörningen. Återigen måste det säkerställas att vi testar dessa funktioner för olika värden så att funktionen testas noggrant.

I en källkod kan det finnas flera funktioner och beroende på vilka ingångsvärden som används kan en funktion anropas eller inte. Syftet med funktionstäckning är således att säkerställa att vi har varje funktion som krävs.

Till exempel, i källkoden ovan om våra tester kallar 'Lägg till' -funktionen ens en gång, då skulle vi kalla detta som ett komplett funktionsdäck.

Skyddstäckning

I en källkod varhelst vi har ett villkor skulle resultatet vara ett booleskt värde antingen sant eller falskt. Villkorstäckning syftar till att fastställa om testerna täcker både värdena, dvs. sant, falskt.

I källkoden, när varje förekommande tillstånd utvärderas för både sanna och falska tillstånd, sägs villkorstäckningen för koden vara fullständig.

Till exempel, i ovannämnda kod om värdesatser (2, 3) och (4, 2) används, skulle villkorstäckningen vara 100%. När datamängden (2, 3) används utvärderas (b> a) till true och (a> b) utvärderas till false. På samma sätt, när datamängden (4, 2) används, utvärderas (b> a) till falskt och (a> b) utvärderas till sant.

bästa gratis video till DVD-omvandlare

Således täcker båda villkoren både värdena dvs sant och falskt. Följaktligen skulle villkorstäckningen vara 100%.

Filialtäckning

Denna metod syftar till att säkerställa att varje gren som visas i varje villkorlig struktur körs i källkoden. Till exempel, i ovanstående kod, bör alla ”If” -uttalanden och eventuella medföljande ”Else” -uttalanden täckas av testet för 100% filialtäckning.

Till exempel, i ovanstående kod om värdesatser (2, 3), (4, 2), (1, 1) används så skulle grengraden vara 100%. När datamängden (2, 3) används så (b> a) och den första 'If' -grenen körs. På samma sätt, när datamängden (4, 2) används, utvärderas (a> b) till true och den andra 'If' -grenen körs.

Sedan med datauppsättningen (1, 1) utvärderas 'Else' -grenen till sant och körs. Därigenom säkerställer du 100% filialtäckning.

Filialtäckning mot villkorstäckning

Filialtäckning förväxlas ofta med villkorstäckning, men de två är olika.

Låt oss förstå detta med ett enkelt exempel.

Låt oss skriva ner den datamängd som behövs för fullständig Filialtäckning:

(1, 1) - I det här fallet är 'a' och 'b' båda sanna, så om villkoret If körs.
(1, 0) - I det här fallet är 'a' sant och 'b' skulle vara falskt, så den andra delen av koden körs.

Som vi vet är syftet med filialtäckning att få varje gren att köras minst en gång och detta syfte uppnås.

Skyddstäckning:

(1, 0) - I det här fallet är 'a' sant och 'b' skulle vara falskt.
(0, 1) - I det här fallet är 'a' falskt och 'b' skulle vara sant.

Syftet med villkorstäckning är att få varje sant och falskt för varje tillstånd som utförs och detta syfte uppnås här.

Märkte du att den andra delen inte körs i villkorstäckningen? Här skiljer sig villkorstäckningen från filialtäckningen.

Verktyg för kodtäckning

För att mäta kodtäckningen för vilken programvara som helst finns det flera verktyg tillgängliga på marknaden.

Nedan finns några av verktygen för din referens:

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

Rekommenderad läsning => Verktyg för kodtäckning

Ovanstående länk innehåller följande information om dessa verktyg:

• Nyckelfunktioner
• Licens typ
• Officiell webbadress
• Fördelar och nackdelar
• Senaste versionen

Fördelar

Som framgår ovan är det ett mycket användbart testmått av följande skäl:

• Det hjälper till att identifiera de områden i en källkod som skulle vara otestad / upptäckt av testerna.
• Det är praktiskt att identifiera begagnad / död kod och därigenom förbättra kodkvaliteten.
• Enhetstestens effektivitet kan vara känd med hjälp av kodtäckning.
• Programvara med bättre kvalitet kan levereras med hjälp av dessa mått.

Nackdelar

• Att försöka sikta på en 100% kodtäckning orsakar ibland bristande robusthet i testerna, vilket leder till att man missar att fånga de utsatta scenarierna.
• Till skillnad från den vanliga uppfattningen kan den inte garantera om den designade programvaran uppfyller alla krav.

Myter mot fakta

Vanliga frågor

F # 1) Vad är en acceptabel kodtäckning?

Svar: Att uppnå 100% kodtäckning bör inte vara målet när enhetstestprogramvarukod. Men varför inte? För att förstå anledningen kan du behöva dyka lite djupare för att förstå den underliggande innebörden.

När vi riktar oss till en 100% täckning, händer det oftare att allt fokus vid utformningen av testerna går till att säkerställa om varje uttalande, slinga, gren eller villkor testas. Så vi landar med att göra alltför många ansträngningar som kanske inte är värda att ta hänsyn till den spenderade tiden.

Dessutom resulterar fokusering på hög täckning också i att du missar de viktiga scenarier som sannolikt kommer att ha defekterna, eftersom allt vi strävar efter är att säkerställa att varje kodrad testas.

Att fokusera på en hög kodtäckning är inte alltid så viktigt och det kan inte vara ett fast nummer att rikta in sig för att testa olika koder. I allmänhet bör dock en täckning på 75-80% vara ett idealiskt nummer.

När vi testar vår kod bör huvudfokus ligga på att säkerställa att täcka kritiska och troliga felbenägna scenarier. Om dessa missas skulle våra tester helt enkelt ha dålig testeffektivitet trots att de har 100% kodtäckning.

F # 2) Hur kontrollerar jag min kodtäckning?

Svar: För att testa procentandelen kodtäckning som du kan ha uppnått genom testerna som är utformade för att testa koden har vi flera verktyg på marknaden. Beroende på det programmeringsspråk man använder har vi olika verktyg.

Några av dem listas nedan:

• Java - Täckning, JaCoCo
• Javascript - Blanket.js, Istanbul
• Pytonorm - Coverage.py
• Rubin - SimpleCov

Med hjälp av dessa verktyg kan vi få en fullständig täckningsrapport om våra tester som hjälper oss att veta vilken del av koden som kommer att köras och vilken som missas av våra tester.

F # 3) Är kodtäckning ett bra värde?

Svar: I verkliga scenarier är detta användbart i viss mån och på vissa sätt.

När vi först tittar på dess begränsningar vet vi mycket väl att ha 100% täckning inte garanterar att koden är felfri, och det garanterar inte heller att alla krav har täckts i koden, dvs. trots 100% kodtäckning är vi mycket sannolikt att ha fel i koden, orsaken är att täckningen inte säkerställer att alla scenarier har testats.

Dessutom, om krav har hoppats över när du skriver koden, finns det ingen kartläggning av krav med koden som tas om hand som en del av kodtäckningen.

Med detta sagt kan vi inte förneka att när vi använder kodtäckning som mått, ger det oss en uppfattning om vi har täckt de grundläggande kraven för att testa varje rad i vår kod. Denna täckningsprocent ger oss en uppfattning om hur många delar av vår kod som körs med våra enhetstester.

Vi lär oss hur mycket av vår kod som inte kan utföras. Detta i sin tur hjälper oss att bestämma hur mycket fler enhetstester som behövs och för vilka delar av koden.

Vi kan således dra slutsatsen att att ha dålig täckning ger oss en uppfattning om enhetstestens ineffektivitet. Samtidigt är det inte en garanti för en felfri kod att garantera 100% täckning. Man måste alltså ha ett balanserat tillvägagångssätt där vi inte överbetonar vikten av att rikta in en hög procentsats för kodtäckning.

F # 4) Hur kan jag förbättra min kodtäckning?

Svar: Kodtäckningsrapporten som tillhandahålls av täckningsverktyg som JaCoCo, Istanbul etc. visar de områden som omfattas av testerna och även de som skulle gå oproverade.

Genom att känna till de oprövade delarna av koden kan test skrivas antingen manuellt eller med hjälp av vilket automatiseringsverktyg som helst för att täcka de områden som annars skulle bli oproverade och därmed öka kodtäckningen.

En viktig sak att notera här är att även om vi kan skriva hundratals rader kod för att testa en funktion i kod men ändå kan täckningen vara mycket mindre. Anledningen är att det att bli för djupt för att testa en del av den enorma koden inte hjälper till att öka kodtäckningen.

Således, om målet är att öka täckningen, måste man ta hand om att täcka alla funktioner, förhållanden och slingor istället för att dyka djupt i en enda funktion och skriva stora tester för den enda funktionen.

skillnad mellan kvalitetskontroll och kvalitetssäkring

Slutsats

En högkvalitativ mjukvaruprodukt är det som krävs i dagens snabba internetvärld.

Att säkerställa en högkvalitativ programvara är inte bara en QA-ingenjörs ansvar utan det är också utvecklarens ansvar. Kodtäckning är således till stor nytta när det gäller att leverera en kvalitetsprodukt till QA-teamet av utvecklarna.

Denna handledning förklarar allt om kodtäckning och dess användning. Vi grävde också lite djupare för att förstå skillnaden mellan kodtäckning och testtäckning. Förutom detta fick vi en förståelse för de metoder som används tillsammans med en mängd olika kodtäckningsverktyg.

Fördelar och nackdelar beskrivs här. Slutligen slog vi ner några av de myter och vanliga frågor som är kopplade till kodtäckning

Glad läsning!!

Rekommenderad läsning

• Topp 15 verktyg för kodtäckning (för Java, JavaScript, C ++, C #, PHP)
• 15 bästa JAVA-verktyg för utveckling, byggnad, profilering, kodtäckning och granskning
• C # -funktioner / metodhandledning med kodexempel
• C # Handledning för undantagshantering med kodexempel
• Tortoise SVN Tutorial: Revisions In Code Repository
• Java Array Length Tutorial With Code Exempel
• AWS CodeBuild Tutorial: Extrahera kod från Maven Build
• SVN-handledning: Källkodshantering med subversion