Testing av programvareytelse - Software performance testing

I kvalitetssikring av programvare er ytelsestesting generelt en testpraksis som utføres for å bestemme hvordan et system fungerer når det gjelder respons og stabilitet under en bestemt arbeidsbelastning. Den kan også tjene til å undersøke, måle validere eller bekrefte andre kvalitetsegenskaper for systemet, slik som skalerbarhet , pålitelighet og ressursbruk.

Ytelsestesting, en delmengde av performance engineering , er en informatikkpraksis som streber etter å bygge ytelsesstandarder inn i implementering, design og arkitektur av et system.

Testtyper

Last testing

Lasttesting er den enkleste formen for ytelsestesting. En lasttest utføres vanligvis for å forstå systemets oppførsel under en bestemt forventet belastning. Denne belastningen kan være det forventede samtidige antallet brukere på applikasjonen som utfører et bestemt antall transaksjoner innenfor den angitte varigheten. Denne testen vil gi responstidene for alle viktige forretningskritiske transaksjoner. Den database , applikasjonsserver , etc. er også overvåkes i løpet av testen, vil dette bidra til å identifisere flaskehalser i programvaren og maskinvaren som programvaren er installert på.

Stress testing

Stresstester brukes vanligvis for å forstå de øvre grensene for kapasitet i systemet. Denne typen test er utført for å bestemme systemets robusthet når det gjelder ekstrem belastning og hjelper applikasjonsadministratorer med å avgjøre om systemet vil fungere tilstrekkelig hvis den nåværende belastningen går godt over det forventede maksimumet.

Bløtleggingstesting

Bløtleggingstesting , også kjent som utholdenhetstesting, gjøres vanligvis for å avgjøre om systemet kan opprettholde den kontinuerlige forventede belastningen. Under bløtleggingstester overvåkes minnebruk for å oppdage potensielle lekkasjer. Også viktig, men ofte oversett, er ytelsesforringelse, det vil si å sikre at gjennomstrømningen og/eller responstiden etter en lang periode med vedvarende aktivitet er så god som eller bedre enn ved begynnelsen av testen. Det innebærer i hovedsak å påføre et system en betydelig belastning i en lengre, betydelig periode. Målet er å oppdage hvordan systemet oppfører seg ved vedvarende bruk.

Spike testing

Spike testing utføres ved plutselig å øke eller redusere belastningen som genereres av et veldig stort antall brukere, og observere oppførselen til systemet. Målet er å avgjøre om ytelsen vil lide, systemet vil mislykkes, eller det vil være i stand til å håndtere dramatiske endringer i belastningen.

Test av bruddpunkter

Breakpoint testing er lik stresstesting. En trinnvis belastning påføres over tid mens systemet overvåkes for forhåndsbestemte feilforhold. Brytningstesting blir noen ganger referert til som kapasitetstesting fordi det kan sies å bestemme maksimal kapasitet som systemet vil utføre under de nødvendige spesifikasjonene eller servicenivåavtalene. Resultatene av bruddpunktanalyse anvendt på et fast miljø kan brukes til å bestemme den optimale skaleringsstrategien når det gjelder nødvendig maskinvare eller forhold som bør utløse utskalering av hendelser i et skymiljø.

Konfigurasjonstesting

I stedet for å teste for ytelse fra et belastningsperspektiv, opprettes tester for å bestemme effekten av konfigurasjonsendringer i systemets komponenter på systemets ytelse og oppførsel. Et vanlig eksempel ville være å eksperimentere med forskjellige metoder for lastbalansering .

Isolasjonstesting

Isolasjonstesting er ikke unikt for ytelsestesting, men innebærer å gjenta en testkjøring som resulterte i et systemproblem. Slike tester kan ofte isolere og bekrefte feildomenet.

Internett -testing

Dette er en relativt ny form for ytelsestesting når globale applikasjoner som Facebook, Google og Wikipedia testes ytelse fra lastgeneratorer som plasseres på det faktiske målkontinentet, enten det er fysiske maskiner eller nettsky -VM -er. Disse testene krever vanligvis en enorm mengde forberedelse og overvåking for å bli utført vellykket.

Sette prestasjonsmål

Ytelsestesting kan tjene forskjellige formål:

  • Det kan demonstrere at systemet oppfyller ytelseskriterier.
  • Den kan sammenligne to systemer for å finne hvilke som fungerer bedre.
  • Den kan måle hvilke deler av systemet eller arbeidsmengden som får systemet til å fungere dårlig.

Mange ytelsestester utføres uten å sette tilstrekkelig realistiske, målrettede prestasjonsmål. Det første spørsmålet fra et forretningsperspektiv bør alltid være, "hvorfor tester vi ytelse?". Disse hensynene er en del av business case for testen. Ytelsesmål vil variere avhengig av systemets teknologi og formål, men bør alltid inneholde noen av følgende:

Samtidig og gjennomstrømning

Hvis et system identifiserer sluttbrukere ved en eller annen form for pålogging, er et samtidig mål svært ønskelig. Per definisjon er dette det største antallet samtidige systembrukere som systemet forventes å støtte til enhver tid. Arbeidsflyten til en scriptet transaksjon kan påvirke ekte samtidighet, spesielt hvis den iterative delen inneholder påloggings- og avloggingsaktiviteten.

Hvis systemet ikke har et begrep om sluttbrukere, vil resultatmålet sannsynligvis være basert på en maksimal gjennomstrømning eller transaksjonsrate.

Serverens responstid

Dette refererer til tiden det tar før en systemnode reagerer på forespørselen fra en annen. Et enkelt eksempel vil være en HTTP 'GET' forespørsel fra nettleserklient til webserver. Når det gjelder responstid, er dette hva alle lasttestverktøy faktisk måler. Det kan være aktuelt å sette serverens responstidsmål mellom alle nodene i systemet.

Gi responstid

Lasttestingsverktøy har problemer med å måle gjengivelsestid, siden de vanligvis ikke har noen ide om hva som skjer i en node bortsett fra å gjenkjenne en periode der det ikke er aktivitet "på ledningen". For å måle responstid for gjengivelse er det generelt nødvendig å inkludere funksjonelle testskript som en del av ytelsestestscenariet. Mange lastetestingsverktøy tilbyr ikke denne funksjonen.

Ytelsesspesifikasjoner

Det er avgjørende å detaljere ytelsesspesifikasjoner (krav) og dokumentere dem i en ytelsestestplan. Ideelt sett gjøres dette i løpet av kravutviklingsfasen for ethvert systemutviklingsprosjekt, før noen designarbeid. Se Performance Engineering for mer informasjon.

Imidlertid utføres ytelsestesting ofte ikke mot en spesifikasjon; for eksempel vil ingen ha gitt uttrykk for hva den maksimalt akseptable responstiden for en gitt brukergruppe skal være. Ytelsestesting brukes ofte som en del av prosessen med tuning av ytelsesprofiler. Tanken er å identifisere den "svakeste lenken" - det er uunngåelig en del av systemet som, hvis det blir gjort for å svare raskere, vil resultere i at det generelle systemet går raskere. Det er noen ganger en vanskelig oppgave å identifisere hvilken del av systemet som representerer denne kritiske banen, og noen testverktøy inkluderer (eller kan ha tillegg som gir) instrumentering som kjører på serveren (agenter) og rapporterer transaksjonstider, databasetilgangstider , nettverksoverhead og andre servermonitorer, som kan analyseres sammen med rå ytelsesstatistikk. Uten slik instrumentering må man kanskje ha noen på huk over Windows Oppgavebehandling på serveren for å se hvor mye CPU -belastning ytelsestestene genererer (forutsatt at et Windows -system er under test).

Ytelsestesting kan utføres på nettet, og til og med utføres i forskjellige deler av landet, siden det er kjent at responstidene på internett i seg selv varierer regionalt. Det kan også gjøres internt, selv om rutere da må konfigureres for å introdusere etterslepet som vanligvis oppstår på offentlige nettverk. Last bør innføres i systemet fra realistiske punkter. For eksempel, hvis 50% av systemets brukerbase får tilgang til systemet via en 56K modemforbindelse og den andre halvparten over en T1 , bør lastinjektorene (datamaskiner som simulerer virkelige brukere) enten injisere last over den samme blandingen av tilkoblinger (ideell) eller simuler nettverksforsinkelsen til slike tilkoblinger, etter den samme brukerprofilen.

Det er alltid nyttig å ha en uttalelse om det sannsynlige toppantallet brukere som kan forventes å bruke systemet i rushtiden. Hvis det også kan være en uttalelse om hva som utgjør den maksimalt tillatte responstiden på 95 prosentil, kan en injeksjonskonfigurasjon brukes til å teste om det foreslåtte systemet oppfyller den spesifikasjonen.

Spørsmål å stille

Ytelsesspesifikasjoner bør stille minst følgende spørsmål:

  • I detalj, hva er ytelsestestens omfang? Hvilke undersystemer, grensesnitt, komponenter osv. Er innenfor og utenfor omfanget av denne testen?
  • Hvor mange samtidige brukere forventes for hver brukergrensesnitt (UI) (spesifiser topp vs. nominell)?
  • Hvordan ser målsystemet (maskinvaren) ut (spesifiser alle server- og nettverkskonfigurasjoner)?
  • Hva er applikasjonsarbeidsmengdeblandingen for hver systemkomponent? (for eksempel: 20% pålogging, 40% søk, 30% varevalg, 10% betaling).
  • Hva er System Workload Mix? [Flere arbeidsmengder kan simuleres i en enkelt ytelsestest] (for eksempel: 30% arbeidsbelastning A, 20% arbeidsbelastning B, 50% arbeidsbelastning C).
  • Hva er tidskravene for noen/alle back-end-batchprosesser (spesifiser topp vs. nominell)?

Forutsetninger

En stabil konstruksjon av systemet som må ligne produksjonsmiljøet så tett som mulig.

For å sikre konsekvente resultater, bør ytelsestestmiljøet være isolert fra andre miljøer, for eksempel tester for brukeraksept (UAT) eller utvikling. Som en god praksis er det alltid lurt å ha et eget ytelsestestmiljø som ligner produksjonsmiljøet så mye som mulig.

Testforhold

I ytelsestesting er det ofte avgjørende at testforholdene ligner den forventede faktiske bruken. Imidlertid er dette i praksis vanskelig å ordne og ikke helt mulig, siden produksjonssystemer utsettes for uforutsigbare arbeidsmengder. Testbelastninger kan etterligne hendelser i produksjonsmiljøet så langt som mulig, men bare i de enkleste systemene kan en nøyaktig replikere denne variasjonen i arbeidsmengden.

Løst koblede arkitektoniske implementeringer (f.eks. SOA ) har skapt ytterligere kompleksitet med ytelsestesting. For å virkelig replikere produksjonslignende stater, foretakstjenester eller eiendeler som deler en felles infrastruktur eller plattform, kreves det koordinert ytelsestesting, med alle forbrukere som lager produksjonslignende transaksjonsvolumer og belastning på delte infrastrukturer eller plattformer. Fordi denne aktiviteten er så kompleks og kostbar i penger og tid, bruker noen organisasjoner nå verktøy for å overvåke og simulere produksjonslignende forhold (også referert til som "støy") i ytelsestestmiljøene ( PTE ) for å forstå kapasitet og ressurskrav og verifisere / validere kvalitetsattributter.

Timing

Det er avgjørende for kostnadseffektiviteten til et nytt system at ytelsestestinnsatsen begynner fra begynnelsen av utviklingsprosjektet og strekker seg til distribusjon. Jo senere en ytelsesfeil blir oppdaget, desto høyere blir utbedringskostnaden. Dette er sant når det gjelder funksjonell testing, men enda mer med ytelsestesting, på grunn av omfanget fra ende til ende. Det er avgjørende for et ytelsestestteam å bli involvert så tidlig som mulig, fordi det er tidkrevende å skaffe og forberede testmiljøet og andre viktige ytelseskrav.

Verktøy

Ytelsestesting er hovedsakelig delt inn i to hovedkategorier:

Performance scripting

Denne delen av ytelsestesting omhandler hovedsakelig opprettelse/scripting av arbeidsflytene til viktige identifiserte forretningsprosesser. Dette kan gjøres ved hjelp av et stort utvalg verktøy.

Hvert av verktøyene som er nevnt i listen ovenfor (som ikke er uttømmende eller fullstendig) bruker enten et skriptspråk (C, Java, JS) eller en eller annen form for visuell representasjon (dra og slipp) for å lage og simulere arbeidsflyter for sluttbrukere. De fleste verktøyene åpner for noe som kalles "Record & Replay", hvor i ytelsestester vil starte testverktøyet, koble det til en nettleser eller tykk klient og fange alle nettverkstransaksjoner som skjer mellom klienten og serveren. Ved å gjøre dette utvikles et skript som kan forbedres/modifiseres for å etterligne ulike forretningsscenarier.

Ytelsesovervåkning

Dette danner det andre ansiktet på ytelsestesting. Med ytelsesovervåking observeres atferd og responsegenskaper for applikasjonen som testes. Parametrene nedenfor overvåkes vanligvis under kjøring av en ytelsestest

Server maskinvareparametere

  • CPU -bruk
  • Minneutnyttelse
  • Diskutnyttelse
  • Nettverksutnyttelse

Som et første trinn gir mønstrene som genereres av disse 4 parameterne en god indikasjon på hvor flaskehalsen ligger. For å bestemme den eksakte årsaken til problemet, bruker programvareingeniører verktøy som profilere for å måle hvilke deler av en enhet eller programvare som bidrar mest til dårlig ytelse, eller for å etablere gjennomstrømmingsnivåer (og terskler) for å opprettholde akseptabel responstid.

Teknologi

Ytelsestestteknologi bruker en eller flere PCer eller Unix -servere for å fungere som injektorer, som hver etterligner tilstedeværelsen av antall brukere og hver kjører en automatisk sekvens av interaksjoner (spilt inn som et skript, eller som en serie skript for å etterligne forskjellige typer brukere interaksjon) med verten hvis ytelse blir testet. Vanligvis fungerer en egen PC som en testleder, som koordinerer og samler beregninger fra hver av injektorene og samler ytelsesdata for rapporteringsformål. Den vanlige sekvensen er å øke belastningen: å starte med noen få virtuelle brukere og øke antallet over tid til et forhåndsbestemt maksimum. Testresultatet viser hvordan ytelsen varierer med belastningen, gitt som antall brukere kontra responstid. Ulike verktøy er tilgjengelige for å utføre slike tester. Verktøy i denne kategorien utfører vanligvis en serie tester som etterligner virkelige brukere mot systemet. Noen ganger kan resultatene avsløre merkeligheter, for eksempel at mens gjennomsnittlig responstid kan være akseptabel, er det avvik fra noen få nøkkeltransaksjoner som tar betydelig lengre tid å fullføre - noe som kan være forårsaket av ineffektive databasespørringer, bilder osv.

Ytelsestesting kan kombineres med stresstester for å se hva som skjer når en akseptabel belastning overskrides. Krasjer systemet? Hvor lang tid tar det å gjenopprette hvis en stor belastning reduseres? Kan feilen forårsake sikkerhetsskade?

Analytisk ytelsesmodellering er en metode for å modellere oppførselen til et system i et regneark. Modellen mates med målinger av transaksjonsressursbehov ( CPU , disk I/O, LAN , WAN ), vektet av transaksjonsblandingen (forretningstransaksjoner per time). De veide transaksjonsressursbehovene blir lagt sammen for å få timekravene til ressurser og delt på ressurskapasiteten i timen for å hente ressursbelastningene. Ved å bruke formelen for responstid (R = S/(1-U), R = responstid, S = servicetid, U = last), kan responstider beregnes og kalibreres med resultatene av ytelsestestene. Analytisk ytelsesmodellering gjør det mulig å evaluere designalternativer og systemstørrelse basert på faktisk eller forventet forretningsbruk. Det er derfor mye raskere og billigere enn ytelsestesting, selv om det krever grundig forståelse av maskinvareplattformene.

Oppgaver å utføre

