Menu

Forskellen mellem præstationsprøveplan og præstationsprøvestrategi

  • Vigtigste
  • Andet
  • Forskellen mellem præstationsprøveplan og præstationsprøvestrategi

difference between performance test plan

Prøv Vores Instrument Til At Fjerne Problemer

Hvad er forskellen mellem Performance Test Plan og Test Strategy?

I denne Performance-testserie , vores tidligere tutorial, forklaret om Funktionel testning vs Performance Testing i detaljer.

=> Klik her for at få komplette præstationsprøvetutorials-serier

I denne vejledning lærer du forskellen mellem Performance Test Plan og Test Strategy og det indhold, der skal medtages som en del af disse dokumenter.

Præstationsprøveplan vs teststrategi

Lad os forstå forskellen mellem disse to dokumenter.

Hvad du lærer:

Performance Test Strategi

Performance Test Strategy-dokument er et dokument på højt niveau, der giver os information om, hvordan vi udfører performance-test i testfasen. Det fortæller os, hvordan vi tester et forretningskrav, og hvilken tilgang der kræves for at kunne levere produktet til slutklienten.

Dette vil have alle oplysninger om forretningsprocessen på et meget højt niveau.

Dette dokument er normalt skrevet af Performance Test Managers baseret på deres tidligere erfaring, da der kun vil være begrænset information til rådighed, da dette dokument er udarbejdet i de indledende faser af projektet, dvs. under fase Kravsanalyse eller efter Kravsanalysefase.

Så med andre ord er et Performance Test Strategy-dokument intet andet end en retning, som du satte i starten af ​​projektet med den tilgang, du vil tage for at nå Performance Test-målene.

Et typisk dokument for præstationsteststrategi indeholder det overordnede mål for præstationstest, hvad skal testes? hvilket miljø vil blive brugt? hvilke værktøjer vil blive brugt? hvilke typer test udføres? Indgangs- og udgangskriterier, hvilke risici for en interessent mindskes? og få flere, som vi skal se detaljeret, når vi bevæger os længere i denne vejledning.

Performance Test Strategi

Ovenstående diagram forklarer, at Performance Test Strategy-dokumentet oprettes under eller efter projektets analyseanalyse.

Præstationsprøveplan

Performance Test Plan-dokument skrives på et senere tidspunkt i projektet, når kravene og designdokumenterne næsten er frossne. Performance Test Plan-dokumentet indeholder alle detaljerne i tidsplanen til implementering af strategien eller tilgangen, som blev beskrevet under kravanalysefasen.

Fra nu af er designdokumenterne næsten klar, Performance Test Plan indeholder alle detaljer om de scenarier, der skal testes. Det har også flere detaljer om de miljøer, der bruges til præstationstestkørsler, hvor mange cyklusser af testkørsler, ressourcer, indgangs- / udgangskriterier og mere. Performance Test Plan er enten skrevet af Performance Manager eller Performance Test Lead.

Præstationsprøveplan

Ovenstående diagram forklarer tydeligt, at Performance Test Plan oprettes under projektdesignet eller efter designfasen baseret på tilgængeligheden af ​​designdokumenterne.

Indhold i strategidokument for præstationstest

Lad os nu se, hvad alt skal inkluderes i et Performance Test Strategy-dokument:

#1. Introduktion: Giv en kort oversigt over, hvad et Performance Test Strategy-dokument vil indeholde for det pågældende projekt. Nævn også de hold, der vil bruge dette dokument.

entry level qa tester interview spørgsmål

# 2) Anvendelsesområde: Definition af omfanget er meget vigtigt, fordi det fortæller os, hvad der præcist vil være den testede ydelse. Vi skal være meget specifikke, når vi definerer omfanget eller ethvert andet afsnit.

Skriv aldrig noget generaliseret. Scope fortæller os, hvad der nøjagtigt vil blive testet for hele projektet. Vi har In scope og Out of scope som en del af scope, In scope beskriver alle de funktioner, der vil blive præsteret, og Out of scope beskriver de funktioner, som ikke vil blive testet.

# 3) Test Nærme sig: Her skal vi nævne den tilgang, som vi skal følge for vores præstationstest, da hvert script udføres med en enkelt bruger for at oprette en basislinje, og derefter vil disse baseline-tests blive brugt som en reference til benchmarking på et senere tidspunkt af tid under testkørsler.

Hver komponent testes også individuelt, inden de integreres sammen og så videre.

# 4) Test Typer: Her nævner vi de forskellige typer tests, der skal dækkes, som belastningstest, stresstest, udholdenhedstest, volumintest osv.

# 5) Test Leverancer: Nævn, hvad alle leverancer vil blive leveret som en del af Performance Testing for projektet som Test Run Report, Executive Summary Report osv.

# 6) Miljø: Her skal vi nævne detaljerne i miljøet. Miljøoplysninger er meget vigtige, da det beskriver, hvilke operativsystemer der skal bruges til Performance Testing.

Hvis miljøet vil være en kopi af produktionen, eller vil det blive dimensioneret eller dimensioneret fra produktionen og også forholdet mellem størrelse op og størrelse ned, dvs. vil det være halvt så stort som produktionen, eller vil det være dobbelt så stort som produktionen ?

Vi er også nødt til tydeligt at nævne eventuelle programrettelser eller sikkerhedsopdateringer, der skal betragtes som en del af det miljø, der er oprettet, og også under Performance Test Run.

# 7) Værktøjer: Her skal vi nævne alle de værktøjer, der vil blive brugt som f.eks. Ledelsesværktøjer , Performance Testing og Monitoring Tools. Nogle Eksempler af værktøjer til fejlsporing er JIRA , Til styring af dokumenter som Confluence, til Performance Testing Jmeter og til overvågning Nagios .

# 8) Ressourcer: Detaljer om de ressourcer, der kræves til Performance Testing Team, er dokumenteret i dette afsnit. For eksempel , Performance Manager, Performance Test Lead, Performance Testers osv.

# 9) Indgang & Afslut Kriterier: Indgangs- og udgangskriterier vil blive beskrevet i dette afsnit.

For eksempel,

Indgangskriterier - Applikationen skal være funktionelt stabil inden installation af build til Performance Testing.

Udgangskriterier - Alle de store fejl er lukket, og de fleste SLA'er er opfyldt.

# 10) Risiko og afbødning: Eventuelle risici, der påvirker præstationstesten, skal anføres her sammen med afbødningsplanen for det samme. Dette vil hjælpe enhver risiko, der opstår under Performance-test, eller i det mindste en løsning til risikoen vil blive planlagt i god tid. Dette vil hjælpe med at gennemføre præstationsprøveplanerne til tiden uden at påvirke resultaterne.

manuel test interview spørgsmål og svar i 3 år erfarne

# 11) Forkortelser: Bruges til forkortelser. For eksempel, PT - Performance Test.

# 12) Dokumenthistorik: Dette indeholder dokumentversionen.

Indhold i Performance Test Plan Document

Lad os se på, hvad alt skal inkluderes i et Performance Test Plan-dokument:

#1. Introduktion: Det er det samme som anført i dokumentet Performance Test Strategy, snarere nævner vi bare Performance Test Plan i stedet for Performance Test Strategy.

# 2) Mål: Hvad er formålet med denne præstationsafprøvning, hvad opnås ved at udføre præstationsafprøvning, dvs. hvad er fordelene ved at udføre præstationstest bør nævnes tydeligt her.

# 3) Anvendelsesområde : Omfanget af præstationsafprøvning, både i omfang og uden for anvendelsesområdet, er defineret her.

# 4) tilgang: Den overordnede tilgang er beskrevet her, hvordan præstationstest udføres? Hvad er forudsætningerne for at oprette miljøet? osv. er inkluderet.

# 5) Arkitektur: Detaljer om applikationsarkitekturen skal nævnes her som det samlede antal applikationsservere, webservere, DB-servere, firewalls, 3rdd part applikation Load generator maskiner osv.

# 6) Afhængigheder: Alle præ-performance testhandlinger skal nævnes her, ligesom komponenterne, der skal testes, er funktionelt stabile, miljøet skaleres til en produktion som en og er tilgængelig eller ej, Testdato er tilgængelig eller ej, Performance Testing-værktøjer er tilgængelige med licenser hvis nogen og så videre.

# 7) Miljø: Vi skal nævne alle detaljerne i systemet som IP-adresse, hvor mange servere osv. Vi skal også nævne klart, hvordan miljøet skal indstilles som forudsætningerne, eventuelle patches, der skal opdateres osv.

# 8) Testscenarier: Listen over scenarier, der skal testes, er nævnt i dette afsnit.

# 9) Work Load Mix: Arbejdsbelastningsblandingen spiller en vigtig rolle i den vellykkede udførelse af ydelsestesten, og hvis arbejdsbelastningsblandingen ikke forudsiger realtids slutbrugerhandling, bliver alle testresultater forgæves, og vi ender med dårlig ydelse i produktionen når applikationen går live.

Derfor er det nødvendigt at designe arbejdsbelastningen korrekt. Forstå, hvordan brugerne får adgang til applikationen i produktionen, og hvis applikationen allerede er tilgængelig, ellers prøv at få flere detaljer fra forretningsteamet for korrekt at forstå applikationsanvendelsen og definere arbejdsbyrden.

# 10) Ydelsesudførelsescyklusser: Detaljer om antallet af præstationstestkørsler vil blive beskrevet i dette afsnit. For eksempel, Basislinjetest, cyklus 1 50 brugertest osv.

# 11) Metrics for præstationstest: Detaljerne om de indsamlede metrics vil blive beskrevet her, disse metrics skal være i godkendelseskriterier med de aftalte præstationskrav.

# 12) Testleverancer: Nævn leverancerne, og inkorporer også links til dokumenterne, hvor det er relevant.

# 13) Fejlhåndtering: Her skal vi nævne, hvordan manglerne håndteres, sværhedsgrader og prioritetsniveauer skal også beskrives.

# 14) Risikostyring: Nævn de risici, der er involveret i afbødningsplanen, som hvis applikationen ikke er stabil, og hvis funktionelle defekter med høj prioritet stadig er åbne, vil det påvirke tidsplanen for præstationstestkørslerne, og som tidligere nævnt vil dette hjælpe eventuelle risici, der opstår under Performance test mindst en løsning til risikoen vil blive planlagt i god tid.

# 15) Ressourcer: Nævn holdets detaljer sammen med deres roller og ansvar.

# 16) Versionshistorik: Holder styr på dokumenthistorikken.

# 17) Dokumentanmeldelser og godkendelser: Dette har listen over personer, der vil gennemgå og godkende det endelige dokument.

Således har præstationsteststrategien grundlæggende en tilgang til præstationstestning og præstationstestplan har detaljerne i tilgangen, derfor går de sammen. Nogle virksomheder har bare en præstationsprøveplan, hvor tilgang er tilføjet til dokumentet, mens nogle har både strategi og plandokument separat.

Tips til udvikling af disse dokumenter

Følg nedenstående retningslinjer, mens du designer strategien eller et plandokument til vellykket udførelse af præstationstest.

  • Husk altid, at når vi definerer en strategi for præstationstest eller testplan, skal vi fokusere på testmål og omfang. Hvis vores teststrategi eller -plan ikke er i overensstemmelse med kravene eller omfanget, er vores test ugyldige.
  • Prøv at koncentrere dig og inkorporere de målinger, som er vigtige at registrere under testkørslen for at identificere eventuelle flaskehalse i systemet eller for at se applikationens ydeevne.
  • Planlæg testkørslerne på en sådan måde, at du ikke tester alle scenarierne på én gang og styrter systemet. Lav et antal testkørsler, og øg gradvist scenarierne og brugerbelastningen.
  • I din tilgang skal du prøve at tilføje alle de enheder, som din applikation vil få adgang til, dette gælder normalt for mobile enheder.
  • Hav altid en risiko- og afbødningsafsnit i dit strategidokument, da kravene ændrer sig fra tid til anden, og disse ændringer vil have stor indflydelse på eksekveringscyklusser og deadlines, der skal rettes til klienten i god tid.

Konklusion

Jeg er sikker på, at denne vejledning ville have orienteret dig om forskellene mellem en Performance Test Strategy og plan sammen med dens indhold, Approach for Mobile Application Performance Testing & Cloud application performance testing på en detaljeret måde med eksempler.

Se vores kommende vejledning for at vide mere om måderne at overbelaste din præstationstest på.

=> Besøg her for komplette ydeevne-test tutorials-serier

PREV-vejledning | NÆSTE vejledning

Anbefalet læsning

^