Menu

Tutorial over destructief testen en niet-destructief testen

  • Hoofd
  • Andere
  • Tutorial over destructief testen en niet-destructief testen

destructive testing

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Verschil tussen destructief testen en niet-destructief testen met de soorten en methoden:

In dit artikel gaan we details bespreken over destructief testen en niet-destructief softwaretesten.

We zullen er een voor een over leren en aan het einde van het artikel zullen we ook de verschillen tussen deze twee testtypen zien.

Destructief en niet-destructief onderzoek

Wat je leert:

Wat is destructief onderzoek en wat zijn de voordelen ervan?

Destructive Software Testing (DST) is een soort softwaretest die probeert om een ​​deel van de softwaretoepassing op een ongecontroleerde manier te laten falen, om de robuustheid te testen en het punt van mislukking te detecteren.

Destructief

In tegenstelling tot andere conventionele softwaretestmethoden die de functionaliteit van de software controleren, inspecteert deze methode het onvoorspelbare gebruikersgedrag binnen de software. Het stelt ons dus in staat om softwarefouten aan het licht te brengen die over het algemeen niet voorkomen bij gemiddelde gebruikers.

Houd er rekening mee dat destructieve softwaretests (DST) een alternatieve benadering zijn voor conventionele softwaretests (CST), maar niet de vervanging ervan. Het is effectief om naast CST ook zomertijd uit te voeren.

Destructieve tests worden uitgevoerd onder de meest rigoureuze bedrijfsomstandigheden en gaan door totdat de toepassing breekt. Het belangrijkste idee van deze tests is niet alleen om de eventuele zwakke punten van het ontwerp aan het licht te brengen die mogelijk niet onder normale werkomstandigheden zullen worden onthuld, maar ook om de levensduur van het softwareproduct te ontdekken.

Dit type testen heeft overeenkomsten met Monkey Testing, Ad hoc Testing en Exploratory Testing.

Voordelen van destructieve softwaretests

de beste mp3-downloader-app voor Android
  • Het helpt om de robuustheid, herstelbaarheid en levensduur van de applicatie te meten.
  • Onthult de storingspunten in geval van ongepast of misbruik van de software.
  • Het schept de juiste context voor de tester, aangezien het de vooroordelen van gebruikersverhalen tijdens het testen negeert.
  • Het stelt ons in staat om softwarefouten aan het licht te brengen die over het algemeen niet voorkomen bij gemiddelde gebruikers.
  • Dit type testen is uniek in het ontdekken van gebreken in de toepassing die, wanneer ze worden aangepakt, de rang van de software naar een beginnende bewijsstatus zullen verhogen.

Stappen om deze test uit te voeren

  1. Aan het begin van de destructieve softwaretestcyclus stuurt de klant een toepassingskopie of toegangsreferenties en gebruikersvereisten.
  2. De klant presenteert vervolgens de vereisten en demonstreert de toepassing aan een QA-analist.
  3. Vervolgens stelt de QA-analist de functie van de grenzen binnen de applicatie vast en creëert hij de bruikbaarheidsgrenzen van de applicatie binnen de grenzen.
  4. Nu zal de QA-tester de applicatie willekeurig testen binnen die grenzen, met behulp van de stochastische technieken. De QA-testworkflows en defecten worden geregistreerd.
  5. Ten slotte wordt de defecte directory gedeeld met de client.
  6. Als dat nodig is, kan de destructieve testcyclus worden herhaald op basis van de eisen van de klant.

Voor deze tests is het goed om enige kennis te hebben van de oorspronkelijke eisen van de software. Dit helpt bij het bedenken van een goede teststrategie.

Wat verifieer je in Destructive Test?

  1. Onjuist en correct gedrag van de softwareapplicatie.
  2. Geldige en ongeldige invoergegevens.
  3. Oneigenlijk gebruik van de softwareapplicatie.

Destructieve softwaretestmethoden en -strategieën

Er zijn verschillende manieren waarop destructief onderzoek kan worden uitgevoerd:

1) Analysemethode voor faalpunten:

Bij deze methode wordt de applicatie beoordeeld en onderzocht om toegang te krijgen tot elk pad en elke hoek ervan. Er wordt bepaald wat op verschillende punten kan mislukken. Voor deze methode kunt u hulp krijgen van bedrijfsanalisten om de applicatie te doorlopen.

2) Peer Review:

Laat de applicatie beoordelen door een collega-tester die niet bekend is met de software. Dit zal helpen bij het vinden van enkele verborgen faalpunten die niet zichtbaar waren voor u als tester.

3) Laat testcases beoordelen door het bedrijf:

De eindgebruikers en andere belanghebbenden kunnen soms valide testscenario's bedenken die een tester misschien heeft gemist. Dus als u de testcases door het bedrijf laat beoordelen, kunt u uw testdekking vergroten.

4) verkennende toetsing:

Verricht verkennend onderzoek met behulp van run sheets. Het zal u helpen te weten wat er is getest, de tests te herhalen en de testdekking te controleren.

5) Voorzie het systeem van onjuiste gegevens:

U kunt ongeldige invoer aan de applicatie leveren. Dit kunnen corrupte gegevens zijn, de verkeerde volgorde van stappen op de gebruikersinterface, enz.

6) Gebruik andere bronnen:

U kunt ook andere bronnen of manieren gebruiken om het systeem te breken en te analyseren voor verschillende scenario's. Het goede is dat het gebruikersverhaal van destructieve softwaretests niet per se vraagt ​​om ‘vereisten’ en ‘specificaties’, dus je kunt elke geschikte manier uitproberen om deze tests uit te voeren.

Destructieve testtechnieken

Destructieve softwaretests kunnen worden uitgevoerd met verschillende technieken, zoals:

html5 css3 interviewvragen en antwoorden
  • Acceptatietesten
  • Loop testen
  • Regressietesten
  • Equivalentiepartitionering
  • Grenswaardetesten
  • Interface testen
  • Alpha / Beta-testen
  • Systeem testen
  • Top-down testen
  • Black box testen

Enkele handige tips voor destructieve softwaretests

  • Doe zo veel mogelijk kennis van het product op. Verplaats jezelf in de schoenen van de klant en denk vervolgens vanuit zijn perspectief over het product.
  • Wis alle bevooroordeelde informatie uit het gebruikersverhaal. Vergeet de beschrijving van het gebruikersverhaal en de acceptatiecriteria en probeer de applicatie als een gekke klant te breken.
  • Zoek naar de uitzonderingspaden, niet naar de gelukkige paden. Houd er rekening mee dat u door het negeren van de acceptatiecriteria niet de verwachte of normale workflow kent.
  • Verwacht geen positieve reactie van uw aanvraag. Wat als er iets niet lukt? Probeer alles te simuleren en te corrumperen.
  • Beperk uw netwerkcondities tot een meer realistische configuratie, omdat niet alle echte gebruikers zullen beschikken over eersteklas machines en netwerkcondities.

Wat is niet-destructief onderzoek en wat zijn de voordelen ervan?

Non-Destructive Testing (NDT) wordt beschreven als een software-beoordelingstechniek die de juiste interactie met software inhoudt. In tegenstelling tot destructieve softwaretests waarbij we zoeken naar uitzonderingspaden, zoeken we bij niet-destructieve tests naar gelukkige paden of gouden paden. NDT wordt ook wel positief testen genoemd.

Als er bijvoorbeeld een invoervak ​​is dat een nummer binnen 1-999 accepteert, dan zou een positieve testcase zijn om een ​​nummer binnen dit bereik in te voeren en de functionaliteit van het invoervak ​​te verifiëren.

Voorbeeld van een niet-destructieve test

In NDT hebben we een goed gedefinieerde testcase met een bekende vereiste, die zonder fouten of uitzonderingen wordt uitgevoerd en de gewenste uitvoer produceert. Het geeft de verwachte resultaten en verifieert dat de software werkt zoals verwacht.

Voordelen van niet-destructieve softwaretests

  • Verbeterde softwarekwaliteit en problemen worden opgelost in de hoofdstroom van de applicatie.
  • Handig om aan te tonen dat de softwareapplicatie werkt volgens de vereiste specificaties.
  • Controleert of aan de verwachtingen van de klant is voldaan.
  • Zorgt ervoor dat aan de prestatie-eisen wordt voldaan.
  • Bespaart tijd en geld bij productevaluatie en probleemoplossing.

Wanneer u deze test moet uitvoeren

  • Het zou de eerste vorm van testen moeten zijn en moet in de beginfase van SDLC worden gedaan, omdat het gelukkige pad de hoofdstroom van de applicatie is en als het niet goed werkt, wordt de rest van het testen geblokkeerd.
  • Het kan snel en gemakkelijk worden gedaan als we niet genoeg tijd en budget hebben om te testen. Dit zorgt er in ieder geval voor dat aan softwarevereisten en acceptatiecriteria wordt voldaan.

Strategie voor niet-destructieve softwaretests

  • De positieve testbenadering moet worden aangenomen om de niet-destructieve test uit te voeren.
  • Tijdens het testen moet de tester in gedachten houden dat het doel van de niet-destructieve test is om te verifiëren dat de applicatie goed werkt bij het geven van geldige invoergegevens. Het doel is dus om het applicatiegedrag voor de positieve set gegevens te verifiëren.
  • U kunt het beste controleren of het systeem doet waarvoor het bedoeld is.

Verschil tussen destructief en niet-destructief onderzoek

Destructief testenNiet-destructief onderzoek
Richt zich op de zwakke punten in het ontwerp, maar niet op de functionaliteit.Richt zich op zwakke punten in functionaliteit, maar niet op ontwerp.
Heeft niet per se zakelijke vereisten nodig. Destructief testen wordt gedaan zonder kennis te nemen van vooraf vastgestelde vereisten.Er wordt getest om de functionaliteiten te verifiëren aan de hand van zakelijke vereisten en acceptatiecriteria.
De bedoeling is om de software te kraken door ongebruikelijke inputs te leveren om storingspunten te detecteren.Het is de bedoeling om correct met de software om te gaan om positieve resultaten te verifiëren.

Gevolgtrekking

Bij destructief testen wordt de applicatie met opzet gemaakt om te crashen om de robuustheid van de applicatie te onderzoeken. Het detecteert de foutpunten in de software die kunnen optreden als gevolg van een onjuiste behandeling van de applicatie door de klant.

Het detecteert die zwakke plekken die niet kunnen worden gevolgd met behulp van conventionele softwaretests. Voor een betere testdekking verdient het de voorkeur om destructieve softwaretests uit te voeren naast conventionele softwaretests.

Niet-destructieve tests worden gedaan met de positieve test- of happy path-testbenadering om te verifiëren dat de softwarefunctionaliteit voldoet aan de eisen van de klant. Het gaat om een ​​correcte interactie met de software.

Aanbevolen literatuur

^