Co je objemové testování? Učte se s příklady
Thomas Hamilton
⚡ Chytré shrnutí
Volume testing vystavuje aplikaci velmi velkému množství dat, aby se zjistilo, jak se úložiště, dotazy a doba odezvy chovají s rostoucí databází. Nazývá se také flood testing a škáluje data spíše než počet uživatelů.
Co je objemové testování?
Objemové testování je typ testování softwaru, kdy je software vystaven velkému objemu dat. Označuje se také jako povodňové testování. Testování objemu se provádí za účelem analýzy výkonu systému zvýšením objemu dat v databázi.
Pomocí testování objemu lze studovat dopad na dobu odezvy a chování systému při vystavení velkému objemu dat.
Například služba streamování hudby by mohla být testována s katalogem 50 milionů tracks a tabulku historie poslechu s miliardami řádků, aby se zjistilo, zda se vyhledávací dotazy a doporučení stále vracejí v přijatelném čase.
Všimněte si rozdílu: objemové testování zvyšuje množství dat systém platí. Zvyšování počet souběžných uživatelů je zátěžové testování, což je jiný test s jiným cílem.
Výhody objemového testování
- Včasná identifikace problémů s kapacitou zabraňuje mnohem vyšším nákladům na jejich řešení ve výrobě
- Pomáhá při rychlejším startu plánů škálovatelnosti
- Včasná identifikace úzkých míst
- Zajišťuje, že váš systém je nyní schopen použití v reálném světě
Proč provádět objemové testování?
Cílem provádění objemového testování je
- Kontrolujte výkon systému s rostoucím objemem dat v databázi
- Identifikujte problémy, které se pravděpodobně objeví, jakmile se datová sada rozroste
- Abychom zjistili bod, ve kterém se stabilita systému zhoršuje
- Objemové testování pomůže identifikovat kapacitu systému nebo aplikace – normální a velký objem
Jak provádět objemové testování
Při testování objemu je třeba otestovat následující věci
- Vyzkoušejte, zda nedošlo ke ztrátě dat
- Zkontrolujte dobu odezvy systému
- Zkontrolujte, zda jsou data uložena správně nebo ne
- Ověřte, zda nejsou data přepsána bez upozornění
- Zkontrolujte, zda se varování a chybové zprávy skutečně zobrazují při dosažení limitu hlasitosti.
- Zkontrolujte, zda velký objem dat ovlivňuje rychlost zpracování
- Ověřte, zda má systém paměť a úložné prostředky, které svazek vyžaduje.
- Ověřte, zda objemový test zahrnuje celý systém, a nikoli pouze jednu součást.
- Existuje nějaké riziko, pokud je objem dat větší, než je uvedeno?
- Zjistěte, zda existuje záruka, že objem dat nepřekročí stanovený maximum.
Nejlepší postupy pro testování velkého objemu
Několik níže uvedených postupů je společných pro zátěžové testování, protože oba postupy se obvykle provádějí ve stejném prostředí. Postupy specifické pro daný objem se týkají samotné datové sady:
- Zastavte všechny servery a zkontrolujte všechny protokoly
- Před zátěžovým testem ručně spusťte scénář aplikace
- Pro nejužitečnější výsledky rozložte počet uživatelů
- Chcete-li překonat licenční omezení, vyvažte čas na přemýšlení
- S novou konstrukcí buďte opatrní
- Po stanovení základní linie analyzujte případ použití pro zlepšení
- Opakování jednotlivých částí objemového testování se stává nevyhnutelným v případě, že dojde k omezení výkonu
Objemové testování vs. zátěžové testování
| Objemové testování | Testování zatížení |
|---|---|
|
|
|
|
Výzvy v objemovém testování
- Fragmentace paměti obtížně generovatelná
- Dynamické generování klíčů
- Relační Integrity generovaných dat
Jak se tento test srovnává s jinými výkonnostními testy
Testování výkonu je skupina testů, které se liší tvarem aplikovaného zatížení, a proto se tak snadno zaměňují.
| Typ zkoušky | Co se zvyšuje | Otázka to odpovídá |
|---|---|---|
| Zátěžové testování | Souběžní uživatelé, do očekávaného vrcholu | Splňuje cíle za normální dopravní špičky? |
| Testování objemu | Data uchovávaná v databázi | Zvládá to rostoucí datovou sadu? |
| Stresové testování | Zatížení nad kapacitu, až do selhání | Kde se to láme a jak? |
| Špičkový test | Načíst okamžitě a extrémně | Přežije a zotaví se ze šoku? |
| Testování odolnosti | Doba trvání při normálním zatížení | Snižuje se výkon v průběhu času? |
| Zkouška namáčením | Doba trvání, sledované zdroje | Dochází k únikům paměti nebo popisovačů? |
| Testování stability | Různé podmínky | Zůstává spolehlivý i při změně podmínek? |
Nejdůležitější je zde následující rozlišení: Objemové testování škáluje data, zátěžové testování škáluje uživatele. Sestava, která se pro deset tisíc řádků spustí za dvě sekundy a za dvě minuty za deset milionů řádků, má problém s objemem, nikoli se zátěží, a žádná dodatečná kapacita serveru to nevyřeší.
Jak generovat testovací data pro objemové testování
V části o výzvách se uvádí, že generování realistických dat je obtížnou součástí objemového testování. V praxi se používají čtyři přístupy a každý z nich s sebou nese kompromis.
| Přístup | Realismus | Hlavní nevýhoda |
|---|---|---|
| Kopie výrobních dat | Nejvyšší | Zveřejnění informací o ochraně osobních údajů a dodržování předpisů |
| Maskovaná produkční kopie | Vysoký | Maskování může narušit referenční integritu |
| Syntetická generace | Střední | Distribuce nemusí odpovídat realitě |
| Přehrávaný provoz z produkce | Vysoký | Vyžaduje infrastrukturu pro zachycení |
Ať už zvolíte jakoukoli cestu, musí platit tři vlastnosti, jinak test nenaměří nic užitečného.
- Referenční integrita. Každý cizí klíč se musí vyřešit. Milion osiřelých řádků procvičuje úložný engine, ale nikdy ne cesty spojení, které aplikace skutečně používá.
- Realistická mohutnost. Pokud produkční tabulka obsahuje deset milionů řádků pro dvě stě zákazníků, generování deseti milionů řádků pro deset milionů zákazníků vytvoří zcela odlišné plány dotazů.
- Realistické rozdělení. Reálná data jsou zkreslená. Rovnoměrně náhodná data skrývají aktivní oddíly a konflikty indexů, které způsobují produkční incidenty.
Praktické varování ohledně soukromí. Kopírování produkčních dat do testovacího prostředí je nejčastější příčinou úniku dat při testování. Osobní pole maskujte předtím, než kopie opustí produkční prostředí, ne poté.
