Meny

Forskjellen mellom ytelsestestplan og ytelsesteststrategi

  • Hoved
  • Annen
  • Forskjellen mellom ytelsestestplan og ytelsesteststrategi

difference between performance test plan

Prøv Instrumentet Vårt For Å Eliminere Problemer

Hva er forskjellen mellom Performance Test Plan og Test Strategy?

I dette Performance Testing-serien , vår forrige opplæring, forklart om Funksjonell testing mot ytelsestesting i detalj.

=> Klikk her for å få fullstendige ytelsestestopplæringsserier

I denne veiledningen vil du lære om forskjellen mellom Performance Test Plan og Test Strategy og innholdet som skal inkluderes som en del av disse dokumentene.

Prestasjonstestplan vs teststrategi

La oss forstå forskjellen mellom disse to dokumentene.

Hva du vil lære:

Prestasjonsteststrategi

Performance Test Strategy-dokument er et høyt nivå dokument som gir oss informasjon om hvordan vi kan utføre ytelsestesting i testfasen. Den forteller oss hvordan vi skal teste et forretningskrav og hvilken tilnærming som kreves for å kunne levere produktet til sluttkunden.

Dette vil ha all informasjon om forretningsprosessen på et veldig høyt nivå.

Dette dokumentet er vanligvis skrevet av Performance Test Managers basert på deres tidligere erfaring, da det kun vil være begrenset informasjon tilgjengelig ettersom dette dokumentet er utarbeidet i de innledende stadiene av prosjektet, det vil si i løpet av kravanalysefasen eller etter kravanalysefasen.

Så med andre ord, et Performance Test Strategy-dokument er ingenting annet enn en retning som du satte i starten av prosjektet med den tilnærmingen du skal ta, for å oppnå Performance testing-målene.

Et typisk dokument for ytelsesteststrategi inneholder det overordnede målet med ytelsestesting som hva som skal testes? hvilket miljø vil bli brukt? hvilke verktøy vil bli brukt? hvilke typer testing vil bli utført? Inngangs- og utgangskriterier, hvilke risikoer for en interessent reduseres? og noen flere som vi skal se nærmere på når vi går videre i denne opplæringen.

Prestasjonsteststrategi

Diagrammet ovenfor forklarer at Performance Test Strategy-dokumentet er opprettet under eller etter Krav-analysefasen av prosjektet.

Prestasjonstestplan

Performance Test Plan-dokumentet blir skrevet på et senere tidspunkt i prosjektet når kravene og designdokumentene nesten er frosset. Performance Test Plan-dokumentet har alle detaljene i planen for å implementere strategien eller tilnærmingen som ble beskrevet under Kravsanalysefasen.

Fra nå av er designdokumentene nesten klare, Performance Test Plan inneholder alle detaljer om scenariene som skal testes. Den har også flere detaljer om miljøene som brukes til ytelsestestkjøringer, hvor mange sykluser av testkjøringer, ressurser, inngangsutgangskriterier og mer. Performance Test Plan er enten skrevet av Performance Manager eller Performance Test Lead.

Prestasjonstestplan

Diagrammet ovenfor forklarer tydelig at ytelsestestplanen er opprettet under prosjektet Design eller etter designfasen basert på tilgjengeligheten av designdokumentene.

Innhold i Performance Test Strategy Document

La oss nå se hva alt skal inkluderes i et Performance Test Strategy-dokument:

#1. Introduksjon: Gi en kort oversikt over hva et Performance Test Strategy-dokument vil inneholde for det aktuelle prosjektet. Nevn også teamene som skal bruke dette dokumentet.

vennefunksjoner i c ++

# 2) Omfang: Å definere omfanget er veldig viktig fordi det forteller oss hva som blir testet. Vi må være veldig spesifikke når vi definerer omfanget eller en hvilken som helst annen seksjon.

Skriv aldri noe generalisert. Scope forteller oss hva som skal testes for hele prosjektet. Vi har i omfang og utenfor omfang som en del av omfanget, i omfang beskriver alle funksjonene som vil bli ytelsestestet og utenfor omfang beskriver funksjonene som ikke vil bli testet.

# 3) Test Nærme seg: Her må vi nevne om tilnærmingen vi skal følge for våre ytelsestester, slik at hvert skript vil bli utført med en enkelt bruker for å lage en grunnlinje, og deretter vil disse baselinjetestene bli brukt som referanse for benchmarking på et senere tidspunkt av tid under testkjøringer.

Hver komponent vil også bli testet individuelt før de integreres sammen og så videre.

# 4) Test Typer: Her nevner vi de forskjellige typene tester som skal dekkes, som belastningstest, stresstest, utholdenhetstest, volumtest etc.

# 5) Test Leveranser: Nevn hva alle leveranser vil bli gitt som en del av ytelsestesting for prosjektet, som testkjøringsrapport, sammendragsrapport etc.

# 6) Miljø: Her må vi nevne detaljene i miljøet. Miljødetaljer er veldig viktige ettersom det beskriver hvilke operativsystemer som skal brukes til ytelsestesting.

Hvis miljøet vil være en kopi av produksjonen, eller vil det bli størrelse eller størrelse ned fra produksjonen, og også forholdet mellom størrelse opp og størrelse ned, dvs. vil det være halvparten av størrelsen på produksjonen, eller vil det være dobbelt så stort som produksjonen ?

Vi må også tydelig nevne eventuelle oppdateringer eller sikkerhetsoppdateringer som skal betraktes som en del av miljøet som er satt opp, og også under Performance Test Run.

# 7) Verktøy: Her må vi nevne alle verktøyene som vil bli brukt som verktøy for feilsporing, Ledelsesverktøy , Ytelsestesting og overvåkingsverktøy. Noen Eksempler av verktøy for sporing av mangler er JIRA , For administrasjon av dokumenter som Confluence, for Performance Testing Jmeter og for overvåking Nagios .

# 8) Ressurser: Detaljer om ressursene som kreves for Performance Testing Team er dokumentert i denne delen. For eksempel , Performance Manager, Performance Test Lead, Performance Testers etc.

# 9) Oppføring & Exit Kriterier: Inngangs- og utgangskriterier vil bli beskrevet i denne delen.

For eksempel,

Oppføringskriterier - Applikasjonen skal være funksjonelt stabil før du distribuerer build for Performance Testing.

Utgangskriterier - Alle de store feilene er lukket, og de fleste SLAer blir oppfylt.

# 10) Risiko og avbøtende forhold: Eventuelle risikoer som vil påvirke ytelsestestingen må være oppført her sammen med avbøtningsplanen for det samme. Dette vil hjelpe enhver risiko fra å oppstå under ytelsestesting eller i det minste en løsning for risikoen vil bli planlagt i god tid. Dette vil hjelpe deg med å fullføre ytelsestestplanene i tide uten å påvirke resultatene.

# 11) Forkortelser: Brukes til forkortelser. For eksempel, PT - ytelsestest.

# 12) Dokumenthistorikk: Dette inneholder dokumentversjonen.

Innhold i dokumentet for ytelsestestplan

La oss ta en titt på hva alt skal inkluderes i et Performance Test Plan-dokument:

#1. Introduksjon: Det er det samme som angitt i dokumentet Performance Test Strategy, snarere nevner vi bare Performance Test Plan i stedet for Performance Test Strategy.

# 2) Mål: Hva som er målet med denne ytelsestestingen, hva som oppnås ved å utføre ytelsestesting, dvs. hvilke fordeler det er å gjøre ytelsestesting, bør nevnes tydelig her.

# 3) Omfang : Omfanget av ytelsestesting, både i omfang og utenfor rekkevidde, er definert her.

# 4) Tilnærming: Samlet tilnærming er beskrevet her, hvordan ytelsestesting utføres? Hva er forutsetningene for å sette opp miljøet? etc er inkludert.

# 5) Arkitektur: Detaljer om applikasjonsarkitekturen bør nevnes her, som det totale antallet applikasjonsservere, webservere, DB-servere, brannmurer, 3rdd part applikasjon Last generator maskiner etc.

# 6) Avhengighet: Alle testhandlinger før ytelse bør nevnes her, som komponentene som skal ytelsestestes er funksjonelt stabile, miljøet skaleres til en produksjon som en og er tilgjengelig eller ikke, testdato er tilgjengelig eller ikke, ytelsestestingsverktøy er tilgjengelig med lisenser hvis noen og så videre.

# 7) Miljø: Vi må nevne alle detaljene i systemet som IP-adresse, hvor mange servere osv. Vi bør også nevne tydelig som hvordan miljøet skal settes opp som forutsetninger, eventuelle oppdateringer som skal oppdateres etc.

# 8) Testscenarier: Listen over scenarier som skal testes er nevnt i dette avsnittet.

# 9) Work Load Mix: Arbeidsbelastningsblandingen spiller en viktig rolle i vellykket gjennomføring av ytelsestesten, og hvis arbeidsbelastningsblandingen ikke forutsier sluttbrukerhandling i sanntid, blir alle testresultatene forgjeves, og vi ender med dårlig ytelse i produksjonen når søknaden går live.

Derfor er det nødvendig å utforme arbeidsmengden riktig. Forstå hvordan brukerne får tilgang til applikasjonen i produksjonen, og om applikasjonen allerede er tilgjengelig, ellers prøv å få mer informasjon fra forretningsteamet for å forstå applikasjonsbruken og definere arbeidsmengden.

# 10) Ytelsessykluser for ytelse: Detaljer om antall ytelsestestkjøringer vil bli beskrevet i dette avsnittet. For eksempel, Basislinjetest, syklus 1 50 brukertest osv.

topp 10 markedsundersøkelsesbedrifter i verden

# 11) Måling av ytelsestest: Detaljer om beregningene som er samlet vil bli beskrevet her. Disse beregningene bør være i akseptkriterier med de avtalte ytelseskravene.

# 12) Testleveranser: Nevn leveransen, og ta også med lenker til dokumentene der det er aktuelt.

# 13) Feilbehandling: Her må vi nevne hvordan manglene håndteres, alvorlighetsgrader og prioritetsnivåer skal også beskrives.

# 14) Risikostyring: Nevn risikoen forbundet med avbøtningsplanen, for eksempel hvis applikasjonen ikke er stabil og hvis funksjonsfeil med høy prioritet fremdeles er åpne, vil det påvirke tidsplanen for ytelsestestkjøringene, og som sagt tidligere vil dette bidra til at eventuelle risikoer oppstår under ytelsestesting eller i det minste vil en løsning for risikoen planlegges i god tid.

# 15) Ressurser: Nevn teamets detaljer sammen med deres roller og ansvar.

# 16) Versjonshistorikk: Holder oversikt over dokumenthistorikken.

# 17) Dokumentanmeldelser og godkjenninger: Dette har listen over personer som vil gjennomgå og godkjenne det endelige dokumentet.

Dermed har Performance Test Strategy i utgangspunktet en tilnærming til Performance Testing og Performance Test Plan har detaljene i tilnærmingen, derav de går sammen. Noen selskaper har bare en ytelsestestplan som har tilnærming lagt til dokumentet, mens noen har både strategi og plandokument hver for seg.

Tips for å utvikle disse dokumentene

Følg retningslinjene nedenfor mens du designer strategien eller et plandokument for vellykket gjennomføring av ytelsestester.

  • Husk alltid at mens vi definerer en ytelsesteststrategi eller testplan, må vi fokusere på testmål og omfang. Hvis vår teststrategi eller plan ikke er i tråd med kravene eller omfanget, er testene våre ugyldige.
  • Prøv å konsentrere deg og innlemme beregningene som er viktige å fange under testkjøringen for å identifisere eventuelle flaskehalser i systemet eller for å se ytelsen til applikasjonen.
  • Planlegg testkjøringene på en slik måte at du ikke tester alle scenariene samtidig og krasjer systemet. Gjør et antall testkjøringer og øk gradvis scenariene og brukerbelastningen.
  • I din tilnærming prøver du å legge til alle enhetene som applikasjonen din vil få tilgang til, dette gjelder vanligvis mobile enheter.
  • Ha alltid en risiko- og avbøtende seksjon i strategidokumentet ditt, ettersom kravene endres fra tid til annen, og disse endringene vil ha stor innvirkning på utførelsessyklusene og tidsfrister som må rettes til klienten i god tid.

Konklusjon

Jeg er sikker på at denne opplæringen ville ha orientert deg om forskjellene mellom en ytelsesteststrategi og plan sammen med innholdet, Tilnærming for ytelsestesting av mobilapplikasjon og ytelsestesting i skyapplikasjoner på en detaljert måte med eksempler.

Ta en titt på den kommende veiledningen vår for å lære mer om måtene å overbelaste ytelsestestingen din.

=> Besøk her for komplette ytelsestestopplæringsserier

PREV Opplæring | NESTE veiledning

Anbefalt lesing

^