Vodič za ispitivanje glasnoće: primjeri i alati za ispitivanje volumena

volume testing tutorial

Pregled ispitivanja volumena:

Je li donja slika na neki način povezana s našim aplikacijama? Da, to se točno događa kada preopteretimo svoje poslužitelje, baze podataka, web usluge itd.

Svi mi moramo biti svjesni funkcionalnih i nefunkcionalnih ispitivanja, ali jeste li svjesni činjenice da je nefunkcionalno testiranje jednako važno kao i funkcionalno testiranje? Ponekad u kratkotrajnim izdanjima obično zanemarimo ovo nefunkcionalno testiranje, što u idealnom slučaju ne bismo smjeli.

Ne bi nam trebalo biti važno je li vlasnik proizvoda dao taj zahtjev ili ne. Ovo testiranje trebali bismo smatrati dijelom našeg cjelovitog postupka testiranja čak i za mala izdanja.

Ovaj vodič o ispitivanju glasnoće daje vam cjelovit pregled njegovog značenja, potrebe, važnosti, kontrolnog popisa i nekih njegovih alata kako biste ga mogli bolje razumjeti.

Što ćete naučiti:

• Što je ispitivanje glasnoće?
• Kada je ovo testiranje imperativ?
• Zašto bih trebao težiti ispitivanju volumena?
• Koji je moj kontrolni popis za ovo testiranje?
• Volumensko ispitivanje vs ispitivanje opterećenja
• Kako izvesti ovo testiranje?
• Alati za ispitivanje glasnoće
• Zaključak
• Preporučena literatura

Što je ispitivanje glasnoće?

Volumensko ispitivanje vrsta je nefunkcionalnog ispitivanja. Ovo se ispitivanje vrši radi provjere količine podataka kojom upravlja baza podataka. Volumensko ispitivanje koje se naziva i testiranje poplave je nefunkcionalno testiranje koje se provodi radi provjere performansi softvera ili aplikacije u odnosu na ogromne podatke baze podataka.

Baza podataka rasteže se do praga dodavanjem velike količine podataka u nju, a zatim se sustav testira na odgovor.

Ovo je bio teorijski dio, dopustite mi da vam objasnim nekoliko praktičnih primjera koji će vam pomoći razumjeti 'kada' dio ispitivanja volumena.

Kada je ovo testiranje imperativ?

Idealno bi bilo da svaki softver ili aplikaciju testiramo na količinu podataka, ali u nekim slučajevima kada podaci neće biti teški, nastojimo izbjeći ovo testiranje. Ali u nekim slučajevima kada se podaci obrađuju u MB ili GB svakodnevno, tada bi definitivno trebalo provesti test volumena.

Slijedi nekoliko primjera iz mog vlastitog 8-godišnjeg iskustva koji objašnjavaju dio 'kada':

Primjer 1:

Jedan od mojih pothvata bio je veliki sustav koji se sastojao i od web aplikacije i od mobilne aplikacije. Ali sama web aplikacija imala je 3 modula kojima su upravljala 3 različita tima.

Ponekad je i kod nas baza podataka postajala spora kad smo svi ‘zajedno’ dodavali podatke za svoje testiranje. Bilo je dosadno, a posao je znao biti otežan zbog ogromne količine podataka i kako bismo olakšali posao, morali smo prilično često čistiti DB.

Podaci kojima je 'živi' sustav rukovao iznosili su oko GB, pa je u usporedbi s mobilnom aplikacijom web aplikacija vrlo često testirana na količinu podataka. Timovi QA web-aplikacija imali su vlastite skripte za automatizaciju koje bi se izvodile noću i izvodile ovo testiranje.

Primjer 2:

Još jedan primjer mog pothvata bio je ekosustav koji nije imao samo web aplikaciju, već i SharePoint aplikaciju, pa čak i instalacijski program. Svi su ti sustavi komunicirali u istu bazu podataka za prijenos podataka. Podaci s kojima je radio taj sustav također su bili vrlo veliki i ako iz bilo kojeg razloga DB postane spor, čak bi i instalacijski program prestao raditi.

Stoga se redovno provodilo ispitivanje volumena, a izvedba DB-a promatrala se detaljno za sve probleme.

Slično tome, možemo uzetiPrimjeriod nekoliko aplikacija koje svakodnevno koristimo za kupnju, rezervaciju karata, financijske transakcije itd. koje se bave teškim podatkovnim transakcijama i stoga trebaju test volumena.

S druge strane, idealno ispitivanje volumena nije uvijek moguće postići jer ima svoja ograničenja i izazove.

Nekoliko njegovih ograničenja i izazova uključuju:

• Teško je stvoriti točnu fragmentaciju memorije.
• Generiranje dinamičnog ključa je nezgodno.
• Stvaranje idealnog stvarnog okruženja, tj. Replika aktivnog poslužitelja može biti nezgodno.
• Alati za automatizaciju, mreža itd. Također utječu na rezultate ispitivanja.

Sad smo shvatili kada moramo obaviti ovu vrstu testiranja. Razumijemo i mi 'zašto' ovo bismo testiranje trebali obaviti kao cilj, cilj ili cilj izvođenja ovog testiranja.

Zašto bih trebao težiti ispitivanju volumena?

Testiranje volumena može vam pomoći da shvatite koliko je vaš sustav prilagođen stvarnom svijetu, a također pomaže i uštedjeti novac koji ćete kasnije potrošiti na održavanje.

Slijedi nekoliko mogućih razloga za provođenje ovog testiranja:

• Najosnovnija je potreba analizirati izvedbu vašeg sustava u odnosu na povećane podatke. Stvaranje ogromne količine podataka pomoći će vam da razumijete performanse vašeg sustava u smislu vremena odziva, gubitka podataka itd.
• Utvrdite probleme koji će se pojaviti s ogromnim podacima i pragom.
• Iznad održive točke ili praga, ponašanje sustava, tj. Ako se pad sustava DB ne reagira ili vremensko ograničenje.
• Primjena rješenja za preopterećenje DB-a, pa čak i njihova provjera.
• Pronalaženje krajnje točke vašeg DB-a (koja se ne može popraviti) nakon koje sustav neće uspjeti i stoga treba poduzeti mjere predostrožnosti.
• U slučaju više od jednog DB poslužitelja, otkrivanje problema s DB komunikacijom, tj. Onih koji su najizloženiji neuspjehu, itd.

Sada znamo važnost i razlog izvođenja ovog testiranja.

ILI Neko iskustvo koje bih ovdje volio podijeliti jest da u pogledu mobilnih aplikacija možda neće biti potrebno testiranje glasnoće jer aplikaciju istovremeno koristi samo jedna osoba, a mobilne su aplikacije osmišljene tako da budu jednostavne .

Dakle, ako nemate vrlo složenu aplikaciju s puno podataka, testiranje volumena može se preskočiti.

Jednom kada znate što treba provjeriti za vaš sustav ili aplikaciju, sljedeća stvar koju treba učiniti je napraviti popis za provjeru za vašu aplikaciju koji treba definirati 'što' treba testirati.

Koji je moj kontrolni popis za ovo testiranje?

Prije nego što uđemo u neke primjere za izradu kontrolnog popisa za vašu aplikaciju ili sustav, prvo shvatimo nekoliko uputa koje moramo imati na umu prilikom stvaranja kontrolnog popisa za količinsko testiranje ili pristup prije početka testiranja.

Bodovi koje treba zapamtiti:

• Obavijestite programere o vašem planu testiranja jer oni znaju puno o sustavu i mogu vam pružiti ulazne podatke, pa čak i uska grla.
• Prije strateškog testiranja dobro razumite fizički aspekt kao u konfiguraciji poslužitelja, RAM-u, procesoru itd.
• Shvatite složenost DB-a, procedure, DB skripte itd. U mogućoj mjeri tako da možete u cjelini prikazati složenost vašeg sustava.
• Pripremite informatiku, tj. Grafikone, tablicu podataka itd., Ako je moguće za normalnu količinu podataka i koliko je sustav dobar, ovo će vam pomoći da budete sigurni da će performanse biti dobre za normalno opterećenje podataka prije nego što naglasite DB. To će vam također pomoći da prije nego što prijeđete na naglašeni dio osigurate da nema problema koji će zahtijevati popravak za vaš test glasnoće.

Slijedi nekoliko primjera koje možete dodati ili upotrijebiti na popisu za provjeru:

• Provjerite ispravnost načina pohrane podataka.
• Provjerite ima li sustav potrebne memorijske resurse ili ne.
• Provjerite postoji li rizik od količine podataka veću od navedenog ograničenja.
• Provjerite i promatrajte odgovor sustava na količinu podataka.
• Provjerite gube li se podaci tijekom ispitivanja volumena.
• Provjerite jesu li podaci prepisani, a to se čini uz prethodne informacije.
• Prepoznajte područja koja se protežu izvan normalnog raspona poput puno atributa (pretraživih), ogromnih br. tablica pretraživanja, puno mapiranja lokacija itd.
• Kao što je ranije spomenuto, prvo stvorite osnovnu vrijednost postizanjem rezultata za normalni volumen, a zatim nastavite s naglaskom.

Prije nego što prijeđemo na ostale primjere, test slučajeve i alate, prvo shvatimo kako se ovo testiranje razlikuje od testiranja opterećenja.

Volumensko ispitivanje vs ispitivanje opterećenja

Slijede neke od glavnih razlika između ispitivanja zapremine i opterećenja:

Kako izvesti ovo testiranje?

Ovo se ispitivanje može obaviti ručno ili pomoću bilo kojeg alata. Općenito, upotreba alata uštedjet će nam vrijeme i napore, ali u slučaju ispitivanja glasnoće, prema mom iskustvu korištenje alata može vam dati preciznije rezultate u usporedbi s ručnim testiranjem.

Prije početka izvođenja test slučaja pobrinite se da:

• Tim se složio s planom testiranja za ovo testiranje.
• Ostali timovi vašeg projekta dobro su informirani o promjenama baze podataka i njezinom utjecaju na njihov rad.
• Ispitne površine postavljene su za određene konfiguracije.
• Pripremljena je polazna osnova za ispitivanje.
• Određene količine podataka za testiranje (skripte podataka ili postupci itd.) Su spremne. O alatima za stvaranje podataka možete pročitati na našoj stranici za generiranje podataka.

Pogledajmo nekoliko primjera testnih slučajeva koje možete koristiti u izvršavanju:

Potvrdite ovo za sve odabrane količine podataka za ispitivanje volumena:

1. Provjerite može li se dodavanje podataka uspješno obaviti i odražavaju li se to u aplikaciji ili web mjestu.
2. Provjerite može li se brisanje podataka uspješno obaviti i odražavaju li se to u aplikaciji ili web mjestu.
3. Provjerite može li se ažuriranje podataka uspješno obaviti i odražava li se to u aplikaciji ili web mjestu.
4. Provjerite nije li došlo do gubitka podataka i jesu li svi podaci prikazani kako se očekuje u aplikaciji ili na web mjestu.
5. Provjerite nije li isteklo vrijeme aplikacije ili web stranica zbog velike količine podataka.
6. Provjerite da se pogreške rušenja ne prikazuju zbog velike količine podataka.
7. Provjerite da se podaci ne prepisuju i prikazuju li se odgovarajuća upozorenja.
8. Uvjerite se da se drugi moduli vašeg web mjesta ili aplikacije ne ruše ili ne istječu s velikim brojem podataka.
9. Provjerite je li vrijeme odziva DB-a unutar prihvatljivog raspona.

Alati za ispitivanje glasnoće

Kao što je ranije spomenuto, automatsko testiranje štedi vrijeme i čak daje točne rezultate u usporedbi s ručnim ispitivanjem. Još jedna prednost korištenja alata za testiranje volumena je ta što testove možemo izvoditi noću i na taj način na količinu podataka DB-a neće utjecati rad ostalih timova ili članova tima.

Testove možemo zakazati za jutro i rezultati će biti spremni.

Slijedi popis nekoliko alata za ispitivanje volumena otvorenog koda:

# 1) DbFit:

Ovo je alat otvorenog koda koji podržava razvoj temeljen na testovima.

DbFit okvir za testiranje napisan je na vrhu Fitnessa, testovi su napisani pomoću tablica i mogu se izvršiti pomoću bilo kojeg Java IDE ili CI alata.

# 2) HammerDb:

HammerDb je također alat otvorenog koda koji može biti automatiziran, s više niti i čak omogućuje izvršavanje skripti. Može raditi s SQL-om, Oracleom, MYSQL-om itd.

# 3) JdbcSlim:

JdbcSlim naredbe se lako mogu integrirati u Slim Fitness i podržava sve baze podataka koje imaju JDBC pokretački program. Fokus je na odvojenom čuvanju konfiguracije, podataka o testiranju i SQL upita.

# 4) NoSQLMap:

Ovaj je otvoreni izvor Python alat koji je dizajniran za automatsko ubrizgavanje napada i ometanje DB konfiguracija za analizu prijetnje. Radi samo za MongoDB.

# 5) Ruby-PLSQL-spec:

PLSQL se može jedinstveno testirati koristeći Ruby jer je Oracle dostupan kao alat otvorenog koda. Ovaj u osnovi koristi dvije knjižnice: Ruby-PLSQL i Rspec.

Zaključak

Volumensko ispitivanje je nefunkcionalno testiranje koje se radi za analizu performansi baze podataka. To se može učiniti ručno, kao i uz pomoć nekih alata.

Ako ste QA koji je novi u ovom testiranju, predložio bih da se igrate s alatom ili prvo izvršite neke test slučajeve. To će vam pomoći da razumijete koncept ispitivanja volumena prije nego što uskočite u testiranje.

kako izgleda wep ključ

Ovo je testiranje prilično nezgodno i ima svoje izazove, stoga je vrlo važno temeljito poznavati koncept, stvaranje testnog prostora i DB jezik prije izvođenja.

Nadam se da bi vam ovaj vodič povećao opseg znanja o ovoj temi :)

Preporučena literatura

• Najbolji alati za testiranje softvera 2021. (Alati za automatizaciju ispitivanja kvalitete)
• Vodič za testiranje u parovima ili za sve parove s alatima i primjerima
• Funkcionalno ispitivanje vs nefunkcionalno testiranje
• Vodič za ispitivanje konfiguracije s primjerima
• Testiranje e-knjige za preuzimanje priručnika
• Vodič za ispitivanje razaranja i ispitivanja bez razaranja
• 11 najboljih alata za automatizaciju za testiranje Android aplikacija (Android Tools Testing Tools)
• Najbolji IVR alati za testiranje: Vodič za test CYARA i HAMMER