Mis on tarkvaras destruktiivne testimine?

Autor: Thomas Hamilton Thomas Hamilton
Hours Ajakohastatud

⚡ Nutikas kokkuvõte

Destruktiivne testimine surub tarkvararakendust tahtlikult seni, kuni see ebaõnnestub, paljastades täpsed punktid, kus töökindlus ebaõnnestub ebaõige kasutamise, sobimatu sisendi ja ettearvamatu käitumise tõttu, kuhu tavalised funktsionaalsed kontrollid kunagi ei jõua.

  • ???? Põhiidee: Rakendus on meelega ebaõnnestuma pandud, et selle tõrkekohad oleksid nähtavad ja mõõdetavad.
  • 🔎 Nõudeid pole vaja: Spetsifikatsiooni eelnev tundmine on valikuline, kuigi see teravdab testimisstrateegiat.
  • 🇧🇷 Vastaspaar: Mittepurustav testimine käib õnnelikku rada; destruktiivne testimine ründab seda igast vale nurga alt.
  • 🧰 Lähenemised: Veapunktide analüüs, testijate vastastikune hindamine, äriülevaade ja uurimuslikud katsetused koos katselehtedega.
  • 🧪 Taaskasutatud meetodid: Regressioon, liidestestimine, ekvivalentsusjaotus, tsükli- ja vastuvõtutestimine teenivad kõik destruktiivseid eesmärke.
  • 📉 Ausad piirid: Katvust on raske garanteerida, pingutus on suur ja leide võib olla raske korrata.
Loe rohkem

Mis on tarkvaras destruktiivne testimine koos meetodite ja tehnikatega

Mis on hävitav testimine?

Destruktiivne katsetamine on tarkvara testimise meetod, mida kasutatakse tarkvaraprogrammi tõrkekohtade leidmiseks. Selle tehnika puhul pannakse rakendus tahtlikult ebaõnnestuma, et saaks kontrollida selle töökindlust ja tuvastada tõrkekohti. Erinevalt testimismeetoditest, mis kontrollivad, mida rakendus peaks tegema, uurib destruktiivne testimine ettearvamatut kasutajakäitumist rakenduses.

Algsete nõuete tundmine ei ole purustava testimise jaoks vajalik. Mõningane teadmine on aga arendusprotsessis abiks.ping hea testimisstrateegia.

Allolev illustratsioon tabab idee – testija töötab toote vastu, mitte koos sellega.

Destruktiivse testimise kontseptsioon: rakendus, mida tahtlikult surutakse rikkepunkti.

Miks tehakse destruktiivset testimist?

  • See aitab mõista tarkvara ennustatavat käitumist olukordades, kus seda kasutatakse valesti.
  • See aitab kontrollida tarkvaratoote töökindlust.
  • See toob esile haruldased defektid, mida tavakasutajad kunagi ei põhjusta, kuid mis ilmnevad hiljem tootmises.

Hävitav testimine vs mittepurustav testimine

Need kaks lähenemisviisi täiendavad teineteist, mitte ei ole konkurendid. Mittepurustav katsetamine – mida nimetatakse ka positiivseks või õnneliku tee testimiseks – suhtleb tarkvaraga korrektselt ja jätab versiooni puutumata. Destruktiivne testimine toimib vastupidiselt: see toidab vigaseid andmeid ja valesid järjestusi, kuni midagi katki läheb.

Aspekt Destruktiivne katsetamine Mittepurustav katsetamine
Tahtlus Rakenduse sundimine nurjuma Veenduge, et rakendus töötab ettenähtud viisil
Kasutatud sisend Kehtetu, vigane, vahemikust väljas, järjestusest väljas Kehtivad andmed eeldatavas vahemikus
Küsimusele vastati Kus ja kuidas see katki läheb? Kas see teeb seda, mida peaks?
Nõuete tundmine vabatahtlik oluline
Tüüpiline maksumus Kõrgem — uurimuslik ja avatud Madalam — skriptitud ja korratav
Tulemus Rikkepunktid, ulatuse piirid, taastumiskäitumine Vastab spetsifikatsioonile või ei vasta sellele

Mida kontrollitakse destruktiivse testimise käigus?

Destruktiivne testimine vaatleb käitumispiiri mõlemat poolt:

  • Tarkvara õige käitumine
  • Tarkvara vale käitumine
  • Ebaõige kasutamine
  • Valed sisendandmed
  • Õiged väljundandmed

Kogu harjutuse vältel peavad kehtima kaks tingimust:

  • Tarkvara ei tohi kunagi töödelda ega aktsepteerida sobimatuid sisendandmeid.
  • Olenemata sisendandmete kehtivusest või õigsusest peaks tarkvara alati tootma korrektseid väljundandmeid.
Ära jäta:

Kuidas teha hävitavat testimist?

Destruktiivne testimine hõlmab paljusid tegevusi, näiteks testiskriptide komplekti kavandamist, nende käivitamist, vigade esiletõstmist, vigade parandamist ning iteratsiooni lõpus sidusrühmadele läbimise või mitteläbimise mõõdikute edastamist.

