Mitä on testausautomaatio? Yksinkertainen ja selkeä johdanto
Ohjelmistomaailmassa on kahdenlaista testausta – manuaalista ja automatisoitua. Jotkin manuaalisen testauksen lajit, kuten löytötestaus ja käytettävyystestaus, ovat korvaamattomia. Muunkinlaista testausta – kuten regressiotestausta ja toiminnallista testausta – voi tehdä manuaalisesti, mutta on melko turhaa, että ihmiset tekevät samaa asiaa yhä uudelleen ja uudelleen. Juuri tällaiset toistuvat testit sopivat hyvin testiautomaatiolle.
Testiautomaatio on käytäntö, jossa testit suoritetaan automaattisesti, testidataa hallitaan ja tuloksia hyödynnetään ohjelmiston laadun parantamiseksi. Se on ensisijaisesti laadunvarmistustoimenpide, mutta sen toimintaan sitoutuu koko ohjelmistotuotantotiimi. Liiketoiminta-analyytikoista kehittäjiin ja DevOps-insinööreihin, testiautomaatiosta parhaan mahdollisen hyödyn saaminen edellyttää kaikkien osallistumista.
Tässä kirjoituksessa saat korkean tason käsityksen siitä, mistä testiautomaatiossa on kyse. Testejä on kaikenlaisia, mutta kaikkia ei kannata automatisoida, joten aloitetaan testien automatisoinnin yleisistä kriteereistä.
Automaation kriteerit
Testin on täytettävä tietyt kriteerit, jotta se voidaan automatisoida – muutoin se saattaa lopulta maksaa enemmän kuin säästää. Loppujen lopuksi yksi automatisoinnin päätavoitteista on säästää aikaa, vaivaa ja rahaa. Seuraavassa on joitakin yleisiä kriteerejä testien automatisoinnille. Nämä ovat kuitenkin lähtökohtia. Kriteerisi voivat vaihdella olosuhteistasi riippuen.
toistettavissa
Testin on oltava toistettavissa. Ei ole mitään järkeä automatisoida testiä, joka voidaan suorittaa vain kerran. Toistettavassa testissä on seuraavat kolme vaihetta:
- Testin asettaminen, mukaan lukien data ja ympäristö.
- Funktion suorittaminen ja tuloksen mittaaminen.
- Datan ja ympäristön siivoaminen.
Ensimmäisen vaiheen aikana ympäristö halutaan saattaa yhdenmukaiseen tilaan. Toisin sanoen, jos meillä on testi, jossa yritetään lisätä olemassa oleva käyttäjä, meidän on varmistettava, että käyttäjä on olemassa ennen testin suorittamista. Kun testi on suoritettu, ympäristö on palautettava perustilaan.
Determinantti
Kun funktio on determinantti, se tarkoittaa, että lopputulos on sama joka kerta, kun se suoritetaan samalla syötteellä. Sama pätee myös testeihin, jotka voidaan automatisoida. Sanotaan esimerkiksi, että haluamme testata yhteenlaskutoiminnon. Tiedämme, että 1 + 1 = 2 ja että 394,19 + 5,81 = 400,00. Yhteenlasku on determinanttifunktio.
Ohjelmistot taas saattavat käyttää niin suurta määrää muuttuvia syötteitä, että on vaikea saada samaa tulosta koko ajan. Jotkin muuttujat voivat olla jopa satunnaisia, jolloin tietyn lopputuloksen määrittäminen voi olla vaikeaa. Ohjelmistosuunnittelussa tätä voidaan kompensoida sallimalla testisyötteet testivalikoiman avulla.
Sovelluksen muut ominaisuudet voivat olla additiivisia; esimerkiksi uuden käyttäjän luominen lisäisi käyttäjien määrää. Ainakin kun lisäämme käyttäjän, tiedämme, että käyttäjien määrän pitäisi kasvaa vain yhdellä. Testien suorittaminen rinnakkain voi kuitenkin aiheuttaa odottamattomia tuloksia. Eristämisellä voidaan estää tällaiset väärät positiiviset tulokset.
Mielipidettömät
Mielipideasioita ei voi automatisoida. Tässä kohtaa käytettävyystestaus, beta-testaus ja niin edelleen todella loistavat. Käyttäjäpalaute on tärkeää, mutta sitä ei vain voi automatisoida … anteeksi!
Automatisoitujen testien tyypit
Testejä on niin monenlaisia, ja monet niistä voidaan automatisoida, ettemme voi sisällyttää niitä kaikkia yhteen viestiin. Mutta tässä on tarpeeksi, jotta saat hyvän lähtökohdan.
Koodianalyysi
Koodianalyysityökaluja on itse asiassa monenlaisia, mukaan lukien staattinen analyysi ja dynaaminen analyysi. Jotkut näistä testeistä etsivät tietoturva-aukkoja, toiset tarkistavat tyyliä ja muotoa. Nämä testit suoritetaan, kun kehittäjä tarkistaa koodia. Sääntöjen määrittämistä ja työkalujen pitämistä ajan tasalla lukuun ottamatta näiden automatisoitujen testien kanssa ei tarvitse juurikaan kirjoittaa testejä.
Yksikkötestit
Voit myös automatisoida yksikkötestisarjan. Yksikkötestit on suunniteltu testaamaan yksittäistä toimintoa tai toimintayksikköä eristyksissä. Ne suoritetaan tyypillisesti rakennuspalvelimella. Nämä testit eivät ole riippuvaisia tietokannoista, ulkoisista API:ista tai tiedostovarastoista. Niiden on oltava nopeita, ja ne on suunniteltu testaamaan vain koodia, ei ulkoisia riippuvuuksia.
Integrointitestit
Integrointitestit ovat automatisoinnissa toisenlainen eläin. Koska integraatiotestien – joita joskus kutsutaan end-to-end-testeiksi – on oltava vuorovaikutuksessa ulkoisten riippuvuuksien kanssa, ne ovat monimutkaisempia asettaa. Usein on parasta luoda tekaistuja ulkoisia resursseja, varsinkin kun on kyse resursseista, joihin et voi vaikuttaa.
Jos sinulla on esimerkiksi logistiikkasovellus, joka on riippuvainen toimittajan verkkopalvelusta, testisi saattaa epäonnistua yllättäen, jos toimittajan palvelu ei toimi. Tarkoittaako tämä, että sovelluksesi on rikki? Voi olla, mutta sinun pitäisi hallita koko testiympäristöä riittävästi, jotta voit luoda jokaisen skenaarion eksplisiittisesti. Älä koskaan ole riippuvainen ulkoisesta tekijästä testiskenaariosi lopputuloksen määrittämisessä.
Automatisoidut hyväksymistestit
Tänä päivänä on olemassa useita käytäntöjä, joissa käytetään automatisoituja hyväksymistestejä (automated acceptance tests, AAT), mutta periaatteessa ne tekevät samaa asiaa. Käyttäytymislähtöinen kehitys (Behavior-driven development, BDD) ja automatisoitu hyväksymistestauslähtöinen kehitys (automated acceptance test-driven development, AATDD) ovat samankaltaisia. Molemmissa noudatetaan samaa käytäntöä, jossa hyväksymistesti luodaan ennen ominaisuuden kehittämistä.
Automaattinen hyväksymistesti ajetaan lopuksi sen määrittämiseksi, tuottaako ominaisuus sen, mitä on sovittu. Siksi on ratkaisevan tärkeää, että kehittäjät, liiketoiminta ja QA kirjoittavat nämä testit yhdessä. Ne toimivat jatkossa regressiotesteinä ja varmistavat, että ominaisuus kestää sen, mitä odotetaan.
Regressiotestit
Jollei hyväksymistestejä ole käytössä, joudut kirjoittamaan regressiotestejä jälkikäteen. Vaikka molemmat ovat toiminnallisten testien muotoja, niiden kirjoittamistapa, -ajankohta ja -tapa ovat hyvin erilaisia. AAT:ien tavoin niitä voidaan ohjata API:n kautta koodilla tai käyttöliittymällä. Näiden testien kirjoittamiseen graafisen käyttöliittymän avulla on olemassa työkaluja.
suorituskykytestit
Suorituskykytestejä on monenlaisia, mutta ne kaikki testaavat jotakin sovelluksen suorituskyvyn osa-aluetta. Kestääkö se äärimmäistä painetta? Testataanko järjestelmää suurelle kuumuudelle? Tavoittelemmeko pelkkää vasteaikaa kuormituksessa? Entä skaalautuvuus?
Joskus nämä testit edellyttävät massiivisen käyttäjämäärän emulointia. Tällöin on tärkeää, että käytössä on ympäristö, joka pystyy suorittamaan tällaisen suorituksen. Tällaiseen testaukseen on saatavilla pilviresursseja, mutta on mahdollista käyttää myös tiloissa olevia resursseja.
Savutestit
Mikä on savutesti? Se on perustesti, joka suoritetaan yleensä käyttöönoton tai ylläpitoikkunan jälkeen. Savutestin tarkoituksena on varmistaa, että kaikki palvelut ja riippuvuudet ovat toiminnassa. Savutestin ei ole tarkoitus olla kattava toiminnallinen testi. Se voidaan suorittaa osana automatisoitua käyttöönottoa tai käynnistää manuaalisen vaiheen kautta.
Yleinen testiautomaatioprosessi
Nyt kun olemme nähneet automatisoinnin kriteerit ja nähneet tarpeeksi automatisoitujen testien tyyppejä, jotta saamme tuntumaa asioihin, tässä on testiautomaation yleinen prosessi. Testauksen automatisoinnissa on kolme päävaihetta: valmistaudu, ryhdy toimenpiteisiin, raportoi tulokset.
Valmistaudu
Ensin meidän on valmisteltava tila, testidata ja ympäristö, jossa testit suoritetaan. Kuten olemme nähneet, useimmat testit vaativat, että ympäristön on oltava tietyssä tilassa ennen kuin toiminto tapahtuu. Tyypillisessä skenaariossa tämä vaatii jonkin verran asetuksia. Joko dataa on käsiteltävä tai sovellus on saatettava tiettyyn tilaan tai molempiin!
Take Action
Kun tila ja/tai ympäristö on ennalta määritetyssä tilassa, on aika ryhtyä toimeen! Testiajuri suorittaa testin joko kutsumalla sovelluksen API:ta tai käyttöliittymää tai suorittamalla koodia suoraan. Testiajuri vastaa testien ”ajamisesta”, mutta testienhallintajärjestelmä ottaa vastuulleen kaiken koordinoinnin, myös tulosten raportoinnin.
Tulosten raportointi
Testien automatisointijärjestelmä tallentaa ja raportoi tulokset. Nämä tulokset voivat olla monessa eri muodossa, ja ne voivat jopa luoda ongelmalippuja tai vikoja työnseurantajärjestelmään. Perustulos on kuitenkin hyväksytty tai hylätty. Yleensä jokaisessa testiskenaariossa on vihreä tai punainen merkkivalo, joka ilmaisee läpäisyn tai epäonnistumisen.
Joskus testit ovat tuloksettomia tai niitä ei jostain syystä suoriteta. Kun näin tapahtuu, automaatiojärjestelmässä on täydellinen loki tuloksista kehittäjien tarkasteltavaksi. Tämä loki auttaa heitä jäljittämään ongelman. Ihannetapauksessa he voivat toistaa skenaarion uudelleen, kun he ovat ottaneet korjauksen käyttöön.
Lopputulos
Lopputulos on tämä: testiautomaatio auttaa parantamaan laatua nopeudella. Mutta kaikkea testausta ei voi automatisoida. Siihen liittyy ehdottomasti investointi. Kun testityyppejä on niin paljon, on tärkeää, että saat oikean yhdistelmän. Testipyramidi on yksinkertainen nyrkkisääntö, jonka avulla tämä onnistuu. Sen mukaan useimpien testien pitäisi olla yksikkötestejä, sitten palvelutestejä ja sitten käyttöliittymätestejä.
Testauksen automatisointijärjestelmä koordinoi testaukseen liittyviä huolenaiheita, kuten testidatan hallintaa, testien suorittamista ja tulosten seurantaa. Testauksen automatisointi on seuraava askel tiimeille, jotka ovat hukkumassa taakkaan, joka aiheutuu samojen manuaalisten testien toistamisesta, jotka pitäisi automatisoida.
Autorin bio: Tämän viestin on kirjoittanut Phil Vuollet. Phil käyttää ohjelmistoja prosessien automatisointiin tehokkuuden ja toistettavuuden parantamiseksi. Hän kirjoittaa teknologiaan ja liiketoimintaan liittyvistä aiheista, pitää toisinaan esitelmiä samoista aiheista ja on perheellinen mies, joka pelaa mielellään jalkapalloa ja lautapelejä lastensa kanssa.