Suorituskykytestauksen käyttötapausten ohjelmointi/skriptaus, milloin protokolla ja milloin selain tasolla?


Kun halutaan testata jonkun sovelluksen, esimerkiksi verkkokaupan suorituskyky, se tapahtuu tyypillisesti määrittelemällä tärkeät käyttötapaukset sovelluksessa ja rakentamalla sitten skriptit/ohjelmat, joilla käyttötapauksia voidaan simuloida suurilla määrillä käyttäjiä.

Periaate käyttötapausten simuloinnista on sama, kun toiminnallisen testauksen puolella testiautomaatiossa, mutta tapa jolla skriptejä/ohjelmia rakennetaan poikkeaa radikaalisti. Toiminnallisessa testauksessa simuloidaan tietyn selaimen käyttöä käyttöliittymässä html objekteja käyttämällä eli simuloidaan käyttäjän (client) toimintaa.

Suorituskykytestien skriptauksessa taas simuloidaan yleensä http kutsuja, joita selain lähettää palveluun. Puhutaan siis protokolla tason kutsuista. Web  sovelluksissa tämä protokolla on tyypillisesti HTTP 1.1 tai HTTP 2.0. Miksi tämä on sitten tärkeä ymmärtää ? Alla on esimerkki saman toiminnon kutsumisesta selain ja protokolla tasolla:

Selain tasoinen ”Siirry maksamaan” napin paino(selenium) on helppoa:

 

 

 

Protokolla tasoinen “Siirry maksamaan” napin paino (jmeter), jossa kutsujen 8 kpl ja niiden parametrien täytyy olla täsmälleen oikein

 

 

 

 

 

 

 

Selain skriptaus on tässä tapauksessa helppoa, mutta protokolla-tasoisen kutsun toimimaan saaminen voi viedä tunteja/päiviä ja joskus se on käytännössä mahdotonta,ilman apua sovelluksen kehittäjiltä.

Kun suorituskykytestien käyttötapausten skriptaus protokolla tasolla on välillä erittäin hankalaa, on erinomainen asia, että niiden skriptaus mahdollista tehdä myös selain tasoisella skriptauksella/ohjelmoinnilla. Suunnitelma B:ssä on kuitenkin rajoite: Se ei sovellu suurten käyttäjämäärien simulointiin helposti (yli 50 käyttäjää), suuren resurssi tarpeensa vuoksi, skriptejä ajavissa kuorma generaattori koneissa. Toki tähän on mahdollista saada apua esimerkiksi skaalautuvista pilvipalveluista, mutta kuormitus koneita tarvitaan yleensä paljon.

Tyypillisesti yhdellä kuorman generaattorilla voi esimerkiksi 1000 käyttäjää protokolla tasolla ja 15 käyttäjää selain tasoisella skriptillä. Syy löytyy siitä, että selain tasoinen skripti tarvii toimiakseen oman selain instanssin, jokaiselle käyttäjälle (virtuaali käyttäjä), joka käyttää paljon muistia ja prosessori kapasiteettia.

Todellisten käyttäjien simuloinnissa on kaksi keskeistä haastetta:

  • Saada oikein toimiva käyttötapaus (mahdollisimman nopeasti)
  • Saada käyttötapausta simuloitua suurella määrällä käyttäjiä (mahdollisimman helposti/halvalla)

Koska protokolla-tasoinen kuorman generointi on helppoa yleensä aina 300 käyttäjään asti, katsotaan tyypillisesti, ensin onko protokolla skriptaus kyseiselle sovellukselle helppoa vai haastavaa. Jos se on helppoa, se tehdään protokolla tasolla. Jos se taas on haastavaa/mahdotonta, katsotaan kuinka suuri kuorma pitää saada aikaiseksi eli onko selain tasoinen skriptien ajaminen riittävällä käyttäjä määrällä mahdollista. Myös hybridi ratkaisu on toimiva, joskaan ei ihan helpoin mahdollinen raportoinnin ja ylläpidon kannalta.

Case esimerkki suuresta verkkokaupasta:

“Eräällä asiakkaallamme on esimerkiksi protokolla tasoiset suorituskyky skriptit muuten, mutta eräs käyttötapaus, jossa käytetään kolmannen osapuolen komponenttia, on hankala simuloida oikein protokolla tasolla. Sen sijaan selain tasoinen skripti syntyi puolessa tunnissa. Näin testit saatiin ajettua hybridi mallilla ja tulokset raportoitua. Myöhemmin simuloimaan myös hankala käyttötapaus protokolla tasolla, kun siihen on aikaa ja apua saatavissa.”

Client ajan mittaus – kolmas näkökulma

Kolmas näkökulma skriptaus tason valintaan on aika ja sen mittaus, joka käytetään käyttäjän työasemassa. Protokolla tasoinen skripti ei mittaa, sitä kun taas selain tasoinen mittaa sen eli sen vasteaika samasta käyttäjä toiminnosta on pidempi, kun siinä on ns client aika mukana. Kumpi sitten pitäisi valita? Tämä on toisen artikkelin arvoinen aihe, mutta molemmat ovat yleensä hyviä tapoja mitata, joskin selain tasoinen vasteaika on lähempänä todellisuutta eli käyttäjän kokemaa nopeutta.