Leotustest tarkvaras: tähendus ja näited
Thomas Hamilton
⚡ Nutikas kokkuvõte
Soak Testing rakendab rakendusele pikema aja jooksul püsivat ja realistlikku koormust, et paljastada probleeme, mis ilmnevad alles aja jooksul. Mälu lekked, ühenduste ammendumine ja aeglase jõudluse triiv on defektid, mida see on loodud avastama.
Mis on leotamise testimine?
Leotamise testimine on mittefunktsionaalse testimise tüüp, mida kasutatakse tarkvararakenduse jõudluse mõõtmiseks suure koormuse korral pikema aja jooksul. Soak-testimise eesmärk on tagada, kas tarkvararakendus püsib suure kasutusmahuga, ja kontrollida, mis juhtuks väljaspool selle disaini ootusi.
Allolev pilt kujutab testimistsüklit, mis näitab, millises etapis leotuskatse (Jõudluskatse tüüp) tehakse rakendusel.
Seda tüüpi testimise puhul jälgitakse põhiliselt süsteemi rakenduse mälukasutust. See testib süsteemi tasemel, et teha kindlaks, kas süsteem peab vastu väga suurele kasutusmahule ja näha, mis juhtuks väljaspool selle disaini ootusi.
Miks leotamise testimist teha?
Süsteem võib käituda normaalselt, kui seda kasutatakse 2 tundi, kuid kui sama süsteemi kasutatakse pidevalt 10 tundi või kauem, võib see ebaõnnestuda või käituda ebaharilikult/juhuslikult/jooksuda. Sellise rikke ennustamiseks viiakse läbi leotuskatse.
Millal teha leotamise testi?
Leotamiskatse tuleks teha järgmistel juhtudel: –
- Enne ehitatud rakenduse kliendile juurutamist, st enne mis tahes rakenduse avaldamist konkreetsel platvormil, peab see läbima eduka koormustestide seeria kõrgel või samaväärsel liiklustasemel. Peale seda tehakse leotuskatse. See aitab meil kindlaks teha, kuidas mõnda konkreetset rakendust pikema aja jooksul käivitada. Kui perioodil, st kui see on Soakis, leitakse selliseid probleeme nagu mälulekked/mälu riknemine, tuleb sellest kohe teatada.
- Parim aeg leotuskatse tegemiseks on nädalavahetused, kuna rakendus peab töötama nii kaua kui päev või öö. See sõltub täielikult testimisolukorra piirangutest. Leotustestid on üks olulisemaid vastavusnõudeid, mida iga ettevõte peab väga rangelt järgima.
Leotamise testimise strateegia
Long Session Soak Testing on strateegia, kus süsteem on pikemat aega koormatud.
Lihtne näide on see, kus kasutaja jääb mitmeks tunniks süsteemi sisse logitud, sooritades mitmeid äritehinguid. Sel viisil luuakse palju andmeid. Süsteemil/andmebaasiserveril võib olla palju koormust, mis võib põhjustada süsteemi/andmebaasiserveri seiskumise/krahhi.
Pika seansi leotamise testimise korral tehakse mitu päeva (näiteks 30 päeva) tegevust piiratud aja jooksul (näiteks 2 päeva). Tehingute arv selle piiratud aja jooksul peaks vastama mitme päeva tehingutele või ületama seda. Tähelepanu tuleks pöörata töödeldud tehingute arvule. Leotamise testimise kõige olulisem osa on kontrollida protsessoris saadaolevat mälu ja kasutatava mälumahtu. Peame salvestama mälukasutuse leotustesti alguses ja lõpus. Vajadusel siis selliste rajatiste mälukasutust nagu Java Virtuaalmasinad on samuti olulised ja neid tuleb jälgida.
Allpool on veel mõned kontrollid, mida iga kasutaja/testija peab enne leotustestiga alustamist läbi viima.
a) Jälgige andmebaasi ressursside tarbimist.
b) Jälgige serveri ressursitarbimist (va CPU kasutus).
c) Leotamise test peaks toimuma kasutajate realistliku samaaegsusega.
Leotamise testimise omadused
Standardsel leotamise katsemeetodil peaksid olema järgmised omadused:
- Enamiku leotustestide kestus määratakse sageli olemasoleva aja järgi.
- Iga rakendus peab töötama ilma katkestusteta, kui see nõuab pikemat aega.
- See peaks hõlmama kõiki stsenaariume, milles sidusrühmad on kokku leppinud.
- Enamasti on igal süsteemil regulaarne hooldusakna periood ja selliste akende vaheline aeg on leotustesti ulatuse määramisel peamine tegur.
Leotestimise näited
- Pangandusdomeeni puhul, kus kaupmeestelt on palju andmeid, laadib tester süsteemi pidevalt 70–150 tunniks, et kontrollida, kuidas rakendus sellel laadimisperioodil käitub.
- Oletame, et on 33,000 60 sisselogimist, mis tuleb süsteemist läbi viia, see tähistab seitset ja poolt päeva tegevust. Sel juhul võib reede õhtuks kella 70 paiku alustada 6-XNUMX-tunnise leotustestiga, mille saab lõpetada Monday hommikul kell 6 hommikul. Ainult sellise testiga on kontrollitud tingimustes võimalik jälgida toimivuse halvenemist.
- Videomängude puhul mobiilne rakendused jne hõlmavad mängu või rakenduse jätmist pikemaks ajaks töötavasse olekusse, erinevates töörežiimides – näiteks tühikäigul, pealkirjakuval peatatud jne, et teada saada, kas rakendus suudab pidevalt oodatava koormusega hakkama .
Leotamiskatse ajal täheldatud tavalised probleemid
- Mälu eraldamine (mälu lekked, mis võivad lõpuks põhjustada mälukriisi või ümardamisvigu, mis ilmnevad ainult aja jooksul).
- Andmebaasi ressursside kasutamine (andmebaasi kursorite sulgemata jätmine teatud tingimustel, mis võib lõpuks põhjustada kogu süsteemi seiskumise).
- See võib viia ka jõudluse halvenemiseni, st tagada, et reaktsiooniaeg pärast pikka pidevat tegevust on sama hea kui testi alguses.
- Mitmetasandilise süsteemi tasandite vaheliste ühenduste sulgemine teatud asjaoludel, mis võib mõne või kõik süsteemi moodulid seiskuda.
- Mõnede funktsioonide reaktsiooniaja järkjärguline halvenemine sisemiste andmestruktuuride tõttu muutub pika testi ajal vähem tõhusaks.
Kuidas see test sobib jõudlustestide perekonda
Jõudlustestid on üldmõiste. Allpool loetletud variandid erinevad ainult rakendatava koormuse kuju ja selle kestuse poolest, mistõttu neid nii sageli segamini aetakse.
| Katse tüüp | Koormusmuster | Küsimus, millele see vastab |
|---|---|---|
| Koormustestimine | Eeldatav tippkoormus, lühiajaline | Kas süsteem saavutab oma eesmärgid tavapärase tippkoormuse korral? |
| Stressitestimine | Suurendatud üle võimekuse kuni rikkeni | Kus see puruneb ja kas see puruneb graatsiliselt? |
| Spike testimine | Äkiline äärmuslik tõus, seejärel võõrutusnähud | Kas see jääb ellu ja taastub liiklusšoki järel? |
| Vastupidavuse testimine | Tavaline koormus, mida hoitakse mitu tundi | Kas jõudlus aja jooksul halveneb? |
| Leotustestimine | Pidev koormus pikema aja jooksul | Kas esineb mälulekkeid või ressursside ammendumist? |
| Stabiilsuse testimine | Erinev koormus erinevates tingimustes | Kas süsteem jääb töökindlaks ka muutuvate tingimuste korral? |
| Mahu testimine | Tavakasutajad, väga suur andmemaht | Kas see saab andmebaasi kasvades hakkama? |
Vastupidavus- ja leotuskatseid käsitletakse sageli sünonüümidena. Üldkasutuses on need järgmised: mõlemad hoiavad pikka aega püsivat koormust. Seal, kus meeskonnad neid eristavad, keskendub vastupidavustestimine sellele, kas reageerimisajad pikenevad, samas kui leotustestimine keskendub ressursside tarbimisele, näiteks mälule, failikäepidemetele ja ühenduste kogumitele. Ühe käivitamine annab tavaliselt tõendeid mõlema kohta.
Testi ajal kogutavad peamised mõõdikud
Jõudluskäivituse kvaliteet sõltub sellest, mida sa selle käivitamise ajal salvestad. Salvesta need kuus tulemust serveri ja kliendi poolel ning võrdle neid seejärel pigem algtaseme kui kõhutunde põhjal.
| meetriline | Mida see teile ütleb | Hoiatusmärk |
|---|---|---|
| Keskmine reageerimisaeg | Tüüpiline kasutajakogemus | Igasugune ülespoole triiv jooksu ulatuses |
| 95. protsentiili reageerimisaeg | Kõige aeglasemate kasutajate kogemus | Kaugel üle keskmise, mis tähendab ebajärjekindlust |
| Läbilaskevõime | Sekundis töödeldud päringuid | Langeb, kui koormus jääb konstantseks |
| Veamäär | Ebaõnnestunud või aegunud taotluste osakaal | Igasugune tõus üle kokkulepitud läve |
| Protsessori ja mälu kasutamine | Serveri ressursi reserv | Mälu, mis ronib ja ei naase enam kunagi |
| Andmebaasiühendused ja lõimed | Basseini kurnatus | Loendused, mis kasvavad pidevalt ilma vabastamiseta |
Loe keskmist ja protsentiili koos. Keskmine 800 ms 95. protsentiiliga 900 ms kirjeldab järjepidevat süsteemi. Sama keskmine 95. protsentiiliga 9 sekundit tähendab, et ühel kahekümnest kasutajast on halb olla ja keskmine varjab seda.
Jälgi kuju, mitte ainult väärtust. Mis tahes pikas testis on lame ressursijoon läbitud ja tõusev joon leke, isegi kui absoluutarv on testi lõppedes endiselt mugavalt piiri sees.
