Testul de imersie în software: semnificație și exemple
⚡ Rezumat inteligent
Testarea prin inmergere aplică o sarcină susținută și realistă unei aplicații pe o perioadă extinsă de timp pentru a expune problemele care apar doar în timp. Pierderile de memorie, epuizarea conexiunilor și abaterea de performanță lentă sunt defectele pe care este concepută să le detecteze.

Ce este Soak Testing?
Testarea la înmuiere este un tip de testare nefuncțională care este utilizat pentru a măsura performanța unei aplicații software sub un volum mare de încărcare pentru o perioadă lungă de timp. Scopul testării Soak este de a asigura dacă aplicația software susține un volum mare de utilizare și de a verifica ce s-ar întâmpla în afara așteptărilor sale de proiectare.
Imaginea de mai jos prezintă un ciclu de testare care arată în ce etapă este testarea la înmuiere (Tipul testului de performanță) se efectuează pe o aplicație.
În acest tip de testare, ceea ce este monitorizat practic este utilizarea memoriei de către o aplicație dintr-un sistem. Se testează la nivel de sistem, pentru a afla dacă sistemul va rezista la un volum foarte mare de utilizare și pentru a vedea ce s-ar întâmpla în afara așteptărilor sale de proiectare.
De ce faceți testarea la înmuiere?
Un sistem se poate comporta normal atunci când este utilizat timp de 2 ore, dar când același sistem este utilizat continuu timp de 10 ore sau mai mult decât atât, atunci se poate eșua sau se poate comporta anormal/aleatoriu/se poate bloca. Pentru a prezice o astfel de defecțiune, se efectuează testarea la înmuiere.
Când să faceți testarea la înmuiere?
Testarea la înmuiere ar trebui efectuată în următoarele scenarii: –
- Înainte ca proiectul să fie implementat către client, adică înainte de lansarea oricărei aplicații pe o anumită platformă, acesta trebuie să treacă printr-o serie de teste de încărcare cu succes la niveluri de trafic ridicate sau echivalente. După care se efectuează testarea la înmuiere. Ne ajută să stabilim cum să rulăm orice aplicație pentru o perioadă lungă de timp. Dacă probleme precum scurgeri de memorie/corupție de memorie sunt găsite în timpul perioadei, adică atunci când este pe Soak, atunci ar trebui raportat imediat.
- Cel mai bun moment pentru a face o testare la înmuiere este în weekend, deoarece o aplicație trebuie să fie în stare de funcționare atât timp cât o zi sau o noapte. Depinde în totalitate de limitările situației de testare. Testele de înmuiere sunt una dintre cele mai importante cerințe de conformitate care trebuie respectate cu strictețe de către fiecare companie.
Strategia de testare a înmuiării
Testarea în sesiune lungă este o strategie în care un sistem este sub încărcare pentru o perioadă mai lungă de timp.
Un exemplu simplu este cazul în care utilizatorul rămâne conectat la un sistem timp de multe ore executând o serie de tranzacții comerciale. În acest fel, sunt create o mulțime de date. Poate exista o mulțime de încărcături pe serverul de sistem/bază de date, ceea ce poate duce la blocarea/strângerea sistemului/serverul bazei de date.
În cadrul testării cu sesiune lungă, activitățile de mai multe zile (de exemplu 30 de zile) sunt efectuate într-un interval de timp restrâns (de exemplu 2 zile). Numărul de tranzacții în acest interval de timp restrâns ar trebui să se potrivească sau să depășească valoarea tranzacțiilor de mai multe zile. Accentul ar trebui să fie pus pe numărul de tranzacții procesate. Cea mai importantă parte a Soak Testing este verificarea memoriei disponibile în CPU și a cantității de memorie care va fi utilizată. Trebuie să înregistrăm utilizarea memoriei la începutul și la sfârșitul unui test de înmuiere. Dacă este necesar, atunci utilizarea memoriei unor facilități precum Java Mașinile virtuale sunt, de asemenea, importante și trebuie monitorizate.
Mai jos sunt câteva verificări care trebuie efectuate de către orice utilizator/tester înainte de a începe cu testarea la înmuiere:
a) Monitorizați consumul de resurse ale bazei de date.
b) Monitorizați consumul de resurse server (folosire CPU).
c) Testul de înmuiere ar trebui să ruleze cu concurență realistă a utilizatorului.
Caracteristicile testării la înmuiere
O metodă standard de testare la înmuiere ar trebui să aibă următoarele caracteristici: –
- Durata celor mai multe teste de înmuiere este adesea determinată de timpul disponibil.
- Orice aplicație trebuie să ruleze fără nicio întrerupere dacă necesită o perioadă prelungită de timp.
- Ar trebui să acopere toate scenariile convenite de părțile interesate.
- În cea mai mare parte, fiecare sistem are o perioadă de timp fereastră de întreținere regulată, iar timpul dintre aceste perioade de fereastră este un factor cheie pentru determinarea domeniului de aplicare a unui Test de înmuiere.
Exemple de testare prin imersie
- În cazul domeniului bancar, când există o cantitate mare de date de la comercianți, testerul va pune sistemul sub încărcare continuu timp de 70 de ore până la 150 de ore pentru a verifica cum se comportă aplicația în această perioadă de încărcare.
- Să presupunem că există 33,000 de autentificări, care trebuie introduse prin sistem, reprezintă șapte zile și jumătate de activitate. În acest caz, un test de înmuiere de 60-70 de ore poate fi început până vineri seara în jurul orei 6, care poate fi finalizat de Monday dimineata la 6 dimineata. Doar cu un astfel de test se va putea observa orice degradare a performanței în condiții controlate.
- În cazul jocurilor video, Mobil aplicații etc. implică lăsarea jocului sau a aplicației într-o stare de rulare pentru o perioadă de timp prelungită, în diferite moduri de operare - cum ar fi inactiv, întrerupt la ecranul de titlu și așa mai departe pentru a afla dacă o aplicație poate face față încărcării continue așteptate .
Probleme frecvente observate în timpul testării la înmuiere
- Alocarea memoriei (scăpări de memorie care ar avea ca rezultat o criză de memorie sau erori de rotunjire care se manifestă doar în timp).
- Utilizarea resurselor bazei de date (Eșecul de a închide cursoarele bazei de date în anumite condiții care ar duce în cele din urmă la blocarea întregului sistem).
- De asemenea, poate duce la degradarea performanței, adică pentru a se asigura că timpul de răspuns după o perioadă lungă de activitate susținută este la fel de bun ca la începutul testului.
- Neînchiderea conexiunilor între nivelurile unui sistem cu mai multe niveluri în anumite circumstanțe, care ar putea bloca unele sau toate modulele sistemului.
- Degradarea treptată a timpului de răspuns al unor funcții pe măsură ce structurile de date interne devin mai puțin eficiente în timpul unui test lung.
Cum se încadrează acest test în familia de teste de performanță
Testarea performanței este un termen generic. Variantele de mai jos diferă doar prin forma sarcinii aplicate și durata de timp în care este menținută, motiv pentru care sunt atât de des confundate între ele.
| Tipul testului | Model de încărcare | Întrebare îi răspunde |
|---|---|---|
| Testare de sarcină | Sarcină maximă așteptată, durată scurtă | Își îndeplinește sistemul obiectivele în condiții normale de trafic de vârf? |
| Testare stresanta | Crescut peste capacitate până la defecțiune | Unde se rupe și cedează cu grație? |
| Testarea vârfurilor | Creștere bruscă și extremă, apoi retragere | Supraviețuiește și își revine după un șoc în trafic? |
| Testare de anduranță | Sarcina normală menținută timp de mai multe ore | Se degradează performanța în timp? |
| Testarea prin imersie | Sarcină susținută pe o perioadă extinsă | Există scurgeri de memorie sau epuizare a resurselor? |
| Testare de stabilitate | Sarcină variabilă în funcție de condiții | Sistemul rămâne fiabil chiar și atunci când se schimbă condițiile? |
| Testarea volumului | Utilizatori obișnuiți, volum foarte mare de date | Se descurcă pe măsură ce baza de date crește? |
Testele de anduranță și testarea la îmbibare sunt adesea tratate ca sinonime. În uzul comun, acestea sunt: ambele suportă o sarcină susținută pentru o perioadă lungă de timp. Acolo unde echipele le disting, testarea de anduranță se concentrează asupra creșterii timpilor de răspuns, în timp ce testarea prin absorbție se concentrează pe consumul de resurse, cum ar fi memoria, identificatorii de fișiere și pool-urile de conexiuni. Rularea uneia dintre ele vă oferă de obicei dovezi pentru ambele.
Indicatori cheie de înregistrat în timpul testului
O rulare a performanței este la fel de bună ca ceea ce înregistrezi în timp ce se execută. Înregistrează aceste șase date pe server și pe partea de client, apoi compară-le cu valorile de referință, mai degrabă decât cu o intuiție.
| metric | Ce iti spune | Semn de avertizare |
|---|---|---|
| Timpul mediu de răspuns | Experiență tipică a utilizatorului | Orice deviație ascendentă pe parcursul alergării |
| Timpul de răspuns la percentila 95 | Experiența celor mai lenți utilizatori | Mult peste medie, ceea ce înseamnă inconsecvență |
| tranzitată | Cereri gestionate pe secundă | Cădere în timp ce sarcina rămâne constantă |
| Rata de eroare | Procentul de solicitări eșuate sau cu termen expirat | Orice creștere peste pragul convenit |
| Utilizarea procesorului și a memoriei | Spațiu de resurse al serverului | Amintire care urcă și nu se mai întoarce |
| Conexiuni și fire de execuție la baza de date | Epuizarea piscinei | Numărări care cresc constant fără publicare |
Citiți media și percentila împreună. O medie de 800 ms cu o percentilă 95 de 900 ms descrie un sistem consistent. Aceeași medie cu o percentilă 95 de 9 secunde înseamnă că un utilizator din douăzeci trece printr-o perioadă proastă, iar media ascunde acest lucru.
Atenție la formă, nu doar la valoare. În orice test de lungă durată, o linie de resurse plată este o reușită, iar una în creștere este o scurgere, chiar și atunci când numărul absolut este încă confortabil în interiorul limitei în momentul în care se termină rularea.

