Toimittajan huomautus: Tervetuloa ohjelmistotestauksen asiantuntijan ja konsultin Paul Gerrardin Johtajuus testauksessa -sarjaan. Sarjan tavoitteena on auttaa muutaman vuoden kokemuksen hankkineita testaajia – erityisesti ketterissä tiimeissä työskenteleviä – menestymään testauksen vetäjän ja johtamisen tehtävissä.
Edellisessä artikkelissa tarkastelimme testaajien muuttuvaa roolia ja sitä, miten yhteistyötä kollegoiden kanssa voidaan edistää. Tässä artikkelissa perehdymme verkkosovelluksen suorituskyvyn, luotettavuuden ja hallittavuuden testauksen käytännön yksityiskohtiin. Toisin sanoen palvelutestaukseen.
Tilaa The QA Lead -uutiskirje, niin saat ilmoituksen sarjan uusien osien julkaisusta. Nämä artikkelit ovat otteita Paulin Johtajuus testauksessa -kurssilta, jota suosittelemme lämpimästi, jos haluat perehtyä tähän ja muihin aiheisiin syvällisemmin. Jos päätät osallistua, saat 60 dollaria alennusta kurssin täydestä hinnasta käyttämällä eksklusiivista kuponkikoodiamme QALEADOFFER!
Hei ja tervetuloa Johtajuus testauksessa -sarjan seuraavaan lukuun. Tällä viikolla tarkastelemme verkkosovellusten palvelutestausta. Käsittelemme seuraavia aiheita:
- Mitä palvelutestaus on?
- Mitä suorituskyvyn testaus on?
- Luotettavuuden ja vikatilanteesta palautumisen testaus
- Palvelunhallinnan testaus
Aloitetaan.
Mitä palvelutestaus on?
Verkkosovelluksen tarjoaman palvelun laatu voidaan määritellä siten, että se sisältää kaikki sen ominaisuudet, kuten toiminnallisuuden, suorituskyvyn, luotettavuuden, käytettävyyden, tietoturvan ja niin edelleen.
Tässä yhteydessä erottelemme kuitenkin kolme erityistä palvelutavoitetta, jotka kuuluvat niin sanotun palvelutestauksen piiriin. Nämä tavoitteet ovat seuraavat:
- Suorituskyky: palvelun on vastattava käyttäjille nopeasti ja tuettava siihen kohdistuvia kuormia.
- Luotettavuus: jos palvelu on suunniteltu kestämään vikatilanteita, sen on oltava luotettava ja/tai jatkettava palvelun tarjoamista myös vian ilmetessä.
- Hallittavuus: palvelua on voitava hallita, määrittää tai muuttaa ilman, että loppukäyttäjät havaitsevat palvelun heikkenemistä. Hallittavuuden eli operoinnin testauksen tavoitteena on osoittaa, että järjestelmän hallinnolliset, hallinta- sekä varmuuskopiointi- ja palautusmenettelyt toimivat tehokkaasti.
Kaikissa kolmessa tapauksessa meidän on simuloitava käyttäjäkuormaa, jotta testit voidaan suorittaa tehokkaasti. Suorituskyky-, luotettavuus- ja hallittavuustavoitteet ovat merkityksellisiä tilanteessa, jossa todelliset asiakkaat käyttävät sivustoa liiketoimintansa hoitamiseen.
Sivuston reagointikyky (tässä tapauksessa aika, joka yhdeltä järjestelmäsolmulta kuluu toisen solmun pyyntöön vastaamiseen) liittyy suoraan teknisessä arkkitehtuurissa käytettävissä oleviin resursseihin.
Mitä useampi asiakas käyttää palvelua, sitä vähemmän teknisiä resursseja on käytettävissä kunkin käyttäjän pyyntöjen käsittelyyn, ja vastausajat pitenevät.
On selvää, että kevyesti kuormitettu palvelu vikaantuu epätodennäköisemmin. Suuri osa ohjelmistojen ja laitteistojen monimutkaisuudesta on olemassa, jotta teknisen arkkitehtuurin resurssitarpeisiin voidaan vastata sivuston ollessa raskaasti kuormitettu.
Kun sivustoa kuormitetaan (tai ylikuormitetaan), resurssien keskenään ristiriitaiset pyynnöt on hallittava erilaisten infrastruktuurikomponenttien, kuten palvelin- ja verkko-käyttöjärjestelmien, tietokannan hallintajärjestelmien, verkkopalvelintuotteiden, objektipyyntövälittäjien, väliohjelmistojen ja muiden vastaavien avulla.
Nämä infrastruktuurikomponentit ovat yleensä luotettavampia kuin resurssia tarvitseva räätälöity sovelluskoodi, mutta vikoja voi esiintyä kummassakin:
- Infrastruktuurikomponentit vikaantuvat, koska sovelluskoodi asettaa resurssien käytölle liiallisia vaatimuksia heikon suunnittelun tai toteutuksen vuoksi.
- Sovelluskomponentit voivat vikaantua, koska niiden tarvitsemia resursseja ei välttämättä ole aina saatavilla (ajoissa).
Simuloimalla tyypillisiä ja poikkeuksellisia tuotantokuormia pitkän ajanjakson ajan testaajat voivat paljastaa puutteita järjestelmän suunnittelussa tai toteutuksessa. Kun nämä puutteet korjataan, samat testit osoittavat järjestelmän olevan vikasietoinen. QA-ammattilaiset voivat hyödyntää kuormitustestaustyökaluja suorittaakseen monia alla määriteltyjä prosesseja.
Kaikissa palveluissa on yleensä useita kriittisiä hallintaprosesseja, jotka on suoritettava palvelun sujuvan toiminnan varmistamiseksi. Palvelu voi olla mahdollista sulkea rutiinihuoltoa varten normaalien työaikojen ulkopuolella, mutta useimmat verkkopalvelut toimivat ympäri vuorokauden.
Palvelun työpäivä ei koskaan pääty. Hallintamenettelyt on väistämättä suoritettava palvelun ollessa käynnissä ja käyttäjien ollessa järjestelmässä. Menettelyt on testattava järjestelmän ollessa kuormitettuna, jotta voidaan varmistaa, etteivät ne vaikuta haitallisesti käytössä olevaan palveluun eli suorituskyvyn testaukseen.
Have an account? Log In
Mitä suorituskykytestaus on?
Suorituskykytestaus on palvelutestauksen keskeinen osa. Sen avulla testataan, miten järjestelmä toimii reagointikyvyn ja vakauden osalta tietyn työkuorman alaisena. Tässä yleiskatsaus sen toimintaan:
- Suorituskykytestaus koostuu useista testeistä vaihtelevilla kuormitustasoilla, joissa järjestelmä saavuttaa vakaan tilan (kuormitus ja vasteajat pysyvät vakioina).
- Mittaamme kuormituksen ja vasteajat kullakin kuormitustasolla, jota simuloidaan 15–30 minuutin ajan tilastollisesti merkitsevän mittausmäärän saamiseksi.
- Seuraamme ja tallennamme kunkin simuloidun kuormitustason keskeiset tunnusluvut. Näitä ovat järjestelmämme erilaiset resurssit, kuten suorittimen ja muistin käyttö, verkkokaistan leveys, I/O-nopeudet ja niin edelleen.
Piirrämme kaavion näistä vaihtelevista kuormitustasoista suhteessa ”virtuaalisten” käyttäjiemme kokemiin vasteaikoihin. Kun kaavio esitetään, se näyttää jotakuinkin alla olevan kuvan mukaiselta.

Nollakuormituksessa, jolloin järjestelmässä on vain yksi käyttäjä, hänellä on koko resurssi käytettävissään ja vasteajat ovat lyhyitä. Kun lisäämme kuormitusta ja mittaamme vasteaikoja, ne heikkenevät asteittain, kunnes järjestelmä saavuttaa enimmäiskapasiteettinsa.
Tässä vaiheessa testitapahtumiemme vasteaika on teoreettisesti ääretön, koska yksi järjestelmän keskeisistä resursseista on käytetty kokonaan eikä uusia tapahtumia voida käsitellä.
Kun lisäämme kuormitusta nollasta enimmäistasolle, seuraamme samalla erilaisten resurssityyppien käyttöä, kuten palvelimen suorittimen käyttöä, muistin käyttöä, verkkokaistan leveyttä, tietokannan lukituksia ja niin edelleen.
Enimmäiskuormituksessa jokin näistä resursseista on käytössä 100-prosenttisesti. Tämä resurssi rajoittaa toimintaa, koska se loppuu ensimmäisenä. Tässä vaiheessa vasteajat ovat tietenkin heikentyneet niin paljon, että ne ovat todennäköisesti paljon hitaampia kuin olisi hyväksyttävää.
Alla oleva kaavio näyttää useiden resurssien käytön ja saatavuuden suhteessa kuormitukseen.

Järjestelmän läpimenokapasiteetin lisäämiseksi ja/tai vasteaikojen lyhentämiseksi meidän on tehtävä jokin seuraavista:
- Vähennetään resurssin kysyntää, tyypillisesti tehostamalla resurssia käyttävää ohjelmistoa (tämä kuuluu yleensä kehitystiimin vastuulle).
- Optimoidaan laitteistoresurssin käyttö teknisessä arkkitehtuurissa esimerkiksi määrittämällä DBMS tallentamaan enemmän tietoja välimuistiin tai asettamalla jotkin prosessit sovelluspalvelimella muita tärkeämmiksi.
- Tuodaan enemmän resurssia saataville. Yleensä tämä tehdään lisäämällä suorittimia, muistia tai verkkokaistan leveyttä ja niin edelleen.
Kuten olet epäilemättä jo alkanut huomata, suorituskykytestaus tarvitsee testaajien tueksi tiimin. Siihen kuuluvat tekniset arkkitehdit, palvelinten ylläpitäjät, verkon ylläpitäjät, kehittäjät sekä tietokantojen suunnittelijat ja ylläpitäjät. Nämä tekniset asiantuntijat ovat päteviä analysoimaan resurssien valvontatyökalujen tuottamia tilastoja ja arvioimaan, miten sovellusta kannattaa säätää tai miten järjestelmää kannattaa virittää tai päivittää.
Jos olet testaaja, älä yritä teeskennellä, että pystyt tulkitsemaan näitä tilastoja ja tekemään viritys- ja optimointipäätöksiä, ellet itse ole erityisen perehtynyt näihin aloihin. Sinun on otettava nämä asiantuntijat mukaan projektiin jo varhaisessa vaiheessa saadaksesi heidän neuvojaan ja sitoutumisensa sekä myöhemmin testauksen aikana varmistaaksesi, että pullonkaulat tunnistetaan ja ratkaistaan.
Seuraa seuraavaa artikkelia, jossa perehdymme tarkemmin suorituskykytestauksen hallintaan.
Luotettavuus-/varmistustestaus
Palvelun jatkuvan saatavuuden varmistaminen on todennäköisesti yksi projektisi keskeisistä tavoitteista. Luotettavuustestaus auttaa tuomaan esiin vaikeasti havaittavia vikoja, jotka aiheuttavat odottamattomia häiriöitä. Varmistustestauksella varmistetaan, että ennakoituja häiriöitä varten suunnitellut varmistustoimenpiteet todella toimivat.
Varmistustestaus
Kun sivustojen edellytetään olevan vikasietoisia ja/tai luotettavia, ne suunnitellaan yleensä luotettavista järjestelmäkomponenteista, joissa on sisäänrakennettu redundanssi ja varmistusominaisuudet, jotka otetaan käyttöön häiriöiden ilmetessä.
Näihin ominaisuuksiin voivat kuulua monipuolinen verkon reititys, klustereiksi määritetyt useat palvelimet, kuormanjakoa käsittelevä väliohjelmisto ja hajautettu palveluteknologia sekä liikenteen uudelleenreititys häiriötilanteissa.
Varmistustestauksen tavoitteena on tutkia järjestelmän toimintaa valituissa häiriöskenaarioissa ennen käyttöönottoa, ja siihen sisältyy yleensä seuraavaa:
- Niiden komponenttien tunnistaminen, jotka voivat vikaantua ja aiheuttaa palvelukatkoksen (tarkastelemalla vikoja sisältä ulospäin).
- Niiden vaaratekijöiden tunnistaminen, jotka voivat aiheuttaa vian ja palvelukatkoksen (tarkastelemalla uhkia ulkoa sisäänpäin).
- Niiden vikatilojen tai skenaarioiden analysointi, joita voi ilmetä ja joissa on varmistuttava palautumistoimenpiteen toimivuudesta.
- Automatisoitu testi, jolla järjestelmään voidaan kohdistaa kuormaa ja tutkia järjestelmän toimintaa pitkän ajanjakson ajan.
- Samaa automatisoitua testiä voidaan käyttää myös testattavan järjestelmän kuormittamiseen ja järjestelmän toiminnan valvontaan vikatilanteissa.
Vikapuuanalyysi (FTA) auttaa ymmärtämään palvelun riippuvuuksia sen taustalla olevista komponenteista. Vikapuuanalyysi ja vikapuukaaviot ovat järjestelmän tai palvelun looginen esitys sekä esitys tavoista, joilla se voi vikaantua.
Alla oleva yksinkertainen kaavio näyttää peruskomponenttien vikatapahtumien, välitasojen alijärjestelmien vikatapahtumien ja ylimmän tason palvelun vikatapahtuman välisen suhteen. Tietenkin voi olla mahdollista tunnistaa enemmän kuin kolme vikatapahtumien tasoa.

Nämä testit on suoritettava automatisoidulla kuormalla, jotta järjestelmän toimintaa voidaan tutkia tuotantotilanteissa ja jotta voidaan varmistua suunniteltujen palautumistoimenpiteiden toimivuudesta. Erityisesti halutaan tietää:
- Miten arkkitehtuuri toimii vikatilanteissa?
- Toimivatko kuormantasausratkaisut oikein?
- Ottavatko vikasietotoiminnot kuorman vastaan komponentin vikaantuessa?
- Toimiiko automaattinen palautuminen? Saavatko uudelleenkäynnistetyt järjestelmät kiinni menetetyn ajan?
Lopulta testeissä keskitytään selvittämään, säilyykö palvelu loppukäyttäjien saatavilla ja huomaavatko käyttäjät todella vian ilmenemisen.
Luotettavuustestaus (tai soak-testaus)
Luotettavuustestauksella pyritään varmistamaan, ettei kuormituksen aikana ilmene vikoja.
Useimmat laitteistokomponentit ovat niin luotettavia, että niiden vikojen välinen keskimääräinen aika voidaan mitata vuosissa. Luotettavuustesteissä automaattisia testejä on käytettävä (tai uudelleenkäytettävä) kahdella tavalla seuraavien tilanteiden simuloimiseksi:
- Teknisen arkkitehtuurin tiettyihin komponentteihin tai resursseihin kohdistuvat äärimmäiset kuormat.
- Koko järjestelmään kohdistuvat normaalit (tai äärimmäiset) kuormat pitkien ajanjaksojen ajan.
Kun keskitytään tiettyihin komponentteihin, komponenttia pyritään rasittamaan kohdistamalla siihen kohtuuttoman suuri määrä pyyntöjä sen suunnitellun toiminnon suorittamiseksi. Kriittiset komponentit on usein yksinkertaisempaa rasitustestata ensin erillään suurella määrällä yksinkertaisia pyyntöjä ennen kuin koko infrastruktuuriin kohdistetaan paljon monimutkaisempi testi. Saatavilla on myös erityisesti suunniteltuja rasitustestaustyökaluja, jotka helpottavat QA-tiimien työtä prosessin suorittamisessa.
Soak-testit ovat testejä, joissa järjestelmään kohdistetaan kuormaa pitkän, esimerkiksi 24 tai 48 tuntia kestävän tai sitä pidemmän ajanjakson ajan, jotta yleensä vaikeasti havaittavat ongelmat löytyisivät. Epäselvät viat ilmenevät usein vasta pitkän käyttöjakson jälkeen.
Automatisoitua testiä ei välttämättä tarvitse kasvattaa äärimmäisiin kuormiin (rasitustestaus kattaa sen). Olemme kuitenkin erityisen kiinnostuneita järjestelmän kyvystä kestää jatkuvaa suoritusta, jossa suoritetaan monenlaisia testitapahtumia, jotta voidaan havaita mahdolliset vaikeasti havaittavat muistivuodot, lukitukset tai kilpailutilanteet.
More Articles
Palvelunhallinnan testaus
Lopuksi muutama sana palvelunhallinnan testauksesta.
Kun palvelu otetaan käyttöön tuotannossa, sitä on hallittava. Palvelun pitäminen toiminnassa ja käynnissä edellyttää sen valvontaa, päivittämistä, varmuuskopiointia ja nopeaa korjaamista, kun jokin menee vikaan.
Palvelunhallinnoijien käyttämät menettelyt päivitysten, varmuuskopioiden, julkaisujen ja vikatilanteista palautumisen suorittamiseen ovat ratkaisevan tärkeitä luotettavan palvelun tarjoamisessa, joten ne on testattava erityisesti silloin, jos palvelu muuttuu nopeasti käyttöönoton jälkeen.
Erityisesti käsiteltävät ongelmat ovat:
- Menettelyt eivät tuota haluttua vaikutusta.
- Menettelyt eivät ole toteuttamiskelpoisia tai käyttökelpoisia.
- Menettelyt häiritsevät tuotannossa olevaa palvelua.
Testit olisi suoritettava mahdollisuuksien mukaan mahdollisimman realistisella tavalla.
Ajatuksia herättävää
Jotkin järjestelmät ovat alttiita äärimmäisille kuormille tietyn tapahtuman sattuessa. Esimerkiksi verkkoliiketoiminta voi odottaa kuormitushuippuja heti sen jälkeen, kun tarjouksia mainostetaan televisiossa, tai kansallinen uutissivusto voi ylikuormittua, kun tapahtuu jokin suuri uutinen.
Ajattele tuntemaasi järjestelmää, johon liiketoiminnassasi tai kansallisissa uutisissa ilmenneet suunnittelemattomat häiriöt ovat vaikuttaneet.
Mitkä häiriöt tai tapahtumat voisivat aiheuttaa järjestelmässäsi ylimääräisiä kuormitushuippuja?
Voitko (tai voisitko) kerätä järjestelmälokeista tietoja, joista käy ilmi suoritettujen tapahtumien määrä? Voitko skaalata tämän tapahtuman ennustamaan kerran 100 vuodessa tai kerran 1 000 vuodessa tapahtuvan kriittisen tapahtuman?
Mitä toimenpiteitä voisit toteuttaa (tai olet toteuttanut) joko vähentääksesi huippujen todennäköisyyttä tai niiden suuruutta tai poistaaksesi ne kokonaan?
Tilaa The QA Lead -uutiskirje, niin saat ilmoituksen, kun sarjan uudet osat 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 teet niin, käytä eksklusiivista kuponkikoodiamme QALEADOFFER ja saat 60 dollaria alennusta kurssin täydestä hinnasta!
Suositeltavaa luettavaa: 10 PARASTA AVOIMEN LÄHDEKOODIN TESTAUKSENHALLINTATYÖKALUA



