code coverage tutorial
In deze uitgebreide tutorial wordt uitgelegd wat codedekking is bij softwaretests, de typen, voordelen en nadelen:
Het uiteindelijke doel van elk softwareontwikkelingsbedrijf is om software te ontwikkelen die van goede kwaliteit is. Om dit doel te bereiken, moet de software grondig worden getest.
Testen is dus een integraal onderdeel van het ontwikkelen van een softwareapplicatie. Daarom is het essentieel dat de ontwikkelde software wordt beoordeeld door de ontwikkelaar (dit wordt gedaan tijdens de testfase van de eenheid) en vervolgens wordt doorgegeven aan het QC-team om grondig te worden getest om er zeker van te zijn dat het minimale of geen bugs bevat.
De software wordt unit-getest voordat deze voor testen aan het eigenlijke testteam wordt vrijgegeven. Aangezien deze tests testen op codeniveau omvatten, wordt dit gedaan door de ontwikkelaar. Dit wordt gedaan om ervoor te zorgen dat elk onderdeel van de code die wordt getest, werkt zoals verwacht.
Hier worden kleine stukjes code die zijn ontwikkeld afzonderlijk getest om hun juistheid te garanderen. Maar de vraag die vaak in de geest van een ontwikkelaar opdoemt, is hoeveel eenheidstesten er moeten worden gedaan en het antwoord hierop ligt in de Code Coverage.
Deze tutorial geeft je een grondige kennis van wat Code Coverage is en waarom we het nodig hebben. Je zou leren hoe het verschilt van Test Coverage.
We zullen ook de tools en methodologieën bekijken die worden gebruikt voor codedekking en tegen het einde van deze tutorial zouden we de voordelen en de nadelen ervan zien. Enkele van de mythes die verband houden met codedekking komen hier ook aan bod.
Wat je leert:
Wat is codedekking
Dit is een belangrijke meeteenheid voor het testen van eenheden. Het is handig om de effectiviteit van unit-tests te kennen. Het is een maatstaf die aangeeft welk percentage van de broncode wordt uitgevoerd tijdens het testen.
In simpele termen, de mate waarin de broncode van een softwareprogramma of een applicatie wordt uitgevoerd tijdens het testen, wordt codedekking genoemd.
Als de tests het hele stuk code uitvoeren, inclusief alle branches, voorwaarden of loops, dan zouden we zeggen dat er volledige dekking is van alle mogelijke scenario's en dat de codedekking dus 100% is. Laten we een voorbeeld nemen om dit nog beter te begrijpen.
Hieronder staat een eenvoudige code die wordt gebruikt om twee getallen toe te voegen en het resultaat weer te geven afhankelijk van de waarde van het resultaat.
Het bovenstaande programma heeft twee ingangen, namelijk ‘a’ en ‘b’. De som van beide wordt opgeslagen in variabele c. Als de waarde van c kleiner is dan 10, wordt de waarde van ‘c’ afgedrukt, anders wordt ‘Sorry’ afgedrukt.
Als we nu een aantal tests hebben om het bovenstaande programma te valideren met de waarden van a & b zodat de som altijd kleiner is dan 10, dan wordt het andere deel van de code nooit uitgevoerd. In een dergelijk scenario zouden we zeggen dat de dekking niet volledig is.
Dit was slechts een klein voorbeeld om de betekenis van codedekking te verduidelijken. Naarmate we meer onderzoeken, krijgt u er meer duidelijkheid over.
Waarom we codedekking nodig hebben
(beeld bron
Verschillende redenen maken codedekking essentieel en enkele daarvan worden hieronder opgesomd:
hoe bekijk ik een xml-bestand
- Het helpt om vast te stellen dat de software minder bugs bevat in vergelijking met software die geen goede codedekking heeft.
- Door te helpen bij het verbeteren van de codekwaliteit, helpt het indirect bij het leveren van een betere ‘kwaliteit’ software.
- Het is een maatstaf die kan worden gebruikt om de testeffectiviteit te kennen (effectiviteit van de unit-tests die worden geschreven om de code te testen).
- Helpt bij het identificeren van die delen van de broncode die niet getest zouden worden.
- Het helpt om te bepalen of de huidige tests (unit testing) voldoende zijn of niet en of er nog meer tests nodig zijn.
Codedekking versus testdekking
Om het verschil tussen codedekking en testdekking te begrijpen, laten we eerst de betekenis van testdekking begrijpen.
Testdekking
Het is een maatstaf voor hoeveel delen van de verwachte tests zijn afgedekt tijdens het testen van software. Door ‘Verwachte testen’ we bedoelen de volledige set testcases die zijn geschreven om te worden uitgevoerd om een bepaalde software te testen.
Stel dat voor het testen van software een set van in totaal 500 testcases is geschreven. Nu werden als onderdeel van de testactiviteit slechts 300 testcases uitgevoerd. Laten we aannemen dat dit te wijten is aan tijdgebrek. In dit geval zou het onderstaande de testdekking zijn.
Testdekking = (uitgevoerde testgevallen / totaal aantal testgevallen) * 100
= (300/500) * 100
= 60%
Laten we dit vergelijken met wat Code Coverage is.
Code dekking
Het is een maat die laat zien in hoeverre een broncode van een applicatie wordt uitgevoerd tijdens het testen van de code. Het toont dus de mate waarin een broncode zou worden getest.
Stel dat u een toepassing test met 500 regels code, dan worden slechts 400 regels van de code uitgevoerd door tests. Laten we aannemen dat dit komt doordat een bepaalde lus / conditie niet wordt uitgevoerd. In dit geval zou het onderstaande de codedekking zijn.
Code Coverage = (aantal uitgevoerde regels code / totaal aantal regels code) * 100
= (400/500) * 100
= 80%
voorbeelden van c ++ -programma's die functies gebruiken
Hieronder staan de verschillen tussen codedekking en testdekking vermeld:
Testdekking | Code dekking |
---|---|
Het is een maatstaf voor hoeveel deel van de verwachte testen is gedekt tijdens het testen van software. | Het is een maat die laat zien in hoeverre een broncode van een applicatie wordt uitgevoerd tijdens het testen van de code. |
De testdekking kan worden berekend met behulp van de onderstaande formule: Testdekking = (uitgevoerde testgevallen / totaal aantal testgevallen) * 100 | De codedekking kan worden berekend met behulp van de onderstaande formule: Code Coverage = (aantal uitgevoerde regels code / totaal aantal regels code) * 100 |
Methodologieën
Hier zullen we de verschillende methoden bespreken die zijn / kunnen worden gebruikt om de codedekking te meten.
Laten we het onderstaande codefragment eens bekijken om deze methodologieën te begrijpen:
Verklaring dekking
Deze methodologie is een maatstaf die aangeeft of alle mogelijke uitvoerbare verklaringen van code in de broncode minstens één keer zijn uitgevoerd. Het is een methode om ervoor te zorgen dat elke regel van de broncode minstens één keer door de tests wordt gedekt.
Dit klinkt misschien eenvoudig, maar voorzichtigheid is geboden bij het meten van de dekking van het overzicht. De reden hiervoor is dat er in een broncode een bepaalde voorwaarde kan zijn die mogelijk niet wordt uitgevoerd, afhankelijk van de invoerwaarden.
Dit zou betekenen dat niet alle regels code worden getest. Het is dus mogelijk dat we verschillende invoerwaardesets moeten gebruiken om al dergelijke voorwaarden in de broncode te dekken.
Bijvoorbeeld, in de bovenstaande broncode als invoerwaarden worden genomen als 2 & 3, wordt het ‘Else’ -gedeelte van de code niet uitgevoerd. Als de invoerwaarden echter van het type 3 en 2 zijn, wordt het ‘If’ -gedeelte van de code niet uitgevoerd.
Dit betekent dat met beide sets van waarden van onze Statement Coverage niet 100% zou zijn. In dat geval moeten we de tests mogelijk uitvoeren met alle drie de ((2, 3), (3, 2), (0, 0)) set waarden om 100% Statement Coverage te garanderen.
Functiedekking
Zoals de naam doet vermoeden, meet deze methodologie de mate waarin de functies die aanwezig zijn in de broncode worden afgedekt tijdens het testen. Alle functies die in de broncode staan, worden getest tijdens het uitvoeren van de test. Nogmaals, er moet voor worden gezorgd dat we deze functies testen voor verschillende waarden, zodat de functie grondig wordt getest.
In een broncode kunnen er meerdere functies zijn en afhankelijk van de gebruikte invoerwaarden kan een functie al dan niet worden aangeroepen. Het doel van Function Coverage is dus om ervoor te zorgen dat we elke functie hebben die nodig is.
Bijvoorbeeld, in de broncode hierboven, als onze tests de ‘Toevoegen’ functie zelfs maar één keer aanroepen, dan noemen we dit een volledige functiedekking.
Conditie dekking
In een broncode, waar we ook een voorwaarde hebben, zou het resultaat een Booleaanse waarde zijn van true of false. Condition Coverage is bedoeld om vast te stellen of de tests beide waarden dekken, d.w.z. waar, onwaar.
Wanneer in de broncode elke voorkomende voorwaarde wordt geëvalueerd voor zowel ware als valse toestanden, wordt gezegd dat de conditiedekking voor de code volledig is.
Bijvoorbeeld, in de bovenstaande code als waardensets (2, 3) en (4, 2) worden gebruikt, dan zou de conditiedekking 100% zijn. Wanneer dataset (2, 3) wordt gebruikt, evalueert (b> a) naar true en (a> b) evalueert naar false. Evenzo, wanneer gegevensset (4, 2) wordt gebruikt, evalueert (b> a) naar onwaar en (a> b) evalueert naar waar.
Dus beide voorwaarden hebben beide waarden, d.w.z. waar en niet waar. Daarom is de dekking van de voorwaarden 100%.
Branch dekking
Deze methodologie is bedoeld om ervoor te zorgen dat elke branch die in elke voorwaardelijke structuur verschijnt, wordt uitgevoerd in de broncode. In de bovenstaande code moeten bijvoorbeeld alle 'If'-verklaringen en alle bijbehorende' Else'-verklaringen allemaal worden gedekt door de test voor een 100% Branch Coverage.
Bijvoorbeeld, in de bovenstaande code als waardensets (2, 3), (4, 2), (1, 1) worden gebruikt, dan is de Branch Coverage 100%. Als dataset (2, 3) wordt gebruikt, wordt (b> a) en de eerste ‘If’ -tak uitgevoerd. Evenzo, wanneer dataset (4, 2) wordt gebruikt, evalueert (a> b) naar true en wordt de tweede ‘If’ -tak uitgevoerd.
Dan met de dataset (1, 1) evalueert de ‘Else’ branch als true en wordt uitgevoerd. Daardoor wordt 100% dekking van filialen gegarandeerd.
Bijkantoordekking versus conditiedekking
Branch Coverage wordt vaak verward met Condition Coverage, maar de twee zijn verschillend.
Laten we dit begrijpen met een eenvoudig voorbeeld.
Laten we de dataset opschrijven die nodig is voor het voltooien Branch dekking:
(1, 1) - In dit geval zijn ‘a’ en ‘b’ beide waar, dus de voorwaarde If wordt uitgevoerd.
(1, 0) - In dit geval is ‘a’ waar en ‘b’ onwaar, dus het Else-gedeelte van de code wordt uitgevoerd.
Zoals we weten, is het doel van Branch Coverage om elke branch minstens één keer te laten uitvoeren en dit doel wordt bereikt.
Conditie dekking:
(1, 0) - In dit geval is ‘a’ waar en ‘b’ niet waar.
(0, 1) - In dit geval is ‘a’ onwaar en zou ‘b’ waar zijn.
Het doel van Condition Coverage is om zowel true als false voor elke conditie te laten uitvoeren en dit doel wordt hier bereikt.
Is het u opgevallen dat het andere deel niet wordt uitgevoerd in Conditiedekking? Dit is waar Condition Coverage verschilt van Branch Coverage.
Tools voor codedekking
Om de codedekking van software te meten, zijn er verschillende tools op de markt beschikbaar.
Hieronder vindt u enkele van de tools ter referentie:
- Parasoft JTest
- Testwell CTC ++
- Dekking
- JaCoCo
- CodeCover
- BullseyeCoverage
- EMMA
- OpenCover
- NCover
- Knijp COCO
- Dekking Meter
- GCT
- TCAT C / C ++
- Grietje
- JCov
Aanbevolen literatuur => Tools voor codedekking
De bovenstaande link bevat de volgende informatie over deze tools:
- Belangrijkste kenmerken
- Licentie type
- Officiële URL
- Voors en tegens
- Laatste versie
Voordelen
Zoals hierboven te zien is, zijn het om de onderstaande redenen een zeer nuttige teststatistiek:
- Het helpt om die gebieden in een broncode te identificeren die door de tests niet zouden worden getest / ontdekt.
- Het is handig bij het identificeren van gebruikte / dode code waardoor de kwaliteit van de code wordt verbeterd.
- De effectiviteit van de unit tests kan worden gekend met behulp van Code Coverage.
- Met behulp van deze statistieken kan software van betere kwaliteit worden geleverd.
Nadelen
- Proberen te streven naar een codedekking van 100% veroorzaakt soms een gebrek aan robuustheid van de tests, waardoor de foutgevoelige scenario's mislopen.
- In tegenstelling tot wat vaak wordt gedacht, kan het niet garanderen of de ontworpen software aan alle vereisten voldoet.
Mythen versus feiten
Mythe | Feit |
---|---|
Het hebben van 100% codedekking zorgt ervoor dat de software geen bugs bevat. | Nee, 100% codedekking kan geen bugvrije software garanderen. Een goede codedekking in combinatie met de goede inspanningen van het QC-team kan een software met minimale of geen bugs garanderen. |
Met 100% codedekking betekent dat de geschreven code perfect is. | Nee, als belangrijke vereisten in de eerste plaats niet door de code zijn vastgelegd, kan de code niet als perfect worden bestempeld, ondanks dat de codedekking 100% is. |
Code Coverage meet de effectiviteit van tests die op een softwareproduct zijn uitgevoerd. | Nee, codedekking is slechts een maatstaf die wordt gebruikt om de effectiviteit van unit-tests te testen, d.w.z. de tests die alleen op de broncode van een software worden uitgevoerd. |
Veelgestelde vragen
V # 1) Wat is een acceptabele codedekking?
Antwoord: Het bereiken van 100% codedekking zou niet het doel moeten zijn bij het testen van softwarecode. Maar waarom niet? Om de reden te begrijpen, moet u misschien wat dieper duiken om de onderliggende betekenis te begrijpen.
Wanneer we streven naar een dekking van 100%, komt het vaker voor dat alle aandacht bij het ontwerpen van de tests wordt besteed aan het controleren of elke instructie, lus, vertakking of voorwaarde wordt getest. Dus we komen terecht met te veel inspanningen die misschien niet de moeite waard zijn gezien de bestede tijd.
Bovendien resulteert het focussen op een hoge dekking ook in het mislopen van de belangrijke scenario's die waarschijnlijk de defecten zullen hebben, omdat het enige dat we willen is ervoor te zorgen dat elke regel code wordt getest.
Focussen op een hoge codedekking is niet altijd zo belangrijk en het kan ook geen vast nummer zijn om op verschillende codes te testen. Over het algemeen zou een dekking van 75% - 80% echter een ideaal getal moeten zijn.
Bij het testen van onze code moet de nadruk vooral liggen op het dekken van de kritieke en waarschijnlijke foutgevoelige scenario's. Als deze worden gemist, zouden onze tests, ondanks een codedekking van 100%, gewoon een slechte testeffectiviteit hebben.
Q # 2) Hoe controleer ik mijn codedekking?
Antwoord: Om het percentage codedekking te testen dat u mogelijk hebt behaald met de tests die zijn ontworpen voor het testen van de code, hebben we verschillende tools op de markt. Afhankelijk van de programmeertaal die men gebruikt hebben we verschillende tools.
hoe je een grafiek maakt in java
Sommigen van hen zijn hieronder opgesomd:
- Java - Dekking, JaCoCo
- Javascript - Blanket.js, Istanbul
- Python - Coverage.py
- Robijn - SimpleCov
Met behulp van deze tools kunnen we een volledig dekkingsrapport krijgen van onze tests, zodat we weten welk deel van de code zou worden uitgevoerd en welke door onze tests zouden worden gemist.
Q # 3) Is codedekking een goede maatstaf?
Antwoord: In real-life scenario's is dit tot op zekere hoogte en op een aantal specifieke manieren nuttig.
Als we eerst naar de beperkingen kijken, weten we heel goed dat het hebben van een dekking van 100% niet garandeert dat de code geen fouten bevat, noch dat alle vereisten zijn gedekt in de code, dat wil zeggen, ondanks een dekking van 100% zeer waarschijnlijk bugs in de code, de reden is dat dekking niet garandeert dat alle scenario's zijn getest.
Bovendien, als vereisten zijn overgeslagen tijdens het schrijven van de code, is er geen mapping van vereisten met de code die wordt afgehandeld als onderdeel van de codedekking.
Dat gezegd hebbende, kunnen we niet ontkennen dat wanneer we codedekking als metriek gebruiken, het ons een idee geeft of we aan de basisvereisten voor het testen van elke regel van onze code hebben voldaan. Dit dekkingspercentage geeft ons een idee van hoeveel delen van onze code worden uitgevoerd met onze unit-tests.
We komen te weten hoeveel van onze code niet zou worden uitgevoerd. Dit helpt ons op zijn beurt om te beslissen hoeveel meer unit-tests nodig zijn en voor welke delen van de code.
We kunnen dus concluderen dat het hebben van een slechte dekking ons een idee geeft van de ineffectiviteit van de unit-tests. Tegelijkertijd is het garanderen van 100% dekking geen garantie voor een defectvrije code. Er is dus een evenwichtige aanpak nodig waarbij we het belang van een hoog percentage codedekking niet te sterk benadrukken.
Q # 4) Hoe kan ik mijn codedekking verbeteren?
Antwoord: Het codedekkingsrapport dat wordt verstrekt door dekkingsinstrumenten zoals JaCoCo, Istanbul, enz. Toont de gebieden die worden gedekt door de tests en ook de gebieden die niet getest zouden worden.
Door de niet-geteste delen van de code te kennen, kunnen tests handmatig of met behulp van een automatiseringstool worden geschreven om de gebieden te dekken die anders niet zouden worden getest en daardoor de codedekking te vergroten.
Een belangrijk ding om hier op te merken is dat hoewel we honderden regels code kunnen schrijven om een functie in code te testen, de dekking mogelijk veel minder is. De reden is dat te diep gaan om een deel van de enorme code te testen, niet zal helpen om de codedekking te vergroten.
Dus als het doel is om de dekking te vergroten, moet ervoor worden gezorgd dat alle functies, condities en lussen worden afgedekt in plaats van diep in een enkele functie te duiken en grote tests voor die enkele functie te schrijven.
Gevolgtrekking
Een hoogwaardig softwareproduct is wat nodig is in de snelle internetwereld van vandaag.
Zorgen voor software van goede kwaliteit is niet alleen de verantwoordelijkheid van een QA Engineer, maar ook de verantwoordelijkheid van de ontwikkelaar. Code Coverage is dus van groot nut als het gaat om het leveren van een kwaliteitsproduct aan het QA-team door de ontwikkelaar (s).
In deze tutorial werd alles uitgelegd over codedekking en het gebruik ervan. We zijn ook wat dieper ingegaan op het verschil tussen codedekking en testdekking. Daarnaast hebben we inzicht gekregen in de methodologieën die worden gebruikt, samen met een verscheidenheid aan Code Coverage-tools.
Voordelen en nadelen werden hier geïnformeerd. Ten slotte hebben we enkele van de mythes en veelgestelde vragen over codedekking ontkracht
Veel leesplezier !!
Aanbevolen literatuur
- Top 15 tools voor codedekking (voor Java, JavaScript, C ++, C #, PHP)
- 15 beste JAVA-tools voor ontwikkeling, build, profiler, codedekking en beoordeling
- C # Functies / methoden zelfstudie met codevoorbeelden
- C # Tutorial voor het afhandelen van uitzonderingen met codevoorbeelden
- Tortoise SVN-zelfstudie: herzieningen in coderepository
- Zelfstudie over Java-array-lengte met codevoorbeelden
- AWS CodeBuild-zelfstudie: code extraheren uit Maven Build
- SVN-zelfstudie: broncodebeheer met behulp van Subversion