Miten voit varmistaa, että uusi koodi ei riko aiemmin rakennettuja toiminnallisuuksia? Ohjelmistojen jatkuvaan automaatiotestaukseen on monia keinoja. Eri työkalujen joukosta Robot Framework kuuluu omiin suosikkeihini.
En ole yksin. Robot Frameworkia hyödynnetään Cinialla laajasti eri projekteissa, ja avoimeen lähdekoodiin perustuvan sovelluskehyksen ympärillä on aktiivinen yhteisö. Mikä tekee siitä niin suositun valinnan toiminnalliseen testaukseen? Entä mihin se ei aivan taivu?
Mikä Robot Framework?
Robot Framework on testausautomaatioon tarkoitettu, Python-pohjainen sovelluskehys. Se palvelee varsinkin regressio- ja hyväksyntätestausta, mutta tarjoaa joitain mahdollisuuksia myös suorituskyvyn, kuten vasteaikojen, analyysiin. Viime vuosina Robot Frameworkin käyttökohteet ovat laajentuneet testausautomaatiosta myös ohjelmistorobotiikkaan (RPA).
Komentorivipohjaisuus tuo vapauden laajentaa
Valmiit kirjastot, kuten SeleniumLibrary, tekevät testitapausten rakentamisesta suoraviivaista. Avainsanapohjainen test data -syntaksi on tehty yksinkertaiseksi lukea ja kirjoittaa, mutta pohjimmiltaan Robot Frameworkin komentorivipohjainen käyttö on silti ohjelmointia.
Olen kokeillut testausautomaatioiden tekemistä myös graafisilla työkaluilla. Niissä skripti tehdään tyypillisesti erilaisia toimintoja nauhoittamalla, laatikoita raahaamalla ja tekstikenttiä täyttämällä. Ne voivat olla käteviä testaajille, joille ohjelmointi on vieraampaa, mutta omalla kohdallani graafisen käyttöliittymän kanssa säätäminen on tuntunut hiukan kömpelöltä.
Graafiseen käyttöliittymään liittyy aina myös rajoituksia: voit tehdä vain sitä, mitä käyttöliittymään on määritelty. Robot Frameworkia puolestaan voit laajentaa ja räätälöidä Python-koodilla loputtomiin. Teknologia toki kehittyy myös valmisratkaisujen puolella.
Cinian projekteille tyypillisiä, selaimen kautta käytettäviä sovelluksia voi periaatteessa testata lähes kaikenlaisilla automaatiotestauksen työkaluilla. Milloin sitten on räätälöinnin paikka?
Kustomoidumpaa testikoodia tarvitaan heti, kun sovellus alkaa käyttää kolmannen tahon rajapintoja, ja pitää varmistaa, että lähtevät kutsut näyttävät oikeanlaisilta. Samoin silloin, kun testattavalla sovelluksella itsellään on epästandardeja rajapintoja, joita vasten testejä halutaan ajaa. Sovelluksen lähettämien sähköpostien muodon testaaminen tulee myös mieleen eräänä esimerkkinä.
Ohjelmointikielten omat yksikkötestauskehykset vai Robot Framework?
Vuosien varrella olen käyttänyt testaamiseen myös eri ohjelmointikielten omia yksikkötestausframeworkeja. Niitä on pystynyt adaptoimaan myös järjestelmätason testaamiseen. Esimerkiksi C#:n oma kehys NUnit sinänsä toimii yksittäisten testien kirjoittamiseen ja testien ajamiseen.
Robot Frameworkin tyyppinen, alusta asti testaajille kehitetty työkalu tekee kuitenkin työpäivistä helpompia. Robot Framework on tehty Pythonin päälle, ja Python on testaajalle mukavampi käyttää kuin C#:n tai Javan tyyppiset backend-kielet. Samalla Robot Framework on agnostinen sen suhteen, mitä teknologioita testien kohteena oleva ohjelmistoratkaisu hyödyntää.
Juuri julkaistu uusin versio (Robot Framework 5.0) lisää test data -syntaksiin entistä enemmän ohjelmointikielten rakenteita. Tämä vastaa varmasti monien käyttäjien tarpeisiin, mikä kertoo siitä että testaaminen ja testien määrittely on siirtynyt yhä lähemmäksi ohjelmointia.Samalla kun automaatiotestauksen rooli ylipäänsä jatkaa vahvistumistaan, Robot Framework saa kiinnostavia haastajia. Ainakin JavaScriptiin perustuvaa avoimen lähdekoodin Cypressiä seuraan mielenkiinnolla.
Helppokäyttöiset lokit ja raportit ovat Robot Frameworkin etu
Yhden asian Robot Framework tekee selkeästi paremmin kuin vastaavat sovelluskehykset: sen lokit ja raportit ovat hyvin selkeitä ja näppäriä käyttää. Jokaisen testin suorittamisen jälkeen komentoriville ilmestyy lyhyt raportti suorituksesta. Sen lisäksi testiajosta generoituu HTML-muotoinen, yksityiskohtainen raportti siitä, miten testit ovat onnistuneet ja millaisia virheitä nousi esiin. Helposti luettava muoto nopeuttaa bugien paikantamista.
Kuvassa on testi, jossa ilmeni ongelmia. Lokissa näkyy, missä avainsanassa virhe tapahtui, sekä kuvakaappaus käyttöliittymästä kyseisellä hetkellä.
Ei paras vaihtoehto suorituskykytestaukseen
Robot Framework soveltuu parhaiten regressiotestauksen automatisointiin. Suorituskyky- ja kuormitustestaukseen on tehokkaampaa valita jokin toinen, juuri siihen tarkoitukseen suunniteltu framework. Cinialla kuormitustestaukseen käytetään paljon Apache JMeteriä.
Robot Frameworkin raportit, joita äsken kehuin, ovat käteviä juuri toiminnallisuuksien testaamisessa. Suorituskykyyn liittyville muuttujille, kuten vasteajoille, on erilaiset raportointitarpeet, joskin Robotin testilokista olisi tapauskohtaisesti mahdollista kaivaa myös suorituskykyyn liittyvää dataa.
Tietoturvatestaamisen automatisointiin on samoin kehitetty omia työkalujaan, vaikka Robot Frameworkiakin voi tarkoitukseen jossain määrin valjastaa. Suosittelen joka tapauksessa skannaamaan tunnettuja tietoturvahaavoittuvuuksia erillisillä ratkaisuilla.
Lue myös: Tietoturva ohjelmistoprojekteissa – OWASP Top 10 web-kehittäjän tukena
Kuvantunnistus vielä kehittymässä
Me Cinialla kehitämme softia eri toimialoille, mutta useimpia projekteja yhdistää se, että ohjelmisto on tarkoitettu ammattikäyttöön. Käyttäjä seuraa dashboardistaan esimerkiksi karttanäkymiä tai tulkitsee dataa kuvaajien avulla. Tällaisten graafisten käyttöliittymäelementtien automaattinen testaaminen on vielä haastavaa.
Erinäisiä liitännäisiä ja palikoita automatisoinnin tarpeisiin jo löytyy, ja Robot Frameworkinkin puitteissa kehitetään kuvantunnistusmahdollisuuksia juuri tähän tarkoitukseen. Teknologian kehittyminen on kuitenkin vielä melko varhaisessa vaiheessa.
Tässä ja muissa haastavissa tilanteissa sparrausapua on onneksi tarjolla – joko testaajakollegalta omasta projektitiimistä tai viimeistään muiden cinialaisten testaajien yhteisöltä.
