Lasttestning Komplett guide för nybörjare

load testing complete guide

En komplett lasttestguide för nybörjare:

I den här handledningen kommer vi att lära oss varför vi utför Load Testing, vad som uppnås av det, Arkitektur, vilken metod ska följas för att framgångsrikt utföra ett Load Test, hur man skapar en Load Test-miljö, bästa praxis, tillsammans med de bästa lasttestverktygen som finns på marknaden.

Vi har hört talas om både funktionella och icke-funktionella testtyper. I icke-funktionell testning har vi olika typer av test som prestandatestning, säkerhetstestning, testning av användargränssnitt etc.

Därför är belastningstestning en icke-funktionell typ av testning som är en delmängd av prestandatestning.

När vi säger att vi testar en ansökan om prestanda, vad testar vi alltså här? Vi testar applikationen för belastning, volym, kapacitet, stress etc.

Vad du kommer att lära dig:

• Vad är belastningstestning?
• Ladda testarkitektur
• Varför belastningstestning?
• Miljö
• Närma sig
• Bästa praxis
• Slutsats
• Rekommenderad läsning

Vad är belastningstestning?

Load Testing är en delmängd av Performance Testing, där vi testar systemets respons under varierande belastningsförhållanden genom att simulera flera användare som får åtkomst till applikationen samtidigt. Denna testning mäter vanligtvis applikationens hastighet och kapacitet.

Således när vi ändrar belastningen övervakar vi systemets beteende under olika förhållanden.

Exempel :Låt oss anta att vårt kundkrav för en inloggningssida är 2-5 sekunder och att dessa 2-5 sekunder ska vara konsekventa hela tiden tills belastningen är 5000 användare. Så vad ska vi observera hör? Är det bara systemets lasthanteringsförmåga eller är det bara kravet på svarstid?

Svaret är båda. Vi vill ha systemet som kan hantera en belastning på 5000 användare med en svarstid på 2-5 sekunder för alla samtidiga användare.

Så vad menas med en samtidig användare och en virtuell användare?

Samtidiga användare är de som loggar in på applikationen och samtidigt utför en uppsättning aktiviteter tillsammans och loggar av applikationen samtidigt. Å andra sidan hoppar virtuella användare bara in och hoppar ut ur systemet oavsett andra användaraktiviteter.

Ladda testarkitektur

I nedanstående diagram kan vi se hur olika användare har tillgång till applikationen. Här gör varje användare en förfrågan över internet, som senare skickas genom en brandvägg.

Efter brandväggen har vi en belastningsutjämnare som distribuerar belastningen till någon av webbservrarna och sedan skickas till applikationsservern och senare till databasservern där den hämtar nödvändig information baserat på användarförfrågan.

Lasttestning kan göras manuellt och med hjälp av ett verktyg. Men manuell belastningstest rekommenderas inte eftersom vi inte testar applikationen för mindre belastning.

Exempel: Låt oss anta att vi vill testa en online shoppingapplikation för att se svarstiden för applikationen för varje användarklick, dvs steg 1 –Lansera URL, svarstiden, logga in på applikationen och notera svarstiden och så vidare som att välja en produkt, lägga till i kundvagnen, betala och logga ut. Alla dessa måste göras för 10 användare.

Så nu när vi behöver testa applikationsbelastningen för 10 användare kan vi uppnå detta genom att manuellt sätta belastning med 10 fysiska användare från olika maskiner istället för att använda ett verktyg. I det här scenariot är det lämpligt att gå till ett manuellt belastningstest snarare än att investera i ett verktyg och skapa en miljö för verktyget.

Föreställ dig att om vi behöver ladda test för 1500 användare måste vi automatisera belastningstestet med hjälp av något av de tillgängliga verktygen baserat på den teknik som applikationen är byggd i och även baserat på den budget vi har för projektet.

Om vi ​​har en budget kan vi gå till kommersiella verktyg som Load runner men om vi inte har mycket budget kan vi gå till open source-verktyg som JMeter etc.

världens bästa datahackingsprogramvara gratis nedladdning

Oavsett om det är ett kommersiellt verktyg eller ett open source-verktyg, måste detaljerna delas med klienten innan vi slutför verktyget. Vanligtvis utarbetas ett bevis på koncept, där vi genererar ett exempelskript med verktyget och visar exempelrapporterna till klienten för godkännande av verktyget innan vi slutför det.

Vid automatiserad belastningstestning ersätter vi användarna med hjälp av ett automatiseringsverktyg som efterliknar användaråtgärder i realtid. Genom att automatisera belastning kan vi spara resurser såväl som tid.

Nedan följer diagrammet som visar hur användarna byts ut med ett verktyg.

Varför belastningstestning?

Låt oss anta att det finns en online-shoppingwebbplats som gör det ganska bra under normala arbetsdagar, dvs. användare kan logga in på applikationen, bläddra igenom de olika produktkategorierna, välja produkter, lägga till varor i kundvagnen, kolla in och logga ut inom ett acceptabelt intervall och det finns inga sidfel eller enorma svarstider.

Under tiden kommer det en toppdag, dvs låt oss säga Thanks Giving day och det finns tusentals användare som är inloggade i systemet, systemet kraschar plötsligt och användarna upplever ett mycket långsamt svar, vissa kunde inte ens logga in på webbplatsen, några kunde inte lägga till i kundvagnen och andra kunde inte checka ut.

Därför på denna stora dag, företaget var tvungen att möta en enorm förlust eftersom det förlorade många kunder och mycket affärer också. Allt detta hände bara för att de inte förutspådde användarbelastningen under toppdagar, även om de skulle ha förutsagt att det inte gjordes något belastningstest på företagets webbplats, därför vet de inte hur mycket belastning applikationen kommer att kunna hantera på toppdagarna.

För att hantera sådana situationer och för att övervinna stora intäkter är det därför lämpligt att utföra belastningstest för en sådan typ av applikationer.

• Load Testing hjälper till att bygga starka och tillförlitliga system.
• Flaskhalsen i systemet identifieras i god tid innan ansökan startar.
• Det hjälper till att identifiera applikationens kapacitet.

Vad uppnås under ett belastningstest?

Med ett ordentligt belastningstest kan vi ha en exakt förståelse för följande:

1. Antalet användare som systemet kan hantera eller kan skalas till.
2. Svarstiden för varje transaktion.
3. Hur beter sig varje komponent i hela systemet under Load, dvs. applikationsserverkomponenter, webbserverkomponenter, databaskomponenter etc.
4. Vilken serverkonfiguration är bäst för att hantera belastningen?
5. Oavsett om den befintliga hårdvaran räcker eller finns det något behov av ytterligare hårdvara.
6. Flaskhalsar som CPU-användning, minnesanvändning, nätverksfördröjningar etc. identifieras.

Miljö

Vi behöver en särskild belastningstestmiljö för att genomföra våra tester. Eftersom belastningstestmiljön oftast kommer att vara densamma som produktionsmiljön och även de data som finns tillgängliga i belastningstestmiljön kommer att vara desamma som produktion men det är inte samma data.

Det kommer att finnas flera testmiljöer som SIT-miljö, QA-miljö etc., dessa miljöer är inte samma produktion, för till skillnad från belastningstestning behöver de inte så många servrar eller så mycket testdata för att utföra funktionstestning eller en integrationstestning.

Exempel:

I en produktionsmiljö har vi 3 applikationsservrar, 2 webbservrar och 2 databasservrar. I QA har vi bara 1 applikationsserver, 1 webbserver och 1 databasserver. Därför, om vi utför ett belastningstest på QA-miljön som inte är lika med produktionen, så är våra tester inte giltiga och är också felaktiga och därmed kan vi inte följa dessa resultat.

Försök därför alltid att ha en dedikerad miljö för belastningstestning som liknar den i en produktionsmiljö.

Ibland har vi ibland tredjepartsapplikationer som vårt system kommer att ringa, och i sådana fall kan vi använda stubbar eftersom vi inte alltid kan arbeta med tredjepartsleverantörer för datauppdatering eller andra problem eller support.

Försök att ta en ögonblicksbild av miljön när den är klar så att när du vill bygga om miljön kan du använda den här ögonblicksbilden, vilket skulle hjälpa till med tidshantering. Det finns några verktyg som finns på marknaden för att ställa in miljön som Puppet, Docker etc.

Närma sig

Innan vi startar Load-testet måste vi förstå om något Load-test redan har gjorts på systemet eller inte. Om det gjordes någon lasttest tidigare, måste vi veta vad som var svarstiden, klient- och serverstatistik som samlats in, hur mycket användarkapacitet etc.

Vi behöver också information om hur mycket den nuvarande kapaciteten för applikationshantering är. Om det är en ny applikation måste vi förstå kraven, vad är den riktade belastningen, vad är den förväntade svarstiden och om den verkligen kan uppnås eller inte.

Om det är ett befintligt program kan du hämta belastningskraven och användaråtkomstmönstren från serverloggarna. Men om det är en ny applikation måste du nå affärsteamet för att få all information.

När vi väl har kraven måste vi identifiera hur vi ska utföra lastprovet. Görs det manuellt eller med hjälp av verktyg? Att göra ett lasttest manuellt kräver mycket resurser och är också mycket dyrt. Att upprepa testet, om och om igen, blir också tufft.

Därför kan vi antingen använda Open source-verktyg eller kommersiella verktyg för att övervinna detta. Öppna källkodsverktyg är tillgängliga gratis, dessa verktyg kanske inte har alla funktioner som de andra kommersiella verktygen, men om projektet har en budgetbegränsning kan vi gå efter öppen källkodsverktyg.

Medan kommersiella verktyg har många funktioner stöder de många protokoll och är mycket användarvänliga.

Vår metod för belastningstest kommer att vara som följer:

# 1) Identifiera kriterierna för godkännande av belastningstest

Till exempel:

1. Svarstiden för inloggningssidan bör inte vara mer än 5 sekunder även under maxbelastningsförhållandena.
2. CPU-användningen bör inte vara mer än 80%.
3. Systemets genomströmning bör vara 100 transaktioner per sekund.

# 2) Identifiera de affärsscenarier som behöver testas.

Testa inte alla flöden, försök att förstå de viktigaste affärsflödena som förväntas ske i produktionen. Om det är en befintlig applikation kan vi få hans information från serverloggarna i produktionsmiljön.

Om det är en nybyggd applikation måste vi arbeta med affärsteamen för att förstå flödesmönster, applikationsanvändning etc. Ibland kommer projektgruppen att genomföra workshops för att ge en översikt eller detaljer om varje komponent i applikationen.

Vi måste delta i ansökningsverkstaden och notera all nödvändig information för att genomföra vårt lasttest.

# 3) Modellering av arbetsbelastning

När vi väl har fått information om affärsflöden, användaråtkomstmönster och antalet användare måste vi utforma arbetsbelastningen på ett sådant sätt att den efterliknar den faktiska användarnavigeringen i produktionen eller som förväntas vara i framtiden när applikationen kommer att vara i produktion.

Viktiga punkter att komma ihåg när du utformar en arbetsbelastningsmodell är att se hur mycket tid ett visst affärsflöde tar att slutföra. Här måste vi tilldela tänketiden på ett sådant sätt att användaren navigerar över applikationen på ett mer realistiskt sätt.

Arbetsbelastningsmönstret är vanligtvis med en Ramp upp, Ramp ner och ett stabilt tillstånd. Vi bör sakta ladda systemet och därmed använda ramp upp och ramp ned. Steady state är vanligtvis ett timmes belastningstest med Ramp upp på 15 min och Ram ner på 15 min.

Låt oss ta ett exempel på arbetsbelastningsmodellen:

Översikt över applikationen - Låt oss anta en online-shopping där användarna loggar in i applikationen och har ett brett utbud av klänningar att handla, och de kan navigera över varje produkt.

För att se detaljerna om varje produkt måste de klicka på produkten. Om de gillar produktens kostnad och tillverkning kan de lägga till i kundvagnen och köpa produkten genom att checka ut och göra betalningen.

Nedan följer en lista över scenarier:

1. Bläddra - Här startar användaren applikationen, loggar in i applikationen, bläddrar igenom olika kategorier och loggar ut ur applikationen.
2. Bläddra, Produktvy, Lägg i kundvagn - Här loggar användaren in i applikationen, bläddrar i olika kategorier, visar produktinformation, lägger till produkten i kundvagnen och loggar ut.
3. Bläddra, Produktvy, Lägg i kundvagn och kolla in - I det här scenariot loggar användaren in i applikationen, bläddrar igenom olika kategorier, visar produktinformation, lägger till produkten i kundvagnen, checkar ut och loggar ut.
4. Bläddra, Produktvy, Lägg i kundvagn Kolla in och betala - Här loggar användaren in i applikationen, bläddrar i olika kategorier, visar produktinformation, lägger till produkten i kundvagnen, checkar ut, gör betalning och loggar ut.

Ovanstående värden härleddes baserat på följande beräkningar:

• Transaktioner per timme = Antal användare * Transaktioner gjorda av en enskild användare på en timme.
• Antalet användare = 1600.
• Det totala antalet transaktioner i bläddringsscenariot = 17.
• Svarstid för varje transaktion = 3.
• Total tid för en enskild användare att slutföra 17 transaktioner = 17 * 3 = 51 avrundat till 60 sek (1 min).
• Transaktioner per timme = 1600 * 60 = 96000 Transaktioner.

# 4) Designa lasttesterna- Belastningstestet bör utformas med de data som vi hittills samlat in, dvs. affärsflöden, antal användare, användarmönster, mätvärden som ska samlas in och analyseras. Dessutom bör testerna utformas på ett mycket realistiskt sätt.

# 5) Utför belastningstest - Innan vi utför belastningstestet, se till att applikationen är igång. Lastmiljön är klar. Applikationen är funktionstestad och stabil.

Kontrollera konfigurationsinställningarna för Load-testmiljön. Det ska vara detsamma som produktionsmiljön. Se till att alla testdata är tillgängliga. Se till att lägga till nödvändiga räknare för att övervaka systemets prestanda under testutförandet.

Börja alltid med låg belastning och öka belastningen gradvis. Börja aldrig med full belastning och bryt systemet.

# 6) Analysera belastningstestresultaten - Ha ett baslinjetest för att alltid jämföra med de andra testkörningarna. Samla mätvärdena och serverloggarna efter testkörningen för att hitta flaskhalsarna.

Vissa projekt använder övervakningsverktyg för applikationsprestanda för att övervaka systemet under testkörningen. Dessa APM-verktyg hjälper till att identifiera grundorsaken lättare och sparar mycket tid. Dessa verktyg är väldigt enkla att hitta orsaken till flaskhalsen eftersom de har en bred vy för att hitta var problemet är.

Några av APM-verktygen på marknaden inkluderar DynaTrace, Wily Introscope, App Dynamics etc.

# 7) Rapportering - När testkörningen är klar samlar du in alla mätvärden och skickar testrapporten till det berörda teamet med dina observationer och rekommendationer.

Bästa praxis

Nedan listas några av de bästa metoderna för belastningstest:

# 1) Kontrollera alltid applikationsstabiliteten innan du startar ett belastningstest. Applikationen ska undertecknas funktionellt stabilt av funktionstestteamet och alla större defekter bör åtgärdas och testas innan byggnaden kopieras till Load Test-miljön.

#två) Se till att testmiljön för belastning är en replik eller ligger nära produktionsmiljön, inklusive antalet servrar, belastningsbalanserare, serverkonfigurationer och brandväggar.

# 3) Kontrollera om testdata är unika och att vi har kopierat alla testdata till lastmiljön innan du utför ett lasttest.

# 4) Utforma testscenarierna på ett sådant sätt att de efterliknar användaråtgärden i realtid som händer i produktionen.

# 5) Designa arbetsbelastningen utifrån produktionsanvändarnas belastningar och affärsflöden och i händelse av en gammal applikation, se om det är ett nytt samtal med affärsgruppen angående affärsflöden och användarbelastningen.

# 6) Samla alla viktiga mätvärden som svarstid, träffar per sekund, genomströmning, CPU, minne, nätverk och Running Vusers.

Rekommenderad läsning => Lista över verktyg för testning av prestanda som finns på marknaden för utförande av exklusiv lasttestning.

Slutsats

I den här handledningen har vi lärt oss hur belastningstester spelar en viktig roll i prestandatestning av ett program, hur det hjälper till att förstå applikationens effektivitet och förmåga, etc.

Vi fick också veta hur det hjälper att förutsäga om ytterligare hårdvara, programvara eller tuning krävs för en applikation.

Glad läsning!!

Rekommenderad läsning

• Lasttestning med HP LoadRunner-handledning
• Alpha Testing och Beta Testing (En komplett guide)
• Handbok för testning av webbapplikation
• Stresstestguide för nybörjare
• Nybörjarhandbok för penetreringstestning för webbapplikationer
• En komplett icke-funktionell testguide för nybörjare
• Byggverifieringstestning (BVT-testning) Komplett guide
• Prestandatestning mot belastningstestning vs stresstestning (skillnad)