<\/span><\/h3>\n <\/p>\n
Statisch en dynamisch testen zijn twee verschillende benaderingen om software te verifi\u00ebren, met hun eigen sterke en zwakke punten en mogelijkheden. Direct kiezen tussen de een en de ander is geen realistisch scenario omdat ze verschillende functies hebben.<\/p>\n
Statisch testen gaat over proactief zijn en problemen zo vroeg mogelijk identificeren. Het gaat om het vinden en oplossen van problemen voordat ze beginnen.<\/p>\n
Dynamisch testen is meer reactief in die zin dat het zoekt naar bugs door de code uit te voeren. Ja, over het algemeen kost het meer tijd en middelen dan statisch testen. Er worden echter defecten gevonden die anders door alleen statisch testen aan het licht zouden komen.<\/p>\n
Het echte antwoord hier is dat je door statisch en dynamisch testen samen te gebruiken, ervoor kunt zorgen dat je code en gerelateerde documenten in orde zijn en dat de software voldoet aan de verwachtingen van de belanghebbenden.<\/p>\n
<\/p>\n
<\/span>Wat wordt er getest tijdens statische tests?<\/strong><\/span><\/h2>\n![\"Verschillende](\"https:\/\/www.zaptest.com\/wp-content\/uploads\/2023\/09\/api-testing-1-jpg.webp\")
<\/p>\n
Statisch testen kijkt naar het ontwerp, de code en de documenten waaruit je project bestaat. Laten we eens kijken waar testers op moeten letten voor een uitgebreide aanpak van statisch testen.<\/p>\n
<\/span>1. Documentatie<\/strong><\/span><\/h3>\nEen van de eerste onderdelen van statisch testen is een grondige controle van de documentatie. Hier zijn enkele documenten die onder de loep worden genomen.<\/p>\n
<\/span>Documenten met bedrijfsvereisten<\/strong><\/span><\/h4>\nTesters onderzoeken het document met de bedrijfsvereisten en zorgen ervoor dat ze de behoeften van belanghebbenden nauwkeurig vastleggen en afstemmen op de bedrijfsdoelstellingen.<\/p>\n
<\/span>Specificaties van softwarevereisten (SRS)<\/strong><\/span><\/h4>\nHet document Software Requirement Specifications (SRS) beschrijft de functie en het nut van de software. Statisch testen voert de regel uit over dit document en zorgt ervoor dat het nauwkeurig de functionaliteit van de software beschrijft, inclusief afhankelijkheden en gebruikersinterfaces.<\/p>\n
<\/span>Ontwerpdocumenten<\/strong><\/span><\/h4>\nOntwerpdocumenten worden ook beoordeeld om te garanderen dat ze voldoen aan de vereisten en specificaties. Testers controleren unified modeling language (UML), gegevensstromen en architectuurdiagrammen om ervoor te zorgen dat ze overeenkomen met de projectvereisten.<\/p>\n
<\/span>Use-case documenten en user stories<\/strong><\/span><\/h4>\nStatisch testen onderzoekt ook de user case documenten en user stories om te zien hoe deze overeenkomen met de functionele en niet-functionele aspecten van de software. Deze documenten beschrijven gelukkige paden (bedoeld succesvol gebruik), alternatieve stromen, randgevallen en potenti\u00eble fouten.<\/p>\n
<\/span>Testgevallen<\/strong><\/span><\/h4>\nDeze vroege testfase is een kans om testgevallen te onderzoeken om er zeker van te zijn dat ze voldoende dekking hebben, middelen, geschikte technieken, realistische planningen, enzovoort. Bovendien onderzoeken de beoordelingen ook of de uitkomsten van testcases gedetailleerd en realistisch zijn.<\/p>\n
<\/p>\n
<\/span>2. Codeherziening<\/strong><\/span><\/h3>\nVervolgens wordt de code die is gebruikt voor de toepassing bekeken. Hier zijn enkele gebieden waar testteams naar zullen kijken.<\/p>\n
<\/span>Syntaxfouten<\/strong><\/span><\/h4>\nTesters en ontwikkelaars bekijken de code en onderzoeken deze op syntaxisfouten, typefouten, onjuiste namen van variabelen, ontbrekende interpunctie en alle fouten, klein of groot, die fouten veroorzaken wanneer de code uiteindelijk wordt uitgevoerd.<\/p>\n
<\/span>Dode code<\/strong><\/span><\/h4>\nDode code, ook wel onbereikbare code genoemd, is een deel van de broncode van een programma dat niet kan worden uitgevoerd vanwege problemen met het controlestroompad.<\/p>\n
<\/span>Ongebruikte variabelen<\/strong><\/span><\/h4>\nStatisch testen kijkt ook uit naar ongebruikte variabelen, die worden gedeclareerd maar nooit daadwerkelijk worden uitgevoerd door een compiler.<\/p>\n
<\/span>Schendingen van coderingsstandaarden<\/strong><\/span><\/h4>\nCoderingsstandaarden verwijzen naar een verzameling van best practices, regels en richtlijnen voor het coderen in een bepaalde taal. Statisch testen zorgt ervoor dat aan de best practices wordt voldaan, waardoor het voor anderen makkelijker wordt om de code te bewerken, repareren en bij te werken.<\/p>\n
<\/span>Logische fouten<\/strong><\/span><\/h4>\nLogische fouten kunnen betekenen dat broncode onjuist werkt, maar niet crasht. Statische beoordelingen proberen deze problemen te identificeren en op te lossen voordat de code wordt uitgevoerd.<\/p>\n
<\/span>Gegevensstromen<\/strong><\/span><\/h4>\nTesters onderzoeken ook hoe gegevens in en uit het systeem stromen. Deze beoordeling heeft betrekking op alle interacties die gegevens zullen hebben binnen de software.<\/p>\n
<\/span>Besturingsstromen<\/strong><\/span><\/h4>\nEen ander gebied dat wordt onderzocht is de besturingsstroom. Deze controle onderzoekt de uitvoeringsvolgorde van code statements en zorgt ervoor dat dingen in de juiste volgorde worden uitgevoerd, zodat de software zich gedraagt zoals bedoeld.<\/p>\n
<\/span>Kwetsbaarheden in de beveiliging<\/strong><\/span><\/h4>\nStatische tests zullen ook eventuele beveiligingslekken in de broncode onderzoeken.<\/p>\n
<\/p>\n
<\/span>Statische technieken in software testen<\/strong><\/span><\/h2>\n![\"voordelen](\"https:\/\/www.zaptest.com\/wp-content\/uploads\/2023\/09\/pexels-thisisengineering-3862619-jpg.webp\")
<\/p>\n
Nu je weet welke dingen worden onderzocht bij statisch testen, is het tijd om te kijken hoe deze beoordelingen worden uitgevoerd.<\/p>\n
Er zijn twee primaire statische testtechnieken bij het testen van software die je moet kennen om uitgebreide softwaretests uit te voeren. Dit zijn het beoordelingsproces en statische analyse.<\/p>\n
<\/p>\n
<\/span>1. Het beoordelingsproces bij statisch testen<\/strong><\/span><\/h3>\nHet reviewproces is het eerste onderdeel van het implementeren van statische technieken bij het testen van software. Het idee hier is om fouten in het softwareontwerp te vinden en te verwijderen. Meestal zijn er vier hoofdfasen in het beoordelingsproces van statische testen.<\/p>\n
<\/span>Informele beoordeling<\/strong><\/span><\/h4>\nEen informele review is precies hoe het klinkt: een ongestructureerde brainstorming waar ontwikkelaars, testers en belanghebbenden mogelijke problemen kunnen onderzoeken en vragen en suggesties over de software kunnen aandragen. Het is een kans om eventuele grote gebreken of problemen te identificeren voordat we verder gaan met de volgende fasen.<\/p>\n
<\/span>Doorlopers<\/strong><\/span><\/h4>\nWalkthroughs zijn een kans voor testteams om dieper te gaan. Vaak is het zo dat een of meerdere experts de documentatie doornemen om er zeker van te zijn dat alles overeenkomt met de bedrijfs- en systeemvereisten.<\/p>\n
<\/span>Collegiale toetsing<\/strong><\/span><\/h4>\nDeze volgende stap houdt in dat engineers elkaars broncode bekijken om te zien of ze fouten kunnen ontdekken die moeten worden hersteld voordat de software wordt uitgevoerd.<\/p>\n
<\/span>Inspectie<\/strong><\/span><\/h4>\n