En komplett guide for ytelsestesting med eksempler

complete performance testing guide with examples

Hva er ytelsestesting?

Performance Testing kalles også 'Perf Testing', er en type testing som utføres for å sjekke hvordan applikasjon eller programvare utfører under arbeidsmengde når det gjelder respons og stabilitet. Performance Test-målet er å identifisere og fjerne ytelsesflaskehalser fra et program.

Denne testen utføres hovedsakelig for å sjekke om programvaren oppfyller de forventede kravene til applikasjonshastighet, skalerbarhet og stabilitet.

beste registerrenseren for Windows 7

I denne opplæringsserien vil vi dekke komplette detaljer som - Perf Testing Types, Process, and Writing Performance Test Strategy document fra bunnen av.

Dette er en detaljert opplæringsserie du kanskje vil legge til bokmerker!

La oss utforske!

Liste over ALLE opplæringstester i denne serien:

Opplæring # 1: Performance Testing Complete Guide (Denne opplæringen)
Opplæring # 2: Forskjellen mellom ytelse, belastning og stresstesting
Opplæring # 3: Funksjonell testing mot ytelsestesting
Opplæring # 4: Prestasjonstestplan og teststrategi
Opplæring # 5: Måter å overbelaste ytelsestestingen din
Opplæring # 6: Guide for testing av skyprestasjoner
Opplæring # 7: Veiledning for testing av ytelse for mobilapp
Opplæring # 8: Hvordan utføre manuell ytelsestesting
Opplæring # 9: Veiledning for testing av nettstedets ytelse
Opplæring # 10: Ytelsestesting selskaper
Opplæring # 11: Ytelsestesting med LoadRunner (Serie)

Verktøy:

Opplæring # 12: Topp ytelse testverktøy
Opplæring # 13: Neoload Performance Test Tutorial
Opplæring # 14: BlazeMeter Mobile Performance Test Tutorial
Opplæring # 15: WAPT Load, Stress and Performance Test Tutorial
Opplæring nr. 16: SmartMeter.io Opplæring i ytelsestest for nettsteder

Hva du vil lære:

• Typer ytelsestesting
  • Lastetesting
  • Stress Testing
  • Volumtesting
  • Kapasitetstesting
  • Pålitelighet / gjenopprettingstesting
• Ytelsestestprosess
• Hvordan skrive strategidokument for ytelsestest?
  • Eksempel på ytelsesteststrategimal
  • #1. Introduksjon
    • Objektiv
    • Arkitektur
  • # 2) Omfang
    • I sikte
    • Utenfor omfanget
  • # 3) Tilnærming
    • Scenarier for ytelsestest
    • Ytelsestesttyper
    • Ytelsesmålinger
    • Ytelsestesting aktiviteter og leveranser
  • # 4) Testdata
  • # 5) Oppføring og utgangskriterier
  • # 6) Feilbehandling
    • Definisjon av defekt alvorlighetsgrad
  • # 7) Testverktøy og teknikker
  • # 8) Kriterier for suspensjon og gjenopptakelse
  • # 9) Testleveranser
  • # 10) Roller og ansvar
  • # 11) Potensielle risikoer og avbøtningsplan
  • # 12) Antakelser
  • # 13) Avhengigheter
  • # 14) Forkortelser
• Beste fremgangsmåter for realistisk ytelsestesting
  • # 1) Planlegging
  • # 2) Utvikling
  • # 3) Utførelse
  • # 4) Analyse
  • Konklusjon
  • Anbefalt lesing

Typer ytelsestesting

Lastetesting

Load Testing er en type ytelsestest der applikasjonen testes for ytelse ved normal og topp bruk. Ytelsen til en applikasjon blir sjekket med hensyn til dens svar på brukerforespørselen og dens evne til å svare konsekvent innenfor en akseptert toleranse på forskjellige brukerbelastninger.

De viktigste hensynene er:

1. Hva er den maksimale belastningen applikasjonen klarer å holde før applikasjonen begynner å oppføre seg uventet?
2. Hvor mye data databasen kan håndtere før systemet treges eller krasjen blir observert?
3. Er det noen nettverksrelaterte problemer som skal løses?

Stress Testing

Stress Testing brukes til å finne måter å bryte systemet på. Testen gir også rekkevidden til maksimal belastning systemet kan holde.

Generelt har stresstesting en inkrementell tilnærming der belastningen økes gradvis. Testen startes med en belastning som applikasjonen allerede er testet for. Deretter tilsettes mer belastning sakte for å stresse systemet. Punktet der vi begynner å se servere som ikke svarer på forespørslene, betraktes som bristepunktet.

Følgende spørsmål skal tas opp:

• Hva er den maksimale belastningen et system kan tåle før det går i stykker?
• Hvordan går systemet i stykker?
• Er systemet i stand til å gjenopprette når det krasjer?
• På hvor mange måter et system kan gå i stykker og hvilke er den svake noden når den håndterer den uventede belastningen?

Volumtesting

Volumtesting er å verifisere at ytelsen til applikasjonen ikke påvirkes av datamengden som behandles av applikasjonen. For å utføre en volumtest blir et stort volum data lagt inn i databasen. Denne testen kan være en trinnvis eller jevn test. I den inkrementelle testen økes datamengden gradvis.

Vanligvis vokser databasestørrelsen med applikasjonsbruken, og det er nødvendig å teste applikasjonen mot en tung database. Et godt eksempel på dette kan være et nettsted til en ny skole eller en høyskole som har små datamengder å lagre i utgangspunktet, men etter 5-10 år er datalagrene i databasen til nettstedet mye mer.

Kapasitetstesting

=> Er applikasjonen i stand til å møte forretningsvolum både under normale og toppbelastningsforhold?

Kapasitetstesting gjøres vanligvis for fremtidsutsikter. Kapasitetstesting tar for seg følgende:

1. Vil applikasjonen kunne støtte fremtidig belastning?
2. Er miljøet i stand til å stå for den kommende økte belastningen?
3. Hva er tilleggsressursene som kreves for å gjøre miljøet i stand nok?

Kapasitetstesting brukes til å bestemme hvor mange brukere og / eller transaksjoner en gitt webapplikasjon vil støtte og fremdeles oppfylle ytelsen. Under denne testingen vurderes ressurser som prosessorkapasitet, nettverksbåndbredde, minnebruk, diskkapasitet osv. Og endres for å oppnå målet.

Nettbank er et perfekt eksempel på hvor kapasitetstesting kan spille en viktig rolle.

Pålitelighet / gjenoppretting Testing

Pålitelighetstesting eller gjenopprettingstest - er å verifisere om applikasjonen er i stand til å gå tilbake til sin normale tilstand etter en feil eller unormal oppførsel, og hvor lang tid tar det før den gjør det (med andre ord, tidsestimering).

Hvis et online handelssted opplever en feil der brukerne ikke er i stand til å kjøpe / selge aksjer på et bestemt tidspunkt på dagen (peak hours), men er i stand til å gjøre det etter en time eller to, kan vi si at applikasjonen er pålitelig eller gjenopprettet fra unormal oppførsel.

Ytelsestestprosess

Her er alle aktivitetene som er utført i denne testen:

# 1) Kravsanalyse / samling

Prestasjonsteamet samhandler med klienten for å identifisere og innhente krav - teknisk og forretningsmessig. Dette inkluderer å få informasjon om programmets arkitektur, teknologier og database som brukes, tiltenkte brukere, funksjonalitet, applikasjonsbruk, testkrav , maskinvare- og programvarekrav osv.

# 2) Valg av POC / verktøy

Når nøkkelfunksjonaliteten er identifisert, gjøres POC (Proof Of Concept - som er en slags demonstrasjon av sanntidsaktiviteten, men i begrenset forstand) med de tilgjengelige verktøyene.

Listen over tilgjengelige verktøy avhenger av kostnadene for verktøyet, protokollen som applikasjonen bruker, teknologiene som brukes til å bygge applikasjonen, antall brukere vi simulerer for testen osv. Under POC opprettes skript for den identifiserte nøkkelen funksjonalitet og utført med 10-15 virtuelle brukere.

# 3) Prestasjonstestplan og design

Avhengig av informasjonen som er samlet inn i de foregående trinnene, gjennomføres testplanlegging og design.

Testplanlegging innebærer informasjon om hvordan ytelsestesten skal foregå - testmiljø, arbeidsmengde, maskinvare osv.

Mer om teststrategidokumentet nedenfor.

# 4) Utvikling av ytelsestest

• Brukssaker opprettes for funksjonaliteten som er identifisert i testplanen som omfanget av PT.
• Disse brukssakene deles med klienten for godkjenning. Dette for å sikre at skriptet blir tatt opp med de riktige trinnene.
• Når den er godkjent, starter skriptutvikling med et opptak av trinnene i brukstilfeller med ytelsestestverktøyet valgt under POC (Proof of Concepts) og forbedret ved å utføre Korrelasjon (for håndtering av dynamisk verdi), Parameterisering (verdisubstitusjon) og egendefinerte funksjoner som per situasjon eller behov. Mer om disse teknikkene i våre videoopplæringsprogrammer.
• Skriptene blir deretter validert mot forskjellige brukere.
• Parallelt med å lage skript, fortsetter ytelsesteamet også med å sette opp testmiljøet (programvare og maskinvare).
• Performance-teamet vil også ta seg av Metadata (back-end) gjennom skript hvis denne aktiviteten ikke blir tatt opp av klienten.

# 5) Prestasjonstestmodellering

Performance Load Model opprettes for testutførelsen. Hovedmålet med dette trinnet er å validere om de gitte ytelsesberegningene (levert av klienter) oppnås under testen eller ikke. Det er forskjellige tilnærminger for å lage en Load-modell. “ Little’s Law ”Brukes i de fleste tilfeller.

# 6) Testutførelse

Scenariet er utformet i henhold til Load Model in Controller eller Performance Center, men de første testene utføres ikke med maksimalt antall brukere som er i Load-modellen.

Testutførelse gjøres trinnvis. For eksempel, Hvis maksimalt antall brukere er 100, kjøres scenariene først med 10, 25, 50 brukere og så videre, og til slutt går de videre til 100 brukere.

# 7) Testresultatanalyse

Testresultater er den viktigste leveransen for ytelsestesteren. Det er her vi kan bevise avkastningen (Return on Investment) og produktiviteten som en ytelsestesting kan gi.

Noen av de beste metodene som hjelper resultatanalyseprosessen:

1. Et unikt og meningsfylt navn for hvert testresultat - dette hjelper til å forstå formålet med testen.
2. Inkluder følgende informasjon i testresultatsammendraget:

• Årsak til svikt / er
• Endring i ytelsen til applikasjonen sammenlignet med forrige testkjøring
• Endringer som er gjort i testen fra applikasjonsbygningen eller testmiljøet.
• Det er en god praksis å lage et resultatsammendrag etter hver testkjøring, slik at analyseresultater ikke blir samlet hver gang testresultatene blir henvist.
• PT krever generelt mange testkjøringer for å komme til riktig konklusjon.
• Det er bra å ha følgende punkter i resultatoppsummeringen:
  • Formålet med testen
  • Antall virtuelle brukere
  • Scenariooppsummering
  • Testets varighet
  • Gjennomstrømning
  • Grafer
  • Grafer sammenligning
  • Responstid
  • Feil oppsto
  • Anbefalinger

# 8) Rapport

Testresultatene bør forenkles slik at konklusjonen er klarere og ikke trenger noen avledning. Utviklingsteamet trenger mer informasjon om analyse, sammenligning av resultater og detaljer om hvordan resultatene ble oppnådd.

oracle pl sql intervju spørsmål og svar for erfaren pdf

Testrapporten anses å være god hvis den er kort, beskrivende og til poenget.

Hvordan skrive strategidokument for ytelsestest?

Denne opplæringen vil forklare hvordan du skriver en prøve Performance Test Strategy for a Messaging Application.

Husk at dette bare er et eksempel og at kravene vil variere fra en klient til en annen, vi vil også bli kjent med de beste metodene for ytelsestesting i denne veiledningen.

Eksempel på ytelsesteststrategimal

Om ABC chat-applikasjon - La oss anta at dette er en chat-arbeidsbenk som brukes i et selskap av deres kundesupportagent. Denne chat-applikasjonen bruker XMPP-protokollen, dvs. Extensible Messaging and Presence Protocol og Open fire-server for sending og mottak av direktemeldinger.

Noen forbedringer har blitt gjort med denne eksisterende chatklienten, som ekstern PC-kontroll, PC-diagnose, reparasjonsverktøy, online chat, etc., så denne ytelsesteststrategien er et eksempel på slike applikasjoner.

For denne applikasjonen, la oss anta at prosjektgruppen har bestemt seg for å bruke JMeter for ytelsestesting og JIRA for feilsporing.

Den første siden i Performance Test Strategy-dokumentet skal inneholde tittelen på dokumentet og opphavsretten til selskapet.

Den andre siden skal inneholde Dokumentkontroll som inkluderer, Dokumentversjonshistorikk, Reviewers & Approvers-liste og Contributors-liste.

Den tredje siden skal inneholde innholdsfortegnelsen, etterfulgt av nedenstående emner.

#1. Introduksjon

Formålet med dette dokumentet er å definere / forklare hvordan Performance Testing vil bli utført på ABC chat-applikasjonen for den nåværende og fremtidige tilstanden.

ABC chat-applikasjon er en intern arbeidsbenk for ekstern support Agent. Denne arbeidsbenken vil bli brukt til å oppfylle kundeforespørsler. Denne arbeidsbenken har funksjoner som nettprat, kundeidentifikasjon, ekstern PC-kontroll, PC-diagnose og reparasjonsverktøy.

Objektiv

Hovedmålene for ytelsestesting er som følger:

• For å få tillit til at endringene i den eksisterende chat-applikasjonen er i tråd med den definerte servicenivåavtalen.
• For å sikre at applikasjonsytelsen, tjenestetilgjengeligheten og stabiliteten til applikasjonen ikke påvirkes som et resultat av de nye forbedringene.
• Transaksjonens svartider forblir innenfor akseptabel toleranse over den økende belastningsprofilen.
• JVM-er viser stabil minnebruk over de økende belastningsprofilene.

Bildet nedenfor forklarer tydelig ytelsestesting og optimaliseringsprosess:

Arkitektur

Du må ta med arkitekturdiagrammet til prosjektet ditt i denne økten.

# 2) Omfang

I sikte

Nedenfor er omfanget av ytelsestesting for ABC chat-arbeidsbenk:

• Kunnskapsinnhenting av de viktigste forretningstransaksjonene og bygge belastningsfordeling etter en detaljert studie av systemet.
• Identifiser de kritiske scenariene for ytelsestesting med hjelp fra forskjellige prosjektspor.
• Bruk de forrige utgivelsesresultatene som grunnlinje for fremtidige utgivelser.
• Verifiser og valider ytelsestestmiljøet og ytelses- / belastningsverktøyinfrastrukturen for ytterligere agentmaskiner.
• Utarbeidelse av ytelsestestskripter med JMeter for de identifiserte scenariene som etterligner den identifiserte topplasten.
• Sett opp ytelsesovervåking på serverne for å overvåke testen for å identifisere flaskehalsene i løpet av testutførelsesfasen.
• Publiser resultatresultater.
• Koordinere med ulike interessenter for å løse de identifiserte ytelsesproblemene.
• Basere ytelsesnivået for fremtidige utgivelser.

Utenfor omfanget

• Funksjonell testing , UAT, System Testing & Security Testing.
• Ytelsestesting / overvåking av tredjepartsgrensesnitt.
• Performance Tuning. (De fleste ganger stilles innstilling av et annet team, hvis du har ytelsesingeniører som kan stille inn systemet, kan du legge til dette i Inscope).
• Kodeprofilering / Maskinvarestørrelse / Kapasitetsplanlegging.
• Sikkerhet / Sårbarhetstesting / UAT / Testing av hvit boks .
• Data generering for ytelsestesting.
• Ikke-funksjonelle tester ( For eksempel, failover, katastrofegjenoppretting, sikkerhetskopiering, brukervennlighet) annet enn ytelsestestene.
• Testing av hvilken som helst mobil løsning.
• Tredjeparts applikasjonsytelsestesting og -justering.
• Realisering av ytelsesanbefalinger, endringer i applikasjonskoder og leverandørstøttede produkter / serverkonfigurasjonsendringer vil være utenfor omfanget fra Performance Team-perspektivet.
• Infrastrukturstøtte / Byggdistribusjon / Miljøberedskap / Databasegjenoppretting / Nettverksstøtte etc.

# 3) Tilnærming

Ytelsestesting for ABC chat vil bli utført ved hjelp av Jmeter ved å skrive tilpassede XMPP-plugins som bruker et smack-bibliotek for XMPP-tilkoblinger. Disse bibliotekene brukes til å sette opp tilkoblinger, logge inn og sende chatmeldinger til XMPP-serveren.

Disse bibliotekene er samlet i en jar-fil som distribueres i Jmeter og er designet basert på scenariene som skal testes. Jmeter Work Bench er installert i den lokale maskinen som kobles til JMeter-serveren som har Load Generators for å generere den nødvendige belastningen på Chat-serversystemet for å overvåke systematferden.

Testscenariet blir skriptet ved hjelp av JMeter-verktøyet. Skriptene vil bli tilpasset etter behov. Tidsplanen vil bli opprettet med den nødvendige oppkjøringen for å simulere virkelige scenarier.

Testscenariet vil bli brutt opp og målt i følgende aspekter:

a) Baselinjetest: Å kjøre hvert scenario med 1 Vuser og flere iterasjoner for å identifisere om applikasjonsytelsen oppfyller Business Service Level Agreement eller ikke.

b) Base Load Test: For å oppfylle Business Benchmark under belastningstest, vil Performance Testing-teamet utføre en grunnbelastningstest som vil bidra til å identifisere eventuelle systemytelsesproblemer med økende belastning og skaper grunnlinjen for neste nivå av ytelsestesting.

c) Toppbelastning / skalerbarhetstest: Performance Testing Team vil utføre flere tester med økende Vusers for å møte den forventede belastningen og også for å måle ytelsen til applikasjonen for å etablere ytelseskurven og identifisere om distribusjonen kan støtte servicenivåavtalene under den høyeste brukerbelastningen.

Det hjelper med tuning eller kapasitetsplanlegging av de enkelte virtuelle Java-maskinene (JVM), det totale antallet nødvendige JVM-er og prosessorene. Dette oppnås ved å øke antall Vusers til 50%, 75%, 100% og 125% av toppkapasiteten.

d) Utholdenhetstest: Performance Testing Team vil kjøre denne testen i en periode på 8 timer / 16 timer / 24 timer for å identifisere minnelekkasjer, ytelsesproblemer over tid og generell systemstabilitet. Under utholdenhetstester overvåker Performance Testing-teamet de viktigste ytelsesindikatorene, som for eksempel svartid for transaksjoner og stabiliteten til minnebruk.

Systemressurser som CPU, minne og IO må overvåkes ved hjelp av prosjektgruppen.

Performance-miljøet antas å være en kopi av produksjonsmiljøet. Testene kjøres med en trinnvis belastning for å identifisere hvor applikasjonen mislykkes.

Scenarier for ytelsestest

Inkluder excel med settet med scenarier.

For eksempel,

Scenario 1: For å validere agent- og kundechatten for X-nr. av samtidige økter.

Ytelsestesttyper

Tabellen nedenfor forklarer de forskjellige typene ytelsestester sammen med målene.

Ytelsesmålinger

• Målinger på klientsiden

• System- og nettverksytelsesmålinger

Ytelsestesting aktiviteter og leveranser

# 4) Testdata

Det antas at ytelsesmiljødataene vil være en kopi av produksjonsdataene, og de nødvendige testdataene vil bli gitt av prosjektgruppen.

det help desk intervju spørsmål og svar pdf

# 5) Oppføring og utgangskriterier

• Tilgang til alle applikasjonene i miljøet.
• Miljøberedskap komplett.
• Ytelsestest Data beredskap.

# 6) Feilbehandling

• Defekthåndteringsmodulen i JIRA vil bli brukt i prosjektet for feillogging og for sporing til lukking.
• Identifikasjon av feil som er funnet i løpet av testutførelsesfasen vil bli registrert i JIRA, og disse feilene vil bli løst av utviklingsteamet i henhold til alvorlighetsgraden nedenfor.
• Møter om mangler skal holdes daglig med deltakelse fra test-, utviklings-, kvalitetsanalytikere og forretningsteam.
• Kriteriene for å fikse feil vil bli strenge når prosjektet nærmer seg Go Live-datoen. Retningslinjer for kriterier for mangelfiksering som skal publiseres på møter med mangler.

Definisjon av defekt alvorlighetsgrad

Definisjonene av alvorlighets koder er som følger:

# 7) Testverktøy og teknikker

# 8) Kriterier for suspensjon og gjenopptakelse

Nedenfor er kriteriene for kritisk suspensjon og gjenopptakelse som vil påvirke testaktivitetene:

# 9) Testleveranser

Prestasjonstestleveringene inkluderer:

• Strategi for ytelsestesting
• Dokument for ytelseskrav
• Performance Test Scenario Document
• Ytelsestestskripter
• Resultatresultater for ytelse

# 10) Roller og ansvar

Roller og ansvar er tydelig forklart i tabellen nedenfor.

# 11) Potensielle risikoer og avbøtningsplan

# 12) Antakelser

• Performance Test Environment vil være en kopi av produktarkitekturlandskapet. (dvs. riktig maskinvare, programvare, grensesnitt, integrasjonslag osv.).
• Ytelsesskript vil bli designet basert på de kritiske flytene som bruken er høy for.
• Alle infrastrukturproblemer bør løses før ytelsestesting. Eventuelle endringer i systemkonfigurasjonen som blir gjort senere, ugyldiggjør testresultatene.
• En applikasjon er stabil og klar til bruk i ytelsestestmiljøet.
• Nødvendige maskinvare- og programvareressurser (som lastgeneratormaskiner / programvare, kontroller- / agentmaskiner) blir gjort tilgjengelig.
• Eventuelle endringer i omfanget vil gå gjennom en endringskontrollprosess, og prestasjonstesteteamet vil vurdere effekten av tidslinjer og ressurser.
• Respektive servere forventes å håndtere belastningen.
• Søknadsporlogger for applikasjoner må være aktivert for støttesystemene for overvåkingsformål.

# 13) Avhengigheter

• Tilgjengeligheten av Performance-testmiljøet som er en kopi av produktarkitekturlandskapet.
• Støtte kreves fra forskjellige funksjonelle, utviklings-, database- og infrastrukturteam i løpet av testforberedelsen og gjennomføring.
• Ingen kodeendringer implementeres i løpet av hele ytelsestestingsfasen, siden tiden er veldig begrenset.
• I tilfelle uforutsette problemer som fører til restriksjoner innenfor tidslinjene, hvis tidslinjene ikke tillater at alle testomfangene oppfylles innen de opprinnelige milepældatoene, er støtte tilgjengelig fra Release Managers, for å gi en avgrensning og prioritering.
• Søknadsbedriftsbrukere / fagpersoner vil bli gjort tilgjengelig for funksjonelle avklaringer og forretningstransaksjoner.
• ABC chat Program Manager vil gjennomgå og logge av.

# 14) Forkortelser

Nå må du ha klart forstått hvordan du skal skrive en effektiv ytelsesteststrategi for en Messaging-applikasjon.

Beste fremgangsmåter for realistisk ytelsestesting

For å fullføre et Performance Test-prosjekt, må vi sørge for at vi gjør det på riktig måte fra planleggingsfasen, dvs. planlegging, utvikling, gjennomføring og analyse.

La oss se nærmere på hvert trinn for å kunne utføre ytelsestesting effektivt.

# 1) Planlegging

• Prøv å identifisere de vanligste arbeidsflytene, dvs. forretningsscenariene som må testes. Hvis applikasjonen er en eksisterende, må du sjekke serverloggene for å forstå de mest brukte scenariene. Hvis applikasjonen er ny enn snakk med prosjektledelsen for å forstå den store forretningsflyten.
• Planlegg belastningstesten på en slik måte at du dekker et bredt spekter av arbeidsflyter som lett bruk, middels bruk og toppbelastning.
• Du må utføre mange sykluser av belastningstesten, så prøv å lage et rammeverk slik at du kan bruke de samme skriptene igjen og igjen. Prøv også å ta en sikkerhetskopi av skriptene.
• Prøv å analysere hvor lenge en test må løpe, er det en time? 8 timer? En dag eller en uke? Vanligvis vil langvarige tester avdekke mange store feil som OS-feil, minnelekkasjer, etc.
• Hvis organisasjonen din bruker et hvilket som helst APM (Application Monitoring Tool), kan du inkludere det under testkjøringene, slik at du enkelt kan identifisere ytelsesproblemene og identifisere årsaken lettere.

# 2) Utvikling

• Mens du utvikler skriptene, dvs. opptak, kan du prøve å gi et mer meningsfylt transaksjonsnavn basert på forretningsflytenavnene som er nevnt i planen.
• Ikke ta opp noen tredjepartsapplikasjoner, og hvis det blir registrert, kan du prøve å filtrere det mens du forbedrer skriptene.
• Ikke alle dynamiske verdier kan korreleres ved hjelp av Autokorrelasjons-funksjonen i verktøyet, så prøv å gjøre en manuell korrelasjon for å unngå feil.
• Prøv å utforme ytelsestestene dine på en slik måte at du treffer applikasjonens bakside og ikke bare hurtigbuffer-serveren.

# 3) Utførelse

• Sørg for å kjøre testene i et produksjonslignende miljø, inkludert faktorer som SSL, Load Balancer og Firewalls. Dette er nødvendig for å simulere en realistisk belastning på systemet.
• Prøv å lage en arbeidsmengde som er veldig realistisk, du kan få dette ved å sjekke serverloggene hvis det er et eksisterende program, og hvis det er et nytt program, må du få denne informasjonen fra forretningsteamet. Husk at arbeidsmengde er veldig viktig for å gjennomføre vellykkede ytelsestester.
• Kom aldri til en konklusjon ved å kjøre tester med halvparten av produksjonsstørrelsesmiljøet, det anbefales alltid å utføre tester i et miljø som er akkurat det samme som produksjonen.
• Mens du utfører langvarige tester, kan du prøve å se løpeturen med jevne mellomrom for å sikre at testen kjører problemfritt.

# 4) Analyse

• Prøv å analysere applikasjonen ved å legge til noen viktige tellere først, når en flaskehals er funnet, prøv å legge til flere tellere med hensyn til flaskehalsen. Dette vil igjen hjelpe til med å finne problemet lettere.
• Et program kan mislykkes av mange grunner, for eksempel det kan ikke svare på en forespørsel, svare med en feilkode, mislykkes valideringslogikken din eller svare for sakte. Så prøv å se på alle disse før du kommer til en konklusjon.

Konklusjon

Jeg er sikker på at denne veiledningen ville gitt deg enorm kunnskap om ytelsestester og hvordan du skriver et strategidokument for ytelsestest med detaljerte eksempler.

I vår kommende opplæring vil vi lære forskjellene mellom ytelse, belastning og stresstesting i detalj.

Sjekk også => Gratis LoadRunner inngående treningsserie

NESTE veiledning

Anbefalt lesing

• Ytelsestesting vs belastningstesting vs stresstesting (forskjell)
• Lastetesting med HP LoadRunner-opplæringsprogrammer
• Cloud Performance Testing: Cloud-Based Load Testing Service Providers
• Nettapplikasjonsbelastning, stress og ytelsestesting ved bruk av WAPT
• Verktøy og tjenester for ytelse av nettstedets ytelse
• Hvordan utføre manuell ytelsestesting?
• Ytelsestesting av mobile applikasjoner ved bruk av BlazeMeter
• Nettjenestetestets ytelsestesting ved bruk av LoadRunner VuGen Scripting