Suorituskykytestauksen automatisointi

Ajankohtaista Kirjoittanut:
Perinteisesti testausautomaatiota on käytetty digitaalisten palveluiden toiminnallisen UI-testauksen apuna kuten kollega blogissaankin aihetta sivusi, mutta sen lisäksi testausautomaatiota voi hyödyntää myös palveluiden suorituskykytestauksessa.

Miksi testata palvelun suorituskykyä?

Digitaalisten palveluiden toiminnallisuuksiin tai palveluiden välisiin integraatioihin tehdyt mukautukset sekä muut sovelluspäivitykset voivat ajan myötä aiheuttaa palvelujen toiminnan hidastumista, joka voi ilmetä esimerkiksi kasvaneina sivulatausaikoina tai end-to-end integraationputken läpimenoajan hidastumisena. Näin ollen palvelujen suorituskykyä olisi hyvä seurata säännöllisesti, jotta mahdollisiin suorituskykyongelmiin voidaan proaktiivisesti puuttua ennen kuin nopeasti toimiviin digipalveluihin tottuneet loppukäyttäjät ehtivät tuskastua hidastuvaan palveluun. Olen viime vuosien aikana toiminut Digital Illustratedilla testauskonsulttina Microsoft Dynamics 365 -projekteissa, joissa Dynamicsin suorituskykyä on seurattu lomakkeiden (sivujen) latautumisaikojen osalta testausautomaation avulla.

 

Miten nettisivun latautumisajan saa selville?

Nettisivujen latautumisajan saa selville esimerkiksi selainten Developer toolsien avulla, tai ihan mittaamalla sekuntikellolla kuinka nopeasti jokin tietty elementti tulee lomakkeelle näkyviin. Dynamicsissa lomakkeiden latautumisajan saa myös näppärästi selville sisäänrakennetulla (&perf=true) performance widgetillä:

Yksittäisen sivulatauksen mittaustulos ei vielä kerro mitään suorituskyvystä, vaan mittauksia pitää tehdä useampi, jotta yksittäisten mittausten välinen hajonta tasoittuu. Muutamana päivänäkään tehdyt mittaukset eivät vielä kerro mitään, joten mittauksia pitää tehdä pitemmällä aikavälillä, jotta mittaustulosten mahdollisen muutoksen suunta selviää. Jotta trendejä suorituskyvyssä voidaan seurata ajan yli, on hyödyllistä heti projektin alussa mitata ”baseline” tuotepohjaisen ratkaisun vasteajoista vertailukohdaksi. Baselinea voidaan hyödyntää myös käyttäjäodotusten hallinnassa.

 

Selainikkunassa näytetään Dynamicsin suorituskykytyökalun mittaama tulos lomakkeen latautumisajasta

 

Miten Dynamics 365:n lomakkeiden latautumisaikojen mittaamisen sitten saa automatisoitua?

Simppeliä, ajetaan CI/CD työkalun avulla testiautomaatioframeworkilla luotu UI-testi, joka hoitaa homman. Työkaluina voi käyttää esimerkiksi Azure DevOps + Robot Framework yhdistelmää.Kirjoitetaan aluksi Robot Frameworkilla testiskripti, jossa:

  1. Kirjaudutaan Dynamicsiin
  2. Avataan määritetty lomake kertaalleen, jotta selaimen välimuisti täyttyy (cold cache -> warm cache)
  3. Avataan lomake uudestaan ja luetaan performance widgetin näyttämä mittaustulos
  4. Suoritetaan kohta 3) vielä X kertaa, jonka jälkeen lasketaan eri mittaustulosten keskiarvo
  5. Tallennetaan keskiarvo ja timestamp rivitietona tiedostoon

Tämän jälkeen luodaan Azure DevOpsiin pipeline, joka käynnistää testiskriptin haluttuina ajankohtina ja tallentaa testiajon lopuksi tulostiedoston pipelinen Build artifacteihin, josta mittaustulosten historian saa näkyville:

Automaattisen suorituskykytestiajon mittaamat tulokset ovat näkyvissä tekstitiedostossa, joka on avattu Azure Devopsissa testiajon build artifakteista

Nyt minulla on dataa, entä sitten?

Numeerisesta datasta ei tietenkään helposti näe miten mitattavan sovelluksen suorituskyky on ajan myötä muuttunut, joten testituloksista pitäisi saada luotua visualisointi analysoinnin helpottamiseksi. Tuloksista voisi muodostaa vaikkapa PowerBI-raportin, mutta simppelin kuvaajan saa myös luotua automaattisesti Robot Framework -testin ajon aikana Python-skriptillä. Myös kuvaajan saa talteen build artifacteihin, ja kuvaajasta ja trendiviivasta näkee helposti jos suorituskyvyssä on tapahtunut viime aikoina muutoksia, joihin voidaan tarvittaessa reagoida:

Kuvatiedostossa on näkyvissä automaattisesti generoitu kuvaaja ja trendiviiva viimeisimmistä automaattisen suorituskykytestiajon mittaamista testituloksista

Mitä seuraavaksi?

Ellei aika riitä testitulosten manuaaliseen analysointiin, niin mikäpä estäisi luomasta testiskriptin yhteyteen toiminnallisuutta, joka triggeröi Power Automate Cloud Flown, joka lähettää hälytyksen Teamsiin jos mittaustulos on vaikka viitenä peräkkäisenä päivänä suurempi kuin pitkän ajan keskiarvo. Tai jos kehitettävänä on globaali palvelu, voisi olla hyödyllistä verrata saman suorituskykytestin tuloksia ajettuna eri geolokaatioista, koska verkon latenssi ja laatu vaikuttavat esimerkiksi Dynamicsin vasteaikohin. Mittaamalla vasteaikoja eri maantieteellisistä sijainneista saa parempaa ymmärrystä käyttökokemukseta, silloin kun käyttäjä onkin eri puolella maapalloa kuin Microsoftin konesali.