Vad är destruktiv testning i programvara?

By: Thomas Hamilton Thomas Hamilton
Hours Uppdaterad

⚡ Smart sammanfattning

Destruktiv testning driver medvetet en mjukvaruapplikation tills den misslyckas, vilket avslöjar exakt de punkter där robustheten bryts ner vid felaktig användning, ogiltig inmatning och oförutsägbart beteende som vanliga funktionskontroller aldrig når.

  • ???? Kärnidé: Applikationen är gjord för att misslyckas med flit så att dess felpunkter blir synliga och mätbara.
  • 🔎 Inga krav behövs: Förkunskaper om specifikationen är valfria, men det skärper teststrategin.
  • ⚖️ Motsatt par: Icke-förstörande provning går den lyckliga vägen; destruktiv provning angriper den från alla felaktiga vinklar.
  • 🧰 Tillvägagångssätt: Analys av felpunkter, granskning av testare, verksamhetsgranskning och utforskande körningar med körblad.
  • 🧪 Återanvända metoder: Regressionstestning, gränssnittstestning, ekvivalenspartitionering, looptestning och acceptanstestning tjänar alla destruktiva mål.
  • 📉 Ärliga gränser: Täckning är svår att garantera, ansträngningen är hög och resultaten kan vara svåra att reproducera.
Läs mer

Vad är destruktiv testning i programvara med metoder och tekniker

Vad är destruktiv testning?

Destruktiv provning är en metod för mjukvarutestning som används för att hitta felpunkter i ett program. I den här tekniken görs en applikation avsiktligt fel, så att dess robusthet kan kontrolleras och dess felpunkter identifieras. Till skillnad från testmetoder som verifierar vad applikationen ska göra, undersöker destruktiv testning oförutsägbart användarbeteende inuti applikationen.

Kunskap om de ursprungliga kraven är inte nödvändig för destruktiv provning. Viss kunskap är dock till hjälp vid utvecklingping en bra teststrategi.

Illustrationen nedan fångar idén – testaren arbetar mot produkten snarare än med den.

Koncept för destruktiv testning: en applikation som avsiktligt pressas till bristens punkt

Varför utföra destruktiv testning?

  • Det hjälper till att förstå förutsägbart programvarubeteende när programvaran används felaktigt.
  • Det hjälper till att kontrollera robustheten hos en mjukvaruprodukt.
  • Den avslöjar sällsynta defekter som vanliga användare aldrig utlöser men som uppstår senare i produktionen.

Destruktiv testning kontra icke-destruktiv testning

De två tillvägagångssätten kompletterar varandra, inte är rivaler. Icke-förstörande provning — även kallad positiv testning eller lyckotestning — interagerar korrekt med programvaran och lämnar bygget intakt. Destruktiv testning gör motsatsen: den matar ogiltig data och felaktiga sekvenser tills något går sönder.

Aspect Destruktiv provning Icke-förstörande provning
Intent Tvinga applikationen att misslyckas Bekräfta att applikationen fungerar som angivet
Inmatning som används Ogiltig, felaktigt formaterad, utanför intervallet, utanför sekvensen Giltiga data inom det förväntade intervallet
Fråga besvarad Var och hur går den sönder? Gör den vad den ska?
Kravkunskap Frivillig Väsentlig
Typisk kostnad Högre — utforskande och öppet Lägre — skriptad och repeterbar
Resultat Felpunkter, räckviddsgränser, återhämtningsbeteende Godkänd eller misslyckad enligt specifikationen

Vad kontrollerar man vid destruktiv provning?

Destruktiv testning tittar på båda sidor av beteendegränsen:

  • Korrekt programvarubeteende
  • Felaktigt programvarubeteende
  • Felaktig användning
  • Felaktiga indata
  • Korrekt utdata

Två villkor måste gälla under hela övningen:

  • Programvaran ska aldrig bearbeta eller acceptera ogiltiga indata.
  • Oavsett indatas giltighet eller korrekthet bör programvaran alltid producera korrekta utdata.

RELATERADE ARTIKLAR

Hur gör man destruktiva tester?

Destruktiv testning involverar många aktiviteter, såsom att designa en uppsättning testskript, köra dessa skript, rapportera buggar, åtgärda buggar och tillhandahålla godkänd- eller misslyckadtestmetriker till intressenter i slutet av iterationen.

Det finns många sätt att köra det. Några exempel följer.

  • Metod för analys av felpunkter: en genomgång av systemet som bedömer vad som kan gå fel vid olika tidpunkter. Hjälp från en affärsanalytiker kan vidtas för denna strategi.
  • Peer review av testare: få din testfall analyserad eller granskad av en annan testare som är mindre bekant med systemet eller funktionen.
  • Affärsgranskning av testfall: Slutanvändare eller experter tänker ofta på giltiga scenarier som testare missar, eftersom testarens fokus ligger på de angivna kraven.
  • Genomför utforskande tester med hjälp av körningsblad: utforskande testning Med körscheman registreras vad som testades, testerna kan upprepas och testtäckningen hålls under kontroll.
  • Använd en annan källa: be någon annan att förstöra programvaruprodukten och analysera de scenarier de hittar.

Exempel på destruktiv testning

Tänk på inloggnings- och profilskärmarna i en bankapplikation. En destruktiv pass skulle fungera i fall som dessa:

  • Klistra in en sträng på 5 000 tecken i ett fält som är begränsat till 50 tecken och bekräfta att fältet avvisar den istället för att avkortas tyst.
  • Skicka in bokstäver, symboler och negativa värden i ett numeriskt beloppsfält.
  • Bryt den förväntade sekvensen — öppna betalningsbekräftelsesidan direkt utan att slutföra föregående steg.
  • Tryck på skicka upprepade gånger i snabb följd för att se om dubbletter skapas.
  • Koppla bort nätverket mitt under en transaktion och kontrollera om programmet återställer sig utan problem eller lämnar en ofullständig post.

Varje fall har en definierad förväntan: ett tydligt valideringsmeddelande, ingen datakorruption och inget ohanterat undantag. Allt annat är en felpunkt värd att lyfta fram som en defekt.

Destruktiva testmetoder

Följande metoder används inom mjukvaruutveckling för att uppnå mål med destruktiv testning:

Destruktiva testtekniker

Teknikerna nedan kan användas med modifieringar:

Intilliggande tekniker som är värda att lägga till när robusthet är målet är negativa tester, stresstestning, återhämtningstestning och fuzz testning.

Fördelar och nackdelar med destruktiv testning

Avvägningen är värd att tydligt ange innan tekniken planeras för en lansering.

Fördelar

  • Revidentifierar felpunkter som specifikationsdriven testning aldrig når.
  • Upprättar verkliga räckviddsgränser, så att produkten kan användas inom dem med tillförsikt.
  • Avslöjar sällsynta defekter som uppstår i produktionen långt efter lansering.
  • Kontrollerar hållbarhet, återställningsbarhet och felhantering vid missbruk.

Nackdelar

  • Öppen till sin natur, så täckning kan inte garanteras eller mätas enkelt.
  • Tidskrävande och beroende på testarens erfarenhet och kreativitet.
  • Resultat kan vara svåra att reproducera utan noggrann loggning av de använda stegen.
  • Dåligt kontrollerade körningar kan skada delade testdata, så en isolerad miljö krävs.

Vanliga frågor

De överlappar varandra men skiljer sig åt i omfattning. Negativ testning kontrollerar definierade ogiltiga indata mot förväntad felhantering. Destruktiv testning är bredare och öppen och letar efter alla villkor som gör att applikationen misslyckas.

Vanligtvis erfarna QA-ingenjörer, med stöd av kollegor som inte känner till modulen och av affärsanvändare. Utomstående ögon är viktiga, eftersom de personer som byggde funktionen tenderar att testa den som den designades.

Efter att funktionssviten är stabil, så pekar fel på robusthet snarare än ofärdiga funktioner. Många team schemalägger det under systemtestning och upprepar det före större utgåvor i testningens livscykel.

Modeller genererar felaktiga nyttolaster, gränsvärden och ovanliga åtgärdssekvenser vid en volym som ingen testare kan matcha, och rangordnar sedan vilka som producerade avvikelser. Maskininlärning baserad på tidigare defektdata förutsäger också vilka moduler som förtjänar den hårdaste behandlingen.

GitHub Copilot utarbetar snabbt ingångsgeneratorer, gränsfall och nedmonteringsrutiner. En testare avgör fortfarande vilka fellägen som är viktiga och om det observerade beteendet räknas som ett acceptabelt resultat.

Den exakta inmatningen eller sekvensen som använts, det observerade felet, loggar och skärmdumpar, miljön och hur allvarlig påverkan var. Godkända eller misslyckade mätvärden för iterationen skickas till intressenterna tillsammans med felregister.

Den ska aldrig vidröra produktion. Kör den i en isolerad miljö med återställningsbara data, eftersom avsiktligt ogiltig inmatning och framtvingade krascher kan lämna ofullständiga poster som är dyra att rensa upp.

För ett löpande schema under sessionen där du dokumenterar varje handling och inmatning i ordning. Spela upp schemat från ett rent tillstånd och reducera det sedan till den kortaste sekvensen som fortfarande utlöser felet.

Sammanfatta detta inlägg med: