Co je testování škálovatelnosti? Učte se s příkladem
Thomas Hamilton
⚡ Chytré shrnutí
Testování škálovatelnosti měří, jak se aplikace chová při stoupání nebo poklesu uživatelské zátěže, objemu dat nebo rychlosti transakcí, a odhaluje přesný bod, ve kterém se výkon přestává škálovat, a identifikuje příčinné úzké hrdlo.
Co je testování škálovatelnosti?
Testování škálovatelnosti je nefunkční testovací metoda, která měří výkon systému nebo sítě při zvyšování nebo snižování počtu uživatelských požadavků. Účelem testování škálovatelnosti je zajistit, aby systém zvládl předpokládaný nárůst uživatelského provozu, objemu dat a frekvence transakcí. Testuje schopnost systému uspokojit rostoucí poptávku.
Testování škálovatelnosti je podtypem testování výkonu, takže se zaměřuje na chování aplikace při jejím nasazení na větší systém nebo při nadměrném zatížení. Softwarové inženýrstvíTestování škálovatelnosti měří bod, ve kterém aplikace přestává škálovat, a identifikuje důvod, proč k tomu dochází.
Proč provádět testování škálovatelnosti?
Problémy s kapacitou se během funkčního testování objevují jen zřídka. Objevují se v nejrušnější obchodní den roku, když spustí marketingovou kampaň nebo když datová sada, která dva roky tiše rostla, nakonec zpomalí každý dotaz. Testování škálovatelnosti tyto limity odhaluje nejprve v kontrolovaném prostředí. Konkrétně vám pomáhá:
- Určete, jak se aplikace škáluje s rostoucí pracovní zátěží a kde se tato křivka zplošťuje.
- Určete limit souběžných uživatelů webové aplikace dříve, než se doba odezvy stane nepřijatelně vysokou.
- Určete degradaci na straně klienta a uživatelskou zkušenost při zátěži, například pomalé vykreslování obrazovky.
- Určete robustnost a degradaci na straně serveru, včetně saturace CPU, úniků paměti a vyčerpání fondu připojení.
Nejsnadněji si tento vztah představíme jako křivku: propustnost roste spolu s přidanou zátěží, dokud se zdroj nenasytí, načež další uživatelé pouze prodlužují frontu.
Typy testování škálovatelnosti
Škálovatelnost není jednorázová vlastnost, takže testovací plán obvykle pokrývá více než jednu dimenzi. Čtyři níže uvedené typy jsou ty, které měří většina týmů, a první dva určují tvar samotného testovacího prostředí.
| Typ | Co je škálováno | Co test dokazuje |
|---|---|---|
| Vertikální škálovatelnost (zvětšit) | CPU, paměť nebo úložiště přidané k jednomu serveru | Kolik dodatečné zátěže absorbuje jeden vylepšený stroj a kde se nachází strop pro jeden uzl |
| Horizontální škálovatelnost (navýšení horizontálního horizontu) | Další servery, kontejnery nebo uzly za load balancerem | Zda se propustnost zvyšuje zhruba úměrně k přidaným uzlům, nebo zda ji omezují sdílené zdroje |
| Funkční škálovatelnost | Nové funkce, moduly nebo služby | Zda lze přidané funkce absorbovat bez zhoršení stávajících transakcí |
| Administrativní škálovatelnost | Uživatelé, klienti, týmy nebo prostředí ke správě | Zda je onboarding, oprávnění a monitorování funkční i s růstem organizace |
Vertikální škálování je jednodušší, protože se architektura mění jen zřídka, ale jeden stroj má vždy určitý limit. Horizontální škálování tento limit odstraňuje a zlepšuje odolnost proti chybám, ale za cenu síťové latence, konzistence dat a koordinační režie – to vše musí test měřit, nikoli předpokládat.
Co testovat při testování škálovatelnosti
Škálovatelnost se posuzuje na základě měření, nikoli zobrazení. V každém kroku načítání zaznamenávejte následující atributy, aby byl viditelný trend, a nikoli pouze konečné číslo.
| Atribut | Co vám to říká |
|---|---|
| Doba odezvy | Doba mezi požadavkem uživatele a odpovědí systému; měla by zůstat stejná s rostoucí souběžností |
| Přechod obrazovky | Jak rychle se jedna stránka nebo zobrazení při načtení nahradí další |
| Propustnost | Objem požadavků zpracovaných za jednotku času; plateau označuje limit škálovatelnosti |
| Měření času | Čas relace, čas restartu, čas tisku, čas transakce a čas provedení úlohy |
| Výkon v porovnání s počtem uživatelů | Jak se jednotlivé metriky mění s postupným přidáváním souběžných uživatelů |
| Vyžádat si sazby | Požadavky za sekundu, transakce za sekundu a přístupy za sekundu |
| Využití sítě | Spotřebovaná šířka pásma a latence paketů mezi vrstvami |
| Využití CPU a paměti | Cena zdrojů na transakci; neustále rostoucí číslo často signalizuje únik |
| Čítače webových serverů | Počet požadavků a odpovědí za sekundu, hloubka fronty a odmítnutá připojení |
| Výkon při zátěži | Kombinované chování, jakmile jsou všechny metriky načteny společně ve vrcholu |
Testovací strategie pro testování škálovatelnosti
Testovací strategie pro testování škálovatelnosti se liší v závislosti na typu testované aplikace. Pokud aplikace přistupuje k databáze, testovací parametry budou zahrnovat velikost databáze ve vztahu k počtu uživatelů atd.
Předpoklady pro testování škálovatelnosti
- Schopnost rozložení zátěže — Zkontrolujte, zda nástroj pro zátěžové testování umožňuje generování zátěže z více strojů a její řízení z centrálního bodu.
- Operasystém — Zkontrolujte, co operační systémy Agenti generování zátěže a hlavní server zátěžových testů běží pod tímto kódem.
- Procesor — Zkontrolujte, jaký typ CPU je vyžadován pro virtuálního uživatelského agenta a hlavní server pro zátěžové testování.
- Memory — Zkontrolujte, kolik paměti by stačilo pro virtuálního uživatelského agenta a master zátěžového testu.
- Testovací prostředí — Zkontrolujte, zda testovací prostředí dostatečně přesně odráží produkci, aby se výsledky daly přenést.
Jak provést testování škálovatelnosti
- Definujte opakovatelný proces pro provádění testů škálovatelnosti v průběhu celého životního cyklu aplikace.
- Určete kritéria pro škálovatelnost
- Užší výběr softwarových nástrojů potřebných ke spuštění zátěžového testu
- Nastavte testovací prostředí a nakonfigurujte hardware potřebný k provádění testů škálovatelnosti
- Naplánujte testovací scénáře i testy škálovatelnosti
- Vytvořte a ověřte skript virtuálního uživatele
- Vytvořte a ověřte scénáře zátěžového testu
- Proveďte testy
- Vyhodnoťte výsledky
- Generování požadovaných reportů
Plán testování škálovatelnosti
Než začnete s vlastním vytvářením testů, vypracujte si podrobný plán testování. Je to důležitý krok k zajištění toho, aby test splňoval požadavky aplikace.
Následují atributy pro vytvoření dobře definovaného Testovací plán pro testování škálovatelnosti.
- Kroky pro skriptyTestovací skript by měl obsahovat podrobné kroky, které určují přesné akce, které by uživatel provedl.
- Data za běhuTestovací plán by měl určit veškerá data za běhu, která jsou potřebná pro interakci s aplikací.
- Testy řízené datyPokud skripty za běhu potřebují různá data, musíte znát všechna pole, která tato data vyžadují.
Příklad testování škálovatelnosti
Představte si internetový obchod, který během sezónního výprodeje očekává 2 000 souběžných nakupujících. Tým se nejprve dohodne na kritériu pro úspěšné provedení nákupu: transakce při platbě musí být u 95 procent uživatelů dokončena za méně než tři sekundy s mírou chyb pod jedno procento.
Test poté spustí stejný skript pro prohlížení-hledání-košík-pokladnu pro 250, 500, 1 000, 1 500 a 2 000 virtuálních uživatelů. Doba odezvy se udržuje na úrovni dvou sekund do 1 000 uživatelů, u 1 500 uživatelů klesá na 2.8 sekundy a u 2 000 uživatelů dosahuje devíti sekund, přičemž využití CPU databáze je 98 procent. Limit škálovatelnosti je tedy zhruba 1 500 uživatelů a úzkým hrdlem je databázová vrstva – nikoli aplikační servery, které tým plánoval přidat.
Nástroje pro testování škálovatelnosti
Testování škálovatelnosti vyžaduje nástroj, který dokáže generovat zátěž z několika počítačů najednou a centrálně hlásit výsledky. Volba se obvykle řídí primárním jazykem týmu a testovanými protokoly.
| Nástroj | Skriptování | Nejlépe se hodí |
|---|---|---|
| Apache JMeter | Testovací plány GUI a XML, Java na základě | Široké pokrytí protokolů včetně JDBC, JMS, LDAP a SOAP |
| Grafana k6 | JavaSkript resp TypeScript | Testy API a mikroslužeb zapojené do kanálu CI/CD |
| Gatling | Java, Kotlin nebo Scala DSL | Vysoký počet virtuálních uživatelů na injektor s podrobnými HTML reporty |
| kobylka | Prostý Python | Python týmy, které potřebují rozšířit klienta nad rámec HTTP |
| LoadRunner | Skripty podobné jazyku C nahrané ve VuGenu | Velké podnikové komplexy se staršími a balíčkovými aplikacemi |
Cloudově hostované běžce, jako například BlazeMeter, LoadView a Gatling Enterprise stojí na vrcholu několika z těchto enginů a stojí za zvážení, pokud test vyžaduje desítky tisíc virtuálních uživatelů nebo provoz z více geografických oblastí. Širší přehled této kategorie je k dispozici v průvodci nástroje pro testování výkonu.
Výzvy a osvědčené postupy v testování škálovatelnosti
Nejvíce zklamáním jsou výsledky škálovatelnosti traczpět k testovacímu nastavení, nikoli k aplikaci. Toto jsou problémy, které se opakují, a návyky, které jim předcházejí.
Běžné výzvy
- Poddimenzovaná prostředí — Testovací zařízení s poloviční pamětí v produkčním prostředí hlásí úzké hrdlo, které v produkčním prostředí neexistuje.
- Nerealistické modely pracovní zátěže — Skripty bez doby na přemýšlení nebo variací dat narazí na mezipaměti, které by skuteční uživatelé přehlédli.
- Hlučné výsledky — Automatické škálování, sběr odpadků a sdílený cloudový hardware rozcházejí dva identické běhy.
- Tenká pozorovatelnost — Bez metrik na straně serveru pomalý výsledek ukazuje, že se něco pokazilo, ale ne co.
- Stát — Generování velmi vysoké souběžnosti vyžaduje vlastní flotilu generátorů zátěže, což je snadné podhodnotit.
Nejlepší postupy
- Před prvním spuštěním se dohodněte na kritériích pro úspěšné provedení, jako je percentil doby odezvy a strop chybovosti.
- V plánovaných krocích zvyšujte zátěž a každý krok podržte dostatečně dlouho, aby se systém ustálil.
- Měňte testovací data pro každého virtuálního uživatele, aby ukládání do mezipaměti nezkreslovalo výsledky.
- Shromažďujte metriky aplikací, databází a infrastruktury spolu s čísly na straně klienta.
- Uložte testovací skripty do správy verzí a spusťte krátkou kontrolu škálovatelnosti u každého sestavení a poté před vydáním kompletní kontrolu.
- Porovnávejte trendy napříč sestaveními, spíše než posuzujte jednu zprávu izolovaně.
Testování škálovatelnosti vs. zátěžové testování
Tyto dva pojmy se často zaměňují, protože oba aplikují zátěž. Rozdíl spočívá v otázce, na kterou každý z nich odpovídá: Testování škálovatelnosti se ptá, jak daleko může systém růst, zatímco zátěžové testování ptá se, zda zvládne již očekávanou zátěž.
| Základna | Testování škálovatelnosti | Testování zatížení |
|---|---|---|
| Soustředit | Zaměřuje se na výkon vašich webových stránek, softwaru, hardwaru a aplikací, když se provedou změny velikosti nebo objemu systému s cílem uspokojit rostoucí potřeby. | Zátěžové testování se zaměřuje na testování aplikace při vysoké zátěži, aby se zjistilo, v jakém bodě dochází k selhání doby odezvy systému. |
| Vzor zatížení | Zátěž se zvyšuje po krocích a mezi kroky lze přidávat zdroje. | Zatížení je udržováno na očekávané špičce po pevně stanovenou dobu |
| Odpověď na otázku | Jak daleko se tento systém může rozrůstat a co ho omezuje? | Splňuje tento systém dnes své dohodnuté cíle? |
| Typický výstup | Limit škálovatelnosti, úzké hrdlo a kapacitní plán | Úspěšné nebo neúspěšné porovnání s cílovou dobou odezvy a propustností |
Oba sedí pod nefunkční testování deštník vedle stresové testování, testování hrotů, testování odolnosti a objemové testovánía propracovaná strategie výkonu obvykle spouští několik z nich proti stejným skriptům.