Oppgaver for å utføre en slik test vil omfatte:

  • Bestem om du vil bruke interne eller eksterne ressurser til å utføre testene, avhengig av egen kompetanse (eller mangel på det).
  • Samle eller fremkalle krav til ytelse (spesifikasjoner) fra brukere og/eller forretningsanalytikere.
  • Utvikle en plan på høyt nivå (eller prosjektcharter), inkludert krav, ressurser, tidslinjer og milepæler.
  • Utvikle en detaljert ytelse testplan (inkludert detaljerte scenarier og test tilfeller , arbeidsmengde, miljø info, etc.).
  • Velg testverktøy (er).
  • Spesifiser nødvendige testdata og charterinnsats (ofte oversett, men avgjørende for å utføre en gyldig ytelsestest).
  • Utvikle proof-of-concept- skript for hver applikasjon/komponent som testes, ved hjelp av utvalgte testverktøy og strategier.
  • Utvikle detaljert ytelsesprøveprosjektplan, inkludert alle avhengigheter og tilhørende tidslinjer.
  • Installer og konfigurer injektorer/kontroller.
  • Konfigurer testmiljøet (ideelt identisk maskinvare med produksjonsplattformen), ruterkonfigurasjon, stille nettverk (vi vil ikke at resultatene skal forstyrres av andre brukere), distribusjon av serverinstrumentering, databasetestsett utviklet osv.
  • Tørrkjør testene - før du faktisk utfører lasttesten med forhåndsdefinerte brukere, utføres en tørrkjøring for å kontrollere at skriptet er riktig.
  • Utfør tester-sannsynligvis gjentatte ganger (iterativt) for å se om en faktor som ikke er redegjort for kan påvirke resultatene.
  • Analyser resultatene - enten bestått/ikke bestått, eller undersøkelse av kritisk vei og anbefaling av korrigerende tiltak.

Metodikk

Ytelsestesting av webapplikasjoner

I følge Microsoft Developer Network består ytelsestestmetoden av følgende aktiviteter:

  1. Identifiser testmiljøet. Identifiser det fysiske testmiljøet og produksjonsmiljøet samt verktøyene og ressursene som er tilgjengelig for testteamet. Det fysiske miljøet inkluderer maskinvare, programvare og nettverkskonfigurasjoner. Å ha en grundig forståelse av hele testmiljøet i begynnelsen muliggjør mer effektiv testdesign og planlegging og hjelper deg med å identifisere testutfordringer tidlig i prosjektet. I noen situasjoner må denne prosessen revideres periodisk gjennom prosjektets livssyklus .
  2. Identifiser kriterier for aksept av ytelse. Identifiser responstid, gjennomstrømning og mål og begrensninger for ressursbruk. Generelt er responstid et brukerproblem, gjennomstrømning er et forretningsproblem, og ressursbruk er et systemproblem. Identifiser i tillegg kriterier for suksess for prosjekter som kanskje ikke blir fanget opp av disse målene og begrensningene; for eksempel å bruke ytelsestester for å evaluere hvilken kombinasjon av konfigurasjonsinnstillinger som vil resultere i de mest ønskelige ytelseskarakteristikkene.
  3. Planlegg og design tester. Identifiser nøkkelscenarier , bestem variabilitet blant representative brukere og hvordan du simulerer variabiliteten, definer testdata og opprett beregninger som skal samles inn. Konsolider denne informasjonen til en eller flere modeller for systembruk som skal implementeres, utføres og analyseres.
  4. Konfigurer testmiljøet. Forbered testmiljøet, verktøyene og ressursene som er nødvendige for å utføre hver strategi, ettersom funksjoner og komponenter blir tilgjengelige for test. Sørg for at testmiljøet er instrumentelt for ressursovervåking etter behov.
  5. Gjennomfør testdesignet. Utvikle ytelsestestene i samsvar med testdesignet.
  6. Utfør testen. Kjør og overvåke testene dine. Valider testene, testdataene og resultatinnsamlingen . Utfør validerte tester for analyse mens du overvåker testen og testmiljøet.
  7. Analyser resultater, melodi og test på nytt. Analyser, konsoliderer og deler resultatdata. Gjør en tuningendring og test på nytt. Sammenlign resultatene fra begge testene. Hver forbedring gir mindre forbedring enn den forrige forbedringen. Når stopper du? Når du når en CPU -flaskehals, er valgene enten å forbedre koden eller legge til mer CPU.

Se også