Mallipohjainen testaus on automatisoitua testien generointia niiden suorittamisen aikana. Perinteisten testiskriptien sijaan tuotetaan malli, joka tuottaa skriptit. Varsinaista testauksen suorittamista varten tarvitaan edelleen toteutusta toimintojen automatisointiin, mutta toimintojen yhdistely tehdään mallista lähtien koneellisesti.
Tilannekuvaus
Viimeisen vuoden ajan olen testauskonsulttina osallistunut Vaisalassa lentokenttäsääraportointisovelluksen testaamiseen. Keskeisenä osana on ollut soveltaa automatisoitua mallipohjaista testausta järjestelmähyväksymistestaukseen, ja tässä artikkelissa käydään läpi projektiesimerkin kautta mallipohjaisen testauksen ideaa ja käytäntöä.
Järjestelmän osana on havainto- ja raportointisovellus, jolla lentokentillä voidaan:
- Nähdä säähavaintoja eri sensoreilta
- Täydentää säähavaintoja ihmisen keräämillä tiedoilla
- Lähettää ja hyväksyä vakiosääraportteja
Eräs vakiosääraporteista on METAR (meteorologinen lentokenttäraportti). Tälläinen määrämuotoinen raportti tuotetaan lentokentiltä jaeltavaksi lentosäätiedon yhteistyöverkostoon ja sitä sen tietoja käytetään lentosuunnittelussa.
Testattavasta ominaisuudesta testaushaasteeseen
Esimerkkejä METAR-raporteista löytyy Wikipediasta, ja esimerkki auttaa ymmärtämään testattavan ominaisuuden luonnetta mallipohjaisen testauksen hyödyntämiseksi:
Kokeneelle lukijalle raportti kertoo tiiviissä muodossa säätiedot Burgasin lentokentältä Bulgariasta sen lähettämisen ajankohtana. Wikipedia ohjeistaa yksityiskohtaisesti miten raporttia luetaan. ICAO-standardit määrittelevät yksityiskohtaisesti miten raportin sisältö tuotetaan.
Raportteja tuotetaan säännöllisen aikataulun mukaan, tyypillisesti kerran tunnissa. Testattavan ominaisuuden osalta käyttöliittymä ohjaa luomaan raportin kerätyn säätiedon perusteella. Käyttöliittymästä otetulla kuvalla voi havainnollistaa kyseisen toiminnallisuuden sisältävän mallipohjaisen testauksen hyödyntämiseen oleellisen tilakoneen. Raportilla on erilaisia tiloja ja tilasiirtymiä, ja testiskenaarioiden määrä perinteisesti testit suunnitellen on merkittävä.
Kattavien testien suunnittelutarve on mielenkiintoinen testauksen haaste. Erilaiset polut ovat tärkeitä kattaa. Muutamia esimerkkejä:
- Raportti voi muodostua ja lähteä täysin automatisoidusti
- Raportti voi olla ihmisen kokoama ja perustua havaintoihin, jotka merkittävästi eroavat automaattisesti kerätyistä
- Raportti voi olla viivästynyt, jos ihmisen kokoamistyö viivästyy
- Raportti voi olla ajoissa rakennettu ja odottaa sovittua lähetysaikaa
- Raportti voidaan rakentaa uudelleen jos säätila on muuttunut valmistelun jälkeen
Näidenkin jälkeen jää vielä avoimia testauspohdintoja: Olemmeko käyneet läpi kaikki oleelliset polut? Jäikö meiltä huomiotta jokin listaa laatiessa? Onko sillä merkitystä mikäli raporttia on tarpeen pyörittää samoissa tiloissa useampaan kertaan?
Testien yksityiskohtainen suunnittelu ja testaaminen vie merkittävästi aikaa. Suunnittelun voi kerran tehdä tärkeälle ominaisuudelle, mutta muutostarpeet tuovat kukin mahdollisuuden ohittaa keskeistä toiminnallisuutta.
METAR keskeisenä toiminnallisuutena oli perusteltu kokeilu uudentyyppiselle automatisoidulle testaukselle projektissa.
Mallipohjainen testaaminen
Malli on formaali, yksinkertaistettu kuvaus prosessista tai järjestelmästä. Testausta tehdessä mielessä on aina malli siitä miten järjestelmää käyttää testattaessa.
Mallipohjainen testaus on testaustekniikka, joka ohjaa tuottamaan tästä testaajan mallista formaalin, määrämuotoisen version. Määrämuotoista mallia voidaan analysoida, sen voi jakaa toisten kanssa keskustelun pohjaksi ja päivittää palautteen pohjalta. Määrämuotoista mallia voidaan hyödyntää testien suunnittelussa, kattaen mallin erilaisia polkuja.
Aiemmin esitelty kuva METAR-toiminnallisuudesta on jo malli käyttöliittymäkuviin perustuen erilaisista vaiheista raportoinnissa.
Jo käyttöliittymäkuvin määrämuotoistettu malli auttaa testisuunnittelussa. Keskustelut sen ympärillä selkiyttävät ja yksinkertaistavat vaatimusten ymmärrystä, ja osoittavat piilossa olevan monimutkaisuuden pinnallisesti yksinkertaiselta vaikuttavassa toiminnallisuudessa.
Mallipohjaisessa testauksessa määrämuotoistaminen viedään askelta pidemmälle. Formaalista määrämuotoisesta mallista voidaan generoida ja automatisoida testejä mallin kattamiseksi. Sen sijaan että suuri määrä testejä laaditaan ja automatisoidaan harkiten analysoinnin pohjalta, ne luodaan koneellisesti mallista.
Generointi on erityisesti hyödyllinen muutostilanteessa. Mallia tarvitsee sopeuttaa rajallisesti, kun suuren testimassan muokkaaminen voi olla työläämpää.
Mallipohjaisen testauksen tarkoitus on:
- Testata valikoima satunnaisesti generoituja polkuja
- Perustaa päätöksiä korjauksista suureen määrään testiajoja, joiden pohjalta tunnistaa tärkeimpiä korjattavia ongelmia priorisointiin
Mallipohjaisen testauksen työkalut
Tämän tyyppisen testauksen työkaluvalikoimaan kuuluu formaalien määrämuotoisten mallien rakentamisen työkalut, malliin pohjaavan testigeneroinnin työkaluja, perinteisiä testauksen automatisoinnin työkaluja sekä tulosten visualisoinnin työkaluja. Kaupallisia ratkaisuja on olemassa, joskin tässä kokemuksessa keskitytään avoimen lähdekoodin työkaluvalikoimaan.
- GraphWalker – suosituin mallipohjaisen testauksen työkalu, joka tuottaa suunnatun graafin pohjalta satunnaisia polkuja mallin kattamiseksi erilaisin läpikäyntisäännöin ja lopetusehdoin, Se on erityisesti Java-käyttäjille suunnattu.
- AltWalker – avoimen lähdekoodin työkalu, tuottajana oma yritykseni Altom, joka tuo Graphwalkerin toiminnallisuuden Python ja C# -toteutuksiin.
Mallipohjainen testaus METARin testauksessa
Käytimme toteutuksessa AltWalker:n JSON formaattia METARin mallintamiseen. Aiemmasta käyttöliittymiin perustuvasta mallista muodostui hieman monimutkaisempi koneluettava malli.
Tämä on visuaalinen esitysmuoto json-tiedostosta, joka on luotu käyttäen AltWalker Visual Editor:ia:
Kukin suorakulmio mallissa on METARin tila ja kukin nuoli vastaa toimintoa joka aiheuttaa METARin tilasiirtymän. Kullekin näitä on JSON-tiedoissa nimi, josta muodostuu viittaus Python-funktioon.
AltWalker tarkistaa mallin eheyden ja luo perusrakenteet tarvittaville funktioille. Funktiot vaativat perusrakenteen päälle toteutuksen sovelluksen toimintojen automatisoinnille.
Esimerkkitapauksessa METAR-raportin tiloja ohjataan, tarkastellaan ja muokataan websovelluksella, joten käytimme Selenium-kirjastoa selaimen ohjauksessa METARin toimintojen käyttämisessä. Lisäksi käytössä on muita järjestelmän toimintoja automatisoivia Python-toteutuksia.
Oheisissa kuvissa on esimerkkejä tilojen ja toimintojen toteutuksesta:
Kun tilat ja toiminnot ovat toteutettuna, AltWalker kulkee mallia Graphwalkerin toimintoja hyödyntäen ja tekee tarkastuksia kunkin tilan kattamisesta.
Tilan kattamiseen on vaihtoehtoisia valintoja. Esimerkkitapauksessamme olemme käyttäneet pääasiassa nopeaa satunnaista valintaa polkujen generoinnissa. Tämä tarkoittaa että tilassa valitaan satunnaisesti toiminto jota ei ole vielä tehty testien edistämiseksi. Testaus lopetetaan kun kaikki tilat ja toiminnot on käyty läpi.
Oheisessa kuvaruutukaappauksessa on rinnan malli ja sovellus testiajon aikana:
Mallin suorituksenaikainen visualisointi vasemmalla näyttää yhden tilan olevan kattamatta (harmaalla) kun taas muissa tiloissa on käyty kerran (vaaleanvihreä) tai eniten (tummanvihreä). Eri suorituskerrat tuottavat eri testit, kuitenkin kattaen mallin.
Hyödyt
Ajamme METARin mallipohjaisia testejä päiväsyklillä yöaikaan yhdessä järjestelmäkokonaisuuden sisältävistä ympäristöistämme. Testiajoon kuuluu noin 20 minuuttia, sillä kokonaisjärjestelmässä METAR-raportointiprosessin voi lyhimmillään lyhentää kolmeen minuuttiin tuotannon kaltaisen tunnin sijasta.
Merkittävin hyöty on ollut tärkeiden METAR-tilasiirtymien jatkuva testaus, kattavasti. Lisäksi testeillä on löydetty toiminnallisuuteen liittyvä ongelma raportin tilan katoamisesta tietyllä polulla sovelluslogiikan muutoksen seurauksena.
Hyötyä on myös ollut kokonaisjärjestelmän monitoinnista luottavuusmielessä, sekä pitkäkestoisessa käytössä ilmenevän suorituskykyongelman toteamisessa ja korjauksen varmentamisessa.
Pidemmän aikavälin hyötynä tavoittelemme luotettavuustestausta vielä aiempaa pidempikestoisillä testiajoilla. Mallia voidaan käyttää kulkemaan ilman lopetusehtoa, ja ja testaamaan monitoroiden kunnes jokin testi osoittaa ongelman. .
Yhteenvetona
Mallipohjainen testaus on hyvä testaustekniikka piilomallien jakamiseen, ominaisuuksien monimutkaisuuden visualisointiin ja sitä kautta esille tuomiseen, sekä vaatimusten selkiyttämiseen. Kun malliin yhdistää GraphWalkerin ja AltWalkerin kaltaisten työkalujen testien generoinnin, voimme luoda realistisia monimutkaisua testiskenaarioita, visualisoida kattavuutta, löytää polkuja jotka analysoiden olisimme jättäneet huomiotta sekä löytää muutoksiin liittyviä toiminnallisuusvirheitä, ja järjestelmän luotettavuus- ja suorituskykyongelmia.
Ru Cindrea on johtava testauskonsultti ja Altomin perustaja. Yli 20 vuoden kokemukseen perustuen hänestä kaikki testaus on tutkivaa testausta ja soveltaa tätä ajatusmallia monimutkaisiin testauksen haasteisiin ja testiautomaation rakentamiseen. Hän on AltTester-pelitestausautomaatiotyökalun pääkehittäjä sekä opettaa BBST koulutussarjaa.