Load Testing Komplet guide til begyndere

load testing complete guide

En komplet belastningstestguide til begyndere:

I denne vejledning lærer vi, hvorfor vi udfører belastningstest, hvad der opnås ud af det, arkitektur, hvad er fremgangsmåden, der skal følges for at kunne udføre en belastningstest, hvordan man opretter et belastningstestmiljø, bedste praksis sammen med markedets bedste belastningstestværktøjer.

Vi har hørt om både funktionelle og ikke-funktionelle testtyper. I ikke-funktionel test har vi forskellige typer test som Performance Test, Security Testing, User Interface Testing etc.

Derfor er belastningstestning en ikke-funktionel testtype, der er en delmængde af ydeevne testning.

Når vi siger, at vi tester en ansøgning om ydeevne, hvad tester vi altså her? Vi tester applikationen for belastning, volumen, kapacitet, stress osv.

Hvad du vil lære:

• Hvad er belastningstest?
• Indlæs testarkitektur
• Hvorfor belastningstestning?
• Miljø
• Nærme sig
• Bedste praksis
• Konklusion
• Anbefalet læsning

Hvad er belastningstest?

Load Testing er en delmængde af Performance Testing, hvor vi tester systemets respons under forskellige belastningsforhold ved at simulere flere brugere, der får adgang til applikationen samtidigt. Denne test måler normalt applikationens hastighed og kapacitet.

Så når vi ændrer belastningen, overvåger vi systemets opførsel under forskellige forhold.

Eksempel :Lad os antage, at vores kundekrav til en login-side er 2-5 sek, og at disse 2-5 sek skal være konsistente hele vejen igennem, indtil belastningen er 5000 brugere. Så hvad skal vi observere høre? Er det kun systemets lasthåndteringsevne, eller er det kun kravet om svartid?

Svaret er begge dele. Vi ønsker, at systemet kan håndtere en belastning på 5000 brugere med en responstid på 2-5 sekunder for alle samtidige brugere.

Så hvad menes med en samtidig bruger og en virtuel bruger?

Samtidige brugere er dem, der logger ind på applikationen og samtidig udfører et sæt aktiviteter sammen og logger af applikationen på samme tid. På den anden side hopper virtuelle brugere bare ind og hopper ud af systemet uanset de andre brugeraktiviteter.

Indlæs testarkitektur

I nedenstående diagram kan vi se, hvordan forskellige brugere har adgang til applikationen. Her fremsætter hver bruger en anmodning over internettet, som senere sendes gennem en firewall.

Efter firewall har vi en belastningsafbalancering, der distribuerer belastningen til en hvilken som helst af webserverne og derefter overføres til applikationsserveren og senere til databaseserveren, hvor den henter de nødvendige oplysninger baseret på brugeranmodningen.

Belastningstest kan udføres manuelt såvel som ved hjælp af et værktøj. Men manuel belastningstest anbefales ikke, da vi ikke tester applikationen for mindre belastning.

Eksempel: Lad os antage, at vi vil teste en online shoppingapplikation for at se applikationens responstid for hvert brugerklik, dvs. trin 1 –Lancering af URL, svartid, login til applikationen og bemærk responstid og så videre som at vælge en produkt, tilføje til vognen, foretage betaling og logge af. Alle disse skal gøres for 10 brugere.

Så når vi nu skal teste applikationsbelastningen for 10 brugere, kan vi opnå dette ved manuelt at lægge belastning med 10 fysiske brugere fra forskellige maskiner i stedet for at bruge et værktøj. I dette scenarie anbefales det at gå til en manuel belastningstest snarere end at investere i et værktøj og oprette et miljø til værktøjet.

Mens vi forestiller os, at hvis vi har brug for at indlæse test til 1500 brugere, skal vi automatisere belastningstesten ved hjælp af et af de tilgængelige værktøjer baseret på de teknologier, som applikationen er bygget i, og også baseret på det budget, vi har til projektet.

Hvis vi har et budget, kan vi gå efter kommercielle værktøjer som Load runner, men hvis vi ikke har meget budget, kan vi gå til open source-værktøjer som JMeter osv.

Uanset om det er et kommercielt værktøj eller et open source-værktøj, skal detaljerne deles med klienten, inden vi færdiggør værktøjet. Normalt udarbejdes et bevis på koncept, hvor vi genererer et eksemplescript ved hjælp af værktøjet og viser eksemplets rapporter til klienten til godkendelse af værktøjet, inden vi færdiggør det.

I automatiseret belastningstest erstatter vi brugerne ved hjælp af et automatiseringsværktøj, der efterligner realtidsbrugerhandlinger. Ved at automatisere belastning kan vi spare ressourcer såvel som tiden.

Nedenfor er diagrammet, der viser, hvordan brugerne udskiftes ved hjælp af et værktøj.

Hvorfor belastningstestning?

Lad os antage, at der er et online shoppingwebsted, der klarer sig ret godt under normale hverdage, dvs. brugere er i stand til at logge ind på applikationen, gennemse de forskellige produktkategorier, vælge produkter, tilføje varer til indkøbskurven, tjekke ud og logge af inden for et acceptabelt interval, og der er ingen sidefejl eller enorme svartider.

I mellemtiden kommer der en spidsdag, dvs. lad os sige Thanks Giving-dagen, og der er tusindvis af brugere, der er logget ind på systemet, systemet styrter pludselig ned, og brugerne oplever en meget langsom reaktion, nogle kunne ikke engang log ind på webstedet, nogle kunne ikke tilføje til indkøbskurv, og nogle kunne ikke tjekke ud.

Derfor på denne store dag måtte virksomheden lide et stort tab, da det mistede mange kunder og meget forretning også. Alt dette skete bare fordi de ikke forudsagde brugerbelastningen i spidsdage, selvom de ville have forudsagt, at der ikke blev foretaget nogen belastningstest på firmaets websted, hvorfor de ikke ved, hvor meget belastning applikationen vil være i stand til at håndtere på peak dage.

For at håndtere sådanne situationer og for at overvinde enorme indtægter anbefales det at udføre belastningstest for en sådan type applikationer.

• Load Testing hjælper med at opbygge stærke og pålidelige systemer.
• Flaskehalsen i systemet identificeres i god tid inden applikationen går live.
• Det hjælper med at identificere applikationens kapacitet.

Hvad opnås under en belastningstest?

Med en ordentlig belastningstest kan vi have en nøjagtig forståelse af følgende:

1. Antallet af brugere, som systemet er i stand til at håndtere eller er i stand til at skalere til.
2. Svartiden for hver transaktion.
3. Hvordan opfører hver komponent i hele systemet sig under indlæs, dvs. applikationsserverkomponenter, webserverkomponenter, databaskomponenter osv.
4. Hvilken serverkonfiguration er bedst til at håndtere belastningen?
5. Uanset om den eksisterende hardware er nok, eller er der behov for yderligere hardware.
6. Flaskehalse som CPU-udnyttelse, hukommelsesbrug, netværksforsinkelser osv. Identificeres.

Miljø

Vi har brug for et dedikeret belastningstestmiljø til at udføre vores tests. Fordi det meste af tiden belastningstestmiljøet vil være det samme som produktionsmiljøet, og de tilgængelige data i belastningstestmiljøet vil være de samme som produktion, selvom det ikke er de samme data.

Der vil være flere testmiljøer som SIT-miljø, QA-miljø osv. Disse miljøer er ikke den samme produktion, fordi de i modsætning til belastningstest ikke har brug for så mange servere eller så meget testdata for at udføre funktionstest eller en integrationstest.

Eksempel:

I et produktionsmiljø har vi 3 applikationsservere, 2 webservere og 2 databaseservere. I QA har vi kun 1 applikationsserver, 1 webserver og 1 databaseserver. Derfor, hvis vi udfører en belastningstest på QA-miljøet, som ikke er lig med produktionen, så er vores tests ikke gyldige og også forkerte, og dermed kan vi ikke gå efter disse resultater.

Så prøv altid at have et dedikeret miljø til belastningstest, der svarer til et produktionsmiljø.

Nogle gange har vi også tredjepartsapplikationer, som vores system vil ringe til, og derfor kan vi i sådanne tilfælde bruge stubbe, da vi ikke altid kan arbejde med tredjepartsleverandørerne for dataopdatering eller andre problemer eller support.

Prøv at tage et øjebliksbillede af miljøet, når det er klar, så når du vil genopbygge miljøet, kan du bruge dette øjebliksbillede, hvilket kan hjælpe med tidsstyring. Der er nogle værktøjer, der er tilgængelige på markedet for at oprette miljøet som Puppet, Docker osv.

Nærme sig

Før vi starter belastningstesten, skal vi forstå, om der allerede er foretaget en belastningstest på systemet eller ej. Hvis der blev foretaget nogen belastningstest tidligere, er vi nødt til at vide, hvad der var responstid, klient- og server-metrics indsamlet, hvor meget var brugerens belastningskapacitet osv.

Vi har også brug for information om, hvor meget den aktuelle applikationshåndteringsfunktion er. Hvis det er en ny applikation, skal vi forstå kravene, hvad er den målrettede belastning, hvad er den forventede svartid, og hvis den virkelig kan opnås eller ej.

Hvis det er et eksisterende program, kan du hente belastningskravene og brugeradgangsmønstrene fra serverlogfiler. Men hvis det er en ny applikation, skal du kontakte forretningsteamet for at få alle oplysningerne.

Når vi har opfyldt kravene, skal vi identificere, hvordan vi skal udføre belastningstesten. Gøres det manuelt eller ved hjælp af værktøjer? At lave en belastningstest manuelt har brug for mange ressourcer og er også meget dyrt. Det vil også være svært at gentage testen igen og igen.

Derfor, for at overvinde dette kan vi enten bruge Open source-værktøjer eller kommercielle værktøjer. Open source-værktøjer er tilgængelige gratis, disse værktøjer har muligvis ikke alle de funktioner som de andre kommercielle værktøjer, men hvis projektet har en budgetbegrænsning, kan vi gå efter open source-værktøjer.

Mens kommercielle værktøjer har mange funktioner, understøtter de mange protokoller og er meget brugervenlige.

Vores belastningstest tilgang er som følger:

# 1) Identificer belastningstestens acceptkriterier

For eksempel:

j2ee interviewspørgsmål til seniorudviklere

1. Responstiden på login-siden bør ikke være mere end 5 sekunder, selv under de maksimale belastningsforhold.
2. CPU-udnyttelse bør ikke være mere end 80%.
3. Systemets kapacitet skal være 100 transaktioner pr. Sek.

# 2) Identificer de forretningsscenarier, der skal testes.

Test ikke alle strømme, prøv at forstå de vigtigste forretningsstrømme, som forventes at ske i produktionen. Hvis det er en eksisterende applikation, kan vi få hans oplysninger fra produktionsmiljøets serverlogfiler.

Hvis det er en nybygget applikation, er vi nødt til at arbejde med forretningsteamene for at forstå flowmønstre, applikationsanvendelse osv. Nogle gange gennemfører projektteamet workshops for at give et overblik eller detaljer om hver komponent i applikationen.

Vi er nødt til at deltage i ansøgningsworkshopen og notere alle de nødvendige oplysninger for at udføre vores belastningstest.

# 3) Modeller til arbejdsbelastning

Når vi har fået detaljerne om forretningsstrømme, brugeradgangsmønstre og antallet af brugere, skal vi designe arbejdsbyrden på en sådan måde, at den efterligner den faktiske brugernavigation i produktionen eller som forventet at være i fremtiden, når applikationen vil være i produktion.

De vigtigste punkter, du skal huske, når du designer en arbejdsbelastningsmodel, er at se, hvor lang tid en bestemt forretningsstrøm vil tage at gennemføre. Her skal vi tildele tænketiden på en sådan måde, at brugeren navigerer på tværs af applikationen på en mere realistisk måde.

Arbejdsbelastningsmønsteret vil normalt være med en rampe op, rampe ned og en stabil tilstand. Vi skal langsomt indlæse systemet og dermed bruges rampe op og rampe ned. Den stabile tilstand vil normalt være en times belastningstest med rampe op på 15 min og ram ned på 15 min.

Lad os tage et eksempel på arbejdsbelastningsmodellen:

Oversigt over applikationen - Lad os antage en online shopping, hvor brugerne logger ind på applikationen og har en bred vifte af kjoler til at shoppe, og de kan navigere på tværs af hvert produkt.

For at se detaljerne om hvert produkt skal de klikke på produktet. Hvis de kan lide produktets pris og fabrikat, kan de føje til vognen og købe produktet ved at tjekke ud og foretage betalingen.

Nedenfor er en liste over scenarier:

1. Gennemse - Her starter brugeren applikationen, logger ind i applikationen, gennemsøger forskellige kategorier og logger ud af applikationen.
2. Gennemse, Produktvisning, Læg i kurv - Her logger brugeren ind i applikationen, gennemsøger forskellige kategorier, ser produktoplysninger, tilføjer produktet i indkøbskurven og logger ud.
3. Gennemse, Produktvisning, Læg i kurv og Tjek ud - I dette scenarie logger brugeren på applikationen, gennemsøger forskellige kategorier, ser produktoplysninger, tilføjer produktet i indkøbskurven, tjekker ud og logger ud.
4. Gennemse, Produktvisning, Læg i kurv Tjek ud og foretager betaling - Her logger brugeren ind i applikationen, gennemsøger forskellige kategorier, ser produktoplysninger, tilføjer produktet i indkøbskurven, tjekker ud, foretager betaling og logger ud.

Ovenstående værdier blev afledt baseret på følgende beregninger:

• Transaktioner pr. Time = Antal brugere * Transaktioner foretaget af en enkelt bruger på en time.
• Antallet af brugere = 1600.
• Det samlede antal transaktioner i Browse-scenariet = 17.
• Svartid for hver transaktion = 3.
• Samlet tid for en enkelt bruger til at gennemføre 17 transaktioner = 17 * 3 = 51 afrundet til 60 sek (1 min).
• Transaktioner pr. Time = 1600 * 60 = 96000 Transaktioner.

# 4) Design belastningstestene- Belastningstesten skal designes med de data, vi har samlet indtil videre, dvs. forretningsstrømme, antal brugere, brugermønstre, målinger, der skal indsamles og analyseres. Desuden skal testene designes på en meget realistisk måde.

# 5) Udfør belastningstest - Inden vi udfører belastningstesten, skal du sørge for, at applikationen er i gang. Belastningstestmiljøet er klar. Applikationen er funktionelt testet og er stabil.

Kontroller konfigurationsindstillingerne for Load-testmiljøet. Det skal være det samme som produktionsmiljøet. Sørg for, at alle testdata er tilgængelige. Sørg for at tilføje nødvendige tællere for at overvåge systemets ydeevne under testudførelsen.

Start altid med en lav belastning og øg belastningen gradvist. Start aldrig med fuld belastning og knæk systemet.

# 6) Analyser belastningstestresultaterne - Lav en baseline-test for altid at sammenligne med de andre testkørsler. Saml metrics og serverlogfiler efter testkørslen for at finde flaskehalse.

Nogle projekter bruger Application Performance Monitoring Tools til at overvåge systemet under testkørslen, disse APM-værktøjer hjælper med at identificere grundårsagen lettere og sparer meget tid. Disse værktøjer er meget nemme at finde årsagen til flaskehalsen, da de har bred visning for at finde ud af, hvor problemet er.

Nogle af APM-værktøjerne på markedet inkluderer DynaTrace, Wily Introscope, App Dynamics osv.

# 7) Rapportering - Når testkørslen er afsluttet, skal du samle alle målinger og sende testoversigtsrapporten til det pågældende team med dine observationer og anbefalinger.

Bedste praksis

Nedenfor er nogle af de bedste fremgangsmåder ved belastningstest:

# 1) Kontroller altid applikationsstabiliteten, inden du starter en belastningstest. Applikationen skal underskrives funktionelt stabilt af funktionstestteamet, og alle større fejl skal rettes og testes, før build'en kopieres til Load Test-miljøet.

#to) Sørg for, at belastningstestmiljøet er en replika eller er tæt på produktionsmiljøet, inklusive antallet af servere, belastningsbalancere, serverkonfigurationer og firewalls.

# 3) Kontroller, om testdataene er unikke, og at vi har alle testdata kopieret til belastningsmiljøet, inden vi udfører en belastningstest.

# 4) Design testscenarierne på en sådan måde, at de efterligner den realtidsbrugerhandling, der sker i produktionen.

# 5) Design arbejdsbelastningen baseret på produktionsbrugerbelastninger og forretningsstrømme, og i tilfælde af en gammel applikation, se om det er en ny samtale med forretningsteamet om forretningsstrømme og brugerbelastning.

# 6) Saml alle de vigtige målinger som svartid, hits pr. Sekund, gennemløb, CPU, hukommelse, netværk og Running Vusers.

Anbefalet Læs => Liste over ydeevne testværktøjer tilgængelige på markedet til udførelse af eksklusiv belastningstest.

Konklusion

I denne vejledning har vi lært, hvordan belastningstest spiller en vigtig rolle i præstationstestning af en applikation, hvordan det hjælper med at forstå applikationens effektivitet og kapacitet osv.

Vi lærte også, hvordan det hjælper med at forudsige, om der kræves yderligere hardware, software eller tuning til en applikation.

God læselyst!!

Anbefalet læsning

• Load Testing med HP LoadRunner-vejledninger
• Alpha Testing og Beta Testing (En komplet guide)
• Vejledning til test af webapplikationssikkerhed
• Stresstestguide til begyndere
• Begyndervejledning til penetrationstest af webapplikationer
• En komplet ikke-funktionel testguide til begyndere
• Build Verification Testing (BVT Testing) Komplet guide
• Ydelsestest vs belastningstest vs stresstest (forskel)