Wat is destructief testen in software?

Door: Thomas Hamilton Thomas Hamilton
Hours Bijgewerkt

⚡ Slimme samenvatting

Destructief testen drijft een softwareapplicatie opzettelijk tot het uiterste totdat deze faalt, waardoor de exacte punten aan het licht komen waar de robuustheid faalt bij oneigenlijk gebruik, ongeldige invoer en onvoorspelbaar gedrag, punten die gewone functionele controles nooit bereiken.

  • ???? Kernidee: De applicatie is opzettelijk zo ontworpen dat hij faalt, zodat de zwakke punten zichtbaar en meetbaar worden.
  • 🔎 Geen vereisten nodig: Voorkennis van de specificaties is optioneel, maar verbetert wel de teststrategie.
  • ​ Tegengesteld paar: Niet-destructief onderzoek bewandelt het veilige pad; destructief onderzoek valt het vanuit alle mogelijke hoeken aan.
  • 🧰 benaderingen: Foutanalyse, collegiale toetsing door testers, bedrijfsevaluatie en verkennende tests met bijbehorende testrapporten.
  • 🧪 Hergebruikte methoden: Regressietesten, interfacetesten, equivalentiepartitioneringstesten, lus- en acceptatietesten dienen allemaal destructieve doelen.
  • 📉 Eerlijke grenzen: Dekking is moeilijk te garanderen, vergt veel inspanning en bevindingen zijn lastig te reproduceren.
Meer informatie

Wat is destructief testen in software, inclusief methoden en technieken?

Wat is destructief testen?

Destructief testen Destructief testen is een softwaretestmethode die wordt gebruikt om zwakke punten in een softwareprogramma te vinden. Bij deze techniek wordt een applicatie opzettelijk laten falen, zodat de robuustheid ervan kan worden gecontroleerd en de zwakke punten kunnen worden geïdentificeerd. In tegenstelling tot testmethoden die verifiëren wat de applicatie zou moeten doen, onderzoekt destructief testen onvoorspelbaar gebruikersgedrag binnen de applicatie.

Kennis van de oorspronkelijke eisen is niet nodig voor destructief onderzoek. Enige kennis is echter wel nuttig bij de ontwikkeling.ping een goede teststrategie.

De onderstaande afbeelding illustreert dit idee: de tester werkt tegen het product in plaats van ermee.

Het concept van destructief testen: een applicatie die opzettelijk tot het punt van falen wordt gedreven.

Waarom wordt destructief onderzoek uitgevoerd?

  • Het helpt om voorspelbaar softwaregedrag te begrijpen wanneer de software onjuist wordt gebruikt.
  • Het helpt om de robuustheid van een softwareproduct te controleren.
  • Het brengt zeldzame defecten aan het licht die gewone gebruikers nooit veroorzaken, maar die later in het productieproces aan het licht komen.

Destructief onderzoek versus niet-destructief onderzoek

De twee benaderingen vullen elkaar aan, ze zijn geen concurrenten. Niet-destructief onderzoek — ook wel positief of 'happy-path' testen genoemd — interacteert correct met de software en laat de build intact. Destructief testen doet het tegenovergestelde: het voert ongeldige data en verkeerde sequenties in totdat er iets kapot gaat.

Aspect Destructief testen Niet-destructief onderzoek
Doel Dwing de applicatie om te falen Controleer of de applicatie werkt zoals beschreven.
Gebruikte invoer Ongeldig, misvormd, buiten bereik, niet in de juiste volgorde Geldige gegevens binnen het verwachte bereik
Vraag beantwoord Waar en hoe gaat het kapot? Doet hij wat het zou moeten doen?
Vereistenkennis optioneel Essentiële
Typische kosten Hoger niveau — verkennend en open-ended Onder — gescript en herhaalbaar
Resultaat Storingspunten, bereiklimieten, herstelgedrag Voldoen aan de specificaties of niet?

Wat controleer je bij destructief onderzoek?

Bij destructief onderzoek worden beide kanten van de gedragsgrens bekeken:

  • Correct softwaregedrag
  • Onjuist softwaregedrag
  • Oneigenlijk gebruik
  • Onjuiste invoergegevens
  • Juiste uitvoergegevens

Tijdens de hele oefening moeten aan twee voorwaarden worden voldaan:

  • De software mag nooit ongeldige invoergegevens verwerken of accepteren.
  • Ongeacht de geldigheid of juistheid van de invoergegevens, moet de software altijd correcte uitvoergegevens produceren.
Mis het niet:

Hoe destructief testen uit te voeren?

Destructief testen omvat veel activiteiten, zoals het ontwerpen van een reeks testscripts, het uitvoeren van die scripts, het melden van bugs, het oplossen van bugs en het aan het einde van de iteratie verstrekken van resultaten (geslaagd of mislukt) aan de belanghebbenden.

Er zijn talloze manieren om het uit te voeren. Enkele voorbeelden volgen.

  • Analysemethode voor faalpunten: Een stapsgewijze handleiding van het systeem die beoordeelt wat er op verschillende punten mis zou kunnen gaan. Hulp van een bedrijfsanalist kan voor deze strategie worden aangenomen.
  • Peer review door testers: haal je testgevallen geanalyseerd of beoordeeld door een collega-tester die minder bekend is met het systeem of de functie.
  • Bedrijfsevaluatie van testgevallen: Eindgebruikers of experts bedenken vaak geldige scenario's die testers over het hoofd zien, omdat de tester zich concentreert op de gestelde eisen.
  • Voer verkennende tests uit met behulp van testprotocollen: verkennende tests Testformulieren registreren wat er is getest, maken het mogelijk om de tests te herhalen en zorgen ervoor dat de testdekking onder controle blijft.
  • Gebruik een andere bron: Vraag iemand anders om het softwareproduct te laten crashen en analyseer de scenario's die daarbij ontstaan.

Voorbeeld van destructief onderzoek

Neem bijvoorbeeld de inlog- en profielschermen van een bankapplicatie. Een destructieve aanval zou in gevallen als deze werken:

  • Plak een tekenreeks van 5,000 tekens in een veld dat is beperkt tot 50 tekens en bevestig dat het veld de tekenreeks weigert in plaats van deze stilzwijgend af te korten.
  • Voer letters, symbolen en negatieve waarden in een numeriek bedragveld in.
  • Doorbreek de verwachte volgorde: open direct de pagina met de betalingsbevestiging zonder de voorgaande stap te voltooien.
  • Druk herhaaldelijk en snel achter elkaar op 'Verzenden' om te zien of er dubbele records worden aangemaakt.
  • Verbreek de netwerkverbinding midden in de transactie en controleer of de applicatie probleemloos herstelt of een gedeeltelijke registratie achterlaat.

Voor elk geval geldt een vastgestelde verwachting: een duidelijke validatiemelding, geen gegevenscorruptie en geen onafgehandelde uitzondering. Alles wat hiervan afwijkt, is een faalpunt dat als defect moet worden gemeld.

Destructieve testmethoden

De volgende methoden worden in de software-engineering gebruikt om destructieve testdoelen te bereiken:

Destructieve testtechnieken

De onderstaande technieken kunnen met enkele aanpassingen worden gebruikt:

Aanverwante technieken die de moeite waard zijn om toe te voegen wanneer robuustheid het doel is, zijn: negatief testen, stresstests, herstel testen en fuzz-testen.

Voordelen en nadelen van destructief onderzoek

Het is belangrijk om de afweging duidelijk te vermelden voordat de techniek in een release wordt opgenomen.

Voordelen

  • Revlegt zwakke punten bloot die bij specificatiegestuurde tests nooit aan het licht komen.
  • Hiermee worden realistische bereiklimieten vastgesteld, zodat het product daarbinnen met vertrouwen kan worden gebruikt.
  • Legt zeldzame defecten bloot die pas lang na de release tijdens de productie aan het licht komen.
  • Test de duurzaamheid, het herstelvermogen en de foutafhandeling onder zware belasting.

Nadelen

  • Omdat het van nature een open vraag is, kan de dekking niet gegarandeerd of eenvoudig gemeten worden.
  • Tijdrovend en afhankelijk van de ervaring en creativiteit van de tester.
  • Bevindingen zijn moeilijk te reproduceren zonder een zorgvuldige registratie van de uitgevoerde stappen.
  • Slecht gecontroleerde testruns kunnen gedeelde testgegevens beschadigen, daarom is een geïsoleerde omgeving vereist.

Veelgestelde vragen

Ze overlappen elkaar, maar verschillen in reikwijdte. Negatieve testen Bij destructief testen worden gedefinieerde ongeldige invoerwaarden vergeleken met de verwachte foutafhandeling. Destructief testen is breder en minder gericht op het vinden van elke mogelijke oorzaak waardoor de applicatie faalt.

Meestal zijn dit ervaren QA-engineers, ondersteund door collega's die niet bekend zijn met de module en door zakelijke gebruikers. Een externe blik is belangrijk, omdat de mensen die de functionaliteit hebben ontwikkeld, deze doorgaans testen zoals deze is ontworpen.

Nadat de functionele testsuite stabiel is, wijzen eventuele fouten op robuustheid in plaats van onafgewerkte functionaliteiten. Veel teams plannen dit tijdens de systeemtests en herhalen het vóór belangrijke releases. testlevenscyclus.

Modellen genereren misvormde payloads, grenswaarden en ongebruikelijke actiesequenties op een volume dat geen enkele tester kan evenaren, en rangschikken vervolgens welke de afwijkingen hebben veroorzaakt. Machine learning op basis van historische defectgegevens voorspelt ook welke modules de strengste behandeling verdienen.

GitHub-copiloot Het programma ontwerpt snel inputgeneratoren, randgevallen en teardown-routines. Een tester beslist echter nog steeds welke faalmodi relevant zijn en of het waargenomen gedrag als een acceptabel resultaat geldt.

De exacte invoer of volgorde die is gebruikt, de geconstateerde fout, logbestanden en schermafbeeldingen, de omgeving en de ernst van de impact. De succes- of faalcriteria voor de iteratie worden samen met de resultaten aan de belanghebbenden gepresenteerd. defectenregistraties.

Het mag nooit in een productieomgeving terechtkomen. Voer het uit in een geïsoleerde omgeving met herstelbare gegevens, want opzettelijk ongeldige invoer en geforceerde crashes kunnen onvolledige gegevensbestanden achterlaten die kostbaar zijn om te herstellen.

Houd tijdens de sessie een uitvoerblad bij waarop elke actie en invoer in de juiste volgorde wordt vastgelegd. Speel het blad opnieuw af vanuit een schone toestand en reduceer het vervolgens tot de kortste reeks acties die de fout nog steeds veroorzaakt.

Vat dit bericht samen met: