Vanhaan aikaan, eli vesiputouksen aikakaudella, suorituskykytestaus tehtiin vasta projektin loppuvaiheessa. Toinen vaihtoehto oli se, että loppukäyttäjät havaitsivat ohjelmiston toimimattomuuteen liittyvät virheet tuotantokäytössä. Joka tapauksessa epämiellyttävät yllätykset olivat -ja ovat edelleen- kalliita. Tästä syystä ketterät kehitysmallit ovat hyödyksi myös suorituskykytestaukselle.
Ketterien menetelmien periaatteiden mukaisesti jokaisen sprintin tuloksena on uutta toiminnallisuutta ja toimiva järjestelmä. Suorituskykytestaus tehdään siis aikaisemmin eli mahdollisesti jokaisen sprintin aikana tai heti sen jälkeen. Järjestelmätason suorituskykytestaus tehdään ennen tuotantoon vientiä viimeisessä sprintissä, jota kutsutaan muun muassa stabilointisprintiksi.
DevOpsin kanssa suorituskykytestaus tapahtuu kehitysrytmin aikana. Testaus on myös jatkuvaa, sillä testaustyökaluista esimerkiksi NeoLoad on mukana CI/CD-putkessa. NeoLoad tarjoaa yhteensopivuuden kaikkien suosittujen CI-ratkaisuiden kanssa. Se on osa open source-työkalujen muodostamaa CI/CD-putkea, jonka läpi koodi kulkee ennen tuotantoon vientiä.
Suorituskykytestauksen ja järjestelmätestauksen erot
Suorituskyvyn testaamisen nopeuttaminen ja automatisoinnin yksityiskohtaistason aleneminen lähemmäs kooditasoa ovat tuoneet mukanaan myös yhden ongelman: puutteet järjestelmätason suorituskykytestauksessa.
Verrataanpa näitä kahta eri suorituskyvyn testaustapaa: kehityksen aikana tapahtuvaa suorituskykytestausta vs. järjestelmätason suorituskykytestausta.
| Kehityksen aikana tapahtuva suorituskykytestaus | Järjestelmätason suorituskykytestaus | |
|---|---|---|
| Keskeinen tavoite | Mitataan perusympäristössä haluttujen kohteiden suorituskyky, annetaan siitä kehittäjille nopea palaute ja automatisoidaan tuoreimman käännösversion suorituskyvyn testiajo | Mitataan järjestelmän suorituskykyä tuotantoympäristön kaltaisessa testiympäristössä, jossa realistisen kuormituksen avulla voidaan arvioida myös ympäristön skaalautuvuutta ja kapasiteettivaatimuksia |
| Kuorman laajuus | Yksi käyttäjä ja / tai pieni käyttäjämäärä | Mahdollisimman realistiset käyttäjämäärät |
| Testien rakentaminen | Testit tehdään aina, kun testauksen kohde on valmiina (esim. tietokantakysely, API, mikropalvelu) ja automatisoidaan mahdollisimman paljon | Valikoitujen julkaisuiden / sprinttien testaus, joista muodostuu ajan kuluessa päivittyvä regressiotestisetti. Järjestelmätason testit rakennetaan kriittisten käyttötapauksien avulla ja luodaan realistinen kuormitus unohtamatta kuormahuippuja |
| Testidata | Käytetään sitä, millä saadaan testit suoritettua | Järjestelmätason testissä käytetään mahdollisimman realistista testidataa |
| Testien suorittaminen | Lyhyet testisetit ovat osana CI-putkea | Isot testisetit suoritetaan julkaisun yhteydessä. Osa testisetistä voi olla mukana CI-putkessa, osa ajetaan itsenäisesti tarpeen mukaan regressiotesteinä |
| Analysointityökalut | Yksinkertaiset testiympäristössä pyörivät monitorointityökalut | Mieluiten APM (application performance management) -työkalun avulla |
| Analysoinnin kohde | Koodin suorituskyvyn optimointi (esim. muistin kulutus, CPU-kuorma) | Ympäristön / kokonaisuuden / arkkitehtuurin suorituskyvyn arviointi (esim. skaalautuvuus) |
Suorituskyky on yksi niistä ei-toiminnallisista vaatimuksista, jotka pitää huomioida heti järjestelmän kehitystyön alkumetreillä. Suorituskykytestaus onkin koko projektin vastuulla. Sen osalta pitää olla määriteltynä prosessi: missä ympäristössä testataan, mitä testataan, koska testataan ja millä työkalulla. Esimerkkinä voi olla se, että joka yö ajetaan laajempi suorituskykytestisetti. Lisäksi testauksen kohteille pitää määritellä omat hyväksymiskriteerit tai KPI:t, josta esimerkkinä voi olla jonkun toiminnallisuuden keskimääräinen vasteaika.
Kannattaa aina tallentaa suorituskykytestauksen referenssitestien, siis samoina pysyvien testien, tulokset ja vertailla tallennettua historiatietoa tuoreimpiin testituloksiin. Näin voi helposti havaita, miten jonkun asian lisääminen, muuttaminen tai korjaaminen on voinut vaikuttaa järjestelmän suorituskykyyn.
Perffimies Riku Henriksson,
Technical Specialist
riku.henriksson@codemen.fi
QA-ukkeli Arto Stenberg
arto.stenberg@q-factory.fi
Osittain käytetty lähteenä: https://www.neotys.com/blog/neotyspac-continuous-early-vs-system-level-performance-tests-ramya-ramalinga-moorthy/
