load testing complete guide
Kompletan vodič za ispitivanje opterećenja za početnike:
U ovom uputstvu naučit ćemo zašto provodimo ispitivanje opterećenja, što se od toga postiže, arhitektura, koji je pristup koji treba slijediti za uspješno izvršavanje testa opterećenja, kako postaviti okruženje za ispitivanje opterećenja, najbolje prakse, zajedno s najbolji alati za ispitivanje opterećenja dostupni na tržištu.
Čuli smo i za funkcionalno i za nefunkcionalno ispitivanje. U nefunkcionalnom testiranju imamo različite vrste testiranja poput testiranja performansi, sigurnosnih testova, testiranja korisničkog sučelja itd.
Stoga je ispitivanje opterećenja nefunkcionalna vrsta ispitivanja koja je podskup ispitivanja performansi.
Dakle, kad kažemo da testiramo aplikaciju za izvedbu, što sve ovdje testiramo? Testiramo aplikaciju za opterećenje, zapreminu, kapacitet, stres itd.
Što ćete naučiti:
- Što je ispitivanje opterećenja?
- Arhitektura ispitivanja opterećenja
- Zašto testiranje opterećenja?
- Okoliš
- Pristup
- Najbolje prakse
- Zaključak
- Preporučena literatura
Što je ispitivanje opterećenja?
Ispitivanje opterećenja podskup je ispitivanja performansi, gdje testiramo odgovor sustava pod različitim uvjetima opterećenja simulirajući istovremeno više korisnika koji aplikaciji pristupaju. Ovo ispitivanje obično mjeri brzinu i kapacitet aplikacije.
Stoga, kad god modificiramo opterećenje, nadgledamo ponašanje sustava pod različitim uvjetima.
Primjer :Pretpostavimo da je zahtjev našeg klijenta za stranicu za prijavu 2-5 sekundi i da bi tih 2-5 sekundi trebalo biti dosljedno sve dok učitavanje ne postane 5000 korisnika. Pa što bismo trebali promatrati čuti? Je li to samo sposobnost upravljanja opterećenjem sustava ili je to samo zahtjev vremena odziva?
Odgovor je oboje. Želimo sustav koji može podnijeti opterećenje od 5000 korisnika s vremenom odziva 2-5 sekundi za sve istodobne korisnike.
Dakle, što se podrazumijeva pod istodobnim i virtualnim korisnikom?
Istodobni korisnici su oni koji se prijavljuju u aplikaciju i istodobno izvode skup aktivnosti i istodobno se odjavljuju iz aplikacije. S druge strane, virtualni korisnici samo uskaču i uskaču iz sustava bez obzira na ostale korisničke aktivnosti.
Arhitektura ispitivanja opterećenja
Na donjem dijagramu možemo vidjeti kako različiti korisnici pristupaju aplikaciji. Ovdje svaki korisnik putem Interneta podnosi zahtjev koji se kasnije prosljeđuje kroz vatrozid.
Nakon vatrozida, imamo load balancer koji raspoređuje opterećenje na bilo koji web poslužitelj, a zatim prelazi na poslužitelj aplikacija, a kasnije na poslužitelj baze podataka, gdje dobiva potrebne informacije na temelju korisničkog zahtjeva.
Ispitivanje opterećenja može se obaviti ručno, kao i pomoću alata. No, ručno ispitivanje opterećenja se ne savjetuje jer ne testiramo aplikaciju za manje opterećenje.
Primjer: Pretpostavimo da želimo testirati aplikaciju za internetsku kupnju kako bismo vidjeli vrijeme odziva aplikacije za svaki klik korisnika, tj. Korak1 - URL za pokretanje, vrijeme odziva, prijava u aplikaciju i bilježenje vremena odziva itd., Poput odabira proizvoda, dodavanje u košaricu, plaćanje i odjava. Sve to mora biti učinjeno za 10 korisnika.
Dakle, sada kada trebamo testirati opterećenje aplikacije za 10 korisnika, to možemo postići ručnim stavljanjem opterećenja od 10 fizičkih korisnika s različitih strojeva, umjesto da koristimo alat. U ovom je scenariju poželjno otići na ručno ispitivanje opterećenja, a ne ulagati u alat i postaviti okruženje za alat.
Dok zamislimo ako trebamo učitati test za 1500 korisnika, tada moramo automatizirati test učitavanja pomoću bilo kojeg dostupnog alata koji se temelji na tehnologijama u kojima je aplikacija izgrađena, a također na temelju proračuna koji imamo za projekt.
Ako imamo proračun, onda možemo odabrati komercijalne alate kao što je Load runner, ali ako nemamo puno proračuna, onda možemo koristiti alate otvorenog koda poput JMeter itd.
pitanja i odgovori na internetski intervju za programere
Bez obzira radi li se o komercijalnom alatu ili alatu otvorenog koda, detalje moramo podijeliti s klijentom prije nego što finaliziramo alat. Obično se priprema dokaz o konceptu, gdje generiramo uzorak skripte pomoću alata i prikazujemo uzorke izvješća klijentu na odobrenje za alat prije finaliziranja.
U automatiziranom ispitivanju opterećenja zamjenjujemo korisnike uz pomoć automatiziranog alata koji oponaša radnje korisnika u stvarnom vremenu. Automatizacijom opterećenja možemo uštedjeti resurse kao i vrijeme.
Ispod je dijagram koji prikazuje kako se korisnici zamjenjuju pomoću alata.
Zašto testiranje opterećenja?
Pretpostavimo da postoji web stranica za internetsku kupnju koja prilično dobro posluje tijekom uobičajenih radnih dana, tj. Korisnici se mogu prijaviti u aplikaciju, pregledavati različite kategorije proizvoda, odabrati proizvode, dodati artikle u košaricu, odjaviti se i odjaviti se unutar prihvatljiv raspon i nema pogrešaka na stranici ili ogromnog vremena odziva.
U međuvremenu dolazi vrhunac, tj. Recimo Dan zahvalnosti i tisuće je korisnika koji su prijavljeni u sustav, sustav se iznenada srušio i korisnici imaju vrlo spor odgovor, neki čak nisu mogli prijavite se na web mjesto, nekoliko ih nije uspjelo dodati u košaricu, a neke nisu uspjeli odjaviti.
Stoga se ovaj veliki dan tvrtka morala suočiti s velikim gubitkom jer je izgubila mnogo kupaca i mnogo posla. Sve se to dogodilo samo zato što nisu predvidjeli opterećenje korisnika za vršne dane, čak i da bi predvidjeli da na web mjestu tvrtke nije izvršen test učitavanja, stoga ne znaju s koliko opterećenja će aplikacija moći podnijeti u vršnim danima.
Stoga je za rješavanje takvih situacija i za prevladavanje ogromnog prihoda poželjno provesti test opterećenja za takvu vrstu aplikacija.
- Ispitivanje opterećenja pomaže u izgradnji snažnih i pouzdanih sustava.
- Usko grlo u sustavu identificira se unaprijed prije nego što aplikacija krene s radom.
- Pomaže u utvrđivanju kapaciteta aplikacije.
Što se postiže tijekom ispitivanja opterećenja?
Ispravnim testom opterećenja možemo točno razumjeti sljedeće:
- Broj korisnika koje sustav može obraditi ili ih je sposoban prilagoditi.
- Vrijeme odziva svake transakcije.
- Kako se ponaša svaka komponenta cijelog sustava u okviru Učitavanja, tj. Komponente poslužitelja aplikacija, komponente web poslužitelja, komponente baze podataka itd.
- Koja je konfiguracija poslužitelja najbolja za rukovanje opterećenjem?
- Je li postojeći hardver dovoljan ili postoji li potreba za dodatnim hardverom.
- Utvrđena su uska grla poput upotrebe CPU-a, upotrebe memorije, mrežnih kašnjenja itd.
Okoliš
Za provođenje testova potrebno nam je posebno okruženje za ispitivanje opterećenja. Budući da će većinom vrijeme okruženja za ispitivanje opterećenja biti isto kao i proizvodno okruženje, a također će i podaci dostupni u okruženju za ispitivanje opterećenja biti isti kao i proizvodnja, iako to nisu isti podaci.
Bit će više testnih okruženja poput SIT okruženja, QA okruženja itd., Ta okruženja nisu ista produkcija, jer za razliku od testiranja opterećenja ne trebaju toliko poslužitelja ili toliko testnih podataka za provođenje funkcionalnog testiranja ili integracijskog testiranja.
Primjer:
U proizvodnom okruženju imamo 3 aplikacijska poslužitelja, 2 web poslužitelja i 2 poslužitelja baze podataka. U QA imamo samo 1 poslužitelj aplikacija, 1 web poslužitelj i 1 poslužitelj baze podataka. Dakle, ako provodimo test opterećenja na QA okruženju koji nije jednak proizvodnom, tada naši testovi nisu valjani, a također su netočni, pa stoga ne možemo ići prema ovim rezultatima.
Stoga uvijek nastojte imati namjensko okruženje za ispitivanje opterećenja koje je slično okruženju proizvodnog okruženja.
Također, ponekad imamo programe treće strane koje će naš sustav pozvati, stoga u takvim slučajevima možemo koristiti kvarove jer ne možemo uvijek raditi s nezavisnim dobavljačima za osvježavanje podataka ili bilo koje druge probleme ili podršku.
Pokušajte napraviti snimku okoline kad je spremna, tako da, kad god želite obnoviti okruženje, možete upotrijebiti ovu snimku koja će vam pomoći u upravljanju vremenom. Postoje neki alati dostupni na tržištu za postavljanje okruženja poput Lutka, Docker itd.
Pristup
Prije nego započnemo test opterećenja moramo shvatiti je li test opterećenja već napravljen na sustavu ili nije. Ako je ranije izvršeno testiranje učitavanja, tada moramo znati koje je vrijeme odziva, prikupljene metrike klijenta i poslužitelja, kolika je bila korisnička nosivost itd.
Također, trebamo informacije o tome kolika je trenutna sposobnost rukovanja aplikacijama. Ako je riječ o novoj aplikaciji, moramo razumjeti zahtjeve, koje je ciljano opterećenje, koje je očekivano vrijeme odziva i je li to stvarno moguće ili nije.
Ako se radi o postojećoj aplikaciji, iz dnevnika poslužitelja možete dobiti zahtjeve za učitavanjem i obrasce korisničkog pristupa. Ali ako se radi o novoj aplikaciji, trebate kontaktirati poslovni tim da biste dobili sve informacije.
Nakon što imamo zahtjeve, moramo prepoznati kako ćemo izvršiti test opterećenja. Radi li se ručno ili pomoću alata? Ručno provođenje testa opterećenja zahtijeva puno resursa, a također je vrlo skupo. Također će biti teško ponavljati test, iznova i iznova.
Stoga, da bismo to prevladali, možemo koristiti alate otvorenog koda ili komercijalne alate. Alati otvorenog koda dostupni su besplatno, ti alati možda neće imati sve značajke poput ostalih komercijalnih alata, ali ako projekt ima ograničenje proračuna, onda možemo koristiti alate otvorenog koda.
Iako komercijalni alati imaju brojne značajke, podržavaju mnoge protokole i vrlo su jednostavni za upotrebu.
Naš pristup ispitivanju opterećenja bit će sljedeći:
# 1) Utvrdite kriterije prihvaćanja ispitivanja opterećenja
Na primjer:
- Vrijeme odziva stranice za prijavu ne bi trebalo biti duže od 5 sek, čak i za vrijeme maksimalnog učitavanja.
- Korištenje CPU-a ne bi trebalo biti veće od 80%.
- Propusnost sustava trebala bi biti 100 transakcija u sekundi.
# 2) Identificirajte poslovne scenarije koje treba testirati.
Ne testirajte sve tokove, pokušajte razumjeti glavne poslovne tokove za koje se očekuje da će se dogoditi u proizvodnji. Ako se radi o postojećoj aplikaciji, njegove podatke možemo dobiti iz dnevnika poslužitelja proizvodnog okruženja.
Ako je riječ o novoizgrađenoj aplikaciji, tada moramo surađivati s poslovnim timovima kako bismo razumjeli obrasce protoka, upotrebu aplikacija itd. Ponekad će projektni tim provoditi radionice kako bi dao pregled ili detalje o svakoj komponenti aplikacije.
Moramo pohađati radionicu za prijavu i zabilježiti sve potrebne podatke za provođenje testa opterećenja.
# 3) Modeliranje radnog opterećenja
Nakon što dobijemo detalje o poslovnim tokovima, obrascima pristupa korisnika i broju korisnika, trebamo dizajnirati radno opterećenje na takav način da oponaša stvarnu korisničku navigaciju u proizvodnji ili kako se očekuje u budućnosti nakon aplikacije bit će u proizvodnji.
Ključne točke kojih se trebate sjetiti tijekom dizajniranja modela radnog opterećenja jest vidjeti koliko će vremena trebati određenom poslovnom tijeku. Ovdje moramo dodijeliti vrijeme razmišljanja na takav način da će korisnik navigirati aplikacijom na realniji način.
Uzorak radnog opterećenja obično će biti s Rampom prema gore, Rampom prema dolje i u stabilnom stanju. Trebali bismo polako učitavati sustav i tako se koriste rampe prema gore i dolje. Stacionarno stanje obično će biti jednosatni test opterećenja s rampom do 15 minuta i ramom do 15 minuta.
Uzmimo primjer modela opterećenja:
Pregled aplikacije - Pretpostavimo internetsku kupnju, gdje će se korisnici prijaviti u aplikaciju i imati široku paletu haljina za kupnju, a mogu se kretati po svakom proizvodu.
Da bi pogledali pojedinosti o svakom proizvodu, trebaju kliknuti na proizvod. Ako im se sviđa cijena i izrada proizvoda, mogu dodati u košaricu i kupiti proizvod provjerom i plaćanjem.
Slijedi popis scenarija:
- pretraživati - Ovdje korisnik pokreće aplikaciju, prijavljuje se u program, pregledava različite kategorije i odjavljuje se iz aplikacije.
- Pregledavanje, pregled proizvoda, dodavanje u košaricu - Ovdje se korisnik prijavljuje u aplikaciju, pregledava različite kategorije, pregledava detalje o proizvodu, dodaje proizvod u košaricu i odjavljuje se.
- Pregledajte, pregledajte proizvode, dodajte u košaricu i odjavite - U ovom se scenariju korisnik prijavljuje u aplikaciju, pregledava različite kategorije, pregledava detalje o proizvodu, dodaje proizvod u košaricu, vrši provjeru i odjavu.
- Pregledajte, prikaz proizvoda, dodajte u košaricu Odjavi se i vrši plaćanje - Ovdje se korisnik prijavljuje u aplikaciju, pregledava različite kategorije, pregledava detalje o proizvodu, dodaje proizvod u košaricu, vrši provjeru, vrši plaćanje i odjavi se.
S.Br | Poslovni tijek | Broj transakcija | Učitavanje virtualnog korisnika | Vrijeme odziva (sek) | % Dopuštena stopa kvara | Transakcije po satu |
---|---|---|---|---|---|---|
1 | pretraživati | 17 | 1600 | 3 | Manje od 2% | 96000 |
dva | Pregledavanje, pregled proizvoda, dodavanje u košaricu | 17 | 200 | 3 | Manje od 2% | 12000 |
3 | Pregledajte, pregledajte proizvode, dodajte u košaricu i odjavite | 18 | 120 | 3 | Manje od 2% | 7200 |
4 | Pregledajte, prikaz proizvoda, dodajte u košaricu Odjavi se i vrši plaćanje | dvadeset | 80 | 3 | Manje od 2% | 4800 |
Gornje vrijednosti izvedene su na temelju sljedećih izračuna:
- Transakcije po satu = Broj korisnika * Transakcije koje je izvršio jedan korisnik u jednom satu.
- Broj korisnika = 1600.
- Ukupan broj transakcija u scenariju Pregledaj = 17.
- Vrijeme odgovora za svaku transakciju = 3.
- Ukupno vrijeme za jednog korisnika da izvrši 17 transakcija = 17 * 3 = 51 zaokruženo na 60 sekundi (1 min).
- Transakcije po satu = 1600 * 60 = 96000 transakcija.
# 4) Dizajnirajte testove opterećenja- Test opterećenja trebao bi biti dizajniran s podacima koje smo do sada prikupili, tj. Poslovnim tokovima, brojem korisnika, korisničkim uzorcima, mjernim podacima koji se prikupljaju i analiziraju. Štoviše, testovi bi trebali biti dizajnirani na mnogo realniji način.
# 5) Izvršite test opterećenja - Prije nego što izvršimo test učitavanja, provjerite je li program pokrenut i pokrenut. Okružje za ispitivanje opterećenja je spremno. Aplikacija je funkcionalno testirana i stabilna je.
Provjerite konfiguracijske postavke okruženja za testiranje učitavanja. Trebao bi biti jednak proizvodnom okruženju. Provjerite jesu li dostupni svi podaci o ispitivanju. Obavezno dodajte potrebne brojače za praćenje performansi sustava tijekom izvođenja testa.
Uvijek započnite s malim opterećenjem i postupno povećavajte opterećenje. Nikada nemojte započeti s punim opterećenjem i razbiti sustav.
# 6) Analizirajte rezultate ispitivanja opterećenja - Imajte osnovni test koji ćete uvijek usporediti s ostalim probama. Skupite mjerne podatke i zapisnike poslužitelja nakon probnog rada kako biste pronašli uska grla.
Neki projekti koriste alate za praćenje izvedbe aplikacija za nadzor sustava tijekom probnog rada, ti APM alati pomažu u lakšem prepoznavanju osnovnog uzroka i uštedi puno vremena. Pomoću ovih alata lako je pronaći osnovni uzrok uskog grla jer imaju široki pogled kako bi precizno odredili gdje je problem.
Neki od APM alata na tržištu uključuju DynaTrace, Wily Introscope, App Dynamics itd.
# 7) Izvještavanje - Nakon završetka probnog rada, prikupite sve mjerne podatke i pošaljite izvještaj o sažetku ispitivanja dotičnom timu sa svojim zapažanjima i preporukama.
Najbolje prakse
U nastavku su navedeni neki od najboljih praksi ispitivanja opterećenja:
# 1) Uvijek provjerite stabilnost aplikacije prije početka testa opterećenja. Tim za funkcionalno testiranje prijavu treba potpisati funkcionalno stabilno, a sve glavne nedostatke treba otkloniti i testirati prije kopiranja izrade u okruženje za ispitivanje učitavanja.
#dva) Provjerite je li okruženje za testiranje učitavanja replika ili je blisko proizvodnom okruženju, uključujući broj poslužitelja, uravnoteživače opterećenja, konfiguracije poslužitelja i vatrozid.
# 3) Prije provođenja testa opterećenja provjerite jesu li testni podaci jedinstveni i kopiramo li sve testne podatke u okruženje opterećenja.
# 4) Dizajnirajte scenarije testiranja na takav način da oponašaju radnju korisnika u stvarnom vremenu koja se događa u proizvodnji.
# 5) Dizajnirajte radno opterećenje na temelju korisničkih opterećenja proizvodnje i poslovnih tokova, a u slučaju stare aplikacije, pogledajte je li riječ o novom razgovoru s poslovnim timom u vezi s poslovnim tijekovima i korisničkim opterećenjem.
# 6) Prikupite sve važne mjerne podatke poput vremena odziva, pogodaka u sekundi, protoka, CPU-a, memorije, mreže i vusera koji rade.
Preporučeno čitanje => Popis alata za ispitivanje performansi dostupnih na tržištu za provođenje ekskluzivnog ispitivanja opterećenja.
Zaključak
U ovom vodiču naučili smo kako testiranje opterećenja igra važnu ulogu u testiranju performansi aplikacije, kako pomaže razumjeti učinkovitost i sposobnost aplikacije itd.
Također smo saznali kako pomaže predvidjeti je li potreban dodatni hardver, softver ili podešavanje na aplikaciji.
Sretno čitanje !!
Preporučena literatura
- Ispitivanje opterećenja pomoću HP LoadRunner vodiča
- Alfa testiranje i beta testiranje (cjelovit vodič)
- Vodič za ispitivanje sigurnosti web aplikacija
- Vodič za testiranje naprezanja za početnike
- Vodič za početnike za ispitivanje prodora web aplikacija
- Cjelovit nefunkcionalni vodič za testiranje za početnike
- Potpuni vodič za testiranje provjere izrade (BVT testiranje)
- Ispitivanje performansi vs ispitivanje opterećenja vs testiranje naprezanja (razlika)