Test namakanja u softveru: značenje i primjeri

⚡ Pametni sažetak

Soak Testiranje primjenjuje kontinuirano, realistično opterećenje na aplikaciju tijekom duljeg razdoblja kako bi otkrilo probleme koji se pojavljuju tek s vremenom. Curenje memorije, iscrpljenost veze i sporo pomicanje performansi su nedostaci koje je dizajnirano otkriti.

🕒 Dugo trajanje: Realno opterećenje koje se držalo satima ili danima, a ne kratkotrajno.
💧 osnovni Target: Curenje memorije i bilo koji resurs koji je dodijeljen, ali nikada nije oslobođen.
📉 Provjera degradacije: Vrijeme odziva mora ostati ravnomjerno tijekom cijelog razdoblja, ne samo dobro započeti.
🗄️ Fokus baze podataka: Ovdje se pojavljuju skupovi veza, otvoreni kursori i rastuće tablice dnevnika.
⏰ Realističan vremenski raspored: Uključite zakazane zadatke i serijska razdoblja koja se događaju tijekom razdoblja namakanja.
📊 Pravilo presude: Ravna krivulja resursa prolazi; stalno rastuća ne uspijeva čak ni unutar ograničenja.

Pročitaj više

Što je Soak Test?

Ispitivanje namakanja je vrsta nefunkcionalnog testiranja koja se koristi za mjerenje performansi softverske aplikacije pod velikim opterećenjem tijekom duljeg vremenskog razdoblja. Cilj Soak testiranja je provjeriti održava li softverska aplikacija veliku količinu korištenja i provjeriti što bi se dogodilo izvan očekivanja njezinog dizajna.

Slika u nastavku prikazuje ciklus testiranja koji pokazuje u kojoj je fazi testiranje namakanja (Vrsta testa izvedbe) izvodi se na aplikaciji.

U ovoj vrsti testiranja ono što se u osnovi nadzire je korištenje memorije od strane aplikacije u sustavu. To je testiranje na razini sustava, kako bi se utvrdilo hoće li sustav izdržati vrlo visoku količinu korištenja i vidjeti što bi se dogodilo izvan njegovih projektiranih očekivanja.

Zašto testirati natapanje?

Sustav se može ponašati normalno kada se koristi 2 sata, ali kada se isti sustav neprekidno koristi 10 sati ili više od toga, može zakazati ili se ponašati nenormalno/nasumično/može se srušiti. Kako bi se predvidio takav kvar, provodi se testiranje namakanja.

Kada provesti testiranje natopljenosti?

Ispitivanje natopljenosti treba provesti u sljedećim scenarijima: –

Prije nego što se ugrađeni implementira na klijenta, tj. prije izdavanja bilo koje aplikacije na određenoj platformi, treba proći kroz uspješnu seriju testova opterećenja na visokim ili ekvivalentnim razinama prometa. Nakon toga provodi se ispitivanje natopljenosti. Pomaže nam odrediti kako pokrenuti bilo koju aplikaciju kroz dulje razdoblje. Ako se problemi poput curenja memorije/oštećenja memorije pronađu tijekom razdoblja, tj. dok je na Soak-u, tada to treba odmah prijaviti.
Najbolje vrijeme za provođenje testiranja usisavanja je tijekom vikenda jer aplikacija mora biti u aktivnom stanju čak i preko dana ili noći. To u potpunosti ovisi o ograničenjima situacije testiranja. Ispitivanja upijanja jedan su od najvažnijih zahtjeva sukladnosti koje svaka tvrtka mora vrlo strogo slijediti.

Strategija testiranja namakanja

Dugotrajno testiranje usisavanja je strategija u kojoj je sustav pod opterećenjem dulje vrijeme.

Jednostavan primjer je kada korisnik ostaje prijavljen u sustav mnogo sati izvršavajući niz poslovnih transakcija. Na taj način se stvara mnogo podataka. Može doći do velikog opterećenja sustava/poslužitelja baze podataka što može dovesti do zaustavljanja/pada sustava/poslužitelja baze podataka.