Selle käivitamiseks on palju võimalusi. Järgnevalt on toodud mõned näited.

  • Rikkepunktide analüüsi meetod: süsteemi läbivaatus, mis hindab, mis võib eri punktides valesti minna. Abi a-lt ärianalüütik võib selle strateegia jaoks võtta.
  • Testijate vastastikune hindamine: saada oma testjuhtumid analüüsitud või üle vaadatud kaastestija poolt, kes on süsteemi või funktsiooniga vähem tuttav.
  • Testjuhtumite äriline ülevaade: Lõppkasutajad või eksperdid mõtlevad sageli välja sobivaid stsenaariume, mis testijatel kahe silma vahele jäävad, kuna testija keskendub esitatud nõuetele.
  • Tehke uurimuslikke katseid, kasutades arvutustabeleid: uurimuslik testimine Testimise käigus kogutud andmed registreeritakse testide arvu, mis võimaldab teste korrata ja hoiab testide ulatuse kontrolli all.
  • Kasutage teist allikat: paluge kellelgi teisel tarkvaratoode lahti võtta ja leitud stsenaariume analüüsida.

Destruktiivse testimise näide

Mõelge pangarakenduse sisselogimis- ja profiiliekraanidele. Hävitav parool toimiks sellistel juhtudel:

  • Kleepige 5,000 tähemärgi pikkune string 50 tähemärgiga väljale ja veenduge, et väli lükkab selle tagasi, selle asemel et seda vaikselt kärpida.
  • Sisestage numbrilise summa väljale tähed, sümbolid ja negatiivsed väärtused.
  • Katkesta oodatud järjestus – ava makse kinnitusleht otse ilma eelnevat sammu lõpetamata.
  • Vajutage korduvalt ja kiiresti järjest nuppu „Esita“, et näha, kas luuakse duplikaatkirjeid.
  • Katkestage võrguühendus tehingu keskel ja kontrollige, kas rakendus taastub korrektselt või jätab alles vaid osalise kirje.

Igal juhul on määratletud ootus: selge valideerimissõnum, andmete rikkumise puudumine ja käsitlemata erandite puudumine. Kõik muu on rike, mida tasub defektina tõstatada.

Destruktiivsed testimismeetodid

Tarkvaratehnikas kasutatakse destruktiivse testimise eesmärkide saavutamiseks järgmisi meetodeid:

Destruktiivsed testimismeetodid

Allpool toodud tehnikaid saab kasutada muudatustega:

Kui eesmärk on vastupidavus, tasub lisada kõrvaltehnikaid, näiteks negatiivne test, stressitestimine, taastumise testimine ja hägustestimine.

Destruktiivse testimise eelised ja puudused

Enne tehnika väljalaskeks kavandamist tasub kompromiss selgelt välja öelda.

Eelised

  • Revtuvastab tõrkepunktid, milleni spetsifikatsioonipõhine testimine kunagi ei jõua.
  • Määrab kindlaks tegelikud ulatuse piirid, et toodet saaks nende sees enesekindlalt kasutada.
  • Paljastab haruldased defektid, mis ilmnevad tootmises kaua pärast väljaandmist.
  • Kontrollib vastupidavust, taastatavust ja veakäsitlust väärkasutuse korral.

Puudused

  • Oma olemuselt avatud, seega ei ole katvust võimalik garanteerida ega kergesti mõõta.
  • Aeganõudev ja sõltub testija kogemusest ja loovusest.
  • Ilma kasutatud sammude hoolika logimiseta võib leidude taasesitamine olla keeruline.
  • Halvasti kontrollitud testid võivad jagatud testandmeid rikkuda, seega on vaja isoleeritud keskkonda.

KKK

Need kattuvad, kuid erinevad ulatuse poolest. Negatiivne test kontrollib määratletud sobimatuid sisendeid oodatava veakäsitluse suhtes. Destruktiivne testimine on laiem ja avatud, otsides mis tahes tingimust, mis põhjustab rakenduse ebaõnnestumise.

Tavaliselt kogenud kvaliteedikontrolli insenerid, keda toetavad mooduliga mitte tuttavad kolleegid ja ärikasutajad. Väline pilk on oluline, sest funktsiooni loonud inimesed kipuvad seda testima nii, nagu see oli kavandatud.

Pärast seda, kui funktsionaalne komplekt on stabiilne, viitavad tõrked pigem vastupidavusele kui lõpetamata funktsioonidele. Paljud meeskonnad planeerivad selle süsteemi testimise ajal ja kordavad seda enne suuremaid väljaandeid. testimise elutsükkel.

Mudelid genereerivad vigaseid kasulikke koormusi, piirväärtusi ja ebatavalisi toimingujadasid mahus, millega ükski testija ei suuda sammu pidada, ning seejärel järjestavad need, mis tekitasid anomaaliaid. Masinõpe varasemate defektide andmete põhjal ennustab ka, millised moodulid väärivad kõige karmimat kohtlemist.

GitHubi koopia koostab kiiresti sisendgeneraatorid, piirjuhtumid ja lahtivõtmise rutiinid. Testija otsustab ikkagi, millised rikkeviisid on olulised ja kas vaadeldav käitumine loetakse vastuvõetavaks tulemuseks.

Täpne kasutatud sisend või järjestus, täheldatud tõrge, logid ja ekraanipildid, keskkond ja mõju raskusaste. Iteratsiooni läbimise või läbikukkumise mõõdikud edastatakse sidusrühmadele koos defektide andmed.

See ei tohiks kunagi tootmiskeskkonda puutuda. Käitage seda isoleeritud keskkonnas taastatavate andmetega, sest tahtlikult vale sisend ja sunnitud krahhid võivad jätta osalisi kirjeid, mille puhastamine on kulukas.

Seansi ajal pidage jooksvat tabelit, kuhu salvestate kõik toimingud ja sisendid õiges järjekorras. Esitage tabelit uuesti puhtalt olekust ja seejärel lühendage see lühima järjestuseni, mis ikka veel tõrke käivitab.

Võta see postitus kokku järgmiselt: