Johtajuus testauksessa: suorituskykytestauksen hallinta

By Paul Gerrard

Toimittajan huomautus: Tervetuloa ohjelmistotestauksen asiantuntijan ja konsultin Paul Gerrardin Testauksen johtaminen -sarjaan. Sarja on suunniteltu auttamaan muutaman vuoden kokemuksen omaavia testaajia – erityisesti ketterissä tiimeissä työskenteleviä – menestymään testausvastaavan ja esihenkilön tehtävissä. Edellisessä artikkelissa tarkastelimme palvelutestausta ja sen tärkeimpiä osa-alueita: suorituskykytestausta, vikasietoisuus- ja kestotestausta sekä hallittavuutta. Kuten lupasimme, perehdymme tässä suorituskykytestaukseen hieman yksityiskohtaisemmin. Tilaa The […]

Toimittajan huomautus: Tervetuloa ohjelmistotestauksen asiantuntijan ja konsultin Paul Gerrardin Testauksen johtaminen -sarjaan. Sarja on suunniteltu auttamaan muutaman vuoden kokemuksen omaavia testaajia – erityisesti ketterissä tiimeissä työskenteleviä – menestymään testausvastaavan ja esihenkilön tehtävissä.

Edellisessä artikkelissa tarkastelimme palvelutestausta ja sen tärkeimpiä osa-alueita: suorituskykytestausta, vikasietoisuus- ja kestotestausta sekä hallittavuutta. Kuten lupasimme, perehdymme tässä suorituskykytestaukseen hieman yksityiskohtaisemmin.

Tilaa The QA Lead -uutiskirje, niin saat ilmoituksen, kun sarjan uudet osat julkaistaan. Nämä kirjoitukset ovat otteita Paulin Testauksen johtaminen -kurssilta, jota suosittelemme lämpimästi, jos haluat perehtyä tähän ja muihin aiheisiin syvällisemmin. Jos päätät osallistua, käytä ainutlaatuista kuponkikoodiamme QALEADOFFER ja säästä 60 dollaria kurssin täydestä hinnasta!

Hei ja tervetuloa Testauksen johtaminen -sarjaan. Edellisessä artikkelissa tarkastelimme verkkosovellusten palvelutestausta. 

Tämän luvun tarkoituksena on antaa neuvoja ja parhaita käytäntöjä kyseisessä artikkelissa mainitun palvelutestauksen kriittisen osa-alueen eli, rumpujen pärinää... suorituskykytestauksen hallintaan!

Käsittelemme seuraavat aiheet:

Aloitetaan.

Suorituskykytestauksen tavoitteet

Kerrataan nopeasti: suorituskykytestauksen ensisijainen tavoite voidaan määritellä seuraavasti:

”Osoittaa, että järjestelmä toimii määritysten mukaisesti hyväksyttävillä vasteajoilla käsitellessään tuotantokokoiseen tietokantaan perustuvia vaadittuja tapahtumamääriä.”

Suorituskykytestausympäristösi on testialusta, jota voidaan käyttää myös muihin testeihin ja jolla on laajemmat tavoitteet, jotka voimme tiivistää seuraavasti:

  • Järjestelmän kasvukapasiteetin arviointi (Jos et ole varma, mikä ohjelmisto vastaa tarpeitasi, luettelomme parhaista tietokantojen hallintaratkaisuista voi auttaa.)
  • Arkkitehtuurin heikkojen kohtien tunnistaminen
  • Järjestelmän säätäminen
  • Ohjelmiston vaikeasti havaittavien virheiden tunnistaminen
  • Vikasietoisuuden ja luotettavuuden varmistaminen.

Testausstrategiassasi tulee määritellä sellaisen testausinfrastruktuurin vaatimukset, joka mahdollistaa kaikkien näiden tavoitteiden saavuttamisen.

Suorituskykytestauksen neljä edellytystä

"Jos jokin näistä edellytyksistä puuttuu, ole erittäin varovainen ennen kuin jatkat testien suorittamista ja tulosten julkaisemista. Laadunvarmistuksen automaatiotyökalujen hyödyntäminen voi auttaa varmistamaan, että nämä edellytykset täyttyvät. Testien suorittaminen saattaa olla vaikeaa tai mahdotonta, tai julkaisemiesi tulosten uskottavuus voi olla vakavasti puutteellinen ja helposti kyseenalaistettavissa."

Get Free Access
Get regular tech leadership wisdom for delivering better software and systems.
Get Free Access

Have an account? Log In

1. Määrälliset, olennaiset, mitattavat, realistiset ja saavutettavissa olevat vaatimukset

Kaikkien testien perustana olevista suorituskykyvaatimuksista (tavoitteista) tulee sopia ennen testiä, jotta voidaan määrittää, täyttääkö järjestelmä kyseiset vaatimukset. 

Järjestelmän suorituskyvylle tai vasteajoille asetettavilla vaatimuksilla tulee olla seuraavat ominaisuudet, jotta niitä voidaan käyttää suorituskykytulosten vertailun lähtökohtana. Niiden tulee olla:

  • Ilmaistu määrällisin termein.
  • Olennainen käyttäjän suorittaman tehtävän kannalta.
  • Mitattavissa työkalulla (tai sekuntikellolla) kohtuullisin kustannuksin.
  • Realistinen käyttäjän tehtävään kuluvan ajan näkökulmasta.
  • Saavutettavissa kohtuullisin kustannuksin.

Suorituskykyvaatimukset ovat usein epämääräisiä tai niitä ei ole lainkaan. Etsi mahdolliset dokumentoidut vaatimukset, jos se on mahdollista. Jos vaatimuksissa on puutteita, ne on ehkä dokumentoitava jälkikäteen. 

Ennen kuin suorituskykytesti voidaan määritellä ja suunnitella, seuraavista vaatimuksista on sovittava:

  • Transaktioiden vasteajat.
  • Kuormaprofiilit (simuloitavien käyttäjien ja transaktioiden määrät).
  • Tietokantamäärät (tuotantoympäristön tietokantatauluihin odotettavien tietueiden määrät).

Suorituskykyvaatimukset määritellään usein epämääräisin termein. Nämä vaatimukset perustuvat usein liiketoimintamäärien suuntaa-antaviin ennusteisiin, joten liiketoimintakäyttäjiä voi olla tarpeen ohjata pohtimaan suorituskykyvaatimuksia realistisesti. 

Voit myös joutua tekemään osan vaatimusanalyysistä itse ja dokumentoimaan nämä vaatimukset tavoiteltuina suorituskykytavoitteina. 

2. Vakaa järjestelmä

Jos järjestelmässä on virheitä ja se on epäluotettava, et pääse pitkälle suorituskykytestin kanssa. Suorituskykytestit kuormittavat kaikkia arkkitehtuurin komponentteja jossain määrin. Jotta suorituskykytestaus tuottaisi hyödyllisiä tuloksia, järjestelmän ja teknisen infrastruktuurin on kuitenkin oltava lähtökohtaisesti kohtuullisen luotettavia ja vikasietoisia.

3. Realistinen testiympäristö

Testiympäristö on määritettävä niin, että testi on mielekäs. Et todennäköisesti pysty toisintamaan kohde- tai tuotantojärjestelmää, mutta testiympäristön tulisi vastata kokonaan tai osittain lopullista tuotantoympäristöä. Sinun on sovittava järjestelmäarkkitehdin kanssa siitä, mitkä kompromissit ovat hyväksyttäviä ja mitkä eivät, tai vähintään siitä, millainen hyödyllinen tulkinta testituloksista voidaan tehdä.

Realistisen testiympäristön luominen on olennaista mielekkäiden suorituskykytestien kannalta. Tutustu huolella valittuun ohjelmistotestausalustojen valikoimaamme, jos tarvitset työkaluja todellisen maailman olosuhteiden simulointiin.

4. Hallittu testiympäristö

Suorituskykytestaajat tarvitsevat vakautta. Laitteiston ja ohjelmiston luotettavuuden ja vikasietoisuuden lisäksi on minimoitava testausympäristössä tai testattavassa ohjelmistossa tapahtuvat muutokset. Jos esimerkiksi käyttöliittymää muutetaan edes hieman, käyttöliittymien ohjaamiseen suunnitellut testiskriptit lakkaavat helposti toimimasta välittömästi.

Kaikkia ympäristön muutoksia on valvottava tarkasti. Jos muutos korjaa virheitä, jotka eivät todennäköisesti vaikuta suorituskykyyn, voit harkita julkaisun hylkäämistä. Vain suorituskyvyn tai luotettavuuden parantamiseen tarkoitetut muutokset voitaisiin hyväksyä.

Suorituskykytestauksen työkalupakki

Suorituskykytestauksen työkalupakkiisi kuuluu viisi päätyökalua:

  • Testidatan luonti ja ylläpito – tietokantaan testissä tarvittavien suurten tietomäärien luomiseen. Oletamme, että kyseessä on SQL-pohjainen apuohjelma tai mahdollisesti Microsoft Accessin kaltainen tietokonepohjainen tuote, joka on yhdistetty testitietokantaan.
  • Kuorman generointi – yleisissä työkaluissa käytetään testiohjaimia, jotka simuloivat virtuaalisia asiakkaita lähettämällä HTTP-viestejä verkkopalvelimille.
  • Sovelluksen suorittamistyökalu – tämä ohjaa yhtä tai useampaa sovelluksen esiintymää selainkäyttöliittymän avulla ja tallentaa vasteaikamittaukset. (Tämä on yleensä sama työkalu, jota käytetään kuorman generointiin, mutta sen ei tarvitse olla sama).
  • Resurssien valvonta – apuohjelmat, jotka valvovat ja kirjaavat asiakas- ja palvelinjärjestelmien resursseja, verkkoliikennettä, tietokantatoimintaa ja niin edelleen.
  • Tulosten analysointi ja raportointi – testien suoritus- ja resurssienvalvontatyökalut tuottavat suuria määriä tulostietoja analysoitaviksi.

Aiheeseen liittyvää luettavaa: 10 PARASTA SQL-ANALYTIIKKAPALVELUA LAADUNVARMISTUSTIIMEILLE

Suorituskykytestausprosessi

Alla oleva kuva esittää suorituskykytestauksen ja -virityksen yleisen prosessin. Viritys ei oikeastaan kuulu testausprosessiin, mutta se on erottamaton osa suorituskyvyn ja luotettavuuden parantamista. Viritys voi sisältää arkkitehtuuri-infrastruktuurin muutoksia, mutta sen ei pitäisi vaikuttaa testattavan järjestelmän toiminnallisuuteen.

Suorituskykytestin raportointi-infografiikka

Seuraavaksi tarkastelemme, miten suorituskykytesti kehitetään, suoritetaan, analysoidaan ja raportoidaan.

Testin vaiheittainen kehittäminen

Testin kehittäminen suoritetaan yleensä neljässä vaiheessa:

  1. Jokainen testiskripti valmistellaan ja testataan erikseen sen virheenkorjausta varten.
  2. Scriptit integroidaan työkuorman kehitysversioon, ja työkuorma suoritetaan sen testaamiseksi, että uusi skripti on yhteensopiva sen kanssa.
  3. Työkuorman kasvaessa kehitteillä olevaa testikehystä viimeistellään, sen virheitä korjataan ja siitä tehdään jatkuvasti luotettavampi. Myös kokemus ja perehtyneisyys työkaluihin lisääntyvät.
  4. Kun viimeinen skripti on integroitu työkuormaan, testi suoritetaan ”koeajona” sen varmistamiseksi, että se on täysin toistettavissa ja luotettava sekä valmis varsinaisia testejä varten.

Välitestit voivat tuottaa hyödyllisiä tuloksia

Osittaisen työkuorman ja testitapahtumien suorittaminen voi paljastaa suorituskykyongelmia. Pienen volyymin kuormitusten testit voivat myös antaa varhaisen kuvan verkkoliikenteestä ja mahdollisista pullonkauloista, kun testiä laajennetaan. 

Hitaat vasteajat voivat johtua sovelluksen heikosta suunnittelusta, ja kehittäjät voivat tutkia ja korjata ongelmat aiemmin. Varhaisia testejä voidaan myös suorittaa pidempiä ajanjaksoja kestävyystesteinä.

More Articles

Testin suoritus

Testin suoritus edellyttää jonkinasteista vaiheiden hallintaa tai koordinointia. Sinun tulee olla yhteydessä tukea tarjoaviin osallistujiin, jotka valvovat järjestelmää testien suorittamisen aikana. ”Testin valvonta” -tiimi voi olla hajautettu, joten sinun on pidettävä se ajan tasalla, jotta testi sujuu ongelmitta ja tulokset tallennetaan oikein.

Eri tiiminjäsenten koordinoinnin lisäksi suorituskykytestin suoritus noudattaa yleensä vakiintunutta menettelyä.

  1. Tietokannan valmistelu (palautus nauhalta tarvittaessa).
  2. Valmistele testiympäristö tarpeen mukaan ja varmista sen tila.
  3. Käynnistä valvontaprosessit (verkko, asiakasohjelmat ja palvelimet, tietokanta).
  4. Käynnistä kuormasimulaatio ja seuraa järjestelmän valvontaa.
  5. Jos käytössä on erillinen työkalu, käynnistä kuorman vakiinnuttua sovellustestin suorittava työkalu ja vasteajan mittaus.
  6. Valvo testiä tarkasti koko testin ajan.
  7. Jos testin suorittavat työkalut eivät pysähdy automaattisesti, lopeta testi testijakson päättyessä.
  8. Pysäytä valvontatyökalut ja tallenna tulokset.
  9. Arkistoi kaikki tallennetut tulokset ja varmista, että kaikki tulostiedot varmuuskopioidaan turvallisesti.
  10. Laadi väliraportit ja keskustele muiden tiiminjäsenten kanssa mahdollisista poikkeamista.
  11. Valmistele analyysit ja raportit.

Eri tiiminjäsenten koordinointi testin suorituksen aikana voi olla haastavaa. Sujuvoita prosessia integroimalla Jiraa varten suunnitellut edistyneet testinhallintatyökalut, jotka tarjoavat esimerkiksi reaaliaikaisen yhteistyön ja raportoinnin ominaisuuksia.

Viritystä tehdään yleensä testauksen jälkeen, kun ongelmia ilmenee tai kun tiedetään, että mahdollisia optimointeja voidaan tehdä. Jos kyseessä on toistotesti, on olennaista kirjata kaikki ympäristöön tehdyt muutokset. Näin järjestelmän käyttäytymisessä ja siten suorituskykytuloksissa havaitut erot voidaan yhdistää kokoonpanossa tehtyihin muutoksiin.

Suorituskykytestauksen testitapausten hallinnassa testinhallintaohjelmisto voi muuttaa tilanteen ratkaisevasti. Sen avulla testitapaukset voidaan järjestää ja jäljittää paremmin sekä jopa automatisoida niitä.

Nyrkkisääntönä on viisasta muuttaa vain yhtä asiaa kerrallaan, jotta käyttäytymisessä havaittavat erot voidaan jäljittää tehtyihin muutoksiin.

Tulosten analysointi ja raportointi

Testisuorituksen tyypillisessä raportissa esitetään yhteenveto näistä mittauksista, ja kustakin tehdystä mittauksesta ilmoitetaan seuraavat tiedot:

  • Mittauksien määrä.
  • Vasteajan vähimmäisarvo.
  • Vasteajan enimmäisarvo.
  • Vasteajan keskiarvo.
  • N:s (tyypillisesti 95.) persentiilin vasteaika.

Työkalupakkisi kuormantuottotyökalun tulee tallentaa kunkin tapahtumatyypin määrä testijakson aikana. Kun nämä määrät jaetaan testin kestolla, saadaan tosiasiassa saavutettu tapahtumanopeus eli läpimeno. 

Tapahtumien määrä on järjestelmään kohdistettu kuormitus. Tämä edellyttää, että suoritettujen tapahtumien suhteet vastaavat kuormitusprofiilia, jota yrität käyttää.

Käytetyn kuormituksen tulisi vastata simuloitua kuormitusprofiilia – mutta se ei välttämättä vastaa, jos järjestelmä vastaa hitaasti ja tapahtumat suoritetaan vaihtelevilla nopeuksilla.

Yleensä suoritat sarjan testiajoja vaihtelevilla kuormituksilla. Piirrä testisarjan tulosten perusteella kaavio, jossa esitetään tapahtuman vasteaika käytettyyn kuormitukseen nähden.

Resurssien valvontatyökaluissa on yleensä tilastollisia tai graafisia raportointiominaisuuksia, jotka esittävät resurssien käytön ajan kuluessa. Parannetut raportit resurssien käytöstä suhteessa käytettyyn kuormitukseen ovat erittäin hyödyllisiä ja voivat auttaa tunnistamaan järjestelmän arkkitehtuurin pullonkaulat.

Onnea matkaan!

Tilaa The QA Lead -uutiskirje, niin saat ilmoituksen, kun sarjan uusia osia julkaistaan. Nämä julkaisut ovat otteita Paulin Testauksen johtaminen -kurssilta, jota suosittelemme lämpimästi, jos haluat perehtyä tähän ja muihin aiheisiin syvällisemmin. Jos päätät osallistua, käytä eksklusiivista kuponkikoodiamme QALEADOFFER ja saat 60 dollaria alennusta kurssin täydestä hinnasta!

Aiheeseen liittyvää luettavaa: JÄRJESTELMÄN KUNNON JA SUORITUSKYVYN SEURAAMISEEN KÄYTETTÄVÄT PALVELINVALVONNAN MITTARIT

Paul Gerrard
Paul is an internationally renowned, award-winning software engineering consultant, author, and coach. He is the host of the Technology Leadership Forum and the Programme Chair of the 2014 EuroSTAR Testing conference.

You may also like