Što je Volume Testing? Učite s primjerima
Thomas Hamilton
⚡ Pametni sažetak
Testiranje volumena podvrgava aplikaciju vrlo velikoj količini podataka kako bi se vidjelo kako se pohrana, upiti i vrijeme odziva ponašaju kako baza podataka raste. Također se naziva testiranje poplavom i skalira podatke, a ne broj korisnika.
Što je Volume Testing?
Testiranje volumena je vrsta testiranja softvera, gdje se softver podvrgava ogromnoj količini podataka. Također se naziva ispitivanje poplava. Testiranje volumena provodi se za analizu performansi sustava povećanjem volumena podataka u bazi podataka.
Uz pomoć testiranja količine, može se proučavati utjecaj na vrijeme odziva i ponašanje sustava kada je izložen velikoj količini podataka.
Na primjer, usluga streaminga glazbe mogla bi se testirati s katalogom od 50 milijuna tracks i tablicu povijesti slušanja koja sadrži milijarde redaka kako bi se vidjelo vraćaju li se upiti za pretraživanje i preporuke i dalje u prihvatljivom vremenu.
Obratite pažnju na razliku: testiranje volumena povećava količina podataka sustav drži. Povećanje broj istovremenih korisnika je testiranje opterećenja, što je drugačiji test s drugačijim ciljem.
Prednosti testiranja volumena
- Rano prepoznavanje problema s kapacitetom izbjegava daleko veće troškove njihovog rješavanja u proizvodnji
- Pomaže u bržem pokretanju planova skalabilnosti
- Rano prepoznavanje uskih grla
- Osigurava da je vaš sustav sada sposoban za korištenje u stvarnom svijetu
Zašto provoditi testiranje volumena?
Cilj provođenja volumenskog testiranja je
- Provjerite performanse sustava s povećanjem količine podataka u bazi podataka
- Identificirajte probleme koji se mogu pojaviti kada skup podataka postane velik
- Da bismo utvrdili točku u kojoj stabilnost sustava degradira
- Testiranje glasnoće pomoći će identificirati kapacitet sustava ili aplikacije – normalan i veliki volumen
Kako provesti testiranje volumena
U testiranju volumena potrebno je testirati sljedeće stvari
- Testirajte da provjerite postoji li gubitak podataka
- Provjerite vrijeme odziva sustava
- Provjerite jesu li podaci ispravno pohranjeni ili ne
- Provjerite jesu li podaci prebrisani bez ikakve obavijesti
- Provjerite pojavljuju li se upozorenja i poruke o pogreškama doista kada se dosegne ograničenje glasnoće
- Provjerite utječe li velika količina podataka na brzinu obrade
- Potvrdite da sustav ima memorijske i memorijske resurse potrebne za volumen
- Provjerite da test volumena obuhvaća cijeli sustav, a ne samo jednu komponentu
- Postoji li rizik ako je količina podataka veća od navedene
- Utvrdite postoji li jamstvo da količina podataka neće premašiti određeni maksimum
Najbolje prakse za testiranje velikog broja predmeta
Nekoliko dolje navedenih praksi dijeli se s testiranjem opterećenja jer se obično izvode u istom okruženju. One specifične za volumen odnose se na sam skup podataka:
- Zaustavite sve poslužitelje i provjerite sve zapisnike
- Prije testa opterećenja ručno izvršite scenarij aplikacije
- Za najkorisnije rezultate povećajte broj korisnika
- Kako biste prevladali ograničenja licence, uravnotežite vrijeme razmišljanja
- Budite oprezni s novom izgradnjom
- Analizirajte slučaj upotrebe za poboljšanje nakon što se uspostavi osnovna vrijednost
- Ponavljanje određenih dijelova testiranja volumena postaje neizbježno u slučaju da postoji usko grlo izvedbe
Testiranje volumena u odnosu na testiranje opterećenja
| Testiranje volumena | Testiranje opterećenja |
|---|---|
|
|
|
|
Izazovi u testiranju volumena
- Teško je generirati fragmentaciju memorije
- Dinamičko generiranje ključeva
- Relacijski Integrity generiranih podataka
Kako se ovaj test uspoređuje s drugim testovima performansi
Testiranje performansi je obitelj testova koji se razlikuju po obliku primijenjenog opterećenja, zbog čega ih je tako lako zamijeniti.
| Vrsta ispitivanja | Što je povećano | Pitanje na koje odgovara |
|---|---|---|
| Ispitivanje opterećenja | Istodobni korisnici, do očekivanog vrhunca | Ostvaruje li ciljeve u uvjetima normalnog vršnog prometa? |
| Ispitivanje volumena | Podaci pohranjeni u bazi podataka | Snalazi li se s rastom skupa podataka? |
| Ispitivanje napona | Opterećenje preko kapaciteta, do kvara | Gdje se prekida i kako? |
| Ispitivanje šiljaka | Učitavanje, trenutno i izuzetno | Hoće li preživjeti i oporaviti se od šoka? |
| Ispitivanje izdržljivosti | Trajanje, pri normalnom opterećenju | Smanjuje li se performansa s vremenom? |
| Ispitivanje namakanjem | Trajanje, resursi za gledanje | Postoje li curenja memorije ili handlera? |
| Ispitivanje stabilnosti | Različiti uvjeti | Ostaje li pouzdan kako se uvjeti mijenjaju? |
Razlika koja je ovdje najvažnija: Testiranje volumena skalira podatke, testiranje opterećenja skalira korisnike. Izvješće koje se pokrene za dvije sekunde na deset tisuća redaka i dvije minute na deset milijuna redaka ima problem s volumenom, a ne s opterećenjem, i nikakva količina dodatnog kapaciteta poslužitelja to neće riješiti.
Kako generirati testne podatke za testiranje volumena
U odjeljku o izazovima navodi se da je generiranje realnih podataka težak dio testiranja volumena. U praksi se koriste četiri pristupa, a svaki uključuje kompromis.
| Pristup | Realizam | Glavni nedostatak |
|---|---|---|
| Kopija proizvodnih podataka | Najviši | Izloženost privatnosti i usklađenosti |
| Maskirana produkcijska kopija | visok | Maskiranje može narušiti referencijalni integritet |
| Sintetička generacija | Srednji | Distribucije možda ne odgovaraju stvarnosti |
| Reproducirani promet produkcije | visok | Zahtijeva infrastrukturu za snimanje |
Koji god put odabrali, moraju se ispuniti tri svojstva ili test neće izmjeriti ništa korisno.
- Referencijalni integritet. Svaki strani ključ mora se razriješiti. Milijun redaka bez ovlaštenja aktivira mehanizam za pohranu, ali nikada putanje spajanja koje aplikacija zapravo koristi.
- Realistična kardinalnost. Ako produkcijska tablica ima deset milijuna redaka za dvjesto korisnika, generiranje deset milijuna redaka za deset milijuna korisnika proizvodi potpuno drugačije planove upita.
- Realistična distribucija. Pravi podaci su iskrivljeni. Jednoliko slučajni podaci skrivaju vruće particije i sukob indeksa koji uzrokuju incidente u produkciji.
Praktično upozorenje o privatnosti. Kopiranje produkcijskih podataka u testno okruženje najčešći je uzrok kršenja podataka tijekom testiranja. Maskirajte osobna polja prije nego što kopija napusti produkcijsko okruženje, a ne nakon toga.