Pod dugotrajnim testiranjem natapanja, višednevne aktivnosti (recimo 30 dana) izvode se u ograničenom vremenskom okviru (recimo 2 dana). Broj transakcija u ovom ograničenom vremenskom okviru trebao bi odgovarati ili premašiti višednevne transakcije. Fokus bi trebao biti na broju obrađenih transakcija. Najvažniji dio Soak Testinga je provjera dostupne memorije u CPU-u i količine memorije koja će se koristiti. Moramo zabilježiti korištenje memorije na početku i na kraju testa upijanja. Ako je potrebno, onda korištenje memorije objekata kao što su Java Virtualni strojevi također su važni i potrebno ih je nadzirati.

Ispod je još nekoliko provjera koje svaki korisnik/tester mora obaviti prije nego započne s testiranjem natapanja:

a) Pratiti potrošnju resursa baze podataka.

b) Pratite potrošnju resursa poslužitelja (ex-CPU upotreba).

c) Soak test trebao bi se izvoditi uz realnu korisničku konkurentnost.

Karakteristike ispitivanja natopljenosti

Standardna metoda ispitivanja natopljenosti trebala bi imati sljedeće karakteristike: –

Trajanje većine Soak testa često je određeno raspoloživim vremenom.
Svaka aplikacija mora raditi bez ikakvih prekida ako zahtijeva dulje vremensko razdoblje.
Trebao bi obuhvatiti sve scenarije oko kojih su se dionici složili.
Uglavnom svaki sustav ima redovno vremensko razdoblje održavanja, a vrijeme između takvih razdoblja ključni je pokretač za određivanje opsega testa natapanja.

Primjeri ispitivanja namakanjem

U slučaju bankovne domene kada postoji velika količina podataka od trgovaca, tester će staviti sustav pod kontinuirano opterećenje od 70 do 150 sati kako bi provjerio kako se aplikacija ponaša tijekom tog perioda učitavanja.
Pretpostavimo da postoji 33,000 prijava, koje treba provesti kroz sustav, to predstavlja sedam i pol dana aktivnosti. U tom slučaju, 60-70 sati Soak Testa može se započeti do petka navečer oko 6 sati, a može se završiti do Monday ujutro u 6 sati. Samo s takvim testom bit će moguće uočiti pogoršanje performansi u kontroliranim uvjetima.
U slučaju video igara, Kontakt broj aplikacije, itd. uključuju ostavljanje igre ili aplikacije u pokrenutom stanju dulje vremensko razdoblje, u različitim načinima rada - kao što je mirovanje, pauza na naslovnom zaslonu i tako dalje kako bi se saznalo može li aplikacija podnijeti kontinuirano očekivano opterećenje .

Uobičajeni problemi uočeni tijekom testiranja namakanja

Dodjela memorije (curenje memorije koje bi na kraju rezultiralo krizom memorije ili pogreškama zaokruživanja koje se manifestiraju tek s vremenom).
Korištenje resursa baze podataka (neuspjeh zatvaranja pokazivača baze podataka pod nekim uvjetima što bi na kraju rezultiralo zaustavljanjem cijelog sustava).
To također može dovesti do degradacije performansi, tj. osigurati da je vrijeme odziva nakon dugog razdoblja kontinuirane aktivnosti onoliko dobro koliko je bilo na početku testa.
Neuspjeh zatvaranja veza između razina višeslojnog sustava pod određenim okolnostima koje bi mogle zaustaviti neke ili sve module sustava.
Postupna degradacija vremena odgovora nekih funkcija jer unutarnje strukture podataka postaju manje učinkovite tijekom dugog testa.

Kako se ovaj test uklapa u obitelj testiranja performansi

Ispitivanje performansi je krovni pojam. Varijante u nastavku razlikuju se samo po obliku primijenjenog opterećenja i trajanju njegovog održavanja, zbog čega se tako često miješaju.

Vrsta ispitivanja	Uzorak opterećenja	Pitanje na koje odgovara
Ispitivanje opterećenja	Očekivano vršno opterećenje, kratko trajanje	Ostvaruje li sustav svoje ciljeve pod normalnim vršnim prometom?
Ispitivanje napona	Povećano preko kapaciteta do kvara	Gdje se lomi i otkazuje li graciozno?
Ispitivanje šiljaka	Iznenadni ekstremni porast, a zatim povlačenje	Preživljava li i oporavlja li se od prometnog šoka?
Ispitivanje izdržljivosti	Normalno opterećenje održavano mnogo sati	Smanjuje li se performansa s vremenom?
Ispitivanje namakanjem	Trajno opterećenje tijekom duljeg razdoblja	Ima li curenja memorije ili iscrpljivanja resursa?
Ispitivanje stabilnosti	Promjenjivo opterećenje u različitim uvjetima	Ostaje li sustav pouzdan kako se uvjeti mijenjaju?
Ispitivanje volumena	Obični korisnici, vrlo velika količina podataka	Snalazi li se s rastom baze podataka?

Ispitivanje izdržljivosti i ispitivanje namakanjem često se tretiraju kao sinonimi. U uobičajenoj upotrebi su: oba drže kontinuirano opterećenje dulje vrijeme. Tamo gdje ih timovi razlikuju, testiranje izdržljivosti fokusira se na to povećava li se vrijeme odziva, dok se testiranje soak-a fokusira na potrošnju resursa kao što su memorija, ručke datoteka i skupovi veza. Pokretanje jednog obično daje dokaze za oboje.

Ključne metrike koje treba pratiti tijekom testiranja

Izvođenje testa performansi je onoliko dobro koliko i ono što snimite dok se izvršava. Snimite ovih šest na strani poslužitelja i klijenta, a zatim ih usporedite s osnovnom linijom, a ne s intuicijom.

metrički	Što vam govori	Znak upozorenja
Prosječno vrijeme odziva	Tipično korisničko iskustvo	Bilo kakvo pomicanje prema gore preko staze
Vrijeme odgovora 95. percentila	Iskustvo najsporijih korisnika	Daleko iznad prosjeka, što znači nedosljednost
propusnost	Zahtjevi obrađeni u sekundi	Pad dok opterećenje ostaje konstantno
Stopa pogreške	Udio neuspjelih ili isteklih zahtjeva	Svaki porast iznad dogovorenog praga
Korištenje CPU-a i memorije	Prostor za resurse poslužitelja	Sjećanje koje se penje i nikad se ne vraća
Veze i niti baze podataka	Iscrpljenost bazena	Brojevi koji stalno rastu bez otpuštanja

Pročitajte prosjek i percentil zajedno. Prosjek od 800 ms s 95. percentilom od 900 ms opisuje konzistentan sustav. Isti prosjek s 95. percentilom od 9 sekundi znači da se jedan korisnik od dvadeset loše provodi, a prosjek to skriva.

Pazite na oblik, ne samo na vrijednost. U bilo kojem dugotrajnom testu, ravna linija resursa je prolaz, a rastuća je curenje, čak i kada je apsolutni broj još uvijek udobno unutar ograničenja u trenutku završetka testa.

Pitanja i odgovori

U uobičajenoj upotrebi to dvoje je isto. Tamo gdje ih timovi razlikuju, testiranje izdržljivosti prati pomicanje vremena odziva, dok testiranje namakanja prati potrošnju resursa. Jedno testiranje obično pruža dokaze za oboje.

Dovoljno dugo da pokrije barem jedan puni poslovni ciklus, obično od 8 do 72 sata. Izvođenje mora uključivati sve planirane batch zadatke ili noćne procese, budući da oni često uzrokuju curenje.

Krivulja memorije koja stalno raste i nikada se ne vraća na svoju raniju razinu nakon sakupljanja smeća. Apsolutna vrijednost je manje važna od nagiba: svaki dosljedan uzlazni trend je nedostatak.

Praćenje temeljeno na umjetnoj inteligenciji analizira sate telemetrije i označava točnu točku u kojoj se trend mijenja, što je nepraktično ručno uočiti na tisućama podatkovnih točaka.

Djelomično. Modeli mogu ekstrapolirati trend resursa i ranije predvidjeti iscrpljenost, ali predviđanje i dalje zahtijeva stvarno testiranje kako bi se potvrdilo prije donošenja odluke o puštanju u promet.