Mikä on negatiivinen testaus? Testitapaukset esimerkin kanssa

by: Thomas Hamilton Thomas Hamilton
Hours Päivitetty

⚡ Älykäs yhteenveto

Negatiivisessa testauksessa tarkistetaan, miten ohjelmistosovellus käyttäytyy vastaanottaessaan odottamattomia syöttötietoja tai käyttöolosuhteita, jotta tuote heikkenee hallitusti kaatumisen, tietojen vioittumisen tai tietoturva-aukon paljastamisen sijaan.

  • 🔴 Tarkoitus: Varmista, että sovellus hylkää virheelliset tiedot puhtaasti virheen tai kaatumisen sijaan.
  • 🇧🇷 Kontrasti: Positiivinen testi todistaa onnellisen polun; negatiivinen testi tutkii kaiken sen ulkopuolella olevan.
  • 🛗 Analogia: Hissin on kestettävä ylikuormitus, tulipalo ja sähkökatkos, ei vain normaaleja matkustajamatkoja.
  • 🔒 Turvallisuus: Virheelliset lataukset ja SQL-injektioyritykset ovat klassisia negatiivisen testin skenaarioita.
  • 🧪 Suunnittelu: Raja-arvot, ekvivalenssiluokat, virheenarvaus ja sumeus luovat tapaukset.
  • 📊 Priority: Järjestä virheelliset syötteet vaikutuksen mukaan, koska kattava negatiivinen kattavuus ei ole mahdollinen.
  • ⚠️ Kompromissi: Liiallinen negatiivinen testaus kuluttaa budjettia, jota positiivinen kattavuus saattaa vaatia enemmän.
Lue lisää

Negatiivinen testaus ohjelmistotestauksessa virheellisten syötteiden esimerkeillä

Negatiivinen testaus

Negatiivinen testaus on ohjelmistotestaustyyppi, jota käytetään ohjelmistosovelluksen tarkistamiseen odottamattomia syöttötietoja ja -ehtoja vasten. Odottamattomat tiedot tai ehdot vaihtelevat väärästä tietotyypistä yksinkertaisessa lomakekentässä tahalliseen hakkerointihyökkäykseen. Negatiivisen testauksen tarkoituksena on estää sovelluksen kaatuminen virheellisen syötteen vuoksi ja parantaa tuotteen laatua ja vakautta.

Pelkkä positiivinen testaus todistaa vain, että järjestelmä toimii normaaleissa olosuhteissa. Negatiivinen testaus vahvistaa, että sama järjestelmä käsittelee myös poikkeavia olosuhteita, mikä on vikasietoisen tuotteen edellytys.

Esimerkki negatiivisesta testistä

Hissi on useimmiten negatiivisen testauksen selittämiseen käytetty esimerkki, koska sekä sen normaali käyttäytyminen että sen vikaantumiskäyttäytyminen on helppo hahmottaa.

Hissin vaatimukset ovat tutut: kerrosnumeron painaminen lähettää hissin kyseiseen kerrokseen, ja ovi avautuu automaattisesti, kun hissi saavuttaa määritetyn kerroksen.

Joitakin negatiivisia skenaarioita samalle nousulle on lueteltu alla sen oletuksen vieressä, jonka positiivinen testi tekee sen sijaan.

Negatiivinen testaus Positiivinen testaus
Mitä tapahtuu, jos henkilömäärä (paino) ylittää määritellyn rajan? Oletetaan, että hissiin menee vain määritelty määrä ihmisiä
Mitä tapahtuu, jos joku tupakoi tai aiheuttaa tulipalon hississä? Oletetaan, ettei hissin sisällä ole savua tai tulta
Mitä tapahtuu, jos virta katkeaa käytön aikana? Oletetaan, ettei sähkökatkoa tapahdu hissin käytön aikana

Kaikki nämä tapaukset kuuluvat negatiivisen testituloksen piiriin. Yhdenkään tapauksen toteumaa ei voida taata, joten jokainen niistä on rajoitettava.

Oletetaan, että ylikuormitustilannetta ei koskaan tarkisteta ja hissi käyttäytyy epänormaalisti ylikuormitettuna. Tuo yksittäinen rako vahingoittaa järjestelmän luotettavuutta ja voi jopa vaarantaa hengen. Tätä negatiivinen testaus käytännössä tarkoittaa ja miksi se on tärkeää.

Ohjelmisto toimii samalla tavalla. Negatiivinen testi poikkeaa tarkoituksella normaalista toimintatavasta. Tarkastellaan rekisteröintilomaketta.

Negatiivinen testaus Positiivinen testaus
Syötä virheellinen sähköpostiosoite sähköpostikenttään Sähköpostikenttään syötetään vain kelvolliset sähköpostiosoitteet
Syötä puhelinnumerokenttään virheellinen puhelinnumero, kuten merkkejä Numerokenttään syötetään vain numeroita
Lataa kuva, jonka koko on määritetyn rajan ulkopuolella Vain määritetyn kokorajan sisällä olevat kuvat ladataan
Lataa virheellisiä tiedostoja, kuten XML or SQL tiedostot kuvan latauskentässä Vain kelvollisia kuvamuotoja, kuten .jpg tai .png, ladataan.

