En komplett testtestguide med exempel

complete performance testing guide with examples

Vad är prestandatestning?

Prestandatestning kallas också 'Perf Testing', är en typ av testning som utförs för att kontrollera hur applikation eller programvara fungerar under arbetsbelastning när det gäller respons och stabilitet. Prestandatestmålet är att identifiera och ta bort prestandaflaskhalsar från en applikation.

Detta test utförs främst för att kontrollera om programvaran uppfyller de förväntade kraven för applikationshastighet, skalbarhet och stabilitet.

vad är användningsfall i programvarutestning

I denna handledningsserie kommer vi att täcka fullständiga detaljer som - Perf Testing Typer, Process och Writing Performance Test Strategidokument från grunden.

Detta är en detaljerad handledningsserie som du kanske vill bokmärka!

Låt oss utforska!

Lista över ALLA prestandatestkurser i denna serie:

Handledning nr 1: Prestandatestning Komplett guide (Denna handledning)
Handledning nr 2: Skillnaden mellan prestanda, belastning och stresstestning
Självstudie 3: Funktionell testning mot prestandatestning
Självstudie 4: Prestandatestplan och teststrategi
Handledning nr 5: Sätt att överbelasta din prestandatestning
Självstudie nr 6: Testguide för molnprestanda
Handledning nr 7: Handbok för testning av mobilappsprestanda
Självstudie 8: Hur man utför manuell prestandatestning
Handledning nr 9: Handledning för testning av webbplatsens prestanda
Handledning nr 10: Prestandatestföretag
Handledning nr 11: Prestandatestning med LoadRunner (Serier)

Verktyg:

Handledning nr 12: Testverktyg för bästa prestanda
Handledning nr 13: Neoload Performance Test Tutorial
Handledning nr 14: BlazeMeter Mobile Performance Test-handledning
Handledning nr 15: WAPT Load, Stress and Performance Test Tutorial
Handledning nr 16: SmartMeter.io Handledning för test av webbplatsens prestanda

Vad du kommer att lära dig:

• Typer av prestandatestning
  • Lasttestning
  • Stresstestning
  • Volymtestning
  • Kapacitetstestning
  • Tillförlitlighet / återställningstest
• Prestandatestprocess
• Hur man skriver prestandateststrategidokument?
  • Exempel på prestanda teststrategimall
  • #1. Introduktion
    • Mål
    • Arkitektur
  • # 2) Räckvidd
    • I omfattning
    • Ur sikte
  • # 3) Tillvägagångssätt
    • Scenarier för prestandatest
    • Prestandatesttyper
    • Prestandamätningar
    • Prestanda testaktiviteter och leveranser
  • # 4) Testdata
  • # 5) Kriterier för inträde och utgång
  • # 6) Defekthantering
    • Definition av defekt svårighetsgrad
  • # 7) Testverktyg och tekniker
  • # 8) Kriterier för upphängning och återupptagning
  • # 9) Testleveranser
  • # 10) Roller och ansvar
  • # 11) Potentiella risker och begränsningsplan
  • # 12) Antaganden
  • # 13) Beroenden
  • # 14) Förkortningar
• Bästa metoder för realistiska prestandatest
  • # 1) Planering
  • # 2) Utveckling
  • # 3) Utförande
  • # 4) Analys
  • Slutsats
  • Rekommenderad läsning

Typer av prestandatestning

Lasttestning

Load Testing är en typ av prestandatest där applikationen testas för dess prestanda vid normal och toppanvändning. Prestanda för en applikation kontrolleras med avseende på dess svar på användarförfrågan och dess förmåga att svara konsekvent inom en accepterad tolerans för olika användarbelastningar.

De viktigaste övervägandena är:

1. Vad är den maximala belastningen applikationen kan hålla innan applikationen börjar fungera oväntat?
2. Hur mycket data kan databasen hantera innan systemet saktar eller kraschen observeras?
3. Finns det några nätverksrelaterade problem att hantera?

Stresstestning

Stresstestning används för att hitta sätt att bryta systemet. Testet ger också räckvidden för maximal belastning som systemet kan hålla.

Generellt sett har stresstestning ett stegvis tillvägagångssätt där belastningen ökas gradvis. Testet startas med en belastning som applikationen redan har testats för. Därefter läggs mer belastning långsamt på för att stressa systemet. Den punkt då vi börjar se servrar som inte svarar på förfrågningarna betraktas som brytpunkten.

Följande frågor ska tas upp:

• Vilken är den maximala belastningen ett system kan hålla innan det går sönder?
• Hur går systemet sönder?
• Kan systemet återhämta sig när det har kraschat?
• På hur många sätt kan ett system gå sönder och vilka är den svaga noden när man hanterar den oväntade belastningen?

Volymtestning

Volymtestning är att verifiera att programmets prestanda inte påverkas av datamängden som hanteras av applikationen. För att utföra ett volymtest matas en enorm datamängd in i databasen. Detta test kan vara ett inkrementellt eller stadig test. I det inkrementella testet ökar datamängden gradvis.

I allmänhet växer databasstorleken med applikationsanvändningen och det är nödvändigt att testa applikationen mot en tung databas. Ett bra exempel på detta kan vara en webbplats för en ny skola eller en högskola som har små mängder data att lagra från början, men efter 5-10 år är datalagren i webbplatsens databas mycket mer.

Kapacitetstestning

=> Kan applikationen möta affärsvolymen under både normala och toppbelastningsförhållanden?

Kapacitetstestning görs vanligtvis för framtidsutsikter. Kapacitetstestning behandlar följande:

1. Kommer applikationen att kunna stödja den framtida belastningen?
2. Kan miljön stå för den kommande ökade belastningen?
3. Vilka ytterligare resurser krävs för att göra miljön tillräckligt kapabel?

Kapacitetstestning används för att bestämma hur många användare och / eller transaktioner en viss webbapplikation stöder och fortfarande uppfyller prestanda. Under denna testning beaktas resurser som processorkapacitet, nätverksbandbredd, minnesanvändning, skivkapacitet etc. för att möta målet.

Onlinebank är ett perfekt exempel på var kapacitetstest kan spela en viktig roll.

Pålitlighet / återhämtning Testning

Tillförlitlighetstestning eller återställningstestning - är att verifiera om applikationen kan återgå till sitt normala tillstånd efter ett misslyckande eller onormalt beteende och hur lång tid tar det för det att göra det (med andra ord tidsberäkning).

Om en online-handelswebbplats upplever ett misslyckande där användarna inte kan köpa / sälja aktier vid en viss tidpunkt (topptid) men kan göra det efter en timme eller två, kan vi säga att applikationen är tillförlitlig eller återhämtat sig från det onormala beteendet.

Prestandatestprocess

Här är alla aktiviteter som utförts i denna testning:

# 1) Kravsanalys / insamling

Prestationsteamet interagerar med klienten för identifiering och insamling av krav - tekniskt och affärsmässigt. Detta inkluderar att få information om applikationens arkitektur, teknik och databas som används, avsedda användare, funktionalitet, applikationsanvändning, testkrav , hårdvaru- och programvarukrav etc.

# 2) Val av POC / verktyg

När nyckelfunktionaliteten har identifierats görs POC (Proof Of Concept - som är ett slags demonstration av realtidsaktiviteten men i begränsad mening) med de tillgängliga verktygen.

Listan över tillgängliga verktyg beror på kostnaden för verktyget, protokollet som applikationen använder, de tekniker som används för att bygga applikationen, antalet användare vi simulerar för testet etc. Under POC skapas skript för den identifierade nyckeln funktionalitet och körs med 10-15 virtuella användare.

# 3) Prestandatestplan och design

Beroende på informationen som samlats in i föregående steg genomförs testplanering och design.

Testplanering innefattar information om hur prestandatestet ska ske - testmiljö, arbetsbelastning, hårdvara etc.

Mer om teststrategidokumentet nedan.

# 4) Prestandatestutveckling

• Användningsfall skapas för den funktionalitet som i testplanen identifieras som omfattningen av PT.
• Dessa användningsfall delas med klienten för godkännande. Detta för att säkerställa att manuset kommer att spelas in med rätt steg.
• När det väl är godkänt börjar skriptutvecklingen med en inspelning av stegen i användningsfall med prestandatestverktyget som valts under POC (Proof of Concepts) och förbättras genom att utföra korrelation (för hantering av dynamiskt värde), parametrisering (värdesubstitution) och anpassade funktioner som beroende på situation eller behov. Mer om dessa tekniker i våra videohandledning.
• Skriptet valideras sedan mot olika användare.
• Parallellt med att skapa skript fortsätter prestandateamet också med att ställa in testmiljön (programvara och hårdvara).
• Prestationsteamet kommer också att ta hand om Metadata (back-end) genom skript om denna aktivitet inte tas upp av klienten.

# 5) Prestandatestmodellering

Performance Load Model skapas för testkörningen. Huvudsyftet med detta steg är att validera om de angivna prestandamätvärdena (tillhandahållna av klienter) uppnås under testet eller inte. Det finns olika sätt att skapa en Load-modell. “ Little's Law ”Används i de flesta fall.

# 6) Testkörning

Scenariot är utformat enligt Load Model in Controller eller Performance Center men de initiala testerna utförs inte med maximalt antal användare som finns i Load-modellen.

Testkörning görs stegvis. Till exempel, Om det maximala antalet användare är 100, körs scenarierna först med 10, 25, 50 användare och så vidare och går så småningom vidare till 100 användare.

# 7) Testresultatanalys

Testresultat är de viktigaste resultaten för testaren. Det är här vi kan bevisa ROI (Return on Investment) och produktivitet som en prestandatestning kan erbjuda.

Några av de bästa metoderna som hjälper resultatanalysprocessen:

1. Ett unikt och meningsfullt namn för varje testresultat - detta hjälper till att förstå syftet med testet.
2. Inkludera följande information i testresultatsammanfattningen:

• Orsak till misslyckandet
• Ändring i applikationens prestanda jämfört med föregående testkörning
• Ändringar som gjorts i testet från applikationsbyggnad eller testmiljö.
• Det är en bra metod att göra en resultatöversikt efter varje testkörning så att analysresultaten inte sammanställs varje gång testresultaten hänvisas.
• PT kräver i allmänhet många testkörningar för att nå rätt slutsats.
• Det är bra att ha följande poäng i resultatöversikten:
  • Syfte med testet
  • Antal virtuella användare
  • Scenarioöversikt
  • Testets varaktighet
  • Genomströmning
  • Grafer
  • Diagramjämförelse
  • Respons tid
  • Fel inträffade
  • Rekommendationer

# 8) Rapportera

Testresultaten bör förenklas så att slutsatsen blir tydligare och inte behöver någon härledning. Utvecklingsteamet behöver mer information om analys, jämförelse av resultat och detaljer om hur resultaten erhölls.

Testrapporten anses vara bra om den är kort, beskrivande och till sak.

Hur man skriver prestandateststrategidokument?

Denna handledning kommer att förklara hur man skriver ett exempel på en prestandateststrategi för en meddelandeapplikation.

Kom ihåg att detta bara är ett exempel och att kraven kommer att skilja sig från en klient till en annan, vi kommer också att lära känna de bästa metoderna för prestandatestning i denna handledning.

hur man öppnar swf-filen i krom

Exempel på prestanda teststrategimall

Om ABC-chattapplikation - Låt oss anta att detta är en chattarbetsbänk som används i ett företag av deras kundsupportagent, den här chattapplikationen använder XMPP-protokoll, dvs Extensible Messaging and Presence Protocol och Open fire-server för att skicka och ta emot snabbmeddelanden.

Några förbättringar har gjorts av denna befintliga chattklient som fjärr-PC-kontroll, PC-diagnos, reparationsverktyg, onlinechatt, etc., så denna prestandatest-strategi är ett exempel på sådana applikationer.

För den här applikationen ska vi anta att projektgruppen har beslutat att använda JMeter för prestandatestning och JIRA för spårning av defekter.

Den första sidan i dokumentet Performance Test Strategy bör innehålla titeln på dokumentet och företagets upphovsrätt.

Den andra sidan ska innehålla dokumentkontroll som innehåller, Dokumentversion historik, Granskare & Approvers lista och Bidragsgivare lista.

Den tredje sidan ska innehålla innehållsförteckningen, följt av nedanstående ämnen.

#1. Introduktion

Syftet med detta dokument är att definiera / förklara hur Performance Testing kommer att utföras på ABC-chattapplikationen för nuvarande och framtida tillstånd.

ABC-chattapplikationen är en intern arbetsbänk för fjärrsupportagent. Denna arbetsbänk kommer att användas för att uppfylla kundförfrågningar. Denna arbetsbänk har funktioner som onlinechatt, kundidentifiering, fjärrstyrning av PC, PC-diagnos och reparationsverktyg.

Mål

De viktigaste målen för Performance Testing är följande:

• För att få förtroendet för att ändringarna i den befintliga chattapplikationen är i linje med det definierade servicenivåavtalet.
• För att säkerställa att applikationsprestanda, tillgänglighet och stabilitet i applikationen inte påverkas till följd av de nya förbättringarna.
• Svarstider för transaktioner ligger inom acceptabel tolerans över den ökande belastningsprofilen.
• JVM visar stabil minnesanvändning över de ökande belastningsprofilerna.

Bilden nedan förklarar tydligt Performance Testing & Optimization process:

Arkitektur

Du måste ta med arkitekturdiagrammet för ditt projekt i den här sessionen.

# 2) Räckvidd

I omfattning

Nedan följer prestanda testområdet för ABC chatt arbetsbänk:

• Kunskapsinhämtning av de viktigaste affärstransaktionerna och byggd belastningsfördelning efter en detaljerad studie av systemet.
• Identifiera de kritiska scenarierna för prestandatestning med hjälp från olika projektspår.
• Använd de tidigare utgivningsresultaten som baslinje för framtida utgåvor.
• Verifiera och validera prestandatestmiljön och prestanda / belastningstestverktygsinfrastrukturen för ytterligare agentmaskiner.
• Förberedelse av prestandatestskript med JMeter för de identifierade scenarierna som efterliknar den identifierade toppbelastningen.
• Ställ in prestandaövervakning på servrarna för att övervaka testet för att identifiera flaskhalsarna under testutförandefasen.
• Publicera prestandatestresultat.
• Koordinera med olika intressenter för att lösa de identifierade prestationsproblemen.
• Baslinjen prestandanivån för framtida utgåvor.

Ur sikte

• Funktionell testning , UAT, systemtestning och säkerhetstestning.
• Prestandatestning / övervakning av gränssnitt från tredje part.
• Prestandajustering. (Oftast görs inställningen av ett annat team, om du har prestandatekniker som kan ställa in systemet kan du lägga till detta i Inscope).
• Kodprofilering / Storleksbestämning av maskinvara / Kapacitetsplanering.
• Säkerhet / Sårbarhetstestning / UAT / Vitlåda testning .
• Datagenerering för prestandatestning.
• Icke-funktionella tester ( Till exempel, failover, katastrofåterställning, säkerhetskopiering, användbarhet) annat än prestandatesterna.
• Test av valfri mobil lösning.
• Testning och inställning av applikationsprestanda från tredje part.
• Förverkligande av prestationsrekommendationer, ändringar av applikationskod och leverantörsstödda produkter / serverkonfigurationsändringar kommer inte att omfattas av Performance Team-perspektivet.
• Infrastrukturstöd / Byggdistribution / Miljöberedskap / Databasåterställning / Nätverksstöd etc.

# 3) Tillvägagångssätt

Prestandatestning för ABC-chatt kommer att utföras med Jmeter genom att skriva anpassade XMPP-plugins som använder ett smackbibliotek för XMPP-anslutningar. Dessa bibliotek används för att ställa in anslutningar, logga in och skicka chattmeddelanden till XMPP-servern.

Dessa bibliotek buntas i en jar-fil som distribueras i Jmeter och är utformad utifrån de scenarier som ska testas. Jmeter Work Bench är installerad i den lokala maskinen som ansluter till JMeter-servern som har Load Generators för att generera den erforderliga belastningen på Chat-serversystemet för att övervaka systembeteendet.

Testscenariot kommer att skriptas med JMeter-verktyget. Manusen skulle anpassas efter behov. Schemat skapas med den nödvändiga rampen upp för att simulera verkliga scenarier.

Testscenariot skulle brytas upp och mätas i följande aspekter:

a) Baslinjetest: Att köra varje scenario med 1 Vuser och flera iterationer för att identifiera om applikationsprestanda uppfyller Business Service Level Agreement eller inte.

b) Basbelastningstest: För att uppfylla Business Benchmark under belastningstest kommer Performance Testing-teamet att utföra ett grundbelastningstest som hjälper till att identifiera eventuella systemprestandaproblem med ökad belastning och skapar baslinjen för nästa nivå av prestandatestning.

c) Toppbelastning / skalbarhetstest: Performance Testing-teamet kommer att utföra flera tester med ökande Vusers för att möta den förväntade belastningen och också för att mäta applikationsprestanda för att fastställa prestandakurvan och identifiera om distributionen kan stödja servicenivåavtal under den högsta användarbelastningen.

Det hjälper till att ställa in eller kapacitetsplanera de enskilda Java-virtuella maskinerna (JVM), det totala antalet nödvändiga JVM: erna och processorerna. Detta uppnås genom att öka antalet Vusers till 50%, 75%, 100% och 125% av toppkapaciteten.

d) Uthållighetstest: Prestandatestteamet kommer att köra detta test under en period av 8 timmar / 16 timmar / 24 timmar för att identifiera minnesläckor, prestandaproblem över tiden och övergripande systemstabilitet. Under uthållighetstester övervakar Performance Testing-teamet nyckelprestationsindikatorerna, såsom svarstider för transaktioner och minnesanvändningens stabilitet.

Systemresurser som CPU, minne och IO måste övervakas med hjälp av projektteamet.

Prestandatestmiljön antas vara en kopia av produktionsmiljön. Testerna körs med en stegvis belastning för att identifiera var applikationen misslyckas.

Scenarier för prestandatest

Inkludera excel med uppsättningen scenarier.

Till exempel,

Scenario 1: För att validera agent- och kundchatten för X-nr. av samtidiga sessioner.

Prestandatesttyper

Tabellen nedan förklarar de olika typerna av prestandatester tillsammans med deras mål.

Prestandamätningar

• Mätvärden på klientsidan

• Mätvärden för system- och nätverksprestanda

Prestanda testaktiviteter och leveranser

# 4) Testdata

Det antas att prestandamiljödata kommer att vara en kopia av produktionsdata och de nödvändiga testdata kommer att tillhandahållas av projektgruppen.

# 5) Kriterier för inträde och utgång

• Tillgång till alla applikationer i miljön.
• Miljöberedskap komplett.
• Prestanda Test Data beredskap.

# 6) Defekthantering

• Modulen Defekthantering i JIRA kommer att användas i projektet för defektering och för spårning till stängning.
• Identifiering av defekter som upptäcks under testutförandefasen kommer att fångas i JIRA och dessa defekter kommer att lösas av utvecklingsteamet enligt nedanstående svårighetsgrader.
• Möten om granskning av fel skulle hållas dagligen med deltagande från test-, utvecklings-, kvalitetsanalytiker och affärsteam.
• Kriterierna för att åtgärda defekter skulle bli stränga när projektet närmar sig Go Live-datumet. Riktlinjer för kriterier för att korrigera fel ska publiceras vid möten för granskning av fel.

Definition av defekt svårighetsgrad

Definitionerna av svårighetskoder är följande:

# 7) Testverktyg och tekniker

# 8) Kriterier för upphängning och återupptagning

Nedan följer de kritiska kriterierna för upphängning och återupptagning som påverkar testaktiviteterna:

qa testa intervjufrågor och svar för erfarna

# 9) Testleveranser

Prestandatestens leveranser inkluderar:

• Strategi för prestandatestning
• Dokument om prestationskrav
• Dokument om scenariot för prestandatest
• Prestandatestskript
• Prestandatestresultat

# 10) Roller och ansvar

Roller och ansvar förklaras tydligt i tabellen nedan.

# 11) Potentiella risker och begränsningsplan

# 12) Antaganden

• Prestandatestmiljö kommer att vara en kopia av produktarkitekturlandskapet. (dvs. korrekt hårdvara, programvara, gränssnitt, integrationslager, etc).
• Prestandaskript kommer att utformas baserat på de kritiska flöden för vilka användningen är hög.
• Alla infrastrukturproblem bör lösas innan prestandatestning påbörjas. Eventuella ändringar av systemkonfigurationen som görs senare ogiltigförklarar testresultaten.
• En applikation är stabil och redo att användas i Performance-testmiljön.
• Nödvändiga hårdvaru- och mjukvaruresurser (som lastgeneratormaskiner / programvara, controller / agentmaskiner) görs tillgängliga.
• Alla ändringar i omfattningen kommer att gå igenom en förändringskontrollprocess och prestandatestteamet kommer att utvärdera effekterna av tidslinjer och resurser.
• Respektive servrar förväntas hantera belastningen.
• Applikationsspårningsloggar måste vara aktiverade för stödsystemen för övervakningssyfte.

# 13) Beroenden

• Tillgängligheten för Performance-testmiljön som är en kopia av produktarkitekturlandskapet.
• Support krävs från olika team för funktionalitet, utveckling, databas och infrastruktur under testförberedelserna och genomförandestegen.
• Inga kodändringar genomförs under hela prestandatestfasen eftersom tiden är mycket begränsad.
• I händelse av oförutsedda problem som leder till begränsningar inom tidslinjerna, om tidslinjerna inte tillåter att alla testomfång uppfylls inom de ursprungliga milstolparna, finns support tillgängligt från Release Managers, för att ge ett beslut om omfattning och prioritering.
• Applikationsaffärsanvändare / ämnesmaterialsexperter kommer att göras tillgängliga för funktionella förtydliganden och avskrivning av affärstransaktioner.
• ABC Chat Program Manager kommer att granska och logga ut.

