load testing complete guide
En komplett lastetestguide for nybegynnere:
I denne opplæringen vil vi lære hvorfor vi utfører lastetesting, hva som oppnås ut av det, arkitektur, hva er tilnærmingen som skal følges for å kunne utføre en lastetest, hvordan du setter opp et belastningstestmiljø, beste praksis, sammen med markedets beste lasttestverktøy.
Vi har hørt om både funksjonelle og ikke-funksjonelle testtyper. I ikke-funksjonell testing har vi forskjellige typer testing som ytelsestesting, sikkerhetstesting, testing av brukergrensesnitt etc.
Derfor er belastningstesting en ikke-funksjonell type testing som er en delmengde av ytelsestesting.
Når vi sier at vi tester en applikasjon for ytelse, hva tester vi altså her? Vi tester applikasjonen for belastning, volum, kapasitet, stress etc.
Hva du vil lære:
- Hva er belastningstesting?
- Last testarkitektur
- Hvorfor lastetesting?
- Miljø
- Nærme seg
- Beste praksis
- Konklusjon
- Anbefalt lesing
Hva er belastningstesting?
Load Testing er en delmengde av Performance Testing, der vi tester systemets respons under varierende belastningsforhold ved å simulere flere brukere som får tilgang til applikasjonen samtidig. Denne testen måler vanligvis hastigheten og kapasiteten til applikasjonen.
Når vi endrer belastningen, overvåker vi således systemets oppførsel under forskjellige forhold.
Eksempel :La oss anta at kundekravet vårt for en påloggingsside er 2-5 sek, og at dette 2-5 sek skal være konsistent hele veien til belastningen er 5000 brukere. Så hva bør vi observere høre? Er det bare systemets lasthåndteringsevne, eller er det bare kravet om responstid?
Svaret er begge deler. Vi ønsker systemet som kan håndtere en belastning på 5000 brukere med responstid på 2-5 sekunder for alle samtidige brukere.
Så hva menes med en samtidig bruker og en virtuell bruker?
Samtidige brukere er de som logger på applikasjonen og samtidig utfører et sett med aktiviteter sammen og logger av applikasjonen samtidig. På den annen side hopper virtuelle brukere bare inn og hopper ut av systemet uavhengig av andre brukeraktiviteter.
Last testarkitektur
I diagrammet nedenfor kan vi se hvordan forskjellige brukere får tilgang til applikasjonen. Her gjør hver bruker en forespørsel over internett, som senere sendes gjennom en brannmur.
Etter brannmur har vi en Load balancer som distribuerer belastningen til hvilken som helst av webserverne, og deretter går til applikasjonsserveren og senere til databaseserveren der den henter nødvendig informasjon basert på brukerforespørselen.
Lastetesting kan gjøres manuelt og ved hjelp av et verktøy. Men manuell belastningstesting anbefales ikke, ettersom vi ikke tester applikasjonen for mindre belastning.
Eksempel: La oss anta at vi ønsker å teste en online shoppingapplikasjon for å se responstiden for applikasjonen for hvert brukerklikk, dvs. trinn 1 –Lansere URL, responstid, Logg inn på applikasjonen og legg merke til responstid og så videre som å velge en produkt, legge til i handlekurven, betale og logge av. Alt dette må gjøres for 10 brukere.
Så når vi trenger å teste applikasjonsbelastningen for 10 brukere, kan vi oppnå dette ved å legge belastningen manuelt av 10 fysiske brukere fra forskjellige maskiner i stedet for å bruke et verktøy. I dette scenariet anbefales det å gå for en manuell belastningstest i stedet for å investere i et verktøy og sette opp et miljø for verktøyet.
Mens du forestiller deg at hvis vi trenger å laste test for 1500 brukere, må vi automatisere belastningstesten ved hjelp av et av de tilgjengelige verktøyene basert på teknologiene applikasjonen er bygget i og også basert på budsjettet vi har for prosjektet.
Hvis vi har et budsjett, kan vi gå for kommersielle verktøy som Load runner, men hvis vi ikke har mye budsjett, kan vi gå for open source-verktøy som JMeter, etc.
kvalitetsanalytiker intervju spørsmål og svar
Enten det er et kommersielt verktøy eller et åpen kildekodeverktøy, må detaljene deles med klienten før vi fullfører verktøyet. Vanligvis utarbeides et bevis på konseptet der vi genererer et eksempelskript ved hjelp av verktøyet og viser eksempler på rapportene til klienten for godkjenning av verktøyet før vi fullfører det.
I automatisert belastningstesting erstatter vi brukerne ved hjelp av et automatiseringsverktøy som etterligner sanntids brukerhandlinger. Ved å automatisere belastning kan vi spare ressurser og tid.
Nedenfor er diagrammet som viser hvordan brukerne byttes ut ved hjelp av et verktøy.
Hvorfor lastetesting?
La oss anta at det er et nettbasert shoppingnettsted som gjør det ganske bra under normale virkedager, dvs. at brukerne kan logge på applikasjonen, bla gjennom de forskjellige produktkategoriene, velge produkter, legge til varer i handlekurven, sjekke ut og logge av innen et akseptabelt område, og det er ingen sidefeil eller enorme responstider.
I mellomtiden kommer det en toppdag, dvs. la oss si Thanks Giving-dagen, og det er tusenvis av brukere som er logget på systemet, systemet krasjer plutselig og brukerne opplever en veldig langsom respons, noen kunne ikke engang logg inn på nettstedet, noen klarte ikke å legge til i handlekurven, og noen klarte ikke å sjekke ut.
Derfor på denne store dagen måtte selskapet møte et stort tap ettersom det mistet mange kunder og mye forretning også. Alt dette skjedde bare fordi de ikke forutsa brukerbelastningen i toppdager, selv om de ville ha spådd at det ikke ble gjort noen belastningstest på selskapets nettside, og de vet derfor ikke hvor mye belastning applikasjonen vil kunne håndtere på toppdagene.
For å håndtere slike situasjoner og for å overvinne store inntekter, er det tilrådelig å gjennomføre belastningstest for en slik type applikasjoner.
- Load Testing hjelper deg med å bygge sterke og pålitelige systemer.
- Flaskehalsen i systemet er identifisert i god tid før søknaden går live.
- Det hjelper med å identifisere kapasiteten til applikasjonen.
Hva oppnås under en belastningstest?
Med en skikkelig belastningstest kan vi ha en nøyaktig forståelse av følgende:
- Antall brukere systemet er i stand til å håndtere eller er i stand til å skalere til.
- Svartiden for hver transaksjon.
- Hvordan oppfører hver komponent i hele systemet seg under Last inn dvs. applikasjonsserverkomponenter, webserverkomponenter, databaskomponenter etc.
- Hvilken serverkonfigurasjon er best for å håndtere belastningen?
- Enten den eksisterende maskinvaren er nok, eller er det behov for ekstra maskinvare.
- Flaskehalser som CPU-bruk, minnebruk, nettverksforsinkelser osv. Identifiseres.
Miljø
Vi trenger et dedikert belastningstestemiljø for å gjennomføre testene våre. Fordi belastningstestmiljøet mesteparten av tiden vil være det samme som produksjonsmiljøet, og dataene som er tilgjengelige i lastetestmiljøet vil være de samme som produksjonen, selv om det ikke er de samme dataene.
Det vil være flere testmiljøer som SIT-miljø, QA-miljø osv. Disse miljøene er ikke den samme produksjonen, fordi de i motsetning til belastningstesting ikke trenger så mange servere eller så mye testdata for å utføre funksjonstesting eller en integrasjonstesting.
Eksempel:
I et produksjonsmiljø har vi 3 applikasjonsservere, 2 webservere og 2 databaseservere. I QA har vi bare 1 applikasjonsserver, 1 webserver og 1 databaseserver. Derfor, hvis vi utfører en belastningstest på QA-miljøet som ikke er lik produksjonen, så er testene våre ikke gyldige og er også feil, og dermed kan vi ikke gå etter disse resultatene.
Prøv derfor alltid å ha et dedikert miljø for belastningstesting som ligner på et produksjonsmiljø.
Noen ganger har vi også tredjepartsapplikasjoner som systemet vårt vil ringe til, og i slike tilfeller kan vi bruke stubber, ettersom vi ikke alltid kan samarbeide med tredjepartsleverandørene for dataoppdatering eller andre problemer eller støtte.
Prøv å ta et øyeblikksbilde av miljøet når det er klart, slik at når du vil gjenoppbygge miljøet, kan du bruke dette øyeblikksbildet, noe som kan hjelpe deg med tidsstyring. Det er noen verktøy som er tilgjengelige i markedet for å sette opp miljøet som Puppet, Docker etc.
Nærme seg
Før vi starter Load-testen, må vi forstå om det allerede er gjort Load-test på systemet eller ikke. Hvis det ble gjort lastetesting tidligere, må vi vite hva som var responstid, klient- og serverberegning samlet, hvor mye var brukerens lastekapasitet etc.
Vi trenger også informasjon om hvor mye den nåværende applikasjonshåndteringsfunksjonen er. Hvis det er en ny applikasjon, må vi forstå kravene, hva er målrettet belastning, hva er forventet responstid og om den virkelig er oppnåelig eller ikke.
Hvis det er et eksisterende program, kan du få belastningskravene og brukeradgangsmønstrene fra serverloggene. Men hvis det er en ny applikasjon, må du nå ut til forretningsteamet for å få all informasjon.
Når vi har kravene, må vi identifisere hvordan vi skal gjennomføre lastetesten. Gjøres det manuelt eller ved hjelp av verktøy? Å gjøre en lastetest manuelt trenger mange ressurser og er også veldig dyrt. Å gjenta testen, igjen og igjen, vil også være tøff.
Derfor, for å overvinne dette, kan vi enten bruke verktøy med åpen kildekode eller kommersielle verktøy. Åpne kildekodeverktøy er tilgjengelig gratis, disse verktøyene har kanskje ikke alle funksjonene som de andre kommersielle verktøyene, men hvis prosjektet har en budsjettbegrensning, kan vi gå etter verktøy med åpen kildekode.
Mens kommersielle verktøy har mange funksjoner, støtter de mange protokoller og er veldig brukervennlige.
Load Test-tilnærmingen vår vil være som følger:
# 1) Identifiser kriteriene for godkjenning av belastningstest
For eksempel:
- Responstiden for påloggingssiden bør ikke være mer enn 5 sekunder, selv ikke under maksimale belastningsforhold.
- CPU-utnyttelse bør ikke være mer enn 80%.
- Gjennomstrømningen til systemet skal være 100 transaksjoner per sekund.
# 2) Identifiser forretningsscenariene som må testes.
Ikke test alle strømmer, prøv å forstå de viktigste forretningsstrømmene som forventes å skje i produksjonen. Hvis det er en eksisterende applikasjon, kan vi få informasjonen hans fra serverloggene i produksjonsmiljøet.
Hvis det er en nybygd applikasjon, må vi samarbeide med forretningsteamene for å forstå flytmønster, applikasjonsbruk etc. Noen ganger vil prosjektgruppen gjennomføre workshops for å gi en oversikt eller detaljer om hver komponent i applikasjonen.
Vi må delta på søknadsverkstedet og legge merke til all nødvendig informasjon for å gjennomføre lastetesten.
# 3) Modeller for arbeidslast
Når vi har detaljene om forretningsstrømmene, brukertilgangsmønstrene og antall brukere, må vi utforme arbeidsmengden på en slik måte at den etterligner den faktiske brukernavigasjonen i produksjonen eller som forventet å være i fremtiden når applikasjonen vil være i produksjon.
Nøkkelpunktene du må huske når du designer en arbeidsbelastningsmodell, er å se hvor lang tid en bestemt forretningsstrøm vil ta å fullføre. Her må vi tilordne tenketiden på en slik måte at brukeren vil navigere over applikasjonen på en mer realistisk måte.
Arbeidsbelastningsmønsteret vil vanligvis være med en rampe opp, rampe ned og en jevn tilstand. Vi bør sakte laste systemet og dermed brukes rampe opp og rampe ned. Jevn tilstand vil vanligvis være en times belastningstest med Ramp opp på 15 min og Ram ned på 15 min.
La oss ta et eksempel på arbeidsbelastningsmodellen:
Oversikt over applikasjonen - La oss anta en online shopping, der brukerne vil logge inn på applikasjonen og ha et bredt utvalg av kjoler å handle, og de kan navigere på tvers av hvert produkt.
For å se detaljene om hvert produkt, må de klikke på produktet. Hvis de liker produktets pris og merke, kan de legge til i handlekurven og kjøpe produktet ved å sjekke ut og betale.
Nedenfor er en liste over scenarier:
- Bla gjennom - Her starter brukeren applikasjonen, logger seg inn i applikasjonen, blar gjennom forskjellige kategorier og logger seg ut av applikasjonen.
- Bla gjennom, Produktvisning, Legg i handlekurven - Her logger brukeren seg inn i applikasjonen, blar gjennom forskjellige kategorier, viser produktdetaljer, legger produktet i handlekurven og logger av.
- Bla gjennom, Produktvisning, Legg i handlekurven og sjekk ut - I dette scenariet logger brukeren seg på applikasjonen, blar gjennom forskjellige kategorier, viser produktdetaljer, legger til produktet i handlekurven, sjekker ut og logger ut.
- Bla gjennom, Produktvisning, Legg i handlekurven Sjekk ut og betaler - Her logger brukeren seg inn i applikasjonen, blar gjennom forskjellige kategorier, viser produktdetaljer, legger produktet i handlekurven, sjekker ut, foretar betaling og logger ut.
S. nr | Forretningsflyt | Antall transaksjoner | Virtuell brukerbelastning | Svartid (sek) | % Feilfrekvens tillatt | Transaksjoner per time |
---|---|---|---|---|---|---|
1 | Bla gjennom | 17 | 1600 | 3 | Mindre enn 2% | 96000 |
to | Bla gjennom, Produktvisning, Legg i handlekurven | 17 | 200 | 3 | Mindre enn 2% | 12000 |
3 | Bla gjennom, Produktvisning, Legg i handlekurven og sjekk ut | 18 | 120 | 3 | Mindre enn 2% | 7200 |
4 | Bla gjennom, Produktvisning, Legg i handlekurven Sjekk ut og betaler | tjue | 80 | 3 | Mindre enn 2% | 4800 |
Ovennevnte verdier ble avledet basert på følgende beregninger:
- Transaksjoner per time = Antall brukere * Transaksjoner gjort av en enkelt bruker på en time.
- Antall brukere = 1600.
- Totalt antall transaksjoner i Bla gjennom-scenariet = 17.
- Svartid for hver transaksjon = 3.
- Total tid for en enkelt bruker å fullføre 17 transaksjoner = 17 * 3 = 51 avrundet til 60 sek (1 min).
- Transaksjoner per time = 1600 * 60 = 96000 Transaksjoner.
# 4) Design lastetestene- Lastetesten skal utformes med dataene vi har samlet inn så langt, dvs. forretningsstrømmene, antall brukere, brukermønstre, beregninger som skal samles inn og analyseres. Videre bør testene utformes på en mye realistisk måte.
# 5) Utfør belastningstest - Før vi utfører belastningstesten, må du sørge for at applikasjonen er i gang. Lasttestmiljøet er klart. Applikasjonen er funksjonstestet og er stabil.
Kontroller konfigurasjonsinnstillingene for Last testmiljøet. Det skal være det samme som produksjonsmiljøet. Forsikre deg om at alle testdataene er tilgjengelige. Sørg for å legge til nødvendige tellere for å overvåke systemytelsen under testutførelsen.
Start alltid med lav belastning og øk belastningen gradvis. Start aldri med full belastning og ødelegg systemet.
# 6) Analyser belastningstestresultatene - Har en baselinjetest for alltid å sammenligne med de andre testkjøringene. Samle beregningene og serverloggene etter testkjøringen for å finne flaskehalsene.
Noen prosjekter bruker Application Performance Monitoring Tools for å overvåke systemet under testkjøringen. Disse APM-verktøyene hjelper deg med å identifisere grunnårsaken lettere og sparer mye tid. Disse verktøyene er veldig enkle å finne årsaken til flaskehalsen, ettersom de har bred visning for å finne ut hvor problemet er.
Noen av APM-verktøyene i markedet inkluderer DynaTrace, Wily Introscope, App Dynamics etc.
# 7) Rapportering - Når testkjøringen er fullført, samler du alle beregningene og sender testoppsummeringsrapporten til det aktuelle teamet med dine observasjoner og anbefalinger.
Beste praksis
Nedenfor er noen av de beste metodene for lastetesting:
#1) Sjekk alltid applikasjonsstabiliteten før du starter en belastningstest. Søknaden skal signeres funksjonelt stabil av funksjonstesteteamet, og alle større feil skal rettes og testes før bygningen kopieres til belastningstestmiljøet.
#to) Forsikre deg om at belastningstestmiljøet er en kopi eller er nær produksjonsmiljøet, inkludert antall servere, belastningsbalansere, serverkonfigurasjoner og brannmurer.
# 3) Sjekk om testdataene er unike, og vi har alle testdataene kopiert til lastmiljøet før du gjennomfører en lastetest.
# 4) Design testscenariene på en slik måte at de etterligner den sanntidsbrukerhandlingen som skjer i produksjonen.
# 5) Design arbeidsmengden basert på produksjonsbrukerlastene og forretningsstrømmene, og i tilfelle en gammel applikasjon, se om det er en ny samtale med forretningsteamet angående forretningsstrømmene og brukerbelastningen.
# 6) Samle alle viktige beregninger som responstid, treff per sekund, gjennomstrømning, CPU, minne, nettverk og Running Vusers.
Anbefalt lese => Liste over ytelsestestingsverktøy tilgjengelig i markedet for å utføre eksklusiv lastetesting.
Konklusjon
I denne veiledningen har vi lært hvordan belastningstesting spiller en viktig rolle i ytelsestesting av et program, hvordan det hjelper å forstå effektiviteten og evnen til applikasjonen, etc.
Vi fikk også vite hvordan det hjelper å forutsi om det er nødvendig med ekstra maskinvare, programvare eller tuning på et program.
Glad lesning !!
Anbefalt lesing
- Lastetesting med HP LoadRunner-veiledninger
- Alpha Testing og Beta Testing (En komplett guide)
- Veiledning for testing av webapplikasjoner
- Stresstesting guide for nybegynnere
- Nybegynnerveiledning for penetreringstesting av webapplikasjoner
- En komplett ikke-funksjonell testveiledning for nybegynnere
- Build Verification Testing (BVT Testing) Komplett guide
- Ytelsestesting vs belastningstesting vs stresstesting (forskjell)