Load Testing Kompletní průvodce pro začátečníky

load testing complete guide

Kompletní průvodce testováním zátěže pro začátečníky:

V tomto tutoriálu se naučíme, proč provádíme Testování zátěže, čeho je z toho dosaženo, Architektura, jaký je přístup, který je třeba dodržet při úspěšném provedení Test zátěže, jak nastavit prostředí Test zátěže, osvědčené postupy, spolu s nejlepší nástroje pro testování zátěže dostupné na trhu.

Slyšeli jsme o funkčních i nefunkčních typech testování. V nefunkčním testování máme různé typy testování, jako je Testování výkonu, Testování zabezpečení, Testování uživatelského rozhraní atd.

Zátěžové testování je tedy nefunkční typ testování, který je podmnožinou testování výkonu.

Když tedy řekneme, že testujeme výkon aplikace, co všechno zde testujeme? Testujeme aplikaci na zatížení, objem, kapacitu, stres atd.

Co se naučíte:

• Co je testování zátěže?
• Architektura zátěžového testu
• Proč načítat testování?
• životní prostředí
• Přístup
• Osvědčené postupy
• Závěr
• Doporučené čtení

Co je testování zátěže?

Testování zátěže je podmnožinou Testování výkonu, kde testujeme odezvu systému za různých zátěžových podmínek simulací toho, že k aplikaci přistupuje více uživatelů současně. Toto testování obvykle měří rychlost a kapacitu aplikace.

Kdykoli tedy upravíme zatížení, sledujeme chování systému za různých podmínek.

Příklad :Předpokládejme, že náš požadavek klienta na přihlašovací stránku je 2–5 s a tato 2–5 s by měla být konzistentní po celou dobu, dokud nebude zatížení 5000 uživatelů. Co bychom tedy měli pozorovat? Je to jen schopnost systému nakládat s nákladem nebo je to jen požadavek na dobu odezvy?

Odpověď je obojí. Chceme systém, který zvládne zátěž 5 000 uživatelů s dobou odezvy 2–5 sekund pro všechny souběžné uživatele.

Co tedy znamená souběžný uživatel a virtuální uživatel?

Souběžní uživatelé jsou ti, kteří se přihlašují k aplikaci a současně provádějí společně sadu aktivit a současně se odhlašují z aplikace. Na druhou stranu, virtuální uživatelé pouze naskočí a vyskočí ze systému bez ohledu na aktivity ostatních uživatelů.

Architektura zátěžového testu

V níže uvedeném diagramu vidíme, jak různí uživatelé přistupují k aplikaci. Zde každý uživatel zadává požadavek přes internet, který je později předán bránou firewall.

Po firewallu máme nástroj pro vyrovnávání zatížení, který distribuuje zátěž na některý z webových serverů a poté předává aplikačnímu serveru a později databázovému serveru, kde na základě požadavku uživatele načte potřebné informace.

Zátěžové testy lze provádět ručně i pomocí nástroje. Ruční testování zátěže se ale nedoporučuje, protože aplikaci netestujeme na menší zátěž.

Příklad: Předpokládejme, že chceme otestovat aplikaci pro online nakupování, abychom viděli dobu odezvy aplikace pro každé kliknutí uživatele, tj. Krok 1 - Spusťte URL, dobu odezvy, Přihlaste se k aplikaci a poznamenejte si dobu odezvy atd. produkt, přidání do košíku, provedení platby a odhlášení. To vše musí být provedeno pro 10 uživatelů.

Takže teď, když potřebujeme otestovat zatížení aplikace pro 10 uživatelů, toho můžeme dosáhnout ručním uvedením zatížení 10 fyzických uživatelů z různých strojů namísto použití nástroje. V tomto scénáři je vhodné jít spíše na manuální zátěžový test, než na investice do nástroje a nastavení prostředí pro nástroj.

Zatímco si představte, že pokud potřebujeme zavést test pro 1500 uživatelů, pak musíme automatizovat zaváděcí test pomocí některého z dostupných nástrojů založených na technologiích, ve kterých je aplikace postavena, a také na základě rozpočtu, který máme na projekt.

Pokud máme rozpočet, můžeme jít na komerční nástroje, jako je Load runner, ale pokud nemáme příliš velký rozpočet, můžeme jít na open source nástroje, jako je JMeter atd.

jaký je nejlepší bezplatný čistič pc

Ať už se jedná o komerční nástroj nebo nástroj s otevřeným zdrojovým kódem, podrobnosti je třeba před dokončením nástroje sdílet s klientem. Obvykle je připraven důkaz konceptu, kdy pomocí nástroje vygenerujeme ukázkový skript a před dokončením ukážeme klientovi ukázkové zprávy ke schválení nástroje.

V automatizovaném testování zátěže nahrazujeme uživatele pomocí automatizačního nástroje, který napodobuje akce uživatelů v reálném čase. Automatizací načítání můžeme ušetřit zdroje i čas.

Níže je uveden diagram, který ukazuje, jak jsou uživatelé nahrazeni pomocí nástroje.

Proč načítat testování?

Předpokládejme, že existuje web pro online nakupování, který si v běžných pracovních dnech vede dobře, tj. Uživatelé se mohou přihlásit k aplikaci, procházet různé kategorie produktů, vybírat produkty, přidávat položky do košíku, odhlásit se a odhlásit se přijatelný rozsah a nedochází k žádným chybám na stránce nebo velkým dobám odezvy.

Mezitím přichází špičkový den, tj. Řekněme Den díkůvzdání a do systému jsou přihlášeny tisíce uživatelů, systém se zřítil najednou a uživatelé zaznamenali velmi pomalou odezvu, někteří nemohli ani přihlaste se na web, pár se nepodařilo přidat do košíku a některé se nepodařilo odhlásit.

Proto v tento velký den musela společnost čelit obrovské ztrátě, protože ztratila mnoho zákazníků a také mnoho obchodů. To vše se stalo jen proto, že nepředpovídali zatížení uživatelů ve špičkách, i když by předpovídali, že na webu společnosti nebyl proveden žádný test zatížení, a proto nevědí, jaké zatížení aplikace zvládne. ve špičkách.

Pro zvládnutí takových situací a za účelem překonání obrovských výnosů je vhodné provést zátěžový test pro tento typ aplikací.

• Testování zátěže pomáhá budovat silné a spolehlivé systémy.
• Úzké místo v systému je identifikováno v dostatečném předstihu před spuštěním aplikace.
• Pomáhá při identifikaci kapacity aplikace.

Co je dosaženo během zátěžového testu?

Při správném zátěžovém testu můžeme přesně pochopit následující:

1. Počet uživatelů, které je systém schopen zpracovat nebo je schopen škálování.
2. Doba odezvy každé transakce.
3. Jak se jednotlivé komponenty celého systému chovají pod zátěží, tj. Komponenty aplikačního serveru, komponenty webového serveru, komponenty databáze atd.
4. Jaká konfigurace serveru je nejlepší zvládnout zatížení?
5. Ať už je stávající hardware dostačující, nebo je potřeba dalšího hardwaru.
6. Jsou identifikována úzká místa, jako je využití CPU, využití paměti, zpoždění sítě atd.

životní prostředí

K provádění našich testů potřebujeme vyhrazené prostředí pro testování zátěže. Protože většinu času bude testovací prostředí zátěže stejné jako produkční prostředí a také data dostupná v zátěžovém testovacím prostředí budou stejná jako produkční, i když to nejsou stejná data.

Bude existovat několik testovacích prostředí, jako je prostředí SIT, prostředí QA atd., Tato prostředí nejsou stejná produkce, protože na rozdíl od testování zátěže nepotřebují tolik serverů nebo tolik testovacích dat k provedení funkčního testování nebo testování integrace.

Příklad:

V produkčním prostředí máme 3 aplikační servery, 2 webové servery a 2 databázové servery. V QA máme pouze 1 aplikační server, 1 webový server a 1 databázový server. Pokud tedy provádíme zátěžový test v prostředí QA, který se nerovná produkci, pak naše testy nejsou platné a jsou také nesprávné, a proto nemůžeme podle těchto výsledků jít.

Proto se vždy snažte mít vyhrazené prostředí pro testování zátěže, které je podobné prostředí produkčního prostředí.

Někdy také máme aplikace třetích stran, které náš systém zavolá, a proto v takových případech můžeme použít pahýly, protože nemůžeme vždy spolupracovat s dodavateli třetích stran na aktualizaci dat nebo jiných problémech či podpoře.

Pokuste se pořídit snímek prostředí, jakmile je připraveno, takže kdykoli budete chtít prostředí znovu sestavit, můžete použít tento snímek, který by pomohl se správou času. Na trhu jsou k dispozici některé nástroje pro nastavení prostředí, jako jsou Puppet, Docker atd.

Přístup

Než zahájíme test zátěže, musíme pochopit, zda je v systému již proveden test zátěže. Pokud nějaké testování zátěže proběhlo dříve, musíme vědět, jaká byla doba odezvy, metriky klienta a serveru, kolik byla kapacita zatížení uživatele atd.

Také potřebujeme informace o tom, kolik je aktuální schopnost zpracování aplikace. Pokud se jedná o novou aplikaci, musíme porozumět požadavkům, jaké je cílové zatížení, jaká je očekávaná doba odezvy a zda je skutečně dosažitelná nebo ne.

Pokud se jedná o existující aplikaci, můžete požadavky na načtení a vzory přístupu uživatelů získat z protokolů serveru. Pokud se však jedná o novou aplikaci, musíte se obrátit na obchodní tým a získat všechny informace.

Jakmile máme požadavky, musíme určit, jak provedeme zátěžový test. Dělá se to ručně nebo pomocí nástrojů? Ruční provedení zátěžového testu vyžaduje spoustu zdrojů a je také velmi drahé. Také opakování testu, znovu a znovu, bude také těžké.

Proto k překonání toho můžeme použít buď nástroje s otevřeným zdrojovým kódem, nebo komerční nástroje. Open source nástroje jsou k dispozici zdarma, tyto nástroje nemusí mít všechny funkce jako ostatní komerční nástroje, ale pokud má projekt rozpočtové omezení, můžeme jít na open source nástroje.

Zatímco komerční nástroje mají mnoho funkcí, podporují mnoho protokolů a jsou velmi uživatelsky přívětivé.

Náš přístup k testu zátěže bude následující:

# 1) Určete kritéria přijetí zátěžového testu

Například:

1. Doba odezvy přihlašovací stránky by neměla být delší než 5 s, a to ani při podmínkách maximálního zatížení.
2. Využití CPU by nemělo být vyšší než 80%.
3. Propustnost systému by měla být 100 transakcí za sekundu.

# 2) Určete obchodní scénáře, které je třeba otestovat.

Netestujte všechny toky, zkuste pochopit hlavní obchodní toky, které se ve výrobě očekávají. Pokud se jedná o existující aplikaci, můžeme jeho informace získat z protokolů serveru produkčního prostředí.

Pokud se jedná o nově vytvořenou aplikaci, musíme spolupracovat s obchodními týmy, abychom porozuměli vzorům toku, využití aplikací atd. Někdy projektový tým provede workshopy, aby poskytl přehled nebo podrobnosti o jednotlivých komponentách aplikace.

Musíme se zúčastnit aplikačního workshopu a zaznamenat všechny požadované informace, abychom mohli provést zátěžový test.

# 3) Modelování pracovního zatížení

Jakmile máme podrobnosti o obchodních tocích, vzorcích přístupu uživatelů a počtu uživatelů, musíme navrhnout pracovní zátěž takovým způsobem, který napodobuje skutečnou navigaci uživatele ve výrobě nebo podle očekávání v budoucnu, jakmile bude aplikace bude ve výrobě.

Klíčovými body, které je třeba pamatovat při navrhování modelu pracovního vytížení, je zjistit, kolik času zabere dokončení konkrétního obchodního toku. Tady musíme přiřadit dobu uvažování takovým způsobem, že uživatel bude procházet aplikací realističtěji.

Vzor pracovního zatížení bude obvykle s Ramp up, Ramp down a ustáleným stavem. Měli bychom pomalu načítat systém, a tak se používají rozběh a doběh. Ustálený stav bude obvykle jednohodinový zátěžový test s náběhem 15 minut a poklesem 15 minut.

Vezměme si příklad modelu pracovního vytížení:

Přehled aplikace - Předpokládejme online nakupování, při kterém se uživatelé přihlásí do aplikace a budou mít k dispozici širokou škálu šatů, kde budou moci procházet jednotlivé produkty.

Chcete-li zobrazit podrobnosti o každém produktu, musíte na něj kliknout. Pokud se jim líbí cena a značka produktu, mohou přidat do košíku a koupit produkt kontrolou a provedením platby.

Níže uvádíme seznam scénářů:

1. Procházet - Zde uživatel spustí aplikaci, přihlásí se do aplikace, prochází různé kategorie a odhlásí se z aplikace.
2. Procházet, zobrazit produkt, přidat do košíku - Zde se uživatel přihlásí do aplikace, prochází různé kategorie, prohlíží si podrobnosti o produktu, přidá produkt do košíku a odhlásí se.
3. Procházet, zobrazit produkt, přidat do košíku a vyzkoušet - V tomto scénáři se uživatel přihlásí do aplikace, prochází různé kategorie, prohlíží si podrobnosti o produktu, přidá produkt do košíku, provede rezervaci a odhlásí se.
4. Procházet, zobrazit produkt, přidat do košíku Zkontrolovat a provést platbu - Zde se uživatel přihlásí do aplikace, prochází různé kategorie, prohlíží si podrobnosti o produktu, přidává produkt do košíku, provádí check-out, provádí platby a odhlásí se.

Výše uvedené hodnoty byly odvozeny na základě následujících výpočtů:

• Transakce za hodinu = počet uživatelů * Transakce provedené jedním uživatelem za jednu hodinu.
• Počet uživatelů = 1600.
• Celkový počet transakcí ve scénáři Procházet = 17.
• Doba odezvy pro každou transakci = 3.
• Celkový čas pro jednoho uživatele na dokončení 17 transakcí = 17 * 3 = 51 zaokrouhlený na 60 s (1 min).
• Transakce za hodinu = 1600 * 60 = 96 000 transakcí.

# 4) Navrhněte zátěžové testy- Zátěžový test by měl být navržen s údaji, které jsme dosud shromáždili, tj. Obchodní toky, počet uživatelů, uživatelské vzory, metriky, které mají být shromážděny a analyzovány. Kromě toho by testy měly být koncipovány mnohem realističtěji.

# 5) Proveďte test zatížení - Než provedeme test zatížení, ujistěte se, že je aplikace funkční. Prostředí zátěžového testu je připraveno. Aplikace je funkčně testována a je stabilní.

Zkontrolujte nastavení konfigurace v prostředí zátěžového testu. Mělo by to být stejné jako v produkčním prostředí. Zajistěte, aby byla k dispozici všechna testovací data. Ujistěte se, že jste přidali nezbytná čítače k ​​monitorování výkonu systému během provádění testu.

Vždy začněte s malým zatížením a postupně zvyšujte zatížení. Nikdy nezačínejte s plným zatížením a nerozbijte systém.

# 6) Analyzujte výsledky zátěžového testu - Udělejte základní test, který budete vždy porovnávat s ostatními testovacími běhy. Shromážděte metriky a protokoly serveru po zkušebním provozu, abyste našli úzká místa.

Některé projekty používají k monitorování systému během zkušebního běhu nástroje pro sledování výkonu aplikací, tyto nástroje APM pomáhají snáze identifikovat hlavní příčinu a šetří spoustu času. Tyto nástroje snadno zjistí hlavní příčinu úzkého místa, protože mají široký přehled, aby přesně určily, kde je problém.

Některé z nástrojů APM na trhu zahrnují DynaTrace, Wily Introscope, App Dynamics atd.

# 7) Hlášení - Po dokončení testovacího běhu shromážděte všechny metriky a odešlete souhrnnou zprávu o testu dotčenému týmu s vašimi pozorováními a doporučeními.

Osvědčené postupy

Níže jsou uvedeny některé z osvědčených postupů testování zátěže:

# 1) Před zahájením zátěžového testu vždy zkontrolujte stabilitu aplikace. Aplikační tým by měl být funkčně stabilní podepsán funkčním testovacím týmem a všechny hlavní vady by měly být opraveny a otestovány před zkopírováním sestavení do prostředí Load Test.

#dva) Zajistěte, aby prostředí Testování zátěže bylo replikou nebo blízké produkčnímu prostředí, včetně počtu serverů, nástroje pro vyrovnávání zatížení, konfigurací serverů a bran firewall.

# 3) Před provedením zátěžového testu zkontrolujte, zda jsou data testu jedinečná a zda jsme všechna data testu zkopírovali do prostředí zátěže.

# 4) Navrhněte testovací scénáře tak, aby napodobovaly akci uživatele v reálném čase, která se děje v produkci.

# 5) Navrhněte pracovní zátěž na základě zatížení produkčních uživatelů a obchodních toků a v případě staré aplikace zjistěte, zda se jedná o nový rozhovor s obchodním týmem týkající se obchodních toků a zatížení uživatele.

# 6) Shromažďujte všechny důležité metriky, jako je doba odezvy, zásahy za sekundu, propustnost, procesor, paměť, síť a běžící uživatelé.

Doporučené čtení => Seznam nástrojů pro testování výkonu dostupných na trhu pro provádění exkluzivního testování zátěže.

Závěr

V tomto kurzu jsme se naučili, jak testování zátěže hraje důležitou roli při testování výkonu aplikace, jak pomáhá pochopit efektivitu a možnosti aplikace atd.

Zjistili jsme také, jak pomáhá předvídat, zda je v aplikaci vyžadován nějaký další hardware, software nebo vyladění.

Šťastné čtení!!

Doporučené čtení

• Testování zátěže s výukovými programy HP LoadRunner
• Alfa testování a beta testování (kompletní průvodce)
• Průvodce testováním zabezpečení webových aplikací
• Průvodce stresovým testováním pro začátečníky
• Průvodce pro začátečníky k testování penetrace webových aplikací
• Kompletní průvodce nefunkčním testováním pro začátečníky
• Kompletní průvodce pro testování ověřování sestavení (testování BVT)
• Testování výkonu vs. zátěžové testování vs. zátěžové testování (rozdíl)