Áztatási teszt szoftverben: Jelentés és példák
Thomas Hamilton
⚡ Okos összefoglaló
A beázásos tesztelés tartós, valós terhelést jelent egy alkalmazásra hosszabb időn keresztül, hogy feltárja azokat a problémákat, amelyek csak idővel jelentkeznek. A memóriaszivárgások, a kapcsolat kimerülése és a lassú teljesítményeltolódás azok a hibák, amelyeket kiszűrni hivatott.
Mi az az áztatási teszt?
Áztatási tesztelés a nem funkcionális tesztelés egy fajtája, amelyet egy szoftveralkalmazás teljesítményének mérésére használnak nagy terhelés mellett, hosszabb ideig. A Soak tesztelés célja annak biztosítása, hogy a szoftveralkalmazás nagy mennyiségben használható-e, és hogy ellenőrizze, mi történik a tervezési elvárásain kívül.
Az alábbi kép egy tesztelési ciklust mutat be, amely megmutatja, hogy az áztatási teszt (A teljesítményteszt típusa) alkalmazáson hajtják végre.
Az ilyen típusú tesztelés során alapvetően egy rendszerben lévő alkalmazás memóriahasználatát figyelik. Rendszerszinten teszteli, hogy megtudja, kibírja-e a rendszer nagyon nagy mennyiségű felhasználást, és hogy megnézze, mi történik a tervezési elvárásain kívül.
Miért végezzünk áztatási tesztet?
Egy rendszer normálisan viselkedhet 2 órás használat esetén, de ha ugyanazt a rendszert 10 órán keresztül folyamatosan használják, akkor meghibásodhat, vagy rendellenesen/véletlenszerűen viselkedik/összeomolhat. Az ilyen meghibásodás előrejelzésére áztatási tesztet kell végezni.
Mikor kell beáztatási tesztet végezni?
Az átitatási tesztet a következő forgatókönyvek szerint kell elvégezni: –
- Mielőtt a buildet üzembe helyezné az ügyfélen, azaz mielőtt egy adott platformon bármilyen alkalmazást kiadnának, sikeres terhelési tesztsorozaton kell keresztülmennie magas vagy azzal egyenértékű forgalmi szinten. Ezek után áztatási vizsgálatot végeznek. Segít meghatározni, hogyan futtassunk egy adott alkalmazást hosszabb ideig. Ha olyan problémákat észlel, mint például memóriaszivárgás/memóriasérülés az adott időszakban, azaz amikor a Soak állapotban van, akkor azonnal jelenteni kell.
- Az áztatási teszt elvégzésére a legalkalmasabb a hétvége, mivel az alkalmazásnak akár egy napig vagy éjszakán át működő állapotban kell lennie. Ez teljes mértékben a tesztelési helyzet korlátaitól függ. Az áztatási tesztek az egyik legfontosabb megfelelési követelmény, amelyet minden cégnek nagyon szigorúan be kell tartania.
Áztatási tesztelési stratégia
A Long Session Soak Testing olyan stratégia, ahol a rendszer hosszabb ideig terhelés alatt van.
Egy egyszerű példa az, amikor a felhasználó több órán keresztül bejelentkezve marad a rendszerbe, és számos üzleti tranzakciót hajt végre. Ily módon rengeteg adat jön létre. A rendszer/adatbázis-kiszolgáló nagy terhelést jelenthet, ami a rendszer/adatbázis-kiszolgáló leállását/összeomlását eredményezheti.
A Long Session Soak Testing alatt több napos (mondjuk 30 napos) tevékenységeket hajtanak végre korlátozott időkeretben (mondjuk 2 nap). A tranzakciók számának ebben a korlátozott időkeretben meg kell egyeznie vagy meg kell haladnia a több napos tranzakciók számát. A hangsúlyt a feldolgozott tranzakciók számára kell helyezni. A Soak Testing legfontosabb része a CPU-ban rendelkezésre álló memória és a használatban lévő memória mennyiségének ellenőrzése. Fel kell jegyeznünk a memóriahasználatot az áztatási teszt elején és végén. Ha szükséges, akkor az olyan létesítmények memóriahasználatát, mint pl Java A virtuális gépek szintén fontosak, és figyelni kell őket.
Az alábbiakban felsorolunk néhány további ellenőrzést, amelyeket minden felhasználónak/tesztelőnek el kell végeznie, mielőtt elkezdené az áztatási tesztet:
a) Figyelje az adatbázis erőforrás-felhasználását.
b) Figyelje a szerver erőforrás-felhasználását (kivéve a CPU-használatot).
c) Az áztatási tesztnek reális felhasználói párhuzamossággal kell futnia.
Az áztatási vizsgálat jellemzői
A szabványos beázási vizsgálati módszernek a következő jellemzőkkel kell rendelkeznie: –
- A legtöbb áztatási teszt időtartamát gyakran a rendelkezésre álló idő határozza meg.
- Minden alkalmazásnak megszakítás nélkül kell futnia, ha hosszabb ideig tart.
- Ki kell terjednie az érdekelt felek által elfogadott összes forgatókönyvre.
- Többnyire minden rendszernek van egy rendszeres karbantartási időszaka, és az ilyen időszakok közötti idő kulcsfontosságú tényező a beázási teszt hatókörének meghatározásában.
Áztatásos tesztelés példái
- Banki tartomány esetén, amikor nagy mennyiségű adat érkezik a kereskedőktől, a tesztelő 70-150 óráig folyamatosan terhelés alá helyezi a rendszert, hogy ellenőrizze, hogyan viselkedik az alkalmazás ebben a betöltési időszakban.
- Tegyük fel, hogy 33,000 60 bejelentkezés van, amit át kell vinni a rendszeren, ez hét és fél napos tevékenységet jelent. Ebben az esetben péntek este 70 óra körül egy 6-XNUMX órás áztatási tesztet lehet kezdeni, amelyet Monday reggel 6 órakor. Csak egy ilyen teszttel lehet megfigyelni a teljesítmény bármilyen romlását ellenőrzött körülmények között.
- Videojátékok esetében Mobil Az alkalmazások stb. magukban foglalják a játék vagy alkalmazás futási állapotban hagyását hosszabb időre, különféle üzemmódokban – például üresjáratban, szüneteltetésben a címképernyőnél stb. .
Az áztatási teszt során megfigyelt gyakori problémák
- Memóriafoglalás (memóriaszivárgás, amely végül memóriaválságot vagy kerekítési hibákat eredményez, amelyek csak idővel jelentkeznek).
- Adatbázis-erőforrás kihasználtság (Az adatbázis-kurzorok bezárásának elmulasztása bizonyos feltételek mellett, ami végül a teljes rendszer leállását eredményezi).
- Ez a teljesítmény romlásához is vezethet, vagyis annak biztosítására, hogy a válaszidő hosszú ideig tartó tevékenység után olyan jó legyen, mint a teszt elején volt.
- A többszintű rendszer rétegei közötti kapcsolatok lezárásának elmulasztása bizonyos körülmények között, ami a rendszer néhány vagy összes modulját leállíthatja.
- Egyes funkciók válaszidejének fokozatos csökkenése, mivel a belső adatszerkezetek kevésbé hatékonyak egy hosszú teszt során.
Hogyan illeszkedik ez a teszt a teljesítménytesztelési családba
A teljesítménytesztelés egy gyűjtőfogalom. Az alábbi változatok csak az alkalmazott terhelés alakjában és annak időtartamában különböznek, ezért gyakran összekeverik őket egymással.
| Teszt típusa | Betöltési minta | Kérdés, amit megválaszol |
|---|---|---|
| Terhelési tesztelés | Várható csúcsterhelés, rövid időtartam | Eléri-e a rendszer a céljait normál csúcsforgalom mellett? |
| Stressz tesztelés | Kapacitáson túl növelve, egészen meghibásodásig | Hol törik el, és kecsesen meghibásodik? |
| Tüskék tesztelése | Hirtelen extrém hullám, majd megvonás | Túléli és felépül egy közlekedési sokk után? |
| Tartóssági vizsgálat | Normál terhelés sok órán át | Idővel romlik a teljesítmény? |
| Áztatási tesztelés | Tartós terhelés hosszabb időn keresztül | Vannak memóriaszivárgások vagy erőforrás-kimerülések? |
| Stabilitási vizsgálat | Változó terhelés a körülményektől függően | Megbízható marad-e a rendszer a változó körülmények ellenére is? |
| Térfogatvizsgálat | Átlagos felhasználók, nagyon nagy adatmennyiség | Vajon bírja az adatbázis növekedését? |
A tartóssági és az átitatási vizsgálatot gyakran szinonimaként kezelik. Gyakori használatuk szerint mindkettő hosszú ideig tartós terhelést tart. Ahol a csapatok különbséget tesznek közöttük, a tartóssági tesztelés arra összpontosít, hogy a válaszidők felfelé csúsznak-e, míg a tartóssági tesztelés az erőforrás-fogyasztásra, például a memóriára, a fájlkezelőkre és a kapcsolatkészletekre összpontosít. Az egyik futtatása általában mindkettőre bizonyítékot szolgáltat.
A teszt során rögzítendő legfontosabb mutatók
Egy teljesítményfutás csak annyira jó, mint amit futás közben rögzítesz. Rögzítsd ezt a hat adatot a szerver és a kliens oldalon, majd hasonlítsd össze őket az alapvonallal, ne pedig a megérzéseiddel.
| Metric | Mit mond neked | Figyelmeztető jel |
|---|---|---|
| Átlagos válaszidő | Tipikus felhasználói élmény | Bármilyen felfelé sodródás a pályán |
| 95. percentilis válaszidő | A leglassabb felhasználók tapasztalatai | Messze az átlag felett, ami következetlenséget jelent |
| áteresztőképesség | Másodpercenként kezelt kérések | Esés, miközben a terhelés állandó marad |
| Hibaarány | Sikertelen vagy időtúllépéses kérelmek aránya | Bármilyen emelkedés a megállapodott küszöbérték felett |
| CPU- és memóriahasználat | Szerver erőforrás-tartalék | Emlék, mely felkúszik és soha nem tér vissza |
| Adatbázis-kapcsolatok és szálak | Medence kimerülése | Olyan számok, amelyek folyamatosan növekednek kiadás nélkül |
Olvasd le az átlagot és a percentilist együtt. Egy 800 ms-os átlag 900 ms 95. percentilissel egy konzisztens rendszert ír le. Ugyanez az átlag 9 másodperces 95. percentilissel azt jelenti, hogy minden huszadik felhasználó rosszul érzi magát, és az átlag ezt elrejti.
A formára is figyelj, ne csak az értékre. Bármely hosszú ideig futó tesztben a lapos erőforrás-vonal sikeres, az emelkedő pedig szivárgást jelent, még akkor is, ha az abszolút szám a teszt végén még kényelmesen a határértéken belül van.
