Mitä on tuhoava testaus ohjelmistoissa?
Thomas Hamilton
⚡ Älykäs yhteenveto
Tuhoava testaus ajaa ohjelmistosovellusta tarkoituksella kaatumaan asti, paljastaen tarkat kohdat, joissa sen kestävyys pettää väärän käytön, virheellisen syötteen ja arvaamattoman käyttäytymisen vuoksi, joihin tavalliset toiminnalliset tarkistukset eivät koskaan yltä.
Mitä tuhoava testaus on?
Tuhoava testaus on ohjelmistotestausmenetelmä, jota käytetään löytämään ohjelmiston vikakohtia. Tässä tekniikassa sovellus tehdään tarkoituksella vikaantuvaksi, jotta sen kestävyyttä voidaan tarkistaa ja vikakohdat tunnistaa. Toisin kuin testausmenetelmät, jotka varmistavat, mitä sovelluksen on tarkoitus tehdä, tuhoava testaus tutkii ennakoimatonta käyttäjän käyttäytymistä sovelluksen sisällä.
Alkuperäisten vaatimusten tuntemus ei ole välttämätöntä rikkovalle testaukselle. Jonkin verran tietoa on kuitenkin hyödyllistä kehitystyössä.ping hyvä testausstrategia.
Alla oleva kuva kiteyttää ajatuksen – testaaja työskentelee tuotetta vastaan eikä sen kanssa.
Miksi tuhoavaa testausta tehdään?
- Se auttaa ymmärtämään ohjelmiston ennustettavaa toimintaa, kun ohjelmistoa käytetään väärin.
- Se auttaa tarkistamaan ohjelmistotuotteen kestävyyden.
- Se tuo esiin harvinaisia vikoja, joita tavalliset käyttäjät eivät koskaan huomaa, mutta jotka ilmenevät myöhemmin tuotannossa.
Tuhoava testaus vs. rikkomaton testaus
Nämä kaksi lähestymistapaa täydentävät toisiaan, eivät kilpaile. Tuhoamaton testaus – jota kutsutaan myös positiiviseksi tai onnellisen polun testaukseksi – toimii ohjelmiston kanssa oikein ja jättää koonnin ennalleen. Tuhoava testaus toimii päinvastoin: se syöttää virheellistä dataa ja vääriä sekvenssejä, kunnes jokin hajoaa.
| Aspect | Tuhoava testaus | Tuhoamaton testaus |
| Tarkoitus | Pakota sovellus epäonnistumaan | Varmista, että sovellus toimii määritellyllä tavalla |
| Käytetty syöte | Virheellinen, väärin muotoiltu, alueen ulkopuolella, järjestyksen ulkopuolella | Kelvolliset tiedot odotetulla alueella |
| Kysymykseen vastattu | Missä ja miten se rikkoutuu? | Tekeekö se mitä sen pitäisi? |
| Vaatimusten tuntemus | Suosittelijan tunnus | Essential |
| Tyypillinen hinta | Korkeampi — tutkiva ja avoin | Alempi — skriptattu ja toistettavissa |
| Tulos | Vikakohdat, vaihteluvälin rajat, palautumiskäyttäytyminen | Hyväksytty tai hylätty spesifikaatiota vasten |
Mitä tarkistat rikkovassa testauksessa?
Tuhoava testaus tarkastelee käyttäytymisrajan molempia puolia:
- Ohjelmiston oikea toiminta
- Ohjelmiston virheellinen toiminta
- Epäasianmukainen käyttö
- Virheelliset syöttötiedot
- Oikeat lähtötiedot
Kahden ehdon on täytyttävä koko harjoituksen ajan:
- Ohjelmisto ei saa koskaan käsitellä tai hyväksyä virheellisiä syöttötietoja.
- Syöttötietojen oikeellisuudesta tai pätevyydestä riippumatta ohjelmiston tulisi aina tuottaa oikeaa tulostusdataa.
Kuinka tehdä tuhoava testi?
Tuhoava testaus sisältää monia toimintoja, kuten testiskriptien suunnittelun, niiden suorittamisen, virheiden nostamisen esiin, virheiden korjaamisen ja läpäisy- tai hylkäysmittareiden toimittamisen sidosryhmille iteraation lopussa.
Sen voi suorittaa monella eri tavalla. Joitakin esimerkkejä on seuraavassa.
- Vikapisteen analyysimenetelmä: järjestelmän läpikäynti, jossa arvioidaan, mikä voi mennä pieleen eri vaiheissa. Apua liiketoiminnan analyytikko voidaan ottaa huomioon tässä strategiassa.
- Testaajan vertaisarviointi: saat oman testitapaukset analysoinut tai tarkistanut toinen testaaja, joka tuntee järjestelmän tai toiminnon vähemmän.
- Testitapausten liiketoiminnan tarkastelu: Loppukäyttäjät tai asiantuntijat usein keksivät päteviä skenaarioita, jotka testaajat eivät huomaa, koska testaajan keskittyminen on ilmoitettuihin vaatimuksiin.
- Suorita tutkiva testaus käyttämällä ajolomakkeita: tutkiva testaus Suorituslomakkeilla kirjataan testatut tiedot, mikä mahdollistaa testien toistamisen ja pitää testikattavuuden hallinnassa.
- Käytä toista lähdettä: pyydä jotakuta muuta purkamaan ohjelmistotuote ja analysoimaan löytämänsä skenaariot.
Esimerkki tuhoavasta testauksesta
Ajatellaanpa pankkisovelluksen kirjautumis- ja profiilinäyttöjä. Tuhoava salasana toimisi esimerkiksi seuraavissa tapauksissa:
- Liitä 5 000 merkin pituinen merkkijono kenttään, jonka pituus on rajoitettu 50 merkkiin, ja varmista, että kenttä hylkää sen sen sijaan, että se katkaistaisiin äänettömästi.
- Syötä kirjaimia, symboleja ja negatiivisia arvoja numeeriseen summakenttään.
- Rikkoa odotettu toimintajärjestys — avaa maksun vahvistussivu suoraan suorittamatta edellistä vaihetta.
- Paina Lähetä-painiketta toistuvasti ja nopeasti peräkkäin nähdäksesi, luodaanko tietueiden kaksoiskappaleita.
- Katkaise verkkoyhteys kesken tapahtuman ja tarkista, palautuuko sovellus virheettömästi vai jättääkö jäljelle vain osittaisen tallenteen.
Jokaisella tapauksella on määritelty odotusarvo: selkeä validointiviesti, ei datan korruptoitumista eikä käsittelemättömiä poikkeuksia. Kaikki muu on vika, joka kannattaa nostaa esiin virheenä.
Tuhoavat testausmenetelmät
Seuraavia menetelmiä käytetään ohjelmistotekniikassa tuhoavan testauksen tavoitteiden saavuttamiseksi:
- Alfa-/beta-testaus
- Regressiotestaus
- Käyttöliittymän testaus
- Ekvivalenssiositus
- Silmukan testaus
- Hyväksyntätestaus ja niin edelleen
Tuhoavat testaustekniikat
Seuraavia tekniikoita voidaan käyttää muutoksin:
- Valkoisen laatikon testaus
- Turvallisuustestaus
- Vikatestaus
- Savutestaus, ja niin edelleen
Vierekkäiset tekniikat, jotka kannattaa lisätä, kun tavoitteena on kestävyys, ovat negatiivinen testi, stressitestaus, palautumistesti ja fuzz-testaus.
Tuhoavan testauksen edut ja haitat
Kompromissi kannattaa mainita selvästi ennen kuin tekniikkaa suunnitellaan julkaisuun.
edut
- Revhavaitsee vikapisteet, joihin spesifikaatiopohjainen testaus ei koskaan saavuta.
- Määrittää todelliset toimintasäteen rajat, jotta tuotetta voidaan käyttää niiden sisällä luottavaisin mielin.
- Paljastaa harvinaisia vikoja, jotka ilmenevät tuotannossa kauan julkaisun jälkeen.
- Tarkistaa kestävyyden, palautettavuuden ja virheiden käsittelyn väärinkäytön aikana.
Haitat
- Luonteeltaan avoin, joten kattavuutta ei voida taata tai mitata helposti.
- Aikaa vievää ja riippuu testaajien kokemuksesta ja luovuudesta.
- Löydöksiä voi olla vaikea toistaa ilman huolellista käytettyjen vaiheiden kirjaamista.
- Huonosti kontrolloidut testiajot voivat vioittaa jaettua testidataa, joten erillinen ympäristö on välttämätön.
