Niet-destructief softwaretesten (NDT): Wat is het? Teststrategie

Wat is niet-destructief softwaretesten?

Niet-destructief onderzoek is een softwaretesttype waarbij de softwareapplicatie correct wordt getest en gebruikt. Met andere woorden, Non Destructive Software Testing (NDT) wordt ook wel Positive Testing of Happy path testen genoemd. Het geeft de verwachte resultaten en bewijst dat de softwareapplicatie zich gedraagt ​​zoals verwacht.

De naam is ontleend aan de techniek, waar niet-destructief onderzoek een fysiek onderdeel inspecteert zonder het te beschadigen. In software is het principe hetzelfde: de applicatie wordt gebruikt zoals deze is ontworpen en doorstaat de test zonder problemen.

Voorbeeld: Het invoeren van de juiste gegevens in een inlogmodule en controleren of de inloggegevens worden geaccepteerd en of er naar de volgende pagina wordt doorgestuurd.

De onderstaande schermafbeelding toont het inlogformulier, met een geldige waarde ingevoerd in het gebruikersnaamveld voordat de test wordt uitgevoerd.

Om niet-destructief te testen op het bovenstaande voorbeeld, voert u een geldige gebruikersnaam en wachtwoord in het inlogformulier in. Omdat de invoer overeenkomt met wat de vereiste toestaat, is het gewenste resultaat positief en bevestigt de tester eenvoudigweg dat de applicatie naar de volgende pagina gaat.

Waarom niet-destructieve softwaretests (NDT)?

Niet-destructief testen beantwoordt de eerste vraag die elke stakeholder stelt over een project: doet de functionaliteit daadwerkelijk wat ervan verwacht wordt? Dit zijn de redenen waarom teams het uitvoeren.

• Het grootste voordeel van de NDT-methode is dat deze leidt tot een verbeterde softwarekwaliteit, omdat defecten die in de hoofdcode worden gevonden, vroegtijdig worden verholpen.
• Om aan te tonen dat softwarefuncties volgens de specificatie werken.
• Om te controleren of aan de prestatie-eisen is voldaan.
• Om te controleren of aan de eisen van de eindgebruikers wordt voldaan.
• Om te controleren of een klein gedeelte van de code of functionaliteit naar behoren werkt en de gerelateerde functionaliteit niet verstoort.
• Om bewijsmateriaal te produceren dat kan worden getoond op een gebruikersacceptatie testen Bij de goedkeuringsfase wil de klant het beoogde gedrag zien in plaats van de mogelijke fouten.

Wanneer wordt niet-destructief onderzoek (NDT) uitgevoerd?

Timing is hier belangrijker dan bij de meeste technieken, omdat het succesvolle scenario bepalend is voor alles wat erna komt.

• Het is de eerste test die een tester uitvoert op een applicatie, oftewel in de beginfase van de ontwikkeling. SDLC.
• Niet-destructief onderzoek wordt doorgaans uitgevoerd wanneer er onvoldoende tijd is voor een volledige testcyclus, omdat het toch aantoont dat aan de acceptatiecriteria is voldaan.
• Het wordt uitgevoerd vóór negatieve en destructieve scenario's. Als de hoofdstroom wordt onderbroken, rapporteren foutafhandelingstests ruis in plaats van echte defecten.
• Het wordt na elke foutcorrectie herhaald, en dat is waar het overlapt met regressietesten.

Teststrategie voor niet-destructief testen

De strategie voor niet-destructief onderzoek is bewust eenvoudig, en de discipline schuilt in een positieve instelling in plaats van in de gebruikte apparatuur.

• De benadering van niet-destructief onderzoek moet positief zijn.
• Het doel van de NDT-techniek is aan te tonen dat een applicatie werkt wanneer deze geldige invoergegevens ontvangt.
• Voor het uitvoeren van niet-destructief onderzoek zijn geen speciale vereisten of omstandigheden nodig.
• De beste werkwijze voor niet-destructief onderzoek is om te controleren of het systeem doet wat het moet doen.

Het onderstaande diagram geeft een overzicht van hoe die strategie normaal gesproken is georganiseerd gedurende een testcyclus.

Hoe schrijf je niet-destructieve (positieve) testgevallen?

Een niet-destructieve testcase is alleen nuttig als de invoer aantoonbaar geldig is en het verwachte resultaat voortkomt uit een vereiste in plaats van uit een aanname van de tester. De volgende stappen leiden tot zo'n testcase. testcase.

Stap 1) Kies één acceptatiecriterium. Lees de vereiste en herformuleer deze als één verifieerbare verklaring, bijvoorbeeld: "Het gebruikersnaamveld accepteert zes tot twintig alfanumerieke tekens".

Stap 2) Kies geldige invoergegevens. Selecteer waarden die ruim binnen het toegestane bereik vallen. Gelijkwaardigheidspartitionering Dit helpt — één representatieve waarde per geldige partitie is normaal gesproken voldoende.

Stap 3) Noteer het verwachte resultaat voordat u de code uitvoert. Het verwachte resultaat moet uit de specificatie worden afgeleid. Als je het resultaat pas na de uitvoering schrijft, wordt de test een beschrijving van wat de build toevallig heeft gedaan.

Stap 4) Houd de stappen in de door de gebruiker aangegeven volgorde. De volgorde moet overeenkomen met hoe een echte gebruiker de taak zou uitvoeren, omdat het doel van de techniek is om het beoogde traject te bevestigen.

Stap 5) Noteer de vereiste-identificatiecode. TracDoor de casus terug te voeren naar de onderliggende criteria, kan het team tijdens een evaluatie de dekking aantonen.

Een uitgewerkt voorbeeld voor de inlogmodule ziet er als volgt uit.

Merk op dat er in dit geval niets is dat probeert het veld te breken. Een geval waarbij vijf tekens worden ingevoerd om het foutbericht te zien, is een negatieve test, en niet een niet-destructieve.

Voorbeelden van niet-destructieve tests

Het onderstaande voorbeeld laat zien hoe niet-destructief testen werkt in een applicatie met meerdere modules nadat een defect is verholpen.

• Een applicatie bestaat uit vijf modules: inlogpagina, startpagina, gebruikersdetailpagina, pagina voor het aanmaken van een nieuwe gebruiker en pagina voor het aanmaken van taken.
• Stel dat er een fout zit in de inlogpagina: het gebruikersnaamveld accepteert minder dan zes alfanumerieke tekens. Dit is in strijd met de gestelde eis dat de gebruikersnaam niet minder dan zes tekens mag bevatten, dus dit gedrag is een defect.
• De bug wordt via de gebruikelijke kanalen aan het ontwikkelteam gemeld. defectbeheerprocesHet probleem is opgelost en de build wordt teruggestuurd naar het testteam.
• Het testteam controleert niet alleen de inlogpagina waar het defect is verholpen, maar test ook de andere modules. Tijdens het testen van alle modules met geldige gegevens voert het team niet-destructieve tests uit, puur om te bevestigen dat de gehele applicatie nog steeds naar behoren werkt.

Niet-destructief onderzoek versus destructief onderzoek

De twee technieken worden vaak samen aangeleerd omdat ze antwoord geven op tegenovergestelde vragen over hetzelfde bouwwerk. Destructief testen Bij niet-destructief testen wordt gezocht naar het punt waarop de software het begeeft, terwijl bij gewoon testen wordt bevestigd dat het beoogde gedrag behouden blijft.

De twee vullen elkaar aan, ze zijn geen alternatieven. Het uitvoeren van niet-destructieve tests alleen laat de foutafhandeling onverifieerd, en het uitvoeren van destructieve tests alleen bewijst nooit dat het product zijn werk doet.

Voordelen en beperkingen van niet-destructief softwaretesten

Weten waar de techniek ophoudt nuttig te zijn, is net zo belangrijk als weten wat de techniek precies inhoudt.

Voordelen

• Snel te ontwerpen en uit te voeren, omdat de testgegevens rechtstreeks uit de specificatie komen.
• Vereist geen speciale omgeving, foutinjectie of beschadigde dataset.
• Levert bewijsmateriaal op dat één-op-één aansluit op de vereisten, wat geschikt is voor audits en goedkeuringen.
• Werkt net zo goed als handmatig testen en zoals voorgeschreven automatisering testenZodat dezelfde gevallen opnieuw kunnen worden gebruikt in een regressietestsuite.
• Geeft vroegtijdig en eerlijk een indicatie van de bouwkwaliteit op elk niveau, van unit tot en met. integratie testen naar systeem testen.

Beperkingen

• Een volledige testuitslag zegt niets over hoe de applicatie omgaat met ongeldige invoer, waardoor ernstige fouten in de foutafhandeling kunnen blijven bestaan.
• De dekking wordt beperkt door de kwaliteit van de eisen. Alles wat niet gespecificeerd is, wordt nooit getest.
• Het kan een vals gevoel van zekerheid scheppen wanneer alleen het succesvolle scenario wordt doorlopen vóór een release.
• Het meet niet de robuustheid, het herstelvermogen of de prestaties onder stress, waarvoor eigen technieken uit een breder scala aan methoden nodig zijn. software testtypen.

Beschouw niet-destructief onderzoek als de basis waarop elke andere techniek voortbouwt, en plan het in binnen het bredere plan. levenscyclus van softwaretests in plaats van als een eenmalige activiteit.

Veelgestelde vragen