Liotustestaus
Liotustestaus on eräänlainen ei-toiminnallinen testaus, jota käytetään mittaamaan ohjelmistosovelluksen suorituskykyä valtavan kuormituksen alla pitkään. Soak-testauksen tavoitteena on varmistaa, että ohjelmistosovellus ylläpitää suurta käyttöä, ja tarkistaa, mitä tapahtuisi sen suunnittelun odotusten ulkopuolella.
Alla oleva kuva kuvaa testaussykliä, joka osoittaa, missä vaiheessa liotustestaus ( suorituskykytestin tyyppi ) suoritetaan sovellukselle.
Tämäntyyppisessä testauksessa valvotaan periaatteessa järjestelmän muistin käyttöä. Se testaa järjestelmätasolla selvittääkseen, kestääkö järjestelmä erittäin suuren käyttöasteen ja mitä tapahtuisi sen suunnittelun odotusten ulkopuolella.
Tässä opetusohjelmassa opit-
- Miksi liotustestaus?
- Milloin tehdä liotustestaus?
- Liotustestausstrategia
- Liotustestien ominaisuudet
- ESIMERKIT liotustestistä
- Liotustestien aikana havaitut yleiset ongelmat
Miksi liotustestaus?
Järjestelmä voi käyttäytyä normaalisti, kun sitä käytetään 2 tuntia, mutta kun samaa järjestelmää käytetään jatkuvasti vähintään 10 tuntia, se voi epäonnistua tai käyttäytyä epänormaalisti / satunnaisesti / se voi kaatua. Tällaisen vian ennustamiseksi suoritetaan liotustesti.
Milloin tehdä liotustestaus?
Liotustestaus tulisi tehdä seuraavissa tilanteissa: -
- Ennen sisäänrakennetun käyttöönottoa asiakkaalle, ts. Ennen minkä tahansa sovelluksen julkaisua tietylle alustalle, sen on läpäistävä onnistunut sarja kuormitustestejä korkeilla tai vastaavilla liikennetasoilla. Sen jälkeen suoritetaan liotuskoe . Se auttaa meitä määrittämään, kuinka tiettyä sovellusta suoritetaan pitkään. Jos muistivuotoja / muistivirheitä havaitaan ajanjaksona eli kun se on Soak-tilassa, siitä on ilmoitettava välittömästi.
- Paras aika tehdä liotuskoe on viikonloppuisin, koska sovelluksen on oltava käynnissä niin kauan kuin yli päivän tai yön. Se riippuu täysin testaustilanteen rajoituksista. Liotustestit ovat yksi tärkeimmistä vaatimustenmukaisuusvaatimuksista, joita jokaisen yrityksen on noudatettava erittäin tiukasti.
Liotustestausstrategia
Pitkän istunnon liotustestaus on strategia, jossa järjestelmää kuormitetaan pidempään.
Yksinkertainen esimerkki on, että käyttäjä pysyy kirjautuneena järjestelmään useita tunteja suorittamalla useita liiketoimia. Tällä tavalla luodaan paljon dataa. Järjestelmässä / tietokantapalvelimessa voi olla paljon kuormitusta, mikä voi johtaa järjestelmän / tietokantapalvelimen jumittumiseen / kaatumiseen.
Pitkän istunnon liotustestauksessa useita päiviä (sanotaan 30 päivää) suoritetaan rajoitetusti (esimerkiksi 2 päivää). Tapahtumien lukumäärän tässä rajoitetussa aikataulussa on vastattava tai ylitettävä useiden päivien tapahtumien arvo. Painopiste tulisi olla käsiteltyjen tapahtumien määrässä. Liotustestin tärkein osa on tarkistaa suorittimen käytettävissä oleva muisti ja käytössä olevan muistin määrä. Meidän on tallennettava muistin käyttö liotustestin alussa ja lopussa. Tarvittaessa myös Java-virtuaalikoneiden kaltaisten laitteiden muistin käyttö on tärkeää ja sitä on seurattava.
Alla on muutama tarkistus, joka käyttäjän / testaajan on tehtävä ennen liotustestausta:
a) Seuraa tietokannan resurssien kulutusta.
b) Seuraa palvelimen resurssien kulutusta (entinen suorittimen käyttö).
c) Liotuskoe tulisi suorittaa realistisella käyttäjän samanaikaisuudella.
Liotustestien ominaisuudet
Tavallisella liotustestimenetelmällä tulisi olla seuraavat ominaisuudet: -
- Useimpien liotustestien kesto määräytyy usein käytettävissä olevan ajan mukaan.
- Kaikkien sovellusten on oltava käynnissä keskeytyksettä, jos ne vaativat pidemmän ajan.
- Sen tulisi kattaa kaikki skenaariot, joista sidosryhmät ovat sopineet.
- Enimmäkseen jokaisella järjestelmällä on säännöllinen huoltoikkunan aikajakso, ja aika tällaisten ikkunajaksojen välillä on avainasemassa liotustestin laajuuden määrittämisessä.
ESIMERKIT liotustestistä
- Jos pankkitoimialue on suuri määrä kauppiailta, testaaja asettaa järjestelmän jatkuvasti kuormitettavaksi 70–150 tunniksi tarkistaakseen, miten sovellus käyttäytyy tänä latausjaksona.
- Oletetaan, että järjestelmän kautta on 33 000 kirjautumistunnusta, mikä tarkoittaa seitsemän ja puolen päivän toimintaa. Tässä tapauksessa 60-70 tunnin liotuskoe voidaan aloittaa perjantai-iltana noin klo 18, joka voidaan suorittaa maanantaiaamuna kello 6.00. Vain tällaisen testin avulla on mahdollista havaita suorituskyvyn heikkeneminen valvotuissa olosuhteissa.
- Videopelien tapauksessa mobiilisovellukset jne. Sisältävät pelin tai sovelluksen jättämisen käyttötilaan pitkäksi ajaksi eri toimintatiloissa - kuten tyhjäkäynnillä, keskeytettynä otsikkonäytössä ja niin edelleen selvittääkseen, onko sovellus pystyy käsittelemään jatkuvasti odotettua kuormitusta.
Liotustestien aikana havaitut yleiset ongelmat
- Muistin allokointi (muistivuodot, jotka johtavat lopulta muistikriisiin tai pyöristysvirheisiin, jotka ilmenevät vain ajan myötä).
- Tietokannan resurssien käyttö (tietokannan osoittimien sulkemisen epäonnistuminen joissakin olosuhteissa, mikä lopulta johtaa koko järjestelmän jumittumiseen).
- Se voi myös johtaa suorituskyvyn heikkenemiseen eli varmistaa, että vasteaika pitkän jatkuvan toiminnan jälkeen on yhtä hyvä kuin se oli testin alussa.
- Epäonnistuminen monitasoisen järjestelmän tasojen välisten yhteyksien sulkemisessa joissakin olosuhteissa, mikä saattaa estää järjestelmän osan tai kaikki moduulit.
- Joidenkin toimintojen vasteajan asteittainen heikkeneminen, kun sisäiset tietorakenteet eivät ole yhtä tehokkaita pitkän testin aikana.
Yhteenveto
- Ohjelmistotuotannossa tehdään liotustestaus sen selvittämiseksi, pystyykö testattava sovellus kestämään jatkuvaa kuormitusta.
- Se on eräänlainen suorituskykytesti.
- Se auttaa järjestelmää selvittämään, kestääkö se erittäin suuren käyttömäärän
- Tämäntyyppisessä testauksessa seurataan periaatteessa järjestelmän muistin käyttöä
- Tarkistukset, jotka jokaisen käyttäjän / testaajan on tehtävä ennen liotustestauksen aloittamista, ovat
- Seuraa tietokannan resurssien kulutusta.
- Seuraa palvelimen resurssien kulutusta (entinen suorittimen käyttö).
- Liotustestin tulisi toimia realistisella käyttäjän samanaikaisuudella.
Tämän artikkelin on kirjoittanut Pallavi De