Performance Testing Tutorial: Hva er, typer, beregninger og amp; Eksempel

Innholdsfortegnelse:

Anonim

Ytelsestesting

Performance Testing er en testprosess for programvare som brukes til å teste hastigheten, responstiden, stabiliteten, påliteligheten, skalerbarheten og ressursbruken til et program under en spesiell arbeidsbelastning. Hovedformålet med ytelsestesting er å identifisere og eliminere ytelsesflaskehalsene i programvaren. Det er en delmengde av performance engineering og også kjent som "Perf Testing".

Fokus for ytelsestesting er å sjekke programvarens

  • Hastighet - Bestemmer om applikasjonen reagerer raskt
  • Skalerbarhet - Bestemmer maksimal brukerbelastning programvaren kan håndtere.
  • Stabilitet - Bestemmer om applikasjonen er stabil under varierende belastning

I denne veiledningen vil du lære-

  • Hva er ytelsestesting?
  • Hvorfor gjøre ytelsestesting?
  • Typer ytelsestesting
  • Vanlige ytelsesproblemer
  • Ytelsestestingsprosess
  • Ytelse Testing Metrics: Parameters Monitored
  • Eksempel på ytelsestesttilfeller
  • Ytelsestestverktøy
  • FAQ

Hvorfor gjøre ytelsestesting?

Funksjoner og funksjonalitet støttet av et programvaresystem er ikke det eneste problemet. Et programvares ytelse som responstid, pålitelighet, ressursbruk og skalerbarhet har betydning. Målet med Performance Testing er ikke å finne feil, men å eliminere ytelsesflaskehalser.

Performance Testing er gjort for å gi interessenter informasjon om deres applikasjon angående hastighet, stabilitet og skalerbarhet. Enda viktigere, Performance Testing avdekker hva som må forbedres før produktet går på markedet. Uten ytelsestesting, vil programvare sannsynligvis lide av problemer som: kjører sakte mens flere brukere bruker den samtidig, inkonsekvenser på tvers av forskjellige operativsystemer og dårlig brukervennlighet.

Ytelsestesting vil avgjøre om programvaren deres oppfyller hastighet, skalerbarhet og stabilitetskrav under forventede arbeidsmengder. Søknader som sendes til markedet med dårlige ytelsesberegninger på grunn av ikke-eksisterende eller dårlig ytelsestesting, vil sannsynligvis få et dårlig rykte og ikke oppfylle forventede salgsmål.

Også, oppdragskritiske applikasjoner som romoppstartsprogrammer eller livreddende medisinsk utstyr bør ytelsestestes for å sikre at de kjører i en lang periode uten avvik.

Ifølge Dunn & Bradstreet opplever 59% av Fortune 500-selskapene anslagsvis 1,6 timers nedetid hver uke. Tatt i betraktning det gjennomsnittlige Fortune 500-selskapet med minst 10 000 ansatte betaler $ 56 per time, vil arbeidsdelen av nedetidskostnadene for en slik organisasjon være $ 896 000 ukentlig, og oversettes til mer enn $ 46 millioner per år.

Bare en 5-minutters nedetid på Google.com (19. august-13) anslås å koste søkegiganten så mye som $ 545.000.

Det anslås at selskaper mistet salg til en verdi av $ 1100 per sekund på grunn av en nylig Amazon Web Service Outage.

Derfor er ytelsestesting viktig.

Typer ytelsestesting

  • Lastetesting - sjekker applikasjonens evne til å utføre under forventet brukerbelastning. Målet er å identifisere ytelsesflaskehalser før programvaren går live.
  • Stresstesting - innebærer å teste et program under ekstreme arbeidsbelastninger for å se hvordan det håndterer høy trafikk eller databehandling. Målet er å identifisere bruddpunktet for en applikasjon.
  • Utholdenhetstesting - er gjort for å sikre at programvaren kan håndtere forventet belastning over lang tid.
  • Spike testing - tester programvarens reaksjon på plutselige store pigger i belastningen som genereres av brukerne.
  • Volumtesting - Under Volumtesting stort nr. av. Data er fylt ut i en database og det overordnede programvaresystemets oppførsel blir overvåket. Målet er å sjekke programvarens ytelse under varierende databasevolumer.
  • Skalerbarhetstesting - Målet med skalerbarhetstesting er å bestemme programvarens effektivitet i å "skalere opp" for å støtte en økning i brukerbelastningen. Det hjelper med å planlegge kapasitetstillegg til programvaresystemet ditt.

Vanlige ytelsesproblemer

De fleste ytelsesproblemer dreier seg om hastighet, responstid, lastetid og dårlig skalerbarhet. Hastighet er ofte en av de viktigste egenskapene til en applikasjon. Et sakte kjørende program vil miste potensielle brukere. Ytelsestesting gjøres for å sikre at en app kjører raskt nok til å holde brukerens oppmerksomhet og interesse. Ta en titt på følgende liste over vanlige ytelsesproblemer og legg merke til hvordan hastighet er en vanlig faktor i mange av dem:

  • Lang lastetid - Lastetid er normalt den første tiden det tar en applikasjon å starte. Dette bør generelt holdes på et minimum. Mens noen applikasjoner er umulige å laste på under et minutt, bør lastetiden holdes under noen få sekunder hvis mulig.
  • Dårlig responstid - Svartid er tiden det tar fra når en bruker legger inn data i applikasjonen til applikasjonen sender ut et svar på den inngangen. Generelt sett bør dette gå veldig raskt. Igjen hvis en bruker må vente for lenge, mister de interessen.
  • Dårlig skalerbarhet - Et programvareprodukt lider av dårlig skalerbarhet når det ikke kan håndtere forventet antall brukere eller når det ikke har plass til et stort nok utvalg av brukere. Lastetesting bør gjøres for å være sikker på at applikasjonen kan håndtere det forventede antall brukere.
  • Flaskehalsing - Flaskehalser er hindringer i et system som forringer systemets ytelse. Flaskehalsing er når kodingsfeil eller maskinvareproblemer forårsaker redusert gjennomstrømning under visse belastninger. Flaskehalsing er ofte forårsaket av en feil kode. Nøkkelen til å fikse et flaskehalsproblem er å finne den delen av koden som forårsaker avmatningen og prøve å fikse den der. Flaskehalsing løses vanligvis ved å enten fikse dårlige prosesser som kjører eller legge til ekstra maskinvare. Noen vanlige ytelsesflaskehalser er
    • CPU-bruk
    • Minneutnyttelse
    • Nettverksutnyttelse
    • Begrensninger for operativsystem
    • Diskbruk

Ytelsestestingsprosess

Metoden som brukes for ytelsestesting kan variere mye, men målet for ytelsestester forblir den samme. Det kan bidra til å demonstrere at programvaresystemet ditt oppfyller visse forhåndsdefinerte ytelseskriterier. Eller det kan bidra til å sammenligne ytelsen til to programvaresystemer. Det kan også bidra til å identifisere deler av programvaresystemet ditt som forringer ytelsen.

Nedenfor er en generell prosess for hvordan du utfører ytelsestesting

  1. Identifiser testmiljøet ditt - Kjenn til ditt fysiske testmiljø, produksjonsmiljø og hvilke testverktøy som er tilgjengelige. Forstå detaljer om maskinvare, programvare og nettverkskonfigurasjoner som brukes under testing før du begynner testprosessen. Det vil hjelpe testere å lage mer effektive tester. Det vil også bidra til å identifisere mulige utfordringer som testere kan møte under ytelsestestprosedyrene.
  2. Identifiser kriteriene for ytelsesaksept - Dette inkluderer mål og begrensninger for gjennomstrømning, responstid og ressurstildeling. Det er også nødvendig å identifisere suksesskriterier for prosjekter utenfor disse målene og begrensningene. Testere bør ha fullmakt til å sette ytelseskriterier og mål, fordi prosjektspesifikasjonene ofte ikke inkluderer et stort nok utvalg av ytelsesverdier. Noen ganger kan det være ingen i det hele tatt. Når det er mulig å finne et lignende program å sammenligne med, er det en god måte å sette resultatmål.
  3. Planlegg og design ytelsestester - Bestem hvordan bruk sannsynligvis vil variere blant sluttbrukere, og identifiser viktige scenarier for å teste for alle mulige brukssaker. Det er nødvendig å simulere en rekke sluttbrukere, planlegge ytelsestestdata og skissere hvilke beregninger som skal samles inn.
  4. Konfigurere testmiljøet - Forbered testmiljøet før utførelse. Arranger også verktøy og andre ressurser.
  5. Implementere testdesign - Lag ytelsestester i henhold til testdesignet ditt.
  6. Kjør testene - Utfør og overvåke testene.
  7. Analyser, still inn og test på nytt - Konsolider, analyser og del testresultatene. Finjuster deretter og test igjen for å se om det er en forbedring eller reduksjon i ytelsen. Siden forbedringer generelt blir mindre for hver omprøve, må du stoppe når flaskehalsen skyldes CPU. Da kan du vurdere muligheten for å øke CPU-kraften.

Ytelse Testing Metrics: Parameters Monitored

De grunnleggende parametrene som overvåkes under ytelsestesting inkluderer:

  • Prosessorbruk - en tidsprosessor bruker på å utføre ikke-inaktive tråder.
  • Minnebruk - mengden fysisk minne tilgjengelig for prosesser på en datamaskin.
  • Disktid - hvor lang tid disk er opptatt med å utføre en lese- eller skriveforespørsel.
  • Båndbredde - viser bitene per sekund som brukes av et nettverksgrensesnitt.
  • Private bytes - antall byte en prosess har tildelt som ikke kan deles mellom andre prosesser. Disse brukes til å måle minnelekkasjer og bruk.
  • Forpliktet minne - mengden virtuelt minne som brukes.
  • Minne sider / sekund - antall sider skrevet til eller lest fra disken for å løse feil på harde sider. Feil på harde sider er når koden ikke fra det gjeldende arbeidssettet blir hentet fra andre steder og hentet fra en disk.
  • Sidefeil / sekund - den totale hastigheten som feilsider behandles av prosessoren. Dette skjer igjen når en prosess krever kode utenfor arbeidssettet.
  • CPU avbryter per sekund - er gjennomsnittet. antall maskinvareavbrudd en prosessor mottar og behandler hvert sekund.
  • Diskekylengde - er gjennomsnittlig Nei. av lese- og skriveforespørsler i kø for den valgte disken i løpet av et prøveintervall.
  • Lengde på nettverksutgangskø - lengden på utpakkekøen i pakker. Noe mer enn to betyr en forsinkelse og flaskehalsing må stoppes.
  • Nettverksbyte totalt per sekund - hastighet på hvilke byte som sendes og mottas på grensesnittet inkludert innrammingstegn.
  • Svartid - tid fra når en bruker skriver inn en forespørsel til første tegn i svaret er mottatt.
  • Gjennomstrømningshastighet en datamaskin eller et nettverk mottar forespørsler per sekund.
  • Mengde tilkoblingssamling - antall brukerforespørsler som oppfylles av samlede tilkoblinger. Jo flere forespørsler dekkes av tilkoblinger i bassenget, jo bedre blir ytelsen.
  • Maksimalt antall aktive økter - maksimalt antall økter som kan være aktive samtidig.
  • Treffforhold - Dette har å gjøre med antall SQL-setninger som håndteres av hurtigbufrede data i stedet for dyre I / U-operasjoner. Dette er et godt sted å starte for å løse problemer med flaskehals.
  • Treff per sekund - nei. treff på en webserver i løpet av hvert sekund av en belastningstest.
  • Tilbakeslagssegment - mengden data som kan tilbakestilles når som helst.
  • Databaselås - låsing av tabeller og databaser må overvåkes og nøye innstilles.
  • Topp venter - overvåkes for å bestemme hvilke ventetider som kan kuttes ned når det gjelder hvor raskt data hentes fra minnet
  • Trådtall - En applikasjonshelse kan måles med nei. av tråder som kjører og er aktive for øyeblikket.
  • Søppeloppsamling - Det har å gjøre med å returnere ubrukt minne tilbake til systemet. Søppeloppsamling må overvåkes for effektivitet.

Eksempel på ytelsestesttilfeller

  • Bekreft at responstiden ikke er mer enn 4 sekunder når 1000 brukere får tilgang til nettstedet samtidig.
  • Kontroller at responstiden for applikasjonen under belastning er innenfor et akseptabelt område når nettverkstilkoblingen er treg
  • Sjekk maksimalt antall brukere som applikasjonen kan håndtere før den krasjer.
  • Sjekk databasens utførelsestid når 500 poster leses / skrives samtidig.
  • Kontroller CPU- og minnebruk av applikasjonen og databaseserveren under topplastforhold
  • Bekreft responstid for applikasjonen under lave, normale, moderate og tunge belastningsforhold.

Under den faktiske ytelsestestutførelsen blir vage termer som akseptabelt område, tung belastning osv. Erstattet av konkrete tall. Ytelsesingeniører angir disse tallene i henhold til forretningskravene og det tekniske landskapet i applikasjonen.

Ytelsestestverktøy

Det finnes et bredt utvalg av ytelsestestingverktøy tilgjengelig i markedet. Verktøyet du velger for testing vil avhenge av mange faktorer, for eksempel typer protokoller som støttes, lisenskostnader, maskinvarekrav, plattformstøtte osv. Nedenfor er en liste over populære testverktøy.

  • LoadNinja - revolusjonerer måten vi laster test på. Dette skybaserte lastetestingverktøyet gjør det mulig for lag å registrere og avspille øyeblikkelig omfattende lastetester uten kompleks dynamisk korrelasjon og kjøre disse lastetestene i ekte nettlesere i stor skala. Lag er i stand til å øke testdekningen. & reduser belastningstesttiden med over 60%.
  • NeoLoad - er ytelsestestingsplattformen designet for DevOps som sømløst integreres i din eksisterende rørledning for kontinuerlig levering. Med NeoLoad tester team 10 ganger raskere enn med tradisjonelle verktøy for å oppfylle det nye nivået av krav i hele Agile programvareutviklingslivssyklus - fra komponent til hele belastningstester for hele systemet.
  • HP LoadRunner - er det mest populære ytelsestestverktøyet på markedet i dag. Dette verktøyet er i stand til å simulere hundretusenvis av brukere, sette applikasjoner under virkelige belastninger for å bestemme deres oppførsel under forventet belastning. Loadrunner har en virtuell brukergenerator som simulerer handlinger fra levende menneskelige brukere.
  • Jmeter - et av de ledende verktøyene som brukes til lastetesting av web- og applikasjonsservere.

FAQ

Hvilke applikasjoner skal vi ytelsestest?

Ytelsestesting utføres alltid kun for klientserverbaserte systemer. Dette betyr at ethvert program som ikke er en klientserverbasert arkitektur, ikke må kreve ytelsestesting.

For eksempel er Microsoft Calculator verken klient-serverbasert, eller den kjører flere brukere; det er derfor ikke en kandidat for ytelsestesting.

Hva er forskjellen mellom Performance Testing & Performance Engineering

Det er viktig å forstå forskjellen mellom Performance Testing og Performance Engineering. En forståelse deles nedenfor:

Performance Testing er en disiplin som er opptatt av å teste og rapportere den nåværende ytelsen til en programvare under forskjellige parametere.

Performance engineering er prosessen der programvare blir testet og innstilt med den hensikt å realisere den nødvendige ytelsen. Denne prosessen har som mål å optimalisere den viktigste applikasjonsytelsesegenskapen, dvs. brukeropplevelse.

Historisk har testing og tuning vært tydelig atskilt og ofte konkurrerende riker. I løpet av de siste årene har imidlertid flere lommer med testere og utviklere samarbeidet uavhengig for å lage tuningteam. Fordi disse teamene har møtt betydelig suksess, har begrepet kobling av ytelsestesting med ytelsesjustering tatt tak, og nå kaller vi det performance engineering.

Konklusjon

I programvareteknikk er ytelsestesting nødvendig før du markedsfører noe programvareprodukt. Det sikrer kundetilfredshet og beskytter en investors investering mot produktsvikt. Kostnader for ytelsestesting er vanligvis mer enn kompensert med forbedret kundetilfredshet, lojalitet og oppbevaring.