Ledelse i testing: Håndtering av ytelsestesting

Hei, og velkommen til serien Ledelse innen testing. I den forrige artikkelen så vi på tjenestetesting for nettapplikasjoner. 

Formålet med dette kapitlet er å gi råd og anbefalte fremgangsmåter for håndtering av en kritisk komponent innen tjenestetesting som ble nevnt i den artikkelen, nemlig – trommevirvel, takk … ytelsestesting!

Vi skal dekke:

• Mål for ytelsestesting
• Fire forutsetninger for en ytelsestest
• Verktøykasse for ytelsestesting
• Prosessen for ytelsestesting

La oss sette i gang.

Mål for ytelsestesting

Som en rask oppsummering kan vi definere hovedmålet med ytelsestesting slik:

«Å demonstrere at systemet fungerer i henhold til spesifikasjonen, med akseptable svartider, samtidig som det behandler de nødvendige transaksjonsvolumene i en database av produksjonsstørrelse.»

Testmiljøet for ytelse er en testplattform som kan brukes til andre tester med bredere mål, som vi kan oppsummere slik:

• Vurdere systemets kapasitet for vekst (Hvis du er usikker på hvilken programvare som kan dekke behovene dine, kan listen vår over de beste løsningene for databaseadministrasjon hjelpe deg.)
• Identifisere svake punkter i arkitekturen
• Finjustere systemet
• Avdekke skjulte feil i programvaren
• Verifisere motstandsdyktighet og pålitelighet.

Teststrategien din bør definere kravene til en testinfrastruktur som gjør det mulig å oppnå alle disse målene.

Fire forutsetninger for en ytelsestest

«Hvis noen av disse forutsetningene mangler, må du være svært forsiktig før du går videre med å gjennomføre tester og publisere resultater. Bruk av verktøy for automatisering av kvalitetssikring kan bidra til å sikre at disse forutsetningene er oppfylt. Testene kan være vanskelige eller umulige å gjennomføre, eller troverdigheten til resultatene du publiserer kan være alvorlig svekket og lett å undergrave.»

1. Kvantitative, relevante, målbare, realistiske og oppnåelige krav

Som grunnlag for alle tester bør ytelseskravene (målene) avtales før testen, slik at det kan avgjøres om systemet oppfyller disse kravene. 

Krav til systemets gjennomstrømning eller svartider bør ha følgende egenskaper for å kunne brukes som et grunnlag for sammenligning av ytelsesresultater. De må være:

• Uttrykt i kvantifiserbare termer.
• Relevante for oppgaven brukeren ønsker å utføre.
• Målbare ved hjelp av et verktøy (eller et stoppeklokke) og til en rimelig kostnad.
• Realistiske sammenlignet med varigheten på brukeroppgaven.
• Oppnåelige til en rimelig kostnad.

Ofte er ytelseskravene vage eller ikke-eksisterende. Se etter dokumenterte krav hvis du kan. Hvis det finnes mangler, kan det hende du må dokumentere dem i ettertid. 

Før en ytelsestest kan spesifiseres og utformes, må det avtales krav til:

• Svartider for transaksjoner.
• Lastprofiler (antallet brukere og transaksjonsvolumene som skal simuleres).
• Databasevolumer (antallet poster i databasetabellene som forventes i produksjon).

Det er vanlig at ytelseskrav defineres i vage termer. Disse kravene er ofte basert på omtrentlige prognoser for forretningsvolumer, og det kan være nødvendig å få forretningsbrukere til å tenke realistisk på ytelseskravene. 

Det kan også hende at du må utføre noe av kravanalysen selv og dokumentere disse kravene som målene for den ønskede ytelsen. 

2. Et stabilt system

Hvis systemet er fullt av feil og upålitelig, kommer du ikke langt med en ytelsestest. Ytelsestester belaster alle arkitekturkomponentene i en viss grad. Men for at ytelsestesting skal gi nyttige resultater, må systemet og den tekniske infrastrukturen i utgangspunktet være rimelig pålitelige og robuste.

3. Realistisk testmiljø

Testmiljøet må konfigureres slik at testen blir meningsfull. Du kan sannsynligvis ikke gjenskape mål- eller produksjonssystemet, men testmiljøet bør være sammenlignbart, helt eller delvis, med det endelige produksjonsmiljøet. Du må bli enig med systemets arkitekt om hvilke kompromisser som er akseptable og hvilke som ikke er det, eller i det minste om hvilken nyttig tolkning som kan gjøres av testresultatene.

Det er avgjørende å opprette et realistisk testmiljø for å kunne gjennomføre meningsfulle ytelsestester. For verktøy som kan hjelpe deg med å simulere forhold fra den virkelige verden, kan du se vårt håndplukkede utvalg av plattformer for programvaretesting

4. Kontrollert testmiljø

Ytelsestestere trenger stabilitet. Det gjelder ikke bare påliteligheten og robustheten til maskinvare og programvare, men også at endringer i miljøet eller programvaren som testes, begrenses til et minimum. Hvis grensesnittet for eksempel endres bare litt, vil testskript som er utviklet for å styre brukergrensesnitt, ofte mislykkes umiddelbart.

Alle endringer i miljøet bør kontrolleres strengt. Hvis endringen løser feil som sannsynligvis ikke vil påvirke ytelsen, kan det være lurt å ikke godta leveransen. Bare endringer som skal forbedre ytelsen eller påliteligheten, bør godtas.

Verktøysett for ytelsestesting

Verktøysettet ditt for ytelsestesting består av fem hovedverktøy:

• Oppretting og vedlikehold av testdata – for å opprette de store datamengdene i databasen som kreves for testen. Vi forventer at dette er et SQL-basert verktøy, eller kanskje et PC-basert produkt som Microsoft Access, koblet til testdatabasen.
• Lastgenerering – de vanligste verktøyene bruker testdrivere som simulerer virtuelle klienter ved å sende HTTP-meldinger til webservere.
• Verktøy for kjøring av applikasjonen – dette styrer én eller flere forekomster av applikasjonen ved hjelp av nettlesergrensesnittet og registrerer målinger av svartid. (Dette er vanligvis det samme verktøyet som brukes til lastgenerering, men det trenger ikke å være det).
• Ressursovervåking – verktøy som overvåker og logger klient- og serversystemressurser, nettverkstrafikk, databaseaktivitet osv.
• Resultatanalyse og rapportering – verktøy for testkjøring og ressursovervåking genererer store mengder resultatdata for analyse.

Relatert lesning: DE 10 BESTE SQL-ANALYSETJENESTENE FOR QA-TEAMER

Prosessen for ytelsestesting

Nedenfor vises en figur som illustrerer en generell prosess for ytelsestesting og -justering. Justering er egentlig ikke en del av testprosessen, men den er en uatskillelig del av arbeidet med å forbedre ytelse og pålitelighet. Justering kan innebære endringer i den arkitektoniske infrastrukturen, men bør ikke påvirke funksjonaliteten til systemet som testes.

Nå skal vi se på hvordan man utvikler, gjennomfører, analyserer og rapporterer om en ytelsestest.

Trinnvis utvikling av tester

Testutvikling utføres vanligvis trinnvis i fire faser:

1. Hvert testskript utarbeides og testes isolert for å feilsøke det.
2. Skriptene integreres i utviklingsversjonen av arbeidsbelastningen, og arbeidsbelastningen kjøres for å teste at det nye skriptet er kompatibelt.
3. Etter hvert som arbeidsbelastningen vokser, blir testtjenesten under utvikling kontinuerlig forbedret, feilsøkt og gjort mer pålitelig. Erfaringen med og kjennskapen til verktøyene øker også.
4. Når det siste skriptet er integrert i arbeidsbelastningen, kjøres testen som en «prøvekjøring» for å sikre at den er fullstendig repeterbar og pålitelig, og klar for de formelle testene.

Midlertidige tester kan gi nyttige resultater

Kjøringer av den delvise arbeidsbelastningen og transaksjonstestene kan avdekke ytelsesproblemer. Tester med liten belastning kan også gi en tidlig indikasjon på nettverkstrafikk og potensielle flaskehalser når testen skaleres opp. 

Dårlige responstider kan skyldes dårlig applikasjonsdesign og kan undersøkes og utbedres av utviklerne på et tidligere tidspunkt. Tidlige tester kan også kjøres over lengre perioder som utholdenhetstester.

Testgjennomføring

Testgjennomføring krever en viss fasestyring eller koordinering. Du bør samarbeide med deltakerne som støtter testingen, og som skal overvåke systemet mens du kjører testene. Teamet som overvåker testen, kan være distribuert, så du må holde dem orientert for at testen skal kunne gjennomføres uten problemer og resultatene registreres korrekt.

Utover koordineringen av de ulike teammedlemmene følger gjennomføringen av ytelsestester vanligvis en standard rutine.

1. Klargjør databasen (gjenopprett fra tape ved behov).
2. Klargjør testmiljøet etter behov, og kontroller tilstanden.
3. Start overvåkingsprosessene (nettverk, klienter og servere, database).
4. Start belastningssimuleringen, og følg med på systemovervåkingen.
5. Hvis et separat verktøy brukes, starter du verktøyet for kjøring av applikasjonstesten og målingen av responstid når belastningen er stabil.
6. Overvåk testen nøye så lenge den pågår.
7. Hvis verktøyene for testkjøring ikke stopper automatisk, avslutter du testen når testperioden er over.
8. Stopp overvåkingsverktøyene, og lagre resultatene.
9. Arkiver alle registrerte resultater, og sørg for at alle resultatdata sikkerhetskopieres på en trygg måte.
10. Utarbeid foreløpige rapporter, og rådfør deg med andre teammedlemmer om eventuelle avvik.
11. Utarbeid analyser og rapporter.

Det kan være utfordrende å koordinere ulike teammedlemmer under testgjennomføringen. Effektiviser denne prosessen ved å integrere avanserte teststyringsverktøy utviklet for Jira, som tilbyr funksjoner som samarbeid og rapportering i sanntid

Justering følger vanligvis etter testingen når det oppstår problemer, eller når det finnes kjente muligheter for optimalisering. Hvis en test gjentas, er det avgjørende at alle endringer i miljøet registreres. Dette gjør det mulig å knytte eventuelle forskjeller i systemets virkemåte, og dermed i ytelsesresultatene, til endringene i konfigurasjonen.

Når det gjelder håndtering av testtilfeller for ytelsestesting, kan programvare for teststyring gjøre en stor forskjell. Den legger til rette for bedre organisering, sporing og til og med automatisering av testtilfeller.

Som en tommelfingerregel er det lurt å endre bare én ting om gangen, slik at forskjeller i virkemåte kan spores tilbake til endringene som er gjort.

Resultatanalyse og rapportering

Den vanligste rapporten for en testkjøring oppsummerer disse målingene, og for hver måling som er tatt, rapporteres følgende:

• Antall målinger.
• Minimum responstid.
• Maksimum responstid.
• Gjennomsnittlig responstid.
• Responstid ved N.-persentilen (vanligvis 95^te).

Verktøyet for belastningsgenerering i verktøykassen din bør registrere antallet av hver transaksjonstype i testperioden. Hvis disse antallene deles på testens varighet, får man transaksjonsraten eller gjennomstrømningen som faktisk ble oppnådd. 

Antallet transaksjoner er belastningen som påføres systemet. Dette forutsetter at andelene av transaksjonene som kjøres, samsvarer med belastningsprofilen du forsøker å bruke.

Den påførte belastningen bør samsvare med den simulerte belastningsprofilen – men trenger ikke å gjøre det hvis systemet svarer sakte og transaksjonene kjøres med varierende hastighet.

Vanligvis vil du gjennomføre en serie testkjøringer med varierende belastning. Ved å bruke resultatene fra en serie tester kan du lage en graf over responstiden for en transaksjon plottet mot den påførte belastningen.

Verktøy for ressurs overvåking har vanligvis funksjoner for statistisk eller grafisk rapportering som viser ressursbruk over tid. Utvidede rapporter over ressursbruk i forhold til påført belastning er svært nyttige og kan bidra til å identifisere flaskehalser i systemarkitekturen.

Lykke til!

Meld deg på nyhetsbrevet fra QA Lead for å få beskjed når nye deler av serien publiseres. Disse innleggene er utdrag fra Pauls kurs i ledelse innen testing, som vi på det sterkeste anbefaler for å gå mer i dybden på dette og andre emner. Hvis du gjør det, kan du bruke vår eksklusive kupongkode QALEADOFFER og få $60 rabatt på den fullstendige kursprisen!

Relatert lesning: SERVEROVERVÅKINGSMÅLINGER DU BØR FØLGE MED PÅ FOR SYSTEMETS HELSE OG YTELSE