structural testing tutorial what is structural testing
In deze uitgebreide zelfstudie voor structurele tests wordt uitgelegd wat structurele tests zijn, de soorten, wat is controlestroomtesten en controlestroomgrafiek, dekkingsniveaus, enz .:
Een snelle Google-zoektocht naar enkele van de duurste softwarefouten deed me aan het twijfelen - $ 500 miljard. Ja, zo duur kan een bug zijn. Het lezen van alles over verloren levens in de transport- en gezondheidszorgsector als gevolg van een softwarefout kan ook gruwelijk zijn.
Hoewel fouten in de code niet altijd zo extreem zijn als ze gepaard gaan met verlies van grote hoeveelheden geld en levens, is de enige belangrijke opmerking die we hier proberen over te brengen, dat men testen niet over het hoofd kan zien.
Als er in de hele SDLC regelmatig wordt getest, kunnen we bugs opsporen die na verzending van het product veel meer tijd nodig hebben om te herstellen.
Wat van belang is, zijn de soorten softwaretests die we kiezen. Er zijn er verschillende, waaronder functionele, structurele en op verandering gebaseerde tests.
In deze tutorial worden ook structurele testtypen uitgelegd. Leer hoe u mutatietests, slice-based tests en dataflowtests uitvoert in detail met voorbeelden en uitleg.
Wat je leert:
- Waarom is het testen van software belangrijk?
- Wat is structureel testen
- Typen structurele tests
- Voordelen en nadelen van structurele tests
- Best practices voor structureel testen
- Gevolgtrekking
Waarom is het testen van software belangrijk?
Naast het besparen van geld en het vermijden van rampen zoals de hierboven genoemde gevallen, zijn er nog verschillende andere redenen om het belang van testen te rechtvaardigen.
Hieronder staan enkele redenen:
# 1) Om ervoor te zorgen dat aan de gestelde eisen wordt voldaan voordat u begint met het bouwen van een project. Belanghebbenden (bijvoorbeeld ontwikkelaars en klanten) moeten het eens zijn over alle aspecten van de oplossing / product / software die nodig zijn om een project te bouwen.
Bij testen wordt gecontroleerd of aan de softwarevereisten is voldaan. De ontwikkelaar of het bedrijf dat betrokken is bij het bouwen van de oplossing, krijgt ook een goede reputatie voor het ontwerpen van zo'n hoogwaardige oplossing die wordt beheerd door eclat-code.
# 2) Het controleert of de codefunctie werkt zoals bedoeld. Testen omvat ook het verifiëren van de functionaliteit van de software en in geval van een storing, moet dit worden verholpen tijdens de vroege fasen van SDLC (Software Development Life Cycle).
# 3) Het controleert op prestaties: bijvoorbeeld om de totale verstreken tijd tijdens het uitvoeren van code te identificeren. Als we er meerdere gebruiken Voor Loops in onze code duurt het lang om de beoogde uitvoer te krijgen en kan er soms zelfs een time-out optreden.
# 4) Het helpt om een betere gebruikerservaring te bereiken. Gebruikers zullen niet genieten van het gebruik van software die niet goed werkt, bugs bevat of ‘te traag’ is. Gebruikers zullen waarschijnlijk ongeduldig worden en de software gebruiken. Testen geeft ons een betere kans om ervoor te zorgen dat gebruikers onze producten gemakkelijk kunnen gebruiken.
# 5) Het controleert op schaalbaarheid. Een ontwikkelaar moet zich richten op het bouwen van software die kan worden geschaald.
# 6) Het controleert op kwetsbaarheden in de code. Testen stelt ons in staat om te kijken naar beveiligingsproblemen, Bijvoorbeeld, code die een compromis kan sluiten PII (Persoonlijk identificeerbare informatie), wat een hoge prioriteit heeft voor de AVG.
In dit artikel gaan we ons concentreren op één type testen, d.w.z. Structurele testen Zoals de naam suggereert, heeft het te maken met de structuur van de code. Dit is anders dan wat we eerder hadden vermeld, dat testen helpt bij het bepalen van aspecten als codeprestaties, functionaliteit en beveiliging.
Structurele tests versus andere testtypen
Er zijn veel soorten softwaretests. echter, de HOU OP (International Software Testing Qualifications Board), definieert 4 belangrijke soorten softwaretests, namelijk
- Functioneel
- Niet functioneel
- Structureel
- Op verandering gebaseerd
De verschillen kunnen als volgt worden verklaard:
Functioneel testen: Hierbij wordt de functionaliteit van de software getoetst aan de gestelde eisen. Testgegevens worden als invoer gebruikt. We controleren ook of de gegeven output is zoals verwacht.
Niet-functionele testen : Dit omvat een testproces om te analyseren hoe goed de software werkt, bijvoorbeeld, het aantal gebruikers dat het tegelijkertijd kan verwerken.
Structurele testen: Dit type testen is gebaseerd op de structuur van de code. Bijvoorbeeld, Als een code bedoeld is om het gemiddelde van even getallen in een array te berekenen, dan zou op structuur gebaseerde testen meer geïnteresseerd zijn in de ‘stappen die leiden tot het berekenen van het gemiddelde’, in plaats van of de uiteindelijke uitvoer een correcte numerieke waarde is.
Stel dat we moeten controleren of we de code hebben gedefinieerd die even getallen onderscheidt van oneven getallen. We kunnen hier een voorwaardelijke verklaring hebben, zoals, als een array-element deelbaar is door twee zonder een rest, if (arr (i)% 2 === 0) dan kan het nummer worden gezegd als een even getal.
Structurele tests worden uitgevoerd door dezelfde mensen die de code schrijven zoals zij deze het beste begrijpen.
Veranderingsgebaseerd testen : Dit omvat het testen van de effecten van het aanbrengen van wijzigingen in de code en vervolgens controleren of de aangebrachte wijzigingen zijn doorgevoerd. Het zorgt er ook voor dat de wijzigingen in de code deze niet breken.
Wat structureel testen niet is
We hebben eerder vermeld dat structuurgebaseerd testen verwijst naar de structuur van de code. Merk op dat we hier de daadwerkelijke code behandelen. We controleren niet tegen de vereisten en testen zelfs geen inputs tegen de verwachte outputs. We zijn op dit moment niet bezig met functionaliteit, gebruikerservaring of zelfs prestaties.
Wat is structureel testen
Structuurgebaseerd testen kan daarom worden gedefinieerd als een type softwaretest dat de structuur van de code en de beoogde stromen test. Bijvoorbeeld, het verifiëren van de feitelijke code op aspecten als de juiste implementatie van voorwaardelijke statements, en of elk statement in de code correct is uitgevoerd. Het is ook bekend als structuurgebaseerd testen.
Om dit type testen uit te voeren, moeten we de code grondig begrijpen. Dit is de reden waarom deze tests meestal worden uitgevoerd door de ontwikkelaars die de code hebben geschreven zoals zij deze het beste begrijpen.
Hoe structurele tests moeten worden uitgevoerd
Om verschillende aspecten van de code te testen, moeten we eerst de controlestromen begrijpen.
Controle stroomtesten
Dit zijn tests uit de controlestromen van de code (de volgorde waarin instructies, functies en verschillende aspecten van de code worden geïmplementeerd).
Controle stroomtestproces:
verschil tussen testplan en testcase
Controle stroomdiagram
Het controlestroomproces begint met het creëren van een visuele weergave van verschillende secties van de code die ons helpt om de paden te definiëren die kunnen worden gevolgd tijdens de uitvoering.
Deze visuele weergaven staan bekend als Control Flow Graphs (CFG's) en hebben verschillende componenten zoals knooppunten, randen, paden, knooppunten en beslissingspunten. De grafiek kan handmatig of automatisch worden gemaakt, waarbij software wordt gebruikt om de grafiek uit de broncode te halen.
Laten we deze componenten hieronder bekijken:
# 1) Procesblok
Dit deel wordt gebruikt om een codegedeelte weer te geven dat opeenvolgend wordt uitgevoerd. Dit betekent dat het elke keer op dezelfde manier wordt uitgevoerd en dat er geen beslissingen of ‘vertakking’ moeten worden genomen. Het bestaat uit knooppunten met één in- en uitgangspad.
Voorbeeld van een procesblok:
(beeld bron
Het procesblok is geen essentieel onderdeel van de regelstroom en hoeft daarom maar één keer te worden getest.
# 2) Beslissingspunten
Dit zijn enkele belangrijke componenten in de controlestroom van de code. Binnen deze knooppunten worden beslissingen genomen. Dit gebeurt meestal via vergelijking en de besturingsstroom verandert, afhankelijk van de beslissing. Dit deel van de CFG bestaat uit één knooppunt met minimaal 2 uitgangen.
De hier genomen beslissing kunnen voorwaardelijke statements zijn, zoals, if-else statements (die twee mogelijke outputs hebben) en case statements (die meer dan twee outputs kunnen hebben).
(beeld bron
In het bovenstaande diagram is er een beslissingspunt (van de voorwaardelijke ‘leeftijd = 18’) dat wordt gevolgd door ‘ja’ of ‘nee’ opties.
# 3) Knooppunten
Uit het bovenstaande diagram kunnen we gemakkelijk knooppunten identificeren waar de beslissingspunten samenkomen. Knooppunten kunnen veel toegangspaden hebben, maar kunnen slechts één uitgangspad hebben.
Best practices voor stroomdiagrammen:
Er zijn een paar dingen waar u op moet letten bij het maken van controlestroomgrafieken:
- Probeer zoveel mogelijk de CFG eenvoudig te houden. We kunnen dit doen door onderdelen te combineren die als ‘minder belangrijk’ kunnen worden beschouwd, bijvoorbeeld, procesblokken.
- Zorg ervoor dat op beslissingsmomenten slechts één beslissing wordt genomen. Bij complexere CFG's zijn er ‘gevolgen’ die komen nadat de beslissing is genomen. In ons bovenstaande voorbeeld kunnen we ook toevoegen dat als een persoon 18 jaar of ouder is, deze in aanmerking komt en moet betalen voor een ticket. Is dat niet het geval, dan is de toegang gratis. De ‘anders’ beslissing moet een paar knooppunten ‘overslaan’, en al die stappen moeten in onze CFG worden weergegeven.
Zodra we onze CFG hebben gedefinieerd, is het nu tijd om naar de volgende stap in het controlestroomtestproces te gaan, d.w.z. om te bepalen in hoeverre we de code gaan testen.
Bepalen hoeveel u wilt testen:
Hoeveel van de broncode moet worden getest? Moeten we elk mogelijk pad testen? Het is praktisch onmogelijk om alle paden in onze tests te bestrijken. We moeten een middenweg vinden om te bepalen hoeveel testen we kunnen doen.
Als we zeggen dat we streven naar het testen van 50% van onze code, dan zou dit kunnen betekenen dat we alle uitvoerbare codeverklaringen zullen definiëren en proberen ten minste de helft ervan te testen. De vraag die hier echter opkomt is ‘moeten we dan alle mogelijke uitvoerbare paden definiëren?’
Dit kan weer praktisch onmogelijk zijn. Een betere benadering zou kunnen zijn om 50% van de paden te testen die we in elk gedeelte van de code kunnen identificeren.
Er zijn verschillende dekkingsniveaus, namelijk afschrift-, filiaal- en paddekking. We zullen ze later kort bekijken.
Testcases maken:
De volgende stap is het maken van de testcases die we gaan gebruiken. De testcases bij structureel testen zijn gebaseerd op de volgende factoren:
- De uitvoerbare instructies.
- De ‘beslissingen’ die moeten worden genomen.
- De mogelijke paden die kunnen worden gevolgd.
- De voorwaarden waaraan moet worden voldaan (deze kunnen veelvoudig of booleaans zijn).
De bovenstaande factoren geven ons een idee van de soorten testcases die we moeten creëren. We kunnen ook een structurele testgeneratietool gebruiken. Als onze code in de programmeertaal C is, kunnen we PathCrawler gebruiken om testcode te genereren. Een ander hulpmiddel dat we kunnen gebruiken is fMBT.
Uitvoeren van de testcases:
Hier mogen we de tests uitvoeren. We kunnen invoer of gegevens invoeren om te controleren hoe de code deze uitvoert, en vervolgens verifiëren of we de verwachte resultaten krijgen. Bijvoorbeeld, voer een array in een functieaanroep in om te zien dat de resultaten die we krijgen na het doorlopen ervan, of om te controleren of de beslissingspunten de juiste beslissingen nemen.
Analyse van de resultaten:
In dit deel controleren we alleen of we na uitvoering de juiste resultaten krijgen. Bijvoorbeeld, als we een array invoeren waarin alle waarden hoger zijn dan 18, dan zouden alle beslissingspunten moeten resulteren in ‘geschikt’.
Veronderstellingen van de beheersstroom
Het is belangrijk op te merken dat er voor het uitvoeren van controlestroomtests een aantal aannames zijn gedaan. Deze omvatten:
- De enige aanwezige bugs zijn die welke de controlestroom kunnen beïnvloeden.
- Alle variabelen, functies en elementen zijn nauwkeurig gedefinieerd.
Dekkingsniveaus in controlestromen
Zoals we eerder hebben vermeld, zijn er verschillende dekkingsniveaus bij het testen van controlestromen.
Laten we ze kort bekijken.
# 1) Dekking van de verklaring
Bij structureel testen spelen uitvoerbare code-instructies een cruciale rol als het gaat om het bepalen van de methoden voor het ontwerpen van de tests.
We streven naar 100% dekking, wat betekent dat elke executable statement minimaal één keer is getest. Hoe hoger de dekking, hoe kleiner de kans dat u de bugs en fouten mist.
Het is vereist om hier testcases te gebruiken. De gegevens die we nodig hebben, zijn ervoor zorgen dat elke uitvoerbare instructie in een codeblok minstens één keer wordt uitgevoerd.
# 2) Vestigingsdekking
Dit dekkingsniveau omvat het testen van de punten in de CFG-vestigingen (waar beslissingen worden genomen). De uitkomsten zijn booleaans. Zelfs als een switch-instructie wordt gebruikt en er meerdere uitkomsten zijn, is in wezen elk case-blok een vergelijking van een paar waarden.
Net als bij de dekking van verklaringen, moeten we streven naar 100% dekking van het filiaal. Om dit te bereiken, moeten we elke uitkomst minstens één keer op elk beslissingsniveau testen. Aangezien we te maken hebben met booleaanse uitkomsten, moeten we streven naar het uitvoeren van ten minste 2 tests per sectie code.
# 3) Paddekking
Dit dekkingsniveau is grondiger in vergelijking met de dekking van beslissingen en verklaringen. Het doel is hier om alle mogelijke paden te ‘ontdekken’ en ze minstens één keer te testen. Dit kan erg tijdrovend zijn. Het kan echter helpen bij het ontdekken van bugs of fouten in onze code, of zelfs aspecten die we moeten definiëren, bijvoorbeeld, gebruikers invoer.
Typen structurele tests
(beeld bron
Mutatietesten
Mutatietesten is een op fouten gebaseerde testtechniek waarbij verschillende variaties van een softwareapplicatie worden getoetst aan de testdataset.
>> Raadpleeg deze tutorial voor een diepgaande blik op Mutatie testen.
Op plakjes gebaseerde testen
Slice Based Testing (SBT) kan worden gedefinieerd als een softwaretesttechniek die is gebaseerd op plakjes - uitvoerbare delen van het programma of groepen uitspraken die van invloed zijn op bepaalde waarden op bepaalde aandachtspunten in het programma, bijvoorbeeld, delen waarin variabelen zijn gedefinieerd of de uitvoer van een groep uitspraken.
Hoe te snijden
Snijvoorbeeld in SBT: Code om even en oneven getallen af te drukken (Python)
Er zijn twee manieren om naar een segment te kijken: Door het pad te volgen van een interessante variabele of het deel van de code dat de output beïnvloedt.
Als we in ons voorbeeld naar de uitvoer van oneven getallen kijken, kunnen we het deel van de code traceren dat ons naar deze uitvoer leidt.
In de plakcriteria die zijn gegeven door Mark Weiser (die SBT heeft geïntroduceerd), wordt een plak gedefinieerd met behulp van deze formule: S (v, n) , waar, v verwijst naar de betreffende variabele ( bijvoorbeeld, waar een variabele is gedefinieerd), en n is de verklaring van interesse ( bijvoorbeeld, waar output wordt gegeven), en S staat voor de plak.
In het bovenstaande voorbeeld, om de slice te krijgen, beginnen we met onze uitvoer op regel 10, die onze n Onze variabele is waar
Ons snijcriterium is dus:
Onze zorg zijn de uitspraken die ons naar de output leiden.
Dit zijn:
10,9,8,4,3,1
Dus ons segment in deze code is:
Op segmenten gebaseerde testtypen
Er zijn twee soorten SBT: statisch en dynamisch
# 1) Dynamisch op plakjes gebaseerd testen
Het SBT-voorbeeld dat hierboven is uitgelegd, waarbij we de instructies hebben bekeken die van invloed zijn op het afdrukken van de oneven getallen, is dynamische SBT. Onze zorg is heel specifiek. We kunnen ons alleen concentreren op wat de specifieke output rechtstreeks beïnvloedt.
We voeren de code uit en gebruiken testgegevens om ervoor te zorgen dat het werkt zoals het hoort. We zouden het bereik kunnen vergroten tot bereik (1,50), bijvoorbeeld, om te zien of het nog steeds alleen oneven getallen genereert. Dynamische SBT wordt ook wel validatietesten genoemd.
# 2) StatischOp plakjes gebaseerde testen
In tegenstelling tot dynamische SBT ligt de focus van statisch testen op een bepaalde variabele. Als we nadenken over onze output in het bovenstaande voorbeeld als waar , kunnen we het segment traceren dat het beïnvloedt als 10,9,8,7,6,5,4,3,2,1
Het is eigenlijk het hele codeblok! Hier controleren we of de code correct is in termen van syntaxis en vereisten, en we voeren deze niet uit. Statische SBT wordt ook wel verificatietest genoemd.
Het is belangrijk op te merken dat dynamische SBT ‘kleiner’ is in vergelijking met zijn statische tegenhanger. Het is ook specifieker.
Best practices / richtlijnen voor segmentgebaseerd testen
De criteria voor het snijden moeten worden bepaald door:
- Verklaringen waarin waarden zijn gedefinieerd of waarde worden toegewezen, evenals opnieuw toegewezen waarde.
- Verklaringen waarbij waarden worden ontvangen van buiten het programma, bijvoorbeeld, via gebruikersinvoer.
- Verklaringen die uitvoer afdrukken / uitvoer retourneren.
- De laatste verklaring van het programma, bijvoorbeeld, een functieaanroep die waarden kan definiëren of waarden aan argumenten kan geven
Voordelen van slice-based testen zijn onder meer:
- Omdat we bij SBT alleen met specifieke interessegebieden werken, wordt het eenvoudiger om effectief testsuites te genereren.
- Het pad wordt bepaald door afhankelijkheden binnen de code, wat beter is dan het gebruik van pad dekking.
- Met SBT is het gemakkelijker om fouten in de broncode te vinden.
Nadelen van slice-based testen zijn onder meer:
- Als we dynamische tests gebruiken bij het testen van een grote codebase, hebben we veel rekenkracht nodig.
- Als we statische tests gebruiken, lopen we mogelijk fouten mis.
Gegevensstroom testen
Dataflowtests kunnen worden gedefinieerd als een softwaretesttechniek die is gebaseerd op datawaarden en hun gebruik in een programma. Het controleert of de gegevenswaarden correct zijn gebruikt en dat ze de juiste resultaten opleveren. Het testen van gegevensstromen helpt om de afhankelijkheden tussen gegevenswaarden op een bepaald uitvoeringspad te traceren.
Afwijkingen in de gegevensstroom
Afwijkingen in de gegevensstroom zijn gewoon fouten in een softwareprogramma. Ze zijn ingedeeld in respectievelijk typen 1, 2 en 3.
Laten we er hieronder op ingaan:
Type 1: Er wordt een variabele gedefinieerd en er wordt tweemaal een waarde aan toegekend.
Voorbeeldcode: Python
Lst_1 wordt gedefinieerd en er worden twee verschillende waarden aan toegekend. De eerste waarde wordt eenvoudigweg genegeerd. Afwijkingen van type 1 zorgen er niet voor dat het programma mislukt.
Type 2: De waarde van een variabele wordt gebruikt of er wordt naar verwezen voordat deze wordt gedefinieerd.
Voorbeeldcode: Python
De bovenstaande lus heeft geen waarden om te herhalen. Type 2-afwijkingen zorgen ervoor dat het programma mislukt.
Type 3: EEN datawaarde wordt gegenereerd, maar wordt nooit gebruikt.
Voorbeeldcode: Python
De variabele lst_2 is niet verwezen. Afwijkingen van type 3 veroorzaken mogelijk geen programmafouten.
Gegevensstroomtestproces
Om de afhankelijkheden tussen gegevenswaarden te definiëren, moeten we de verschillende paden definiëren die in een programma kunnen worden gevolgd. Om dit effectief te doen, moeten we lenen van een ander structureel testtype dat bekend staat als controle-flow testen
Stap 1) Teken een controlestroomdiagram
We moeten een controlestroomgrafiek tekenen, die een grafische weergave is van de paden die we in ons programma zouden kunnen volgen.
Voorbeeldcode: Python
In het bovenstaande codevoorbeeld zou een lid korting moeten krijgen als ze een bezoeker uitnodigen.
Control Flow Graph (CFG):
Stap 2) Ontdek de definitie en het gebruik van variabelen en gegevenswaarden.
Een variabele in een programma wordt gedefinieerd of gebruikt. In CFG hebben we variabelen op elk knooppunt. Elk knooppunt krijgt een naam volgens het type variabele dat het bevat. Als een variabele op een bepaald knooppunt is gedefinieerd, wordt er een definiërend knooppunt gemaakt. Als een variabele op een knooppunt wordt gebruikt, wordt er een gebruiksknooppunt gemaakt.
Als we de variabele kosten in CFG beschouwen, zijn dit de bepalende en gebruiksknooppunten:
| Knooppunt | Type | Code |
|---|---|---|
| een | Knooppunt definiëren | kosten = 20 |
| 5 | Gebruiksknooppunt | rekening = kosten -1 |
| 7 | Gebruiksknooppunt | factuur = kosten |
Stap 3) Definieer paden voor definitiegebruik.
Er zijn twee soorten definitie-gebruikspaden: du paden en dc paden. du-paden zijn definitiepaden die beginnen met een definitieknooppunt en eindigen met een gebruiksknooppunt. Dit is het geval voor het pad met verwijzing naar de bovenstaande variabele kosten.
Een voorbeeld van een gelijkstroompad, een beslissingsvrij pad, is het pad met betrekking tot de factuurvariabele zoals hieronder:
| Knooppunt | Type | Code |
|---|---|---|
| 5 | Knooppunt definiëren | rekening = kosten -1 |
| 7 | Knooppunt definiëren | factuur = kosten |
| 8 | Gebruiksknooppunt | print (rekening) |
dc-pad heeft meer dan één definitieknooppunt, ook al eindigt het nog steeds bij een gebruiksknooppunt.
Stap 4) Maak de testsuite.
Dit is input toevoegen. Merk op dat we voor elke variabele een andere testsuite moeten hebben. De testsuite helpt ons bij het identificeren van afwijkingen in de gegevensstroom.
Typen gegevensstroomtests
Er zijn twee soorten - Statisch en dynamisch
Statisch betekent dat we de code en CFG doorlopen om gegevensanomalieën te identificeren, zonder deze uit te voeren. Dynamisch betekent dat we de specifieke paden daadwerkelijk identificeren en vervolgens testsuites maken om deze te testen in een poging om afwijkingen te 'vangen' die we mogelijk hebben gemist tijdens statische tests.
Voordelen en nadelen van dataflowtesten:
- Dataflowtests zijn ideaal voor het identificeren van anomalieën in de dataflow, waardoor het een zeer effectieve structurele testmethode is.
- Het nadeel is dat het nodig is om goed thuis te zijn in de taal die wordt gebruikt om de code te schrijven om gegevensstroomtests te gebruiken. Het is ook tijdrovend.
Voordelen en nadelen van structurele tests
Laten we nu de redenen vinden waarom structureel testen een geweldige aanpak is, en ook enkele van de nadelen ervan onderzoeken.
Voordelen:
- Zorgt voor grondige codetests, wat resulteert in minimale fouten. Structuurgebaseerd testen geeft ruimte om software grondig te testen. De verschillende dekkingsniveaus - verklaring voor verklaring, elk beslissingspunt en elk pad zijn gericht op het bereiken van 100% dekking, wat de kans dat fouten onopgemerkt blijven aanzienlijk verkleint.
- De mogelijkheid om te automatiseren Er zijn verschillende tools die we kunnen gebruiken om het testen te automatiseren. Dit zal ons helpen om een maximale codedekking te bereiken en binnen een kortere tijd in vergelijking met het handmatig testen.
- Het resulteert in code van hogere kwaliteit De ontwikkelaars hebben de kans om de structuur en implementatie van de code te bestuderen en eventuele fouten op te lossen en deze aspecten te verbeteren. Het stelt ons in staat om de geweldige structuur in gedachten te houden terwijl we volgende delen van code schrijven of resterende functies implementeren.
- Het kan door elke fase van de SDLC heen worden gedaan - Structurele testen kunnen in elke fase van de SDLC worden uitgevoerd zonder te wachten tot de ontwikkeling 100% voltooid is. Dit maakt het gemakkelijk om fouten in de vroege fase te identificeren en zo veel tijd te besparen in vergelijking met testen nadat de ontwikkeling is voltooid.
- Het helpt bij het verwijderen van dode code Dit kan worden gezien als ‘extra’ of onnodige code, bijvoorbeeld, code die een resultaat berekent maar het nooit gebruikt in een van de volgende berekeningen.
- Efficiëntie - Aangezien de ontwikkelaars die de code schrijven dezelfde zijn die deze testen, is het niet nodig om andere mensen zoals QA's erbij te betrekken.
Nadelen:
- De ontwikkelaars die op structuur gebaseerde tests uitvoeren, moeten een grondige kennis van de taal hebben Andere ontwikkelaars en QA's die niet goed thuis zijn in de taal, kunnen niet helpen met testen.
- Het kan behoorlijk duur worden in termen van tijd en geld Er zijn veel tijd en middelen nodig om efficiënt te testen.
- Het veroorzaakt vertragingen bij de levering van functies Dit komt doordat ontwikkelaars uit het bouwen van software worden gehaald om te testen.
- Schalen is een probleem, zeker als het om grote applicaties gaat Een grote aanvraag staat gelijk aan een te hoog aantal af te leggen routes. Het bereiken van 100% dekking wordt onmogelijk.
- Er kunnen gemiste gevallen en routes zijn bijvoorbeeld, in een geval waarin functies niet volledig zijn ontwikkeld of nog moeten worden ontwikkeld. Dit betekent dat het moet worden gecombineerd met andere testtypen, zoals het testen van vereisten (waarbij we controleren op de gespecificeerde functies die moesten worden gebouwd).
Best practices voor structureel testen
Enkele van de factoren die aandacht vereisen bij het uitvoeren van structuurgebaseerde testen zijn de volgende:
- Label en benoem de tests duidelijk Als iemand anders de tests moet uitvoeren, moeten ze deze gemakkelijk kunnen vinden.
- Voordat u code verbetert, d.w.z. door deze te herstructureren en deze te optimaliseren voor gebruik in verschillende omgevingen, moet u ervoor zorgen dat de structuur en het verloop ervan ideaal zijn.
- Voer tests afzonderlijk uit Op deze manier is het gemakkelijk om bugs te identificeren en op te lossen. Aan de andere kant zullen we minder snel bugs of paden missen als gevolg van overlappingen in codesecties, blokken of paden.
- Genereer tests voordat u wijzigingen aanbrengt De tests moeten worden uitgevoerd zoals verwacht. Op deze manier is het gemakkelijk om het probleem op te sporen en op te lossen als er iets kapot gaat.
- Houd de tests voor elke sectie of codeblok apart Op deze manier hoeven we niet veel tests te wijzigen als er wijzigingen zijn.
- Los bugs op voordat u verder gaat met testen Als we bugs identificeren, kunnen we deze beter oplossen voordat we verder gaan met het testen van de volgende sectie of het volgende codeblok.
- Sla structureel testen nooit over in de veronderstelling dat een QA ‘toch nog testen’ zal doen. Zelfs als de bugs aanvankelijk onbeduidend lijken, kunnen ze cumulatief resulteren in buggy-code die nooit het beoogde doel kan bereiken.
Veelgestelde vragen over structuurgebaseerd testen
Hier gaan we in op de veelgestelde vragen als het gaat om structureel testen.
V # 1) Wat is het verschil tussen functioneel testen en structureel testen?
het automatiseren van de build zal helpen
Antwoord: Functioneel testen is een vorm van softwaretesten op basis van gestelde eisen in de SRS (Software Requirements Specificaties). Het wordt meestal gedaan om verschillen te vinden tussen de specificaties in de SRS en hoe de code werkt. Structurele tests zijn gebaseerd op de interne structuur van de code en de implementatie ervan. Een grondig begrip van de code is vereist.
V # 2) Wat zijn de soorten structurele testen?
Beantwoord de soorten zijn onder meer:
- Gegevensstroom testen
- Mutatie testen
- Controle stroomtesten
- Segment-gebaseerde testen
V # 3) Wat is een voorbeeld van een structurele test?
Antwoord: Hier is een voorbeeld van de dekking van een verklaring:
De hoeveelheid dekking die we krijgen, hangt af van de testgegevens die we als invoer leveren (of deze voldoet aan de voorwaarden van som> 0).
V # 4) Wat is het verschil tussen datastroomtesten en controlestroomtesten?
Antwoord: Zowel gegevensstroomtests als controlestroomtests maken gebruik van controlestroomgrafieken. Het enige verschil is dat we ons bij het testen van controlestromen concentreren op de paden die uit de code worden gegenereerd, terwijl we ons bij het testen van gegevensstromen concentreren op de gegevenswaarden, hun definitie en het gebruik binnen de paden die binnen een programma zijn geïdentificeerd.
V # 5) Waar worden dataflowtests voor gebruikt?
Antwoord: Gegevensstroomtests zijn ideaal voor het identificeren van afwijkingen in het gebruik van gegevenswaarden binnen paden in een controlestroomdiagram, bijvoorbeeld, een variabele waaraan tweemaal waarde is toegewezen, een variabele die is gedefinieerd en niet is gebruikt, of een variabele die is gebruikt of waarnaar wordt verwezen en niet is gedefinieerd.
V # 6) Wat is het verschil tussen snijden en in blokjes snijden bij het testen van software?
Antwoord: Slicing betekent dat u zich concentreert op specifieke uitspraken over interesse in een programma en de rest negeert. Dicing is wanneer we een plak identificeren die verkeerde invoer heeft en deze vervolgens verder snijden om het juiste gedrag te traceren.
V # 7) Wat is het verschil tussen mutatietesten en codedekking?
Antwoord: Bij mutatietesten beschouwen we het aantal gedode mutanten als een percentage van het totaal aan mutanten. Codedekking is gewoon de hoeveelheid code die in een programma is getest.
Gevolgtrekking
In deze tutorial hebben we grondig gekeken naar structurele testen - wat het is, wat het niet is, hoe je het moet aanpakken, soorten dekking, voor- en nadelen, best practices en zelfs enkele veelgestelde vragen over dit type softwaretest.
Er is nog zoveel meer dat we kunnen leren over structuurgebaseerd testen. In toekomstige tutorials zullen we codedekking (statement, beslissing, branch en pad), structurele testtypen (mutatie, gegevensstroom en slice-gebaseerd) en zelfs de tools onderzoeken die we kunnen gebruiken om deze testprocessen te automatiseren.
Het is belangrijk op te merken dat er geen softwaretesttype of -benadering is die 100% efficiënt is. Het is altijd raadzaam om verschillende soorten tests en benaderingen te combineren.
Bijvoorbeeld, constructietesten worden in hoge mate aangevuld door het testen van eisen, omdat er mogelijk kenmerken zijn die mogelijk niet waren ontwikkeld op het moment dat constructietesten werden uitgevoerd.
Structurele testtechnieken zijn gebaseerd op de fouten die menselijke programmeurs maken bij het schrijven van code. De veronderstelling is dat de programmeur een expert is en weet wat hij of zij codeert, maar van tijd tot tijd fouten maakt.
De verschillende structurele testtypen die we hebben bekeken - mutatietesten, slice-based testen en dataflowtesten kunnen worden herleid tot fouten zoals het gebruik van de verkeerde operator (mutatietesten) of het verwijzen naar een variabele voordat deze wordt gebruikt (dataflowtesten) .
Aanbevolen literatuur
- Tutorial over destructief testen en niet-destructief testen
- Functioneel testen versus niet-functioneel testen
- Wat is een op defecten gebaseerde testtechniek?
- Zelfstudie Soak Testing - Wat is Soak Testing?
- SOA-testtutorial: testmethodologie voor een SOA-architectuurmodel
- Laadtests met HP LoadRunner-zelfstudies
- Wat is gammatesten? De laatste testfase
- Tutorial over DevOps-testen: welke invloed heeft DevOps op QA-testen?
- Wat is conformiteitstesten (conformiteitstesten)?