static testing dynamic testing difference between these two important testing techniques
Testen is Verificatie en validatie We weten allemaal dat er 2 Vs nodig zijn om het testen te voltooien.
In het artikel van vandaag zullen we wat licht werpen Statisch testen Het wordt ook wel verificatie genoemd. We zullen er alles over leren en hier speciale nadruk op leggen omdat Dynamisch testen krijgt vaak maximale aandacht en heeft talloze artikelen die het uitwerken.
Geen enkele discussie over statisch testen zou echter compleet zijn zonder uitleg over wat de tegenhanger ervan, dynamisch testen, inhoudt. Dynamisch testen is validatie, de andere “V”.
Dynamisch testen is wanneer u met het daadwerkelijke systeem werkt (niet een artefact of model dat vertegenwoordigt het systeem), een input leveren, output ontvangen en de output vergelijken met het verwachte gedrag. Het is hands-on werken met het systeem met de bedoeling fouten op te sporen.
Tijdens dit proces zullen we begrijpen dat de volgende twee veel voorkomende misvattingen over testen niet waar zijn:
- Testen is een activiteit die aan het einde komt
- Het wordt alleen uitgevoerd door testers en de rest heeft niets te doen
Laten we beginnen met een snelle verwijzing naar het v-model
- Op de linkerkant van het V-model hebben we activiteiten die niet worden uitgevoerd door het QA-team.
- Op de rechterzijde , we hebben er enkele die worden verzorgd door het Dev-team, sommige door de testers en sommige door gebruikers.
Laten we beginnen met - Eisen verzamelen Het wordt uitgevoerd door de Business Analyst en ander hoger management - het outputdocument voor deze fase is het Business Requirements document, BRD.
hoeveel kost het verkooppunt van quickbooks
De volgende fase is de Systeem ontwerp Systeemontwerp is een fase waarin de business requirements worden vertaald naar de Functional requirements, in het FRD (Functional requirements document).
Wanneer de vertaling plaatsvindt, gaat het Dev-team (die de hoofdrolspeler is in deze stap) het BRD-document stap voor stap, pagina voor pagina en regel voor regel doornemen. Hoewel het primaire doel is om de zakelijke vereisten te consumeren met het oog op de vertaling, wordt het BRD-document op zijn beurt herzien.
Een voorbeeld Stel dat dit de BRD is voor een banksite die veel beveiliging biedt. Er is een sectie in de BRD die spreekt over de wachtwoordregels voor de verschillende gebruikers die een account aanmaken bij de site voor internetbankieren. Een van de regels is: Een gebruiker kan geen wachtwoord gebruiken dat hij / zij voor andere accounts gebruikt.
Dit is niet mogelijk. Omdat een site alleen kan suggereren hoe de gebruiker inloggegevens moet instellen, maar er is geen manier, kan deze beperking worden opgelegd. Deze vereiste is dus niet haalbaar - met andere woorden, het kan niet worden bereikt via de software.
Laten we nu de volgende punten bekijken op basis van dit voorbeeld:
- Hoe wordt bepaald dat deze vereiste niet bouwbaar is en dus niet kan worden getest (met andere woorden, niet haalbaar)? Hebben we de site van de bank en stellen we dan de login en het wachtwoord in - en realiseren we ons dan dat dit niet mogelijk is? Nee, we baseren dit eenvoudigweg op onze herziening van de BRD en natuurlijk op gezond zakelijk inzicht.
- Testen we deze vereiste? Zeker, maar puur gebaseerd op de theoretische, conceptuele betekenis, maar niet op de daadwerkelijke AUT (Application under Test).
- Wat is de fysieke vorm van deze test? -Een eenvoudige lezing of een formele herziening van de BRD of een nog formelere haalbaarheidsanalyse van de zakelijke vereisten.
Terugkomend op onze misvattingen:
- Wie voert deze herziening van de BRD uit? - Meestal het ontwikkelteam en andere technische teams die verantwoordelijk zijn voor het maken van het product. Geen testers.
- Vindt deze beoordeling plaats aan het einde van de productcreatie? Nee, in de allereerste fase van projectontwikkeling. Dus niet alleen het einde.
Statische testtechnieken:
Samenvattend, statisch testen is het verificatiedeel van softwaretests die de methoden volgen van:
- Document beoordelingen
- Walkthroughs
- Inspectie
- Haalbaarheidsanalyse of enige andere vorm van analyse om te bepalen of de software is wat het zou moeten zijn of niet
- Code review
Om de CSTE CBOK te citeren, 'Verificatie beantwoordt de vraag:' Hebben we het juiste systeem gebouwd? ' terwijl validaties adresseert: 'Hebben we het systeem goed gebouwd?'
Hieronder volgen alle statische testactiviteiten die plaatsvinden aan de linkerkant van het V-model.
| SDLC-podium | Uitvoer | Verifieert | Acteurs |
|---|---|---|---|
| Verzamelen van zakelijke vereisten | BRD (document met zakelijke vereisten) | Scope document (indien aanwezig) | |
| Ontwerp van systeemvereisten | FRD (Functioneel vereiste document) | Evalueert / verifieert de BRD | Dev, technische teams |
| Ontwerp van technische vereisten | TDD (technisch ontwerpdocument) | Evalueert / verifieert de FRD | Dev, technische teams |
| Ontwerp (code) | Code | Evalueert / verifieert de TDD. Codebeoordeling door het ontwikkelteam op volledigheid, formaat enz. | Dev, technische teams |
Notitie: Deze informatie kan worden geëxtrapoleerd voor projecten die ontwikkelingsmethodologieën volgen, aangezien de stappen min of meer vergelijkbaar zullen zijn.
Aan de rechterkant van het V-model staat validatie.
Dynamische testtechnieken:
- Testen van een eenheid
- Integratietesten
- Systeemtesten
De fasen Unit, Integration, System en UAT hebben alles te maken met het maken van tests die tijdens verschillende ontwikkelingsfasen op de AUT kunnen worden uitgevoerd. Hoewel de tests gericht zijn op het valideren van verschillende soorten vereisten, zijn het allemaal tests.
Dus elke vorm van testen waarbij we een test hebben die moet worden uitgevoerd op een AUT en de uitvoer ervan is vereist om de uitkomst van de test te bepalen (succesvol of niet) - het is validatie.
Zou het ok zijn om te generaliseren dat er aan de rechterkant (RHS) van het V-model helemaal geen verificatie is? Het antwoord is nee.
Alle tests die in elke fase op de RHS worden gemaakt, worden verschillende keren beoordeeld tijdens de fase van het maken / afronden van tests. Het gedetailleerde proces van beoordeling van testdocumentatie is op https://www.softwaretestinghelp.com/test-documentation-reviews/
Op de RHS:
- Tests en code worden door de ontwikkelaars beoordeeld in de Unit / Integration-testfasen.
- Systeemtests ondergaan een peer review tijdens hun documentatie en worden na voltooiing beoordeeld door het ontwikkelteam en de bedrijfsanalist.
- UAT-tests worden beoordeeld door zowel het QA-team als de gebruikers voordat de UAT begint.
Gevolgtrekking
Concluderend, statisch testen is een belangrijke testtechniek die de vorm aanneemt van beoordeling van bedrijfsvereisten, beoordeling van functionele vereisten, ontwerpbeoordelingen, code-walkthroughs en beoordeling van testdocumentatie. Het is een continue activiteit en niet alleen door testers.
Validatie, het dynamische testgedeelte is meer hands-on en gebeurt op het product zelf en niet op een artefact of een weergave van het product. Een veel formeel proces van testcase / conditie-identificatie, dekkingsoverwegingen, uitvoering en defectrapportage kenmerken de dynamische testmethoden.
Over de auteur: Dit artikel is geschreven door STH-teamlid Swati S.
Deel uw opmerkingen, vragen en ervaringen over het onderwerp statisch en dynamisch testen.
Aanbevolen literatuur
- Verschil tussen Desktop, Client Server Testing en Web Testing
- Agile schattingstechnieken: een echte schatting in een agile project
- Black Box-testen: een diepgaande zelfstudie met voorbeelden en technieken
- Wat is conformiteitstesten (conformiteitstesten)?
- Wat is het verschil tussen SIT versus UAT-testen?
- Alfatesten en bètatesten (een complete gids)
- Belangrijkste verschillen tussen Black Box-tests en White Box-tests
- De verschillen tussen unit-tests, integratietests en functionele tests