Meny

Skillnaden mellan prestandatestplan och prestandateststrategi

  • Huvud
  • Övrig
  • Skillnaden mellan prestandatestplan och prestandateststrategi

difference between performance test plan

Prova Vårt Instrument För Att Eliminera Problem

Vad är skillnaden mellan prestandatestplan och teststrategi?

I denna Prestanda Testing-serien , vår tidigare handledning, förklarade om Funktionell testning mot prestandatestning i detalj.

=> Klicka här för fullständiga prestandatesthandledningsserier

I den här handledningen lär du dig skillnaden mellan Prestandatestplan och Teststrategi och innehållet som ska ingå som en del av dessa dokument.

Prestanda Testplan vs teststrategi

Låt oss förstå skillnaden mellan dessa två dokument.

Vad du kommer att lära dig:

Prestandateststrategi

Performance Test Strategy-dokumentet är ett dokument på hög nivå som ger oss information om hur vi utför prestandatestning under testfasen. Den berättar hur vi testar ett affärsbehov och vilket tillvägagångssätt som krävs för att framgångsrikt leverera produkten till slutkunden.

Detta kommer att ha all information om affärsprocessen på en mycket hög nivå.

Detta dokument är vanligtvis skrivet av Performance Test Managers baserat på deras tidigare erfarenhet eftersom det endast kommer att finnas begränsad information tillgänglig eftersom detta dokument utarbetas under de inledande faserna av projektet, dvs. under kravanalysfasen eller efter kravanalysfasen.

Så med andra ord är ett Performance Test-strategidokument inget annat än en riktning som du ställde i början av projektet med det tillvägagångssätt som du kommer att ta för att uppnå Prestanda-testmålen.

Ett typiskt prestandateststrategidokument innehåller det övergripande målet för prestandatestning, vad ska testas? vilken miljö kommer att användas? vilka verktyg kommer att användas? vilka typer av test kommer att genomföras? Inträdes- och utgångskriterier, vilka risker för en intressent mildras? och några fler som vi ska titta i detalj när vi går vidare i denna handledning.

Prestandateststrategi

Ovanstående diagram förklarar att Performance Test Strategy-dokumentet skapas under eller efter projektets fasanalysfas.

Prestandatestplan

Performance Test Plan-dokument skrivs i ett senare skede i projektet när kraven och designdokumenten nästan är frusna. Dokumentet Prestandatestplan har alla detaljer i schemat för att genomföra strategin eller strategin som beskrivs under kravanalysfasen.

Från och med nu är designdokumenten nästan färdiga, Prestandatestplanen innehåller alla detaljer om de scenarier som ska testas. Det har också mer information om de miljöer som används för prestandatestkörningar, hur många cykler av testkörningar, resurser, inträde-utgångskriterier och mer. Prestandatestplanen skrivs antingen av Performance Manager eller Performance Test Lead.

Prestandatestplan

Ovanstående diagram förklarar tydligt att Performance Test Plan skapas under projektet Design eller efter designfasen baserat på tillgängligheten till designdokumenten.

Innehåll i strategidokument för prestandatest

Låt oss nu se vad allt bör inkluderas i ett strategidokument för prestandatest:

#1. Introduktion: Ge en kort översikt över vad ett Performance Test-strategidokument kommer att innehålla för just det projektet. Nämn också de lag som kommer att använda detta dokument.

big data som tjänsteföretag

# 2) Räckvidd: Att definiera omfattningen är mycket viktigt eftersom det berättar för oss vad som exakt kommer att testas. Vi måste vara mycket specifika när vi definierar omfattningen eller något annat avsnitt.

Skriv aldrig något generaliserat. Scope berättar vad som exakt kommer att testas för hela projektet. Vi har In scope och Out of scope som en del av scope, In scope beskriver alla funktioner som kommer att testas Prestanda och Out of scope beskriver de funktioner som inte kommer att testas.

# 3) Testa Närma sig: Här måste vi nämna om det tillvägagångssätt som vi kommer att följa för våra prestandatest som att varje skript kommer att köras med en enskild användare för att skapa en baslinje och sedan kommer dessa baslinjetester att användas som referens för benchmarking vid en senare tidpunkt tid under testkörningar.

Dessutom kommer varje komponent att testas individuellt innan de integreras tillsammans och så vidare.

# 4) Testa Typer: Här nämner vi de olika typerna av tester som ska täckas, som belastningstest, stresstest, uthållighetstest, volymtest etc.

# 5) Testa Leveranser: Nämn vad alla leveranser kommer att tillhandahållas som en del av Performance Testing för projektet som Test Run Report, Sammanfattningsrapport etc.

# 6) Miljö: Här måste vi nämna detaljerna i miljön. Miljödetaljer är mycket viktiga eftersom det beskriver vilka operativsystem som ska användas för prestandatestning.

Om miljön kommer att vara en kopia av produktionen eller kommer den att vara storleksanpassad eller storleksanpassad från produktionen och även förhållandet mellan storlek upp och storlek ner, dvs. kommer den att vara hälften så stor som produktionen eller kommer den att vara dubbelt så stor som produktionen ?

Vi måste också tydligt nämna eventuella korrigeringsfiler eller säkerhetsuppdateringar som ska betraktas som en del av den miljö som ställts in och även under Prestandatestkörningen.

# 7) Verktyg: Här måste vi nämna alla verktyg som kommer att användas som defektspårningsverktyg, Hanteringsverktyg , Prestandatestning och övervakningsverktyg. Vissa Exempel av verktyg för spårning av defekter är JIRA , För hantering av dokument som Confluence, för Performance Testing Jmeter och för övervakning Nagios .

# 8) Resurser: Detaljer om de resurser som krävs för Performance Testing Team finns dokumenterade i detta avsnitt. Till exempel , Performance Manager, Performance Test Lead, Performance Testers etc.

# 9) Inträde & Utgång Kriterier: In- och utgångskriterier kommer att beskrivas i detta avsnitt.

Till exempel,

Inträdeskriterier - Applikationen ska vara funktionellt stabil innan du distribuerar build för Performance Testing.

Utgångskriterier - Alla större brister är stängda och de flesta SLA: er uppfylls.

# 10) Risk och lindring: Eventuella risker som påverkar prestandatestningen måste listas här tillsammans med lindringsplanen för samma. Detta hjälper till att eventuella risker uppstår under Prestandatest eller åtminstone en lösning för Risken kommer att planeras i god tid. Detta kommer att hjälpa dig att slutföra prestandatesttabellerna i tid utan att påverka leveranserna.

# 11) Förkortningar: Används för förkortningar. Till exempel, PT - Prestandatest.

# 12) Dokumenthistorik: Detta innehåller dokumentversionen.

Innehållet i dokument för prestandatestplan

Låt oss ta en titt på vad allt ska ingå i ett dokument för prestandatestplan:

#1. Introduktion: Det är detsamma som anges i dokumentet Performance Test Strategy, snarare nämner vi bara Performance Test Plan istället för Performance Test Strategy.

# 2) Mål: Vad är målet med denna prestandatestning, vad uppnås genom att utföra prestandatestning, det vill säga vad är fördelarna med att göra prestandatestning bör tydligt nämnas här.

# 3) Räckvidd : Omfattning av prestandatestning, både i omfattning och utanför tillämpningsområdet, definieras här.

# 4) Tillvägagångssätt: Det övergripande tillvägagångssättet beskrivs här, hur prestandatester utförs? Vilka är förutsättningarna för att skapa miljön? etc ingår.

# 5) Arkitektur: Detaljer om applikationsarkitekturen bör nämnas här, som det totala antalet applikationsservrar, webbservrar, DB-servrar, brandväggar, 3rdd partyapplikation Lastmaskiner etc.

# 6) Beroenden: Alla teståtgärder före prestanda bör nämnas här, som om komponenterna som ska testas är funktionellt stabila, miljö skalas till en produktion som en och är tillgänglig eller inte, Testdatum är tillgängligt eller inte, Prestandatestverktyg finns med licenser om någon och så vidare.

# 7) Miljö: Vi måste nämna alla detaljer i systemet som IP-adress, hur många servrar etc. Vi bör också tydligt nämna hur miljö bör ställas in som förutsättningar, eventuella korrigeringar som ska uppdateras etc.

# 8) Testscenarier: Listan över scenarier som ska testas nämns i detta avsnitt.

# 9) Arbetsmix: Arbetsmixen spelar en viktig roll i det framgångsrika utförandet av prestandatestet och om arbetsbelastningsmixen inte förutsäger slutanvändarens realtidsåtgärd, blir alla testresultat fåfänga och vi får dålig prestanda i produktionen när ansökan går live.

Därför är det nödvändigt att korrekt utforma arbetsbelastningen. Förstå hur användarna kommer åt applikationen i produktion och om applikationen redan är tillgänglig eller annars försök få mer information från affärsteamet för att förstå applikationsanvändningen korrekt och definiera arbetsbelastningen.

# 10) Prestandakörningscykler: Detaljer om antalet prestandatestkörningar kommer att beskrivas i detta avsnitt. Till exempel, Baslinjetest, cykel 1 50 användartest etc.

# 11) Prestandatestmätvärden: Detaljerna för de insamlade mätvärdena kommer att beskrivas här, dessa mätvärden bör vara i acceptanskriterier med de överenskomna prestandakraven.

# 12) Testleveranser: Nämn leveranserna och inkludera även länkarna till dokumenten när det är tillämpligt.

# 13) Defekthantering: Här måste vi nämna hur fel hanteras, svårighetsgrader och prioritetsnivåer bör också beskrivas.

# 14) Riskhantering: Nämn de risker som är förknippade med åtgärdsplanen som om applikationen inte är stabil och om funktionsdefekter med hög prioritet fortfarande är öppna, kommer det att påverka schemat för prestandatestkörningarna och som sagt tidigare hjälper detta eventuella risker att inträffa under Prestandatest eller åtminstone en lösning för risken kommer att planeras i god tid.

# 15) Resurser: Nämn laguppgifterna tillsammans med deras roller och ansvar.

# 16) Versionshistorik: Håller koll på dokumenthistoriken.

testa fall i programvarutestningsexempel

# 17) Dokumentgranskningar och godkännanden: Detta har listan över personer som kommer att granska och godkänna det slutliga dokumentet.

Således har principiellt prestandateststrategi ett tillvägagångssätt för prestandatestning och prestandatestplan har detaljerna i tillvägagångssättet, varför de går ihop. Vissa företag har bara en prestandatestplan som har tillvägagångssätt lagt till dokumentet, medan andra har både strategi och plandokument separat.

Tips för att utveckla dessa dokument

Följ riktlinjerna nedan när du utformar strategin eller ett plandokument för framgångsrikt genomförande av prestandatester.

  • Kom alltid ihåg att när vi definierar en prestandateststrategi eller testplan måste vi fokusera på testmål och omfattning. Om vår teststrategi eller plan inte överensstämmer med kraven eller omfattningen är våra tester ogiltiga.
  • Försök att koncentrera dig och ta med de mätvärden som är viktiga att fånga under testkörningen för att identifiera eventuella flaskhalsar i systemet eller för att se applikationens prestanda.
  • Planera testkörningarna på ett sådant sätt att du inte testar alla scenarier samtidigt och kraschar systemet. Ha ett antal testkörningar och öka gradvis scenarierna och användarbelastningen.
  • I ditt tillvägagångssätt försök att lägga till alla enheter som din applikation kommer åt från, detta gäller vanligtvis mobila enheter.
  • Ha alltid en risk- och avböjningsavdelning i ditt strategidokument eftersom kraven ändras från tid till annan och dessa förändringar kommer att ha stor inverkan på exekveringscyklerna och tidsfristerna som måste adresseras till klienten i god tid.

Slutsats

Jag är säker på att den här självstudien skulle ha informerat dig om skillnaderna mellan en prestandateststrategi och plan tillsammans med dess innehåll, Approach for Mobile Application Performance Testing & Cloud application performance testing på ett detaljerat sätt med exempel.

Kolla in vår kommande handledning för att lära dig mer om sätten att ladda din prestandatestning.

=> Besök här för kompletta prestandatestningsserier

PREV-handledning | NÄSTA självstudie

Rekommenderad läsning

^