# 14) Förkortningar

Nu måste du ha klart förstått hur man skriver en effektiv prestandateststrategi för en meddelandeapplikation.

Bästa metoder för realistiska prestandatest

För att kunna slutföra ett Prestandatestprojekt framgångsrikt måste vi se till att vi gör det på rätt sätt från planeringsstadiet, dvs. planering, utveckling, genomförande och analys.

Låt oss ta en titt på varje steg i detalj för att kunna genomföra prestandatestning effektivt.

# 1) Planering

• Försök att identifiera de vanligaste arbetsflödena, dvs de affärsscenarier som måste testas. Om applikationen är en befintlig kontrollerar du servern loggar för att förstå de mest använda scenarierna. Om ansökan är ny än prata med projektledningen för att förstå det stora affärsflödet.
• Planera lasttestet på ett sådant sätt att du täcker ett brett spektrum av arbetsflöden som lättanvändning, medelanvändning och toppbelastning.
• Du måste utföra många cykler av Load Test, så försök skapa en ram så att du kan använda samma skript om och om igen. Försök också att ha en säkerhetskopia av skripten.
• Försök att analysera hur länge ett test måste pågå, är det en timme? 8 timmar? En dag eller en vecka? Vanligtvis kommer långvariga tester att avslöja många större defekter som OS-buggar, minnesläckor etc.
• Om din organisation använder något APM (Application Monitoring Tool) kan du inkludera det under testkörningarna så att du enkelt kan identifiera prestandaproblemen och lättare identifiera orsaken.

# 2) Utveckling

• När du utvecklar skript, dvs. inspelning, försök att ge ett mer meningsfullt transaktionsnamn baserat på de affärsflödesnamn som nämns i planen.
• Spela inte in några tredjepartsapplikationer och om det registreras, försök att filtrera bort det medan du förstärker skriptet.
• Inte alla dynamiska värden kan korreleras med hjälp av autokorrelationsfunktionen i verktyget, så försök att göra en manuell korrelation för att undvika fel.
• Försök att utforma dina prestandatester på ett sådant sätt att du träffar applikationens baksida och inte bara cacheservern.

# 3) Utförande

• Se till att köra testerna i en produktionsliknande miljö, inklusive faktorer som SSL, Load Balancer och Firewalls. Detta är nödvändigt för att simulera en realistisk belastning på systemet.
• Försök skapa en arbetsbelastning som är mycket realistisk, du kan få detta genom att kontrollera serverloggarna om det är en befintlig applikation och om det är en ny applikation måste du få denna information från affärsteamet. Kom ihåg att arbetsbelastningen är mycket viktig för att genomföra framgångsrika prestandatester.
• Kom aldrig till en slutsats genom att köra tester med hälften av produktionsstorleken, det rekommenderas alltid att göra tester i en miljö som är precis samma som produktionen.
• När du utför långa tester försöker du titta på körningen med frekventa intervaller för att se till att testet går smidigt.

# 4) Analys

• Försök att analysera applikationen genom att lägga till några viktiga räknare först, när en flaskhals hittas försök sedan lägga till ytterligare räknare med avseende på flaskhalsen. Detta i sin tur hjälper till att hitta problemet lättare.
• En applikation kan misslyckas av många anledningar, eftersom den inte kan svara på en begäran, svara med en felkod, misslyckas med din valideringslogik eller svara för långsamt. Så försök att undersöka alla dessa innan du kommer till en slutsats.

Slutsats

Jag är säker på att den här handledningen skulle ha gett dig enorm kunskap om prestandatest och hur man skriver ett strategidokument för prestandatest med detaljerade exempel.

I vår kommande handledning kommer vi att lära oss skillnaderna mellan prestanda, belastning och stresstest i detalj.

Kontrollera också => Gratis LoadRunner djupgående träningsserie

NÄSTA självstudie

Rekommenderad läsning

• Prestandatestning mot belastningstestning vs stresstestning (skillnad)
• Lasttestning med HP LoadRunner-handledning
• Test av molnprestanda: Molnbaserade tjänsteleverantörer för belastningstest
• Webbelastningstest, stress och prestandatestning med WAPT
• Verktyg och tjänster för testning av webbplatsens prestanda
• Hur utför man manuell prestandatestning?
• Prestandatestning av mobila applikationer med BlazeMeter
• Test av webbtjänstens prestanda med LoadRunner VuGen Scripting