Jokaisen näistä negatiivisista tapauksista on silti jätettävä järjestelmä toimimaan. Jos numerokenttään kirjoitetaan merkki, sovellus ei voi käsitellä odottamatonta dataa, jota se ei koskaan odottanut, ja se voi kaatua. Mikä pahempaa, SQL-injektio merkkijono samassa kentässä voi poistaa tietokannan sisällön. Tällaiset menetykset ovat syynä negatiivisten testitulosten olemassaoloon.

Miksi negatiivinen testaus?

Testaus vie aikaa ja rahaa, joten on tärkeää päättää, mitä, miten ja kuinka paljon testataan. Perustelut budjetin osan käyttämiselle negatiivisiin testeihin näyttävät erilaisilta projektin kahdelta eri osapuolelta.

Organisaation näkökulma

Laadukkaan tuotteen toimittaminen asiakkaalle on organisaation vastuulla, ja negatiivinen testaus on osa tätä velvoitetta. Se on myös organisaation todiste siitä, että se on tehnyt kaiken kohtuullisen estääkseen vian, vaikka mikään järjestelmä ei ole täysin virheetön.

Vaikuttavuus on ratkaiseva tekijä. Verkkokauppasivusto voi läpäistä kaikki positiiviset testit ja silti sisältää porsaanreiän, jonka avulla hyökkääjä voi suorittaa SQL-injektion ja poistaa sen takana olevat tiedot. Kyseessä on vakava tietoturvaloukkaus, ja vain negatiivinen testaus etsii sitä.

Julkisesti saatavilla olevat sovellukset, erityisesti verkkosivustot, eivät tarjoa juurikaan kontrollia kävijöiden käyttöön, joten negatiivinen testaus on ainoa tapa varmistaa, että epätavallinen käyttö on katettu ja rajoitettu. Sama pätee haitallisiin käyttäjiin: hyökkääjät etsivät aktiivisesti tilaisuutta murtaa järjestelmä, ja hakkerointiskenaariot kuuluvat ehdottomasti negatiivisen testin piiriin.

Asiakkaan näkökulma

Asiakkaat odottavat tuotetta, jossa ei ole lainkaan haavoittuvuuksia, ja negatiivinen testaus tukee tätä odotusta. Herkkien tuotteiden, kuten verkkokaupan tai online-osakekaupan, kohdalla turvallisuustestaus ja negatiiviset testit ovat pakollisia eivätkä valinnaisia.

Asiakkaan ainoa todellinen huolenaihe on kustannukset. Kun vian vaikutukset on analysoitu, asiakas voi päättää, kuinka pitkälle negatiivisen testauksen tulisi mennä.

AIHEESEEN LIITTYVÄT ARTIKKELIT

Kuinka tehdä negatiivinen testi

Negatiivinen testaus alkaa tarkastelemalla kaikkia syötteitä, jotka sovellus voi fyysisesti vastaanottaa, ei vain niitä syötteitä, joita sen on tarkoitus vastaanottaa. Jokainen näistä kuuluu johonkin Testitapaus vaikka se olisi ilmiselvästi väärä tapa käyttää ominaisuutta. Sähköpostiosoitekenttä testataan kaikella, mikä ei ole kelvollista sähköpostiosoitetta, ja kuvan latauksen ohjausobjekti testataan kaikilla tiedostotyypeillä, jotka eivät ole kuvia.

Mahdollisten virheellisten syötteiden luettelo on käytännössä loputon, joten negatiiviset testitapaukset on priorisoitava. Kuvakentässä, joka hyväksyy vain .png-tiedostoja, latauksiin voi ladata .jpeg-, .xml- ja .xls-tiedostoja sekä monia muita. XML- tai SQL-tiedostolla on paljon suurempi potentiaalinen vaikutus kuin .jpeg-tiedostolla, joten nämä tapaukset suoritetaan ensin. Tapausten luokittelu vaikutuksen perusteella ennen suorittamista pitää negatiiviset testit kohtuuhintaisina.

Useimmat negatiiviset testitapaukset syntyvät pikemminkin pienestä joukosta vakiintuneita suunnittelutekniikoita kuin improvisaatiosta:

  • Raja-arvot: Käytä arvoja välittömästi kelvollisen alueen ulkopuolella, kuten 0 ja 101 kentässä, joka hyväksyy arvot 1–100.
  • Virheelliset ekvivalenssiluokat: valitse yksi edustaja kustakin hylätyn syötteen luokasta, esimerkiksi kirjaimia numeerisessa kentässä.
  • Virhe arvauksessa: Käytä aiempien vikojen kokemusta kohdistaaksesi tiedot niihin syötteisiin, jotka todennäköisimmin rikkovat tämän tyyppisen ominaisuuden.
  • Väärin muotoillut ja vihamieliset tiedot: komentosarjatunnisteet, SQL-fragmentit ja ylisuuret hyötykuormat, jotka tutkivat validointia ja tietoturvan käsittelyä.
  • Fuzz-testaus: luo automaattisesti suuria määriä satunnaista tai mutatoitunutta syötettä löytääkseen käsittelemättömät kaatumiset.
  • Keskeytetyt virrat: peruuttaa, päivittää, aikakatkaista tai menettää yhteyden kesken tapahtuman.

Riippumatta siitä, millä tekniikalla tapaus syntyy, odotettu tulos on kirjattava muistiin hallittuna, luettavana virheenä – validointiviestinä, hylättynä latauksena, puhtaana palautuksena – eikä koskaan pelkästään muodossa ”järjestelmä ei kaadu”.

Negatiivisen testin hyvät ja huonot puolet

Kuten kaikilla muillakin testaustekniikoilla, negatiivisella testauksella on etuja ja haittoja, jotka riippuvat siitä, missä, milloin ja kuinka paljon sitä käytetään.

Negatiivisen testauksen edut

  • Se suojaa tuotteen laatua suoraan, koska hyvälaatuisessa tuotteessa ei ole hyödynnettävissä olevia haavoittuvuuksia.
  • Se laajentaa kattavuutta. Virheellinen syöte päätyy toimivaan järjestelmään tahallaan tai vahingossa, joten negatiivisten tapausten on oltava rinnakkain positiivisten tapausten kanssa, jotta kattavuudella olisi merkitystä.
  • Se lisää asiakkaan luottamusta ennen julkaisua.
  • Se nostaa esiin vikoja, joihin positiivinen testaus ei rakenteellisesti pysty yltämään, kuten käsittelemättömät poikkeukset ja heikko syötteen validointi.

Negatiivisen testauksen haitat

  • Joissakin tilanteissa se on ajan ja energian tuhlausta. Jos sovellus rakennetaan yhdelle käyttäjälle, 100 samanaikaisen käyttäjän tapaus ei ole testaamisen arvoinen, joten oikeiden ehtojen valinta on tärkeää, ja jotkut järjestelmät tarvitsevat hyvin vähän negatiivisia testejä ollenkaan.
  • Tapausten suunnitteluun tarvitaan osaavia ja kokeneita ihmisiä.
  • Asiakkaan näkökulmasta se lisää kustannuksia ja voi viivästyttää julkaisua.
  • Se kilpailee työpanoksesta. Joukkue, joka käyttää paljon rahaa negatiiviseen testaukseen, saattaa päätyä aliinvestoimaan positiiviseen testaukseen.

UKK

Positiivinen testaus syöttää validia dataa ja vahvistaa odotetun tuloksen. Negatiivinen testaus syöttää virheellistä dataa, vääriä formaatteja ja rikkinäisiä sekvenssejä ja vahvistaa sovelluksen hylkäävän ne hallitussa viestissä epäonnistumisen sijaan.

Tyhjät tunnistetiedot, kelvollinen käyttäjä väärällä salasanalla, SQL-fragmentit käyttäjätunnuksessa, ylipitkät merkkijonot, välilyönnit alussa tai lopussa, käytöstä poistetut tilit ja toistuvat epäonnistuneet yritykset varmistaa lukituksen toimivuus.

Eivät. Ne menevät päällekkäin virheellisen tai vihamielisen syötteen osalta, mutta tietoturvatestaus kattaa myös todennuksen, valtuutuksen, salauksen ja istunnon käsittelyn. Negatiivinen testaus on laajempi syötteiden ja ehtojen tekniikka.

Testaajat ja laadunvarmistusinsinöörit kirjoittavat ne yleensä, ja usein kehittäjä tarkistaa virhepolut ja liiketoiminta-analyytikko vahvistaa, mitkä virheelliset ehdot vaatimukset todella kieltävät.

Riittävästi kattamaan jokaisen hylätyn syöteluokan, jokaisen rajan ja jokaisen suuren vaikutuksen omaavan vikapolun. Tämän lisäksi lisätyt tapaukset tuottavat vain vähän arvoa, joten riski ja vaikutus asettavat pisteen.ping kohta.

Kyllä. Virheellisten syötteiden tapaukset toistuvat erittäin usein, joten ne sopivat automaatiotestaus ja regressiotyökalut. Fuzzing-työkalut automatisoivat satunnaisten syötteiden luomisen, kun taas väitteet tarkistavat, että validointiviestit näkyvät.

Mallit lukevat vaatimuksia tai lomakekaavaa ja ehdottavat virheellisiä arvoja, reunaehtoja ja haitallisia merkkijonoja, joita testaaja ei välttämättä listaa manuaalisesti. Tarkistaja varmistaa silti, että jokainen odotettu tulos vastaa spesifikaatiota.

Kyllä, se luonnostelee väitekoodia, virheellisten tietojen kiinnityksiä ja parametrisoituja tapauksia olemassa olevasta testitiedostosta. Luotuja odotuksia on tarkistettava, koska uskottavalta näyttävä väite voi koodata väärää toimintaa.

Tiivistä tämä viesti seuraavasti: