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.
Palvelujen suorituskykyä olisikin 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 twodaylla 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.
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:
- Kirjaudutaan Dynamicsiin
- Avataan määritetty lomake kertaalleen, jotta selaimen välimuisti täyttyy (cold cache -> warm cache)
- Avataan lomake uudestaan ja luetaan performance widgetin näyttämä mittaustulos
- Suoritetaan kohta 3) vielä X kertaa, jonka jälkeen lasketaan eri mittaustulosten keskiarvo
- 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:
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:
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.