load testing complete guide
Kompletný sprievodca testovaním zaťaženia pre začiatočníkov:
V tomto tutoriále sa dozvieme, prečo vykonávame Testovanie záťaže, čo sa z toho dá vyťažiť, Architektúru, aký je prístup, ktorý je potrebné dodržať pri úspešnom vykonaní Testovania záťaže, ako nastaviť prostredie Testovania záťaže, osvedčené postupy spolu s najlepšie nástroje na testovanie záťaže dostupné na trhu.
Počuli sme o typoch funkčného aj nefunkčného testovania. V nefunkčnom testovaní máme rôzne typy testovania, ako napríklad Testovanie výkonu, Testovanie bezpečnosti, Testovanie používateľského rozhrania atď.
Preto je testovanie záťaže nefunkčným typom testovania, ktoré je podmnožinou testovania výkonu.
Keď teda povieme, že testujeme výkonnosť aplikácie, čo všetko tu testujeme? Testujeme aplikáciu na načítanie, objem, kapacitu, stres atď.
Čo sa dozviete:
- Čo je testovanie záťaže?
- Architektúra záťažového testu
- Prečo testovanie záťaže?
- Životné prostredie
- Prístup
- Osvedčené postupy
- Záver
- Odporúčané čítanie
Čo je testovanie záťaže?
Testovanie zaťaženia je podmnožinou Testovania výkonu, kde testujeme reakciu systému za rôznych podmienok zaťaženia simuláciou toho, že k aplikácii pristupuje viac používateľov súčasne. Toto testovanie zvyčajne meria rýchlosť a kapacitu aplikácie.
Preto kedykoľvek upravíme zaťaženie, sledujeme správanie systému za rôznych podmienok.
Príklad :Predpokladajme, že požiadavka klienta na prihlasovaciu stránku je 2 - 5 s a táto 2 - 5 s by mala byť konzistentná po celú dobu, kým nebude zaťaženie 5 000 používateľov. Čo by sme teda mali pozorovať, počuť? Je to iba schopnosť systému manipulovať s bremenom alebo je to len požiadavka na čas odozvy?
Odpoveď je oboje. Chceme systém, ktorý zvládne zaťaženie 5 000 používateľov s dobou odozvy 2 - 5 sekúnd pre všetkých súbežných používateľov.
Čo teda znamená súbežný používateľ a virtuálny používateľ?
Súbežnými používateľmi sú tí, ktorí sa prihlásia do aplikácie a súčasne vykonávajú množinu aktivít a súčasne sa z aplikácie odhlásia. Na druhej strane, virtuálni používatelia iba naskakujú a vyskakujú zo systému bez ohľadu na aktivity ostatných používateľov.
Architektúra záťažového testu
Na nasledujúcom diagrame vidíme, ako rôzni používatelia pristupujú k aplikácii. Tu každý používateľ zadáva požiadavku cez internet, ktorá sa neskôr odovzdá cez bránu firewall.
Po bráne firewall máme nástroj na vyrovnávanie zaťaženia, ktorý distribuuje zaťaženie na ktorýkoľvek z webových serverov a potom prechádza na aplikačný server a neskôr na databázový server, kde na základe žiadosti používateľa načíta potrebné informácie.
Testovanie záťaže je možné vykonať ručne aj pomocou nástroja. Ručné testovanie načítania sa však neodporúča, pretože aplikáciu netestujeme na menšie načítanie.
Príklad: Predpokladajme, že chceme otestovať aplikáciu na nakupovanie online, aby sme videli čas odozvy aplikácie pre každé kliknutie používateľa, tj. Krok 1 - spustenie adresy URL, čas odozvy, prihlásenie do aplikácie a poznačte si čas odozvy atď., Napríklad výber produkt, pridanie do košíka, uskutočnenie platby a odhlásenie. To všetko musí byť vykonané pre 10 používateľov.
Takže teraz, keď potrebujeme otestovať zaťaženie aplikácie pre 10 používateľov, to môžeme dosiahnuť tak, že namiesto použitia nástroja manuálne prenesieme zaťaženie 10 fyzických používateľov z rôznych strojov. V tomto scenári je vhodné ísť skôr na manuálny test zaťaženia, ako na investovanie do nástroja a nastavenie prostredia pre tento nástroj.
Zatiaľ čo si predstavte, že ak potrebujeme test zaťaženia pre 1 500 používateľov, potom musíme test zaťaženia automatizovať pomocou ktoréhokoľvek z dostupných nástrojov založených na technológiách, v ktorých je aplikácia postavená, a tiež na základe rozpočtu, ktorý máme na projekt.
Ak máme rozpočet, môžeme ísť na komerčné nástroje, ako je Load runner, ale ak nemáme veľa, potom na nástroje s otvoreným zdrojom, ako je JMeter atď.
v čom je linux lepší ako windows
Či už ide o komerčný nástroj alebo nástroj s otvoreným zdrojovým kódom, podrobnosti je potrebné zdieľať s klientom skôr, ako tento nástroj dokončíme. Spravidla sa pripravuje proof of concept, kde pomocou nástroja vygenerujeme vzorový skript a ukážkové správy ukážeme klientovi na schválenie nástroja pred jeho dokončením.
V automatizovanom testovaní záťaže nahradzujeme používateľov pomocou automatizačného nástroja, ktorý napodobňuje akcie používateľov v reálnom čase. Automatizáciou načítania môžeme ušetriť zdroje aj čas.
Ďalej je uvedený diagram, ktorý zobrazuje spôsob výmeny používateľov pomocou nástroja.
Prečo testovanie záťaže?
Predpokladajme, že existuje webová stránka na nakupovanie online, ktorá je v bežných pracovných dňoch veľmi dobrá, tj. Používatelia sa môžu prihlásiť do aplikácie, prechádzať rôznymi kategóriami produktov, vyberať produkty, pridávať položky do košíka, odhlásiť sa a odhlásiť sa z nej. prijateľný rozsah a nevyskytujú sa žiadne chyby na stránke ani veľké doby odozvy.
Medzitým prichádza špičkový deň, tj. Povedzme deň vďakyvzdania a do systému sú prihlásené tisíce používateľov, systém naraz spadol a používatelia majú veľmi pomalú odozvu, niektorí dokonca nedokázali prihlásiť sa na web, niekoľko sa nepodarilo pridať do košíka a niektoré sa nepodarilo odhlásiť.
Preto v tento veľký deň musela spoločnosť čeliť obrovským stratám, pretože prišla o veľa zákazníkov a veľa obchodov. To všetko sa stalo len preto, že nepredpovedali zaťaženie používateľov počas špičkových dní, aj keď by predpovedali, že na webe spoločnosti nebol vykonaný žiadny test zaťaženia, a preto nevedia, aké veľké zaťaženie bude aplikácia schopná zvládnuť. vo vrcholových dňoch.
Na zvládnutie takýchto situácií a na prekonanie obrovských výnosov je vhodné vykonať test zaťaženia pre tento typ aplikácií.
- Testovanie záťaže pomáha budovať silné a spoľahlivé systémy.
- Úzke miesto v systéme je identifikované v dostatočnom predstihu pred zverejnením aplikácie.
- Pomáha pri identifikácii kapacity aplikácie.
Čo sa dosiahne počas záťažového testu?
Pri správnom teste zaťaženia môžeme presne porozumieť nasledujúcemu:
- Počet používateľov, ktorých je systém schopný spracovať alebo je schopný ich škálovať.
- Čas odozvy každej transakcie.
- Ako sa chová každá súčasť celého systému pri načítaní, tj. Komponenty aplikačného servera, komponenty webového servera, komponenty databázy atď.
- Aká konfigurácia servera je najlepšia na zvládnutie záťaže?
- Či už je súčasný hardvér dostatočný, alebo je potrebný ďalší hardvér.
- Identifikujú sa úzke miesta, ako je využitie procesora, využitie pamäte, oneskorenia v sieti atď.
Životné prostredie
Na vykonávanie našich testov potrebujeme špeciálne prostredie pre testovanie záťaže. Pretože prostredie testovania záťaže bude väčšinou rovnaké ako produkčné prostredie a tiež údaje dostupné v prostredí testovania záťaže budú rovnaké ako produkčné, hoci nejde o rovnaké údaje.
Bude existovať niekoľko testovacích prostredí, ako je prostredie SIT, prostredie QA atď., Tieto prostredia nie sú rovnakou produkciou, pretože na rozdiel od testovania záťaže nepotrebujú toľko serverov alebo toľko testovacích údajov na vykonávanie funkčných testov alebo integračných testov.
Príklad:
V produkčnom prostredí máme 3 aplikačné servery, 2 webové servery a 2 databázové servery. V QA máme iba 1 aplikačný server, 1 webový server a 1 databázový server. Ak teda vykonáme záťažový test v prostredí QA, ktorý sa nerovná produkcii, potom naše testy nie sú platné a sú tiež nesprávne, a preto nemôžeme ísť podľa týchto výsledkov.
Preto sa vždy snažte mať vyhradené prostredie pre testovanie záťaže, ktoré je podobné ako v produkčnom prostredí.
Niekedy tiež máme aplikácie tretích strán, ktoré náš systém zavolá, a preto v takýchto prípadoch môžeme použiť pahýly, pretože nemôžeme vždy spolupracovať s dodávateľmi tretích strán na aktualizácii údajov alebo iných problémoch či podpore.
Skúste vytvoriť snímku prostredia, akonáhle je pripravené, takže kedykoľvek chcete prostredie znova vytvoriť, môžete použiť túto snímku, ktorá by pomohla s riadením času. Na trhu existuje niekoľko nástrojov na nastavenie prostredia, ako sú Puppet, Docker atď.
Prístup
Predtým, ako začneme záťažový test, musíme pochopiť, či už je v systéme nejaký záťažový test hotový alebo nie. Ak bolo predtým vykonané nejaké testovanie zaťaženia, musíme vedieť, aký bol čas odozvy, metriky klienta a servera, aká bola kapacita načítania používateľa atď.
Potrebujeme tiež informácie o tom, koľko je súčasná schopnosť spracovania aplikácií. Ak je to nová aplikácia, musíme porozumieť požiadavkám, aké je cieľové zaťaženie, aký je očakávaný čas odozvy a či je skutočne dosiahnuteľný alebo nie.
Ak ide o existujúcu aplikáciu, požiadavky na načítanie a vzory prístupu používateľov môžete získať z denníkov servera. Ak sa však jedná o novú aplikáciu, musíte kontaktovať obchodný tím a získať všetky informácie.
Keď máme požiadavky, musíme zistiť, ako vykonáme záťažový test. Robí sa to ručne alebo pomocou nástrojov? Manuálny test zaťaženia vyžaduje veľa zdrojov a je tiež veľmi drahý. Rovnako náročné bude aj opakovanie testu, znovu a znovu.
Z tohto dôvodu môžeme na prekonanie tohto problému použiť buď nástroje otvoreného zdroja, alebo komerčné nástroje. Nástroje otvoreného zdroja sú k dispozícii zadarmo, tieto nástroje nemusia mať všetky funkcie podobné ostatným komerčným nástrojom, ale ak má projekt obmedzenie rozpočtu, môžeme ísť na nástroje otvoreného zdroja.
Aj keď komerčné nástroje majú veľa funkcií, podporujú veľa protokolov a sú veľmi užívateľsky prívetivé.
Náš prístup k testu záťaže bude nasledovný:
# 1) Identifikujte kritériá prijatia záťažového testu
Napríklad:
- Doba odozvy na prihlasovacej stránke by nemala byť viac ako 5 s, a to ani pri podmienkach maximálneho načítania.
- Využitie procesora by nemalo byť väčšie ako 80%.
- Priepustnosť systému by mala byť 100 transakcií za sekundu.
# 2) Identifikujte obchodné scenáre, ktoré je potrebné testovať.
Netestujte všetky toky, pokúste sa porozumieť hlavným obchodným tokom, ktoré sa očakávajú vo výrobe. Pokiaľ ide o existujúcu aplikáciu, môžeme jeho informácie získať z protokolov servera produkčného prostredia.
Ak sa jedná o novo zostavenú aplikáciu, musíme spolupracovať s obchodnými tímami, aby sme porozumeli tokovým vzorcom, použitiu aplikácie atď. Projektový tím niekedy uskutoční workshopy, ktoré poskytnú prehľad alebo podrobnosti o každej súčasti aplikácie.
Musíme absolvovať aplikačný workshop a poznačiť si všetky požadované informácie, aby sme mohli vykonať test zaťaženia.
# 3) Modelovanie pracovného zaťaženia
Keď už máme podrobnosti o obchodných tokoch, vzorcoch prístupu používateľov a počte používateľov, musíme navrhnúť pracovné zaťaženie takým spôsobom, aby napodobňovalo skutočnú navigáciu používateľa vo výrobe alebo podľa očakávaní v budúcnosti po aplikácii. bude vo výrobe.
Kľúčovými bodmi, ktoré je potrebné pamätať pri navrhovaní modelu pracovného zaťaženia, je zistiť, koľko času bude trvať dokončenie konkrétneho obchodného toku. Tu musíme priradiť čas na premýšľanie takým spôsobom, že používateľ bude v aplikácii navigovať realistickejšie.
Vzor pracovného zaťaženia bude zvyčajne s Ramp up, Ramp down a ustáleným stavom. Mali by sme pomaly načítať systém a tým pádom sa používajú nájazdové a príjazdové rampy. Ustálený stav bude zvyčajne hodinový záťažový test s nábehom o 15 minút a poklesom o 15 minút.
Zoberme si príklad modelu pracovného zaťaženia:
Prehľad aplikácie - Predpokladajme online nakupovanie, pri ktorom sa používatelia prihlásia do aplikácie a budú si môcť kúpiť rôzne šaty, ktoré im umožňujú prechádzať jednotlivé produkty.
Ak chcete zobraziť podrobnosti o každom produkte, je potrebné kliknúť na daný produkt. Ak sa im páči cena a značka produktu, môžu ho vložiť do košíka a kúpiť produkt vykonaním platby a vykonaním platby.
Ďalej uvádzame zoznam scenárov:
- Prechádzať - Tu používateľ spustí aplikáciu, prihlási sa do aplikácie, prehľadá rôzne kategórie a odhlási sa z aplikácie.
- Prehliadať, Prezerať si produkt, Pridať do košíka - Tu sa používateľ prihlási do aplikácie, prechádza rôznymi kategóriami, prezerá si podrobnosti o produkte, pridáva produkt do košíka a odhlási sa.
- Prejdite, prehliadnite si produkt, pridajte do košíka a odhláste sa - V tomto scenári sa používateľ prihlási do aplikácie, prezerá rôzne kategórie, prezerá si podrobnosti o produkte, pridáva produkt do košíka, odhlasuje sa a odhlási sa.
- Prehliadať, zobraziť produkt, pridať do košíka Odhlásiť sa a uskutočniť platbu - Tu sa používateľ prihlási do aplikácie, prezerá rôzne kategórie, prezerá si podrobnosti o produkte, pridáva produkt do košíka, kontroluje platby, vykonáva platby a odhlási sa.
S.No | Obchodný tok | Počet transakcií | Virtuálne načítanie používateľa | Čas odozvy (s) | % Povolená miera zlyhania | Transakcie za hodinu |
---|---|---|---|---|---|---|
1 | Prechádzať | 17 | 1600 | 3 | Menej ako 2% | 96000 |
dva | Prehliadať, Prezerať si produkt, Pridať do košíka | 17 | 200 | 3 | Menej ako 2% | 12000 |
3 | Prejdite, prehliadnite si produkt, pridajte do košíka a odhláste sa | 18 | 120 | 3 | Menej ako 2% | 7200 |
4 | Prehliadať, zobraziť produkt, pridať do košíka Odhlásiť sa a uskutočniť platbu | dvadsať | 80 | 3 | Menej ako 2% | 4800 |
Vyššie uvedené hodnoty boli odvodené na základe nasledujúcich výpočtov:
- Transakcie za hodinu = počet používateľov * Transakcie uskutočnené jedným používateľom za jednu hodinu.
- Počet používateľov = 1600.
- Celkový počet transakcií v scenári prehľadávania = 17.
- Čas odozvy pre každú transakciu = 3.
- Celkový čas pre jedného používateľa na dokončenie 17 transakcií = 17 * 3 = 51 zaokrúhlený na 60 sekúnd (1 min).
- Transakcie za hodinu = 1 600 * 60 = 96 000 transakcií.
# 4) Navrhnite testy zaťaženia- Zaťažovací test by mal byť navrhnutý s údajmi, ktoré sme doteraz zhromaždili, t. J. Obchodné toky, počet používateľov, používateľské vzory, metriky, ktoré sa majú zhromaždiť a analyzovať. Testy by navyše mali byť koncipované veľmi realisticky.
# 5) Vykonajte test zaťaženia - Pred vykonaním testu zaťaženia sa uistite, či je aplikácia funkčná. Prostredie záťažového testu je pripravené. Aplikácia je funkčne testovaná a je stabilná.
Skontrolujte konfiguračné nastavenia prostredia Load test. Malo by to byť to isté ako produkčné prostredie. Zaistite, aby boli k dispozícii všetky údaje o teste. Nezabudnite pridať potrebné počítadlá na sledovanie výkonu systému počas vykonávania testu.
Začnite vždy s malým zaťažením a záťaž postupne zvyšujte. Nikdy nezačínajte s plnou záťažou a systém nerozbite.
# 6) Analyzujte výsledky záťažového testu - Pripravte si základný test, ktorý chcete vždy porovnať s ostatnými testovacími chodmi. Zhromaždite metriky a protokoly servera po testovacej prevádzke, aby ste našli úzke miesta.
Niektoré projekty používajú na sledovanie systému počas testovacej prevádzky nástroje na sledovanie výkonu aplikácií. Tieto nástroje APM pomáhajú ľahšie identifikovať hlavnú príčinu a ušetria veľa času. Tieto nástroje ľahko nájdu hlavnú príčinu úzkeho miesta, pretože majú široký prehľad a umožňujú určiť, kde je problém.
Niektoré z nástrojov APM na trhu zahŕňajú DynaTrace, Wily Introscope, App Dynamics atď.
# 7) Podávanie správ - Po dokončení testovacej prevádzky zhromaždite všetky metriky a pošlite súhrnnú správu o teste dotknutému tímu s vašimi pozorovaniami a odporúčaniami.
Osvedčené postupy
Nižšie sú uvedené niektoré z najlepších postupov testovania záťaže:
# 1) Pred začatím zaťažovacieho testu vždy skontrolujte stabilitu aplikácie. Aplikácia by mala byť funkčne stabilná podpísaná tímom funkčných testov a všetky hlavné chyby by mali byť opravené a otestované pred kopírovaním zostavenia do prostredia Load Test.
#dva) Zaistite, aby prostredie testovania záťaže bolo replikou alebo blízkym produkčnému prostrediu, vrátane počtu serverov, nástrojov na vyrovnávanie zaťaženia, konfigurácií serverov a brán firewall.
# 3) Pred vykonaním záťažového testu skontrolujte, či sú testovacie údaje jedinečné a či máme všetky testovacie údaje skopírované do prostredia záťaže.
# 4) Navrhnite testovacie scenáre tak, aby napodobňovali akciu používateľa v reálnom čase, ktorá sa deje vo výrobe.
# 5) Navrhnite pracovné zaťaženie na základe zaťaženia produkčných používateľov a obchodných tokov a v prípade starej aplikácie zistite, či sa jedná o nový rozhovor s obchodným tímom o obchodných tokoch a zaťažení používateľov.
# 6) Zhromažďujte všetky dôležité metriky, ako je čas odozvy, prístupy za sekundu, priepustnosť, procesor, pamäť, sieť a spustení používateľov.
Odporúčané čítanie => Zoznam nástrojov na testovanie výkonu dostupných na trhu na vykonávanie výhradného testovania záťaže.
Záver
V tomto tutoriáli sme sa naučili, ako testovanie záťaže hrá dôležitú úlohu pri testovaní výkonu aplikácie, ako pomáha pochopiť efektívnosť a schopnosť aplikácie atď.
Zistili sme tiež, ako pomáha predvídať, či je v aplikácii potrebný ďalší hardvér, softvér alebo vyladenie.
Príjemné čítanie !!
Odporúčané čítanie
- Testovanie záťaže s výukovými programami HP LoadRunner
- Alfa testovanie a beta testovanie (kompletný sprievodca)
- Sprievodca testovaním bezpečnosti webových aplikácií
- Sprievodca stresovým testovaním pre začiatočníkov
- Sprievodca pre začiatočníkov k testovaniu penetrácie webových aplikácií
- Kompletný sprievodca nefunkčnými testami pre začiatočníkov
- Kompletný sprievodca zostavením Verification Testing (BVT Testing)
- Výkonové testovanie vs záťažové testovanie vs záťažové testovanie (rozdiel)