volume testing tutorial
Prehľad testovania objemu:
Súvisí obrázok nižšie nejakým spôsobom s našimi aplikáciami? Áno, presne to sa stane, keď preťažíme naše servery, databázy, webové služby atď.
Každý z nás si musí byť vedomý funkčného a nefunkčného testovania, ale pamätáte na skutočnosť, že nefunkčné testovanie je rovnako dôležité ako funkčné testovanie? Občas v krátkych vydaniach máme tendenciu ignorovať toto nefunkčné testovanie, čo by sme v ideálnom prípade nemali robiť.
Malo by nám byť jedno, či vlastník produktu dal túto požiadavku alebo nie. Toto testovanie by sme mali považovať za súčasť nášho kompletného procesu testovania aj pri malých vydaniach.
Tento návod na testovanie zväzkov vám poskytne kompletný prehľad o jeho význame, potrebe, dôležitosti, kontrolnom zozname a niektorých jeho nástrojoch, aby ste mu mohli lepšie porozumieť.
Čo sa dozviete:
- Čo je to testovanie hlasitosti?
- Kedy je toto testovanie nevyhnutné?
- Prečo by som sa mal zamerať na testovanie objemu?
- Aký je môj kontrolný zoznam pre toto testovanie?
- Testovanie objemu vs. Testovanie zaťaženia
- Ako vykonať toto testovanie?
- Nástroje na testovanie objemu
- Záver
- Odporúčané čítanie
Čo je to testovanie hlasitosti?
Volume Testing je druh nefunkčného testovania. Toto testovanie sa vykonáva na kontrolu objemu údajov spracovaných databázou. Objemové testovanie, ktoré sa nazýva aj povodňové testovanie, je nefunkčné testovanie, ktoré sa vykonáva za účelom kontroly výkonu softvéru alebo aplikácie oproti veľkým údajom z databázy.
Databáza sa natiahne na prahový bod pridaním veľkého množstva údajov a potom sa systém otestuje na jej odpoveď.
Toto bola teoretická časť, dovoľte mi vysvetliť vás niekoľkými praktickými príkladmi, ktoré vám pomôžu pochopiť 'kedy' súčasť objemového testovania.
Kedy je toto testovanie nevyhnutné?
V ideálnom prípade by mal byť každý softvér alebo aplikácia testovaná na objem dát, ale v niektorých prípadoch, keď nebudú dáta silné, sa tomuto testovaniu vyhýbame. Ale v niektorých prípadoch, keď sa s údajmi zaobchádza každý deň v MB alebo GB, potom by sa určite mal vykonať objemový test.
Nasleduje niekoľko príkladov z mojich 8-ročných skúseností, ktoré vysvetľujú časť „kedy“:
Príklad 1:
Jedným z mojich podnikov bol veľký systém, ktorý pozostával z webovej aj mobilnej aplikácie. Samotná webová aplikácia mala ale 3 moduly, ktoré ovládali 3 rôzne tímy.
Občas, dokonca aj u nás, sa databáza spomaľovala, keď sme všetci „spolu“ pridávali údaje pre naše testovanie. Bolo to nepríjemné a práca zvyknutá na brzdenie kvôli veľkému množstvu dát a na uľahčenie práce sme museli pomerne často čistiť databázu.
Údaje, ktoré „živý“ systém spracovával, boli okolo GB, a preto bola v porovnaní s mobilnou aplikáciou webová aplikácia veľmi často testovaná na objem dát. Tímy QA pre webové aplikácie mali svoje vlastné automatizačné skripty, ktoré bežali v noci a vykonávali toto testovanie.
Príklad 2:
Ďalším príkladom môjho podnikania bol ekosystém, ktorý mal nielen webovú aplikáciu, ale aj aplikáciu SharePoint a dokonca aj inštalačný program. Všetky tieto systémy komunikovali do rovnakej databázy na účely dátových prenosov. Údaje spracované týmto systémom boli tiež veľmi obrovské a ak by sa DB z nejakého dôvodu spomalila, prestal by fungovať aj inštalátor.
Preto sa objemový test uskutočňoval pravidelne a výkonnosť databázy sa pozorne sledovala pri akýchkoľvek problémoch.
Podobne môžeme vziaťPríkladyniekoľkých aplikácií, ktoré denne používame na nakupovanie, rezervovanie leteniek, finančné transakcie atď., ktoré sa zaoberajú náročnými dátovými transakciami, a preto potrebujú test objemu.
Na druhej strane nemusí byť vždy možné dosiahnuť ideálne testovanie objemu, pretože má svoje vlastné obmedzenia a výzvy.
Niektoré z jeho obmedzení a výziev zahŕňajú:
- Je ťažké vytvoriť presnú fragmentáciu pamäte.
- Generovanie dynamických kľúčov je zložité.
- Vytvorenie ideálneho reálneho prostredia, tj. Repliky živého servera, môže byť zložité.
- Na výsledky testu majú vplyv aj automatizačné nástroje, sieť atď.
Teraz sme to pochopili kedy musíme urobiť tento typ testovania. Poďme to tiež pochopiť „Prečo“ mali by sme robiť toto testovanie ako v, cieľ alebo cieľ vykonania tohto testovania.
Prečo by som sa mal zamerať na testovanie objemu?
Testovanie objemu vám pomôže pochopiť, ako je váš systém vhodný pre skutočný svet, a tiež pomôže ušetriť peniaze, ktoré sa neskôr minú na účely údržby.
Nasleduje niekoľko možných dôvodov na vykonanie tohto testovania:
- Najzákladnejšou potrebou je analyzovať výkon vášho systému na základe zvýšeného množstva údajov. Vytvorenie obrovského množstva údajov vám pomôže pochopiť výkonnosť vášho systému z hľadiska doby odozvy, straty dát atď.
- Identifikujte problémy, ktoré nastanú pri obrovských údajoch a hraničnom bode.
- Za hranicou udržateľného alebo prahového bodu začne správanie systému, tj. Ak dôjde k zrúteniu DB, prestať reagovať alebo vyprší čas.
- Implementácia riešení preťaženia DB a dokonca ich overenie.
- Zistenie krajného bodu vašej databázy (ktorý sa nedá opraviť), za ktorým systém zlyhá, a preto je potrebné prijať preventívne opatrenia.
- V prípade viac ako jedného servera DB zisťovanie problémov s komunikáciou DB, t. J. Z nich najviac náchylných na zlyhanie atď.
Teraz poznáme dôležitosť a dôvod vykonania tohto testovania.
ALEBO Skúsenosti, s ktorými by som sa chcel podeliť, je, že pokiaľ ide o mobilné aplikácie, nemusí byť testovanie objemu potrebné, pretože aplikáciu používa súčasne iba jedna osoba a mobilné aplikácie sú navrhnuté tak, aby boli jednoduché. .
Pokiaľ teda nemáte veľmi zložitú aplikáciu s veľkým podielom dát, testovanie objemu je možné preskočiť.
Keď viete, čo sa musí pre váš systém alebo aplikáciu overiť, musíte urobiť kontrolný zoznam pre svoju aplikáciu, ktorý bude definovať 'čo' treba vyskúšať.
Aký je môj kontrolný zoznam pre toto testovanie?
Predtým, ako vstúpime do niekoľkých príkladov vytvorenia kontrolného zoznamu pre vašu aplikáciu alebo systém, najskôr pochopíme niekoľko ukazovateľov, na ktoré treba pamätať pri vytváraní kontrolného zoznamu na testovanie objemu alebo prístupu pred začatím testovania.
Body, ktoré treba pamätať:
- Udržujte vývojárom prehľad o vašom testovacom pláne, pretože vedia veľa o systéme a môžu vám poskytnúť vstupy alebo dokonca úzke miesta.
- Pred strategizáciou testovania pochopte fyzické aspekty ako v konfiguráciách servera, RAM, procesora atď.
- Pochopte v maximálnej miere zložitosti databázy, postupov, skriptov databázy atď., Aby ste mohli načrtnúť komplexnosť celého systému ako celku.
- Pripravte si informatiku, t. J. Grafy, údajové listy, atď., Pokiaľ je to možné pre normálny objem údajov a ako dobrý je systém, pomôže vám to ubezpečiť sa, že skôr, ako zdôrazníte DB, je výkon v poriadku pre bežné načítanie údajov. Pomôže vám to tiež zabezpečiť predtým, ako prejdete na stresujúcu časť, že neexistujú žiadne problémy, ktoré si budú vyžadovať opravu vášho testu objemu.
Nasleduje niekoľko príkladov, ktoré môžete pridať alebo použiť vo svojom kontrolnom zozname:
- Skontrolujte správnosť metód ukladania údajov.
- Skontrolujte, či má systém potrebné pamäťové prostriedky alebo nie.
- Skontrolujte, či existuje riziko objemu dát presahujúceho stanovený limit.
- Skontrolujte a sledujte reakciu systému na objem dát.
- Skontrolujte, či sa počas testovania objemu dáta nestrácajú.
- Skontrolujte, či sú údaje prepísané, a to pomocou predbežných informácií.
- Identifikujte oblasti, ktoré presahujú normálny rozsah, ako veľa atribútov (prehľadávateľných), obrovské č. vyhľadávacích tabuliek, veľa mapovaní polôh atď.
- Ako už bolo spomenuté, najskôr vytvorte základňu získaním výsledkov pre normálny objem a potom pokračujte v stresovaní.
Než prejdeme k ďalším príkladom, testovacím prípadom a nástrojom, najskôr pochopíme, v čom sa toto testovanie líši od testovania záťaže.
Testovanie objemu vs. Testovanie zaťaženia
Ďalej uvádzame niektoré z hlavných rozdielov medzi testovaním objemu a zaťaženia:
S.No. | Objemové testovanie | Testovanie záťaže |
---|---|---|
1 | Testovanie objemu sa vykonáva na overenie výkonu databázy oproti veľkému množstvu údajov v databáze. | Testovanie zaťaženia sa vykonáva zmenou zaťaženia používateľov prostriedkami a overením ich výkonnosti. |
dva | Primárne zameranie tohto testovania je na „údaje“. | Primárne zameranie tohto testovania je na „používateľov“. |
3 | Databáza je namáhaná do maximálneho limitu. | Server je zaťažený maximálnym limitom. |
4 | Jednoduchým príkladom môže byť vytvorenie súboru veľkej veľkosti. | Jednoduchým príkladom môže byť vytvorenie veľkého množstva súborov. |
Ako vykonať toto testovanie?
Toto testovanie je možné vykonať ručne alebo pomocou ľubovoľného nástroja. Používanie nástrojov vo všeobecnosti ušetrí náš čas a úsilie, ale v prípade objemového testu podľa mojich skúseností používanie nástrojov vám môže poskytnúť presnejšie výsledky v porovnaní s manuálnym testovaním.
Pred začatím vykonania testovacieho prípadu sa uistite, že:
- Tím súhlasil s plánom testovania tohto testovania.
- Ostatné tímy vášho projektu sú dobre informované o zmenách v databáze a ich dopade na ich prácu.
- Testovacie postele sú nastavené pre zadané konfigurácie.
- Je pripravený základ pre testovanie.
- Konkrétne objemy údajov na testovanie (dátové skripty alebo postupy atď.) Sú pripravené. O nástrojoch na vytváranie údajov si môžete prečítať na našej stránke generovania údajov.
Pozrime sa na niekoľko príkladov testovacích prípadov, ktoré môžete použiť pri spustení:
Overte to pre všetky vybrané objemy údajov pre testovanie zväzkov:
- Overte, či je možné úspešne pridať údaje a či sa odrážajú v aplikácii alebo na webe.
- Overte, či je možné vymazanie údajov úspešne vykonať a či sa odráža v aplikácii alebo na webe.
- Overte, či je možné aktualizáciu údajov úspešne vykonať a či sa odráža v aplikácii alebo na webe.
- Skontrolujte, či nedochádza k strate údajov a či sa všetky informácie v aplikácii alebo na webe zobrazujú podľa očakávania.
- Skontrolujte, či aplikácia alebo webové stránky nevypršali kvôli vysokému objemu dát.
- Overte, či sa zlyhania zlyhania nezobrazujú z dôvodu veľkého objemu dát.
- Skontrolujte, či údaje nie sú prepísané a či sa zobrazujú správne varovania.
- Overte, či iné moduly vášho webu alebo aplikácie nezrážajú alebo nevypršajú čas s veľkým objemom dát.
- Overte, či je čas odozvy DB v prijateľnom rozmedzí.
Nástroje na testovanie objemu
Ako už bolo spomenuté vyššie, automatizované testovanie šetrí čas a dokonca poskytuje presné výsledky v porovnaní s manuálnym testovaním. Ďalšou výhodou použitia nástrojov na testovanie objemu je, že môžeme testy spúšťať v noci, a tak nebude objem ostatných databáz ovplyvňovať prácu ostatných tímov alebo členov tímu.
Testy môžeme naplánovať na ráno a výsledky budú hotové.
Nasleduje zoznam niekoľkých nástrojov na testovanie zväzkov otvorených zdrojov:
# 1) DbFit:
Toto je nástroj s otvoreným zdrojovým kódom, ktorý podporuje vývoj založený na testoch.
DbFit testovací rámec je napísaný na vrchole Fitness, testy sú písané pomocou tabuliek a je možné ich vykonávať pomocou ľubovoľného nástroja Java IDE alebo CI.
# 2) HammerDb:
HammerDb je tiež nástroj typu open-source, ktorý je možné automatizovať, kombinovať s viacerými vláknami a dokonca umožňuje skriptovanie za behu. Môže pracovať s SQL, Oracle, MYSQL atď.
# 3) JdbcSlim:
JdbcSlim príkazy sa dajú ľahko integrovať do Slim Fitness a podporuje všetky databázy, ktoré majú ovládač JDBC. Dôraz je kladený na to, aby sa konfigurácia, testovacie údaje a dotazy SQL uchovávali oddelene.
# 4) NoSQLMap:
Toto je open-source nástroj Python, ktorý je navrhnutý tak, aby automaticky injektoval útoky a narušil konfigurácie databázy za účelom analýzy hrozby. Funguje to iba pre MongoDB.
# 5) Ruby-PLSQL-spec:
PLSQL je možné testovať na jednotkách pomocou Ruby, pretože Oracle je k dispozícii ako open-source nástroj. Toto v zásade používa dve knižnice: Ruby-PLSQL a Rspec.
Záver
Objemové testovanie je nefunkčné testovanie, ktoré sa vykonáva s cieľom analyzovať výkonnosť databázy. Môže sa to robiť ručne, ako aj pomocou niektorých nástrojov.
Ak ste QA, ktorá je v tomto testovaní nová, navrhujem najskôr hrať s nástrojom alebo vykonať niektoré testovacie prípady. To vám pomôže porozumieť pojmu objemové testovanie skôr, ako sa do testovania pustíte.
sieťové zariadenia a ich osi osi
Toto testovanie je dosť zložité a má svoje vlastné výzvy, takže je veľmi dôležité mať pred jeho vykonaním dôkladné znalosti o koncepte, tvorbe testovacieho lôžka a jazyku DB.
Dúfam, že by vám tento návod zvýšil objem vedomostí o tejto téme :)
Odporúčané čítanie
- Najlepšie nástroje na testovanie softvéru 2021 [QA Test Automation Tools]
- Výukový program pre párové testovanie alebo testovanie všetkých párov s nástrojmi a príkladmi
- Funkčné testovanie vs. Nefunkčné testovanie
- Výukový program na testovanie konfigurácie s príkladmi
- Stiahnutie e-knihy Testing Primer
- Výukový program pre deštruktívne testovanie a nedeštruktívne testovanie
- 11 najlepších automatizačných nástrojov na testovanie aplikácií pre Android (Android App Testing Tools)
- Najlepšie nástroje na testovanie IVR: Výukový program na testovanie CYARA a HAMMER