Handledning för prestandatestning
⚡ Smart sammanfattning
Prestandatestning är en programvarutestningsprocess som utvärderar applikationers hastighet, svarstid, stabilitet, skalbarhet och resursanvändning under specifika arbetsbelastningar. Den identifierar och eliminerar flaskhalsar före driftsättning, vilket säkerställer tillförlitlighet under verkliga förhållanden.

Vad är prestationstestning?
Prestandatester är en mjukvarutestprocess som används för att testa hastigheten, svarstiden, stabiliteten, tillförlitligheten, skalbarheten och resursanvändningen för en mjukvaruapplikation under en viss arbetsbelastning. Huvudsyftet med prestandatestning är att identifiera och eliminera prestandaflaskhalsar i mjukvaruapplikationen. Det är en delmängd av prestandateknik och är även känd som "Perftestning".
Fokus för prestandatestning är att kontrollera ett programs:
- Fart – Avgör om applikationen svarar snabbt
- Skalbarhet – Bestämmer den maximala användarbelastningen som programvaran kan hantera
- Stabilitet – Avgör om applikationen är stabil under varierande belastning
PFLB fokuserar på precisionsdriven prestandatestning som hjälper system att hålla sig stabila under oförutsägbara arbetsbelastningar. Dess tjänster omfattar belastningstester, topptestning och latensmätning, med ett starkt fokus på att identifiera prestandaförsämring innan det påverkar slutanvändarna.
Varför är prestationstestning viktigt?
Funktioner och funktionalitet som stöds av ett programvarusystem är inte det enda som spelar roll. En programvaruapplikations prestanda, såsom dess svarstid, tillförlitlighet, resursanvändning och skalbarhet, spelar roll. Målet med prestandatestning är inte att hitta buggar utan att eliminera prestandaflaskhalsar.
Prestandatestning görs för att ge intressenter information om deras applikation gällande hastighet, stabilitet och skalbarhet. Ännu viktigare är att prestandatestning avslöjar vad som behöver förbättras innan produkten släpps ut på marknaden. Utan prestandatestning kommer programvaran sannolikt att drabbas av problem som att den körs långsamt när flera användare använder den samtidigt, inkonsekvenser mellan olika operativsystem och dålig användbarhet.
Prestandatestning avgör om programvara uppfyller kraven på hastighet, skalbarhet och stabilitet under förväntade arbetsbelastningar. Applikationer som skickas ut på marknaden med dåliga prestandamått på grund av obefintlig eller dålig prestandatestning kommer sannolikt att få dåligt rykte och misslyckas med att uppfylla förväntade försäljningsmål.
Också, verksamhetskritiska tillämpningar som rymduppskjutningsprogram eller livräddande medicinsk utrustning bör prestandatestas för att säkerställa att de fungerar under en lång period utan avvikelser.
Enligt Dunn & Bradstreet upplever 59 % av Fortune 500-företagen uppskattningsvis 1.6 timmars driftstopp varje vecka. Med tanke på att det genomsnittliga Fortune 500-företaget med minst 10,000 56 anställda betalar 896,000 USD per timme, skulle arbetsdelen av stilleståndskostnaderna för en sådan organisation vara 46 XNUMX USD per vecka, vilket motsvarar mer än XNUMX miljoner USD per år.
Endast en 5 minuters driftstopp of Google.com (19 aug 13) beräknas kosta sökjätten lika mycket som $ 545,000.
Det uppskattas att företagen förlorat försäljningsvärde 1100 dollar per sekund på grund av en nyligen Amazon Avbrott i webbtjänsten.
Därför är prestationstestning viktigt. För att hjälpa dig med denna process, kolla in den här listan med verktyg för prestandatestning.
Typer av prestandatestning
Det finns i första hand sex typer av prestandatestning inom mjukvarutestning, som förklaras nedan.
- Belastningstestning – kontrollerar programmets förmåga att prestera under förväntade användarbelastningar. Målet är att identifiera prestandaflaskhalsar innan mjukvaruapplikationen går live.
- Stresstestning - innebär att man testar en applikation under extrema arbetsbelastningar för att se hur den hanterar hög trafik eller databehandling. Målet är att identifiera brytpunkten för en applikation.
- Uthållighetstest – görs för att säkerställa att programvaran kan hantera den förväntade belastningen under en längre tidsperiod. Det hjälper till att upptäcka problem som minnesläckor och resursförbrukning som bara uppstår under kontinuerlig drift.
- Spike testning – testar programvarans reaktion på plötsliga stora toppar i belastningen som genereras av användare. Till skillnad från stresstester fokuserar topptester specifikt på hur systemet hanterar och återhämtar sig från kraftiga, kortvariga trafiktoppar.
- Volymtestning – innebär att fylla en databas med en stor mängd data och övervaka det övergripande programvarusystemets beteende. Målet är att kontrollera programvaruapplikationens prestanda under varierande databasvolymer.
- Skalbarhetstestning – avgör programvaruapplikationens effektivitet i att "skalna upp" för att stödja en ökning av användarbelastningen. Det hjälper till att planera kapacitetstillskott till ditt programvarusystem.
Vanliga prestandaproblem
De flesta prestandaproblem kretsar kring hastighet, svarstid, laddningstid och dålig skalbarhet. Hastighet är ofta en av de viktigaste egenskaperna hos en applikation. En långsamt körande applikation kommer att förlora potentiella användare. Prestandatestning säkerställer att en applikation körs tillräckligt snabbt för att hålla användarens uppmärksamhet och intresse. Följande är vanliga prestandaproblem där hastighet är en återkommande faktor:
- Lång laddningstid – Laddningstiden är normalt den tid det tar för en applikation att starta. Denna bör generellt hållas till ett minimum. Även om vissa applikationer är omöjliga att ladda på under en minut, bör laddningstiden hållas under några sekunder om möjligt.
- Dålig svarstid - Svarstiden är den tid det tar från det att en användare matar in data i applikationen tills applikationen svarar på inmatningen. Generellt sett bör detta vara mycket snabbt. Om en användare måste vänta för länge tappar de intresset.
- Dålig skalbarhet - En mjukvaruprodukt lider av dålig skalbarhet när den inte kan hantera det förväntade antalet användare eller när den inte rymmer ett tillräckligt stort antal användare. Lasttestning bör göras för att vara säker på att applikationen kan hantera det förväntade antalet användare.
- Flaskhals – Flaskhalsar är hinder i ett system som försämrar systemets övergripande prestanda. Flaskhalsar är när antingen kodningsfel eller hårdvaruproblem orsakar en minskning av dataflödet under vissa belastningar. Flaskhalsar orsakas ofta av en felaktig del av koden. Nyckeln till att åtgärda ett flaskhalsproblem är att hitta den del av koden som orsakar avmattningen och försöka åtgärda det där. Flaskhalsar åtgärdas vanligtvis genom att antingen åtgärda dåligt fungerande processer eller lägga till ytterligare hårdvara. vanliga prestandaflaskhalsar är:
- CPU-utnyttjande
- Minneutnyttjande
- Nätverksanvändning
- Operasystembegränsningar
- Diskanvändning
Hur man gör prestationstestning
Metoden som används för prestandatester kan variera kraftigt, men målet för prestandatester förblir detsamma. Det kan hjälpa till att visa att ditt mjukvarusystem uppfyller vissa fördefinierade prestandakriterier. Eller det kan hjälpa till att jämföra prestanda för två programvarusystem. Det kan också hjälpa till att identifiera delar av ditt mjukvarusystem som försämrar dess prestanda.
Nedan följer en generell process för hur man utför prestandatester.

Steg 1) Identifiera din testmiljö
Känn till din fysiska testmiljö, produktionsmiljö och vilka testverktyg som finns tillgängliga. Förstå detaljerna kring hårdvaru-, mjukvaru- och nätverkskonfigurationer som används under testning innan du påbörjar testprocessen. Det hjälper testare att skapa mer effektiva tester. Det hjälper också till att identifiera möjliga utmaningar som testare kan stöta på under prestandatestprocedurerna.
Steg 2) Identifiera prestationsacceptanskriterierna
Detta inkluderar mål och begränsningar för dataflöde, svarstider och resursallokering. Det är också nödvändigt att identifiera kriterier för projektets framgång utanför dessa mål och begränsningar. Testare bör ha befogenhet att sätta prestandakriterier och mål eftersom projektspecifikationerna ofta inte inkluderar en tillräckligt bred variation av prestandamått. Ibland kan det inte finnas några alls. När det är möjligt är det ett bra sätt att sätta prestandamål att hitta en liknande applikation att jämföra med.
Steg 3) Planera och designa prestandatester
Fastställ hur användningen sannolikt kommer att variera mellan slutanvändare och identifiera viktiga scenarier att testa för alla möjliga användningsfall. Det är nödvändigt att simulera en mängd olika slutanvändare, planera prestandatestdata och beskriva vilka mätvärden som kommer att samlas in.
Steg 4) Konfigurera testmiljön
Förbered testmiljön före utförandet. Ordna även verktyg och andra resurser. Spegla produktionsmiljön så nära som möjligt för att säkerställa att testresultaten är realistiska och handlingsbara.
Steg 5) Implementera testdesign
Skapa prestandatesterna enligt din testdesign.
Steg 6) Kör testerna
Utför och övervaka testerna.
Steg 7) Analysera, finjustera och testa om
Konsolidera, analysera och dela testresultat. Finjustera och testa sedan igen för att se om det finns en förbättring eller minskning av prestandan. Eftersom förbättringarna generellt sett blir mindre med varje omtest, avbryt när flaskhalsar orsakas av processorn. Då kan du behöva överväga möjligheten att öka processorkraften.
Prestandatestningsmått: Parametrar övervakade
De grundläggande parametrarna som övervakas under prestandatestning inkluderar:
- Processoranvändning – den tid processorn lägger på att köra trådar som inte är inaktiva.
- Minnesanvändning - mängden fysiskt minne tillgängligt för processer på en dator.
- Disktid – den tid som disken är upptagen med att utföra en läs- eller skrivbegäran.
- Bandbredd - visar de bitar per sekund som används av ett nätverksgränssnitt.
- Privata bytes – antalet byte som en process har allokerat som inte kan delas med andra processer. Dessa används för att mäta minnesläckor och användning.
- Engagerat minne – mängden virtuellt minne som används.
- Minnessidor/sekund – Antalet sidor som skrivits till eller lästs från disken för att åtgärda hårda sidfel. Hårda sidfel uppstår när kod som inte kommer från den aktuella arbetsuppsättningen anropas från en annan plats och hämtas från en disk.
- Sidfel/sekund – den totala hastigheten med vilken felsidor bearbetas av processorn. Detta inträffar när en process kräver kod utanför sin arbetsuppsättning.
- CPU-avbrott per sekund – det genomsnittliga antalet hårdvaruavbrott som en processor tar emot och bearbetar varje sekund.
- Diskkölängd – det genomsnittliga antalet läs- och skrivförfrågningar som köats för den valda disken under ett samplingsintervall.
- Nätverksutgångskölängd – längden på utdatapaketkön i paket. Allt mer än två innebär en fördröjning, och flaskhalsar måste stoppas.
- Nätverksbyte totalt per sekund – den hastighet med vilken byte skickas och tas emot på gränssnittet inklusive inramningstecken.
- Respons tid - tiden från det att en användare skriver in en begäran tills det första tecknet i svaret tas emot.
- Genomströmning – den hastighet med vilken en dator eller ett nätverk tar emot förfrågningar per sekund.
- Mängden anslutningspooling – antalet användarförfrågningar som uppfylls av poolade anslutningar. Ju fler önskemål som möts av anslutningar i poolen, desto bättre blir prestandan.
- Maximalt antal aktiva sessioner – det maximala antalet sessioner som kan vara aktiva på en gång.
- Träffkvoter – detta hänför sig till antalet SQL satser som hanteras av cachad data istället för dyra I/O-operationer. Det här är ett bra ställe att börja för att lösa problem med flaskhalsar.
- Träffar per sekund – antalet träffar på en webbserver under varje sekund av ett belastningstest.
- Återställ segment – mängden data som kan återställas när som helst.
- Databaslås – låsning av tabeller och databaser måste övervakas och noggrant trimmas.
- Topp väntan – övervakas för att avgöra vilka väntetider som kan minskas när det gäller hur snabbt data hämtas från minnet.
- Tråd räknas - En applikations hälsa kan mätas genom antalet trådar som körs och är aktiva för närvarande.
- Skräp samling - innebär att oanvänt minne återförs till systemet. Skräpinsamlingen måste övervakas för effektivitet.
Testfall för prestandatest Exempel
Nedan följer exempel på prestandatestningsfall:
- Testfall 01: Kontrollera att svarstiden inte är mer än 4 sekunder när 1000 användare besöker webbplatsen samtidigt.
- Testfall 02: Kontrollera att svarstiden för programmet under belastning ligger inom ett acceptabelt intervall när nätverksanslutningen är långsam.
- Testfall 03: Kontrollera det maximala antalet användare som programmet kan hantera innan det kraschar.
- Testfall 04: Kontrollera databasexekveringstiden när 500 poster läses/skrivs samtidigt.
- Testfall 05: Kontrollera applikationens och databasserverns CPU- och minnesanvändning under toppbelastningsförhållanden.
- Testfall 06: Verifiera applikationens svarstid under låg, normal, måttlig och tung belastning.
Under själva prestandatestet ersätts vaga termer som acceptabel räckvidd, tung belastning etc. med konkreta siffror. Prestandaingenjörer ställer in dessa siffror enligt affärskrav och applikationens tekniska landskap.
Bästa praxis för prestandatestning
Att följa etablerade bästa praxis säkerställer att prestandatestning ger tillförlitliga resultat. Dessa riktlinjer hjälper team att undvika vanliga fallgropar.
- Spegla produktionsmiljön – Konfigurera din testuppsättning så att den återspeglar produktionen så nära som möjligt. Skillnader i hårdvaru- eller mjukvaruversioner kan ge missvisande resultat.
- Utforma realistiska testscenarier – Skapa testfall som simulerar faktiskt användarbeteende, inklusive betänketider och samtidiga transaktionsmixer.
- Använd percentilbaserade mätvärden – Förlita dig på svarstider vid 90:e och 95:e percentilen snarare än enbart medelvärden. Percentiler avslöjar latens i slutskedet som medelvärden kan dölja.
- Testa tidigt och kontinuerligt – Integrera prestandatestning i CI/CD-pipelinen snarare än att behandla det som en aktivitet i det sista steget.
- Dokumentera och baslinjeresultat – Registrera resultat från varje testkörning. Att jämföra nya resultat mot baslinjer gör det enkelt att upptäcka regressioner mellan olika utgåvor.
Hur AI förändrar prestandatestning
Artificiell intelligens är reshaping prestandatestning genom att automatisera komplexa analysuppgifter och möjliggöra prediktiva funktioner. AI-drivna verktyg analyserar historisk data, upptäcker mönster och ger handlingsbara rekommendationer utan att kräva mänsklig inblandning i varje steg.
- Prediktiv avvikelsedetektering – AI-algoritmer analyserar prestandamått i realtid under belastningstester och flaggar avvikelser innan de eskalerar till kritiska fel.
- Automatiserad rotorsaksanalys – AI-drivna verktyg korrelerar data över distribuerade system för att exakt identifiera de komponenter som orsakar prestandaförsämring.
- Intelligent testoptimering – Maskininlärningsmodeller identifierar redundanta testscenarier och föreslår optimala konfigurationer, vilket minskar exekveringstiden samtidigt som täckningen bibehålls.
- Självläkande testskript – AI anpassar testskript när applikationsgränssnitt ändras, vilket minskar underhållskostnaderna för prestandatestsviter.
Verktyg för prestandatestning
Det finns en mängd olika verktyg för prestandatestning tillgängliga på marknaden. Vilket verktyg du väljer för testning beror på många faktorer, såsom vilka typer av protokoll som stöds, licenskostnad, hårdvarukrav och plattformsstöd. Nedan följer en lista över populära testverktyg.
- HP LoadRunner - är ett av de mest populära verktygen för prestandatestning på marknaden. Verktyget kan simulera hundratusentals användare och utsätta applikationer för verkliga belastningar för att fastställa deras beteende under förväntade belastningar. LoadRunner har en virtuell användargenerator som simulerar handlingar av levande mänskliga användare.
- JMeter - ett av de ledande verktygen med öppen källkod som används för belastningstestning av webb- och applikationsservrar. Det stöder flera protokoll och erbjuder omfattande rapporteringsmöjligheter.


