info(at)devaten.com +358505945077

Suorituskyvyn mittaaminen

Sovelluksen suorituskyvyn mittaaminen osana automaatiotestejä

Kun DB2-kantojen suorituskyvyn mittaaminen tehdään osana automaatiotestausta selviää tuloksista kokemukseni mukaan mielenkiintoisia ja hyödyllisiä tuloksia.

Tässä kuvattuna yhden testicasen suorittamisen alueet:

  • SQL-lauseiden kpl-määrä
  • Erikseen jaoteltuna select, insert, delete, update –määrät
  • Luettujen rivien määrä, kuinka monta tietokannan riviä testicasen aikana DB2 lukee tietokannasta.

Miksi tarkkuus on valttia?

Laajassa sovelluksessa jo pienet koodimuutokset heijastuvat yleensä moniin eri palveluihin. Esimerkiksi käyttöliittymään lisätään uusi kenttä, ja tietoa ei ole saatavilla nykyisellä palvelulla, koodaaja lisää kentän haun yleiseen palveluun, lisäämällä palveluun uuden palvelukutsun, jolla uusi tieto saadaan haettua. Local-testissä kaikki toimii nopeasti ja kätevästi kuten myös hyväksymistestiympäristössä, automaatiotestit yms näyttävät vihreää. Asia ei ole kuitenkaan näin yksinkertainen.

Uutta kenttää varten tehty palvelumuutos onkin erittäin huonosti toteutettu siellä iteroidaan listoja ja kantaan tehdään useita turhia kyselyitä. Ongelmia alkaakin tulla vasta suorituskykytesteissä, useissa eräajoissa huomataan hitautta sekä myös web service -liittymissä havaitaan hitautta.

Tällöin aletaan selvittää missä vika on ja aikaa kuluu helposti useita päiviä ennen kuin vika löytyy. Useissa tapauksessa näin pienen muutoksen takia ei tehdä kattavaa suorituskykytestiä vaan ongelmia alkaa ilmetä vasta tuotannossa. Laajan sovelluksen kattava suorituskykytestaus yleensä vaatii paljon kalenteriaikaa – ja löydösten korjaaminen viivästyttää koko toimituksen aikataulun.

Nyt kun lisäämme suorituskykymittarit osaksi sovelluksen normaaleja automaatiotestejä, saamme sieltä kiinni heti eri palveluissa muuttuneet suoritettujen SQL-lauseiden määrän. Esimerkiksi tässä tapauksessa muutos yleiseen palveluun vaikutti moneen eri testitapaukseen.

SQL-lauseen muutokset

Toinen vastaava ongelmakohta syntyy kun kehittäjä muuttaa laajassa käytössä olevaa SQL-lausetta esimerkiksi lisäämällä kyselyyn uuden alikyselyn. Tällöin Select-toiminto alkaakin lukemaan koko isoa taulua läpi. Tämänkaltaista ongelmaa ei löydetä vielä pienemmissä testikannoissa, sillä DB2 lukee koko taulun nopeasti läpi. Hitautta alkaakin tulla vasta kun sovellusta aletaan testaamaan isossa suorituskykytestikannassa / tuotannossa.

Lisää onnistumisen mahdollisuuksia

Kun lisäämme suorituskykymittarit osaksi sovelluksen normaaleja automaatiotestejä, saamme sieltä kiinni heti eri palveluissa muuttuneet luettujen rivien määrän verrattuna tilanteeseen ennen muutosta.

Suurissa kehityshankkeissa suorituskykytestaus osana testiautomaatiota nopeuttaa huomattavasti suorituskykyongelmien korjaamista ja tätä kautta koko projektilla on paremmat onnistumisen mahdollisuudet. Turhan usein suorituskykyä korjataan vasta jälkikäteen sammutellaan tulipaloja siellä missä käryää.

Mittareista selviää tämän lisäksi vielä paljon lisää esimerkiksi. Sorttien määrä, epäonnistuneiden sql-lauseiden määrä, committien ja rollbackien määrä, lukkojen odotus aika yms.

Mitä palveluni tekee? 

Tuottamani Analyysipalvelu antaa sinulle ja organisaatiollesi seuraavaa:

Ensimmäisellä ajokerralla nähdään valittujen testitapausten suorituskyvyn tilanne. Etsin ja listaan teille esimerkiksi Top10 parasta / huonoiten suoriutuvaa käyttötapausta.
Seuraavilla ajoilla saadaan kiinni ne testitapaukset, joissa on tapahtunut muutoksia edelliseen testiin verrattuna.

Mikko Larkela

Mikko Larkela