Ohjelmistotestaajina ja automaatioinsinööreinä ajattelemme usein onnistunutta polkua: polkua, jonka käyttäjä todennäköisimmin valitsee käyttäessään sovellustamme. Kun kirjoitamme automatisoituja käyttöliittymätestejämme, haluamme varmistaa, että automatisoimme nämä onnistuneet polut, ja kun kirjoitamme API-automaatiota, haluamme varmistaa, että jokainen päätepiste palauttaa “200 OK”-vastauksen tai vastaavan onnistuneen vastauksen.
On kuitenkin tärkeää ajatella negatiivista testausta sekä manuaalisissa että automatisoiduissa testeissämme. Tässä muutama syy siihen.
Automatisoidut testimme saattavat läpäistä testin vääristä syistä
Kun aloitin automatisoitujen käyttöliittymätestien kirjoittamisen JavaScriptillä, en ymmärtänyt lupauksen käsitettä. Oletin vain, että kun tein pyynnön elementin paikantamiseksi, se ei palauttaisi kyseistä elementtiä ennen kuin se olisi todella löytynyt. Olin niin innoissani, kun testieni tulokset alkoivat näkyä vihreänä “Hyväksytty”-tuloksena, kunnes työtoveri ehdotti, että yrittäisin saada testin epäonnistumaan tarkistamalla jonkin muun arvon. Testi läpäistiin jälleen, koska se itse asiassa validoi olemassa olevaa lupausta, joka palautti aina arvon “Tosi”. Opin siitä arvokkaan läksyn: älä koskaan oleta, että automatisoidut testisi toimivat oikein vain siksi, että ne läpäisevät testin. Muista suorittaa joitakin skenaarioita, joissa testiesi pitäisi epäonnistua, ja varmista, että ne todella epäonnistuvat. Näin voit olla varma, että testaat todella sitä, mitä luulet testaavasi.
Have an account? Log In
Negatiivinen testaus voi paljastaa virheellisen virheenkäsittelyn, joka voi vaikuttaa käyttäjään
API-testauksessa kaikkien asiakkaaseen liittyvien virheiden pitäisi johtaa 400-tason vastaukseen 500-tason palvelinvirheen sijaan. Jos suoritat negatiivista testausta ja huomaat, että 403-vastaus palautuu nyt 500-vastauksena, tämä voi tarkoittaa, ettei koodi enää käsittele kyseistä käyttötapausta asianmukaisesti. Palvelimen 500-vastaus voi estää käyttäjää saamasta asianmukaisia tietoja, joita hän tarvitsee virheensä korjaamiseen, tai mikä pahempaa, se voi kaataa sovelluksen.
Negatiivinen testaus voi löytää tietoturva-aukkoja
Yhtä tärkeää kuin varmistaa, että käyttäjä voi kirjautua sovellukseen, on varmistaa, ettei käyttäjä voi kirjautua sovellukseen silloin, kun hänellä ei pitäisi olla siihen oikeutta. Jos suoritat kirjautumistestin vain kelvollisella käyttäjänimellä ja salasanalla, ohitat tämän ratkaisevan osa-alueen! Olen nähnyt tilanteen, jossa käyttäjä pystyi kirjautumaan millä tahansa salasanalla, tilanteen, jossa käyttäjä pystyi kirjautumaan tyhjällä salasanalla, sekä tilanteen, jossa käyttäjä pystyi kirjautumaan väärällä käyttäjänimellä ja salasanalla.
On myös ratkaisevan tärkeää varmistaa, ettei tietyillä käyttäjillä ole pääsyä sovelluksen tiettyihin osiin. Huolellisesti testatusta ja toimivasta ylläpitäjän sivusta ei ole paljon hyötyä, jos kuka tahansa satunnainen käyttäjä pääsee siihen käsiksi.
Negatiivinen testaus pitää tietokantasi puhtaana
Kuten mainitsin luvussa 12, hyvien ja kelvollisten tietojen säilyttäminen tietokannassa auttaa pitämään sovelluksesi terveenä. Odotusten vastaiset tiedot voivat aiheuttaa verkkosivujen kaatumisen tai latautumisen epäonnistumisen tai saada tiedot näkymään virheellisesti. Mitä enemmän negatiivista testausta voit tehdä syötteillesi, sitä paremmin voit varmistaa, että sinulla on vain hyviä tietoja.
Jokaisen testaamani syöttökentän kohdalla haluan tietää tarkalleen, mitkä merkit ovat sallittuja. Sen jälkeen voin suorittaa suuren määrän negatiivisia testejä varmistaakseni, että kiellettyjä merkkejä sisältävät syötteet hylätään.
More Articles
Joskus käyttäjät valitsevat kielteisen polun
Erityisesti uuden, määräajan saavuttamiseksi kiireellä toteutettavan ominaisuuden yhteydessä on helppo unohtaa testata käyttäjäpolut, joissa käyttäjä napsauttaa Peruuta- tai Poista-painiketta. Käyttäjät kuitenkin tekevät näin jatkuvasti; ajattele vaikka tilanteita, joissa olet harkinnut verkko-ostoksen tekemistä, mutta muuttanut sitten mielesi ja poistanut tuotteen ostoskoristasi. Kuvittele turhautumistasi, jos et pystyisi poistamaan jotain ostoskoristasi tai jos Peruuta-painike ei tyhjentäisi lomaketta ja antaisi sinun aloittaa alusta. Käyttäjäkokemus on tällä osa-alueella aivan yhtä ratkaiseva kuin onnistunut polku.
Ohjelmistotestauksessa etsitään odottamatonta toimintaa, jotta löydämme sen ennen käyttäjää. Kun negatiivinen testaus yhdistetään onnistuneen polun testaukseen, voimme varmistaa, ettei käyttäjillemme tule epämiellyttäviä yllätyksiä.
Jos haluat tehostaa testausprosessejasi entisestään, harkitse huippuluokan tietokannan hallintatyökalun integroimista monimutkaisten tietotarpeidesi käsittelyyn.
Täydellinen ohjelmistotestaajan kirja
Kun vuonna 2009 löysin rakkauteni ohjelmistotestaukseen, halusin oppia kaiken mahdollisen ohjelmistotestauksesta, mutta löysin hyvin vähän kirjoja, jotka olisivat voineet opettaa minua. Lopulta opin yrityksen ja erehdyksen kautta, lukemalla blogikirjoituksia ja keskustelemalla työtovereideni kanssa. Nykyään on olemassa erinomaisia kirjoja ohjelmistotestauksen erityisalueista, kuten tutkivasta testauksesta, ketterästä testauksesta ja testiautomaatiosta, mutta tietääkseni ei ole olemassa kirjaa, joka pyrkisi toimimaan kattavana testauksen perusteoksena.
Kirjoitin teoksen Täydellinen ohjelmistotestaaja, koska halusin tarjota sekä uusille että kokeneille testaajille ajatukset ja työkalut, joita he tarvitsevat ollakseen mahdollisimman tehokkaita. Jos haluat nopeita laadunvarmistusvinkkejä ja lisää kirjavinkkejä, tilaa QA-johtajan uutiskirje.
Aiheeseen liittyvä lukeminen: MIKÄ ZEPHYR SCALE ON?
Aiheeseen liittyvä työkaluluettelo:
Tutustumisen arvoista:
