Når IT-systemer feiler eller har uakseptabel ytelse, er konsekvensene ofte svært høye. Økonomiske tap, tap av konkurranseevne, tapt arbeid, tap av kunder, samt tap av omdømme og anseelse er ofte uunngåelig, særlig dersom virksomheten er en godt synlig aktør i det offentlige rom.
Modne norske virksomheter er klar over risikoen og gjennomfører ofte omfattende tester for å redusere sannsynligheten for at alvorlige konsekvenser inntreffer samt at kravene til ytelse er tilfredsstilt. Typisk gjennomføres det tekniske tester, og da særlig ytelsestester og pålitelighetstester for å redusere risiko. Dersom testene er godt planlagt og gjennomført, gir testenes resultater viktig informasjon om IT-systemets kapasitet, ytelse, pålitelighet og svakheter, og benyttes til å optimalisere områder hvor kravene til ytelse ikke er tilfredsstilt. Sluttresultatet er et robust, stabilt og pålitelig IT-system med god ytelse som alle kan ha tillitt til og være trygge på.
Ytelsestest kan dog gjennomføres på mange måter, og i henhold til mine erfaringer er det en del momenter som er viktige for å sikre størst mulig grad av vellykket testgjennomføring.
Tre fundamentale prinsipper
I første omgang er det tre fundamentale prinsipper innen ytelsestest som i størst mulig grad bør oppfylles:
- Produksjonslikt testmiljø
Testmiljøet må i størst mulig grad være identisk med produksjonsmiljøet. Dette innebærer at servere skal bestå av samme hardvare og kapasitet, software og versjon skal være tilsvarende, databaser skal ha identisk datavolum, stormaskin skal ha identisk prioritet m.m. Det er fullt mulig å gjennomføre test i et nedskalert miljø, og da er det viktig at man vet hvor mye det er nedskalert i forhold til produksjonsmiljøet. I slike tilfeller anbefales det å «kalibrere» lastmodellen nøye. - Produksjonslike testdata
Test med reelle testdata fra produksjon så fremt dette er mulig. For å ivareta personvern, bør dog dataene anonymiseres. Varier også testdata i samme grad som det gjøres i produksjon for å unngå f.eks. at caching påvirker resultatene. - Produksjonslikt bruksmønster, volum og samtidighet
Analyser og design tester slik at de emulerer bruksmønster, volum og grad av samtidighet identisk med produksjon. Driftsovervåkning og produksjonsstatistikk, Real User Experience / APM verktøy, databasespørringer, intervjuer med brukere, UCML modellering vil gi innsikt i hvordan bruksmønsteret er og hvilket volum og grad av samtidighet man har i produksjonsmiljøet.
Når et eller flere av disse punktene ikke er i varetatt, introduseres i økende grad usikkerhet knyttet til resultatene fra test.
Metode
Benytt deg av en ytelsestestmetode som fungerer på best mulig måte i din virksomhet og arbeidshverdag. En god metode vil sikre at ytelsestestprosjekter gjennomføres på en detaljert beskrevet og gjennomprøvet måte som gir et forventet vellykket resultat hver gang. Mitt tips er at metoden skal være nøyaktig så detaljert og omfattende som man trenger, og ikke mer enn det. Videre er det viktig at metoden kontinuerlig forfines og utvikles underveis. I Visma Consulting har vi utviklet vårt eget metodeverk som skalerer fint både opp og ned med størrelsen på ytelsestestprosjektetene, og som sikrer konsistent gjennomføring og vellykket resultat. Nedenfor er det en enkel figur som illustrerer metoden.
Planlegging
Ytelsestest skal etter mitt syn behandles som en hvilken som helst type test og den må planlegges nøye. Planlegging består blant annet av å definere mål og hensikt, krav til ytelse, fremgangsmåte, forutsetninger og avgrensninger, testobjekter og testtyper, krav til verktøy, krav til testdata, overvåkning og testmiljø, ansvar og ressurser, tidsplan, estimat med mer. God planlegging er i henhold til min erfaring et av de viktigste suksesskriterer for vellykket testgjennomføring og nedenfor har jeg oppsummert noen sentrale områder.
Definere mål og hensikt
En viktig del av planleggingen er å lære og forstå systemet som skal ytelsestestes. Etter min oppfatning er det viktig å sette av en slump tid til å analysere og forstå systemet. Den oppnådde forståelsen munner ofte ut i teorier om hvor potensielle problemområder befinner seg og hva som kan være årsaken, og fortjenesten er alltid en mer målrettet og fokusert test som gir resultater av stor verdi. Denne informasjonen brukes så til å beskrive kort systemet/løsningen som skal testes, hva som er bakgrunnen for at det skal gjennomføres ytelsestest, hva målet og hensikten er, og eventuelle definerte eller antatte problemområder.
Krav til ytelse
Enten det er et nytt eller eksisterende system, skal det foreligge tydelig definerte, testbare og målbare krav til ytelse i forkant av en test. Uten tydelig definerte krav til ytelse er det svært vanskelig å vite hvorvidt ytelsen er akseptabel eller ikke. Disse skal i prinsippet defineres av systemeier og min erfaring er at systemeier ofte trenger bistand fra ytelsestesteksperter, driftspersoner, brukere, fagpersoner m.m. til å formulere realistiske, målbare, testbare krav til ytelse. M.a.o. bistå systemeier med å etablere ytelseskrav, bruk så disse kravene til å konfigurere ytelsestestscenariene og til sist evaluèr kravene mot resultatene.
Et eksempel på et responstidskrav kan være:
- Ved 1000 samtidige brukere av løsning X skal brukerne kunne lagre et dokument på 500Kb ved bruk av funksjon A med en transaksjonstid på <=1 sekund.
- Tjenesten C skal kunne håndtere 10 kall pr sekund ved 500 samtidige brukere med en responstid på <=50ms
Fremgangsmåte
Tenk nøye igjennom alle delaktiviteter som skal gjennomføres og beskriv aktivitetene med tilstrekkelig detaljeringsgrad i testplanen. Min erfaring er at det er tilstrekkelig å dele opp fremgangsmåten i 6 delfaser henholdsvis Planlegging, Forberedelser, Gjennomføring, Analyse, Optimalisering, Avslutning og detaljere alle aktiviteter innenfor delfasene.
Forutsetninger og avgrensninger
Det er viktig å forankre forutsetninger og avgrensinger med systemeier tidlig. F.eks. miljø, verktøy, overvåkning, statistikk, ressurser etc og vær nøye med å avgrense testen til kun det som ligger i scope. Dersom det finnes komponenter eller systemer i testmiljøet som ikke inngår i scope, men som er nødvendig for å kunne gjennomføre test, må dette inn under avgrensinger. Tilsvarende hvis noe ikke vil bli testet av ulike årsaker, forskjeller mellom testmiljø og produksjonsmiljø etc.
Testobjekter og testtyper
Tenk igjennom hvilke sentrale testobjekter som inngår i ytelsestesten og hvilke testtyper som vil bli gjennomført. Hvilke testyper som inngår dikteres, normalt av hensikt og mål, samt ytelseskrav. Testobjekter kan for eksempel være metode, funksjon, applikasjon, komponent, system, db, applikasjonsserver, webserver osv. Vær konkret og detaljert, og se testobjekter opp mot krav til ytelse. Da vil det raskt bli tydelig hvilke testobjekter som må inngå i testen. Videre er det en god idè å prioritere testobjektene etter kriterier gitt av sentrale interessenter slik som systemeier, brukere, fag eller liknende. Forsøk også å beskrive testene på en slik måte at alle interessenter forstår hensikten og bruk standardiserte begreper og definisjoner ala ISO og ISTQB.
Testmiljø
Bestill eller reserver miljøet tidlig, som en del av testplanleggingen. Sørg for at du har miljøet for deg selv og at gjennomføring av ytelsestest ikke påvirkes av andre som bruker miljøet. Husk prinsipp nr 1.
Verktøy
Det er ofte en god ide å ta en opptelling av verktøy før test. Har du alle de verktøy som du trenger? Er det behov for å sette opp overvåkning/monitorering i test miljøet? Ta tak i dette i god tid før test og få det på plass.
Tilganger
Jobber man med ytelsestest, trenger man tilganger til mange ulike servere og/eller applikasjoner på servere i testmiljøet. Husk å bestille og verifisere disse før test.
Testdata
Krever testen store mengder testdata? Blir testdata brukt opp under test? Trenger testdata å være av en bestemt type, bestemt størrelse eller liknende? M.a.o. vurder hvilke krav til testdata som foreligger.
Ansvar og ressurser
Sørg for at du har tilgang til de rette ressursene både før, under og etter test. Dette er ofte ressurser som har tilganger som du ikke har, men potensielt vil trenge. Det er utrolig kjedelig (og masse tapt arbeid) å måtte avbryte en test fordi en sentral del av testmiljøet er nede og du har ingen driftsressurser som kan starte den opp! Sørg også for å avklare og banke hvem som er ansvarlig for sentrale aspekter ved testen. Det kan f.eks. være hvem som er ansvarlig for testmiljøet, hvem som er ansvarlig for utrulling av nye versjoner til testmiljø, hvem som har det overordnede ansvaret og trenger å vite om alle hindringer og showstoppers og så videre. Poenget er at når ressurser og ansvar er spikret, vil du få ting gjort langt raskere.
Tidsplan
Erfaringsmessig hender det at ulike hindringer skaper forsinkelser, så det er ofte en god idè å legge inn litt slakk i tidsplanen for å ta høyde for at dette kan inntreffe.
Forberedelser
Etter planleggingen, starter arbeidet med forberedende aktiviteter. Aktivitetene er nødvendige for å kunne realisere testgjennomføring og er etter min oppfatning ofte tidkrevende. Grunnen til dette er at det er i denne delfasen at scriptutvikling foregår, testdata opprettes, testmiljøet etableres, overvåknings-/monitoreringsagenter settes opp osv. Og jo større og mer komplekst IT-systemet er, dess lengre tid vil det ta å ferdigstille alle aktivitetene. Nedenfor har jeg oppsummert noen sentrale aktiviteter som jeg anser som spesielt viktige.
Lastmodell og bruksmønster
Utgangspunktet for en lastmodell under ytelsestest skal være produksjonslikt. Det vil si at lastmodellen skal speile volumet i produksjon, antall brukere og fordeling innenfor sentrale funksjoner, samtidighet m.m. Denne lastmodellen kalles ofte Normallast og baserer seg enten på gjennomsnittlig last/volum eller peak last/volum. Peak last er det høyeste volum, høyeste antall kall m.m. som er målt i produksjonsmiljøet ved et gitt tidspunkt uten at dette var forårsaket av avvik eller ekstraordinære forhold. Er det et eksisterende system som skal ytelsestestes, vil det høyst sannsynelig finnes produksjonsstatistikk i form av grafer, tabeller etc. fra driftsovervåkning og lagrede data i databaser som man kan spørre på.
Er det derimot et nytt system eller applikasjon som skal ytelsestestes, vil det ikke finnes produksjonsstatistikk og lastmodellen må opprettes utfra intervjuer, anslått forventet volum, forventet bruk og fordeling, antall brukere osv. UCML, User Community Modelling Language, definert av Scott Barber, http://www.perftestplus.com/, kan også benyttes med fordel til å modellere bruken av et system i samarbeid med arkitekter, fagpersoner, superbrukere osv. Hvordan UCML brukes, er detaljert på web siden i linken over.
Scriptutvikling og verifisering
Hvilke script som må utvikles dikteres av ytelseskrav, identifiserte tester via UCML, prioriterte prosesser, arbeidsflyt og/eller funksjoner, samt mål og hensikt med test. Selve utviklingen av script gjøres enten via opptaksfunksjon, med påfølgende modifikasjon av scriptet, eller mer eller mindre manuellt fra starten av. Hvis opptakfunksjon mangler, og du tester igjennom f.eks. et nettbasert brukergrensesnitt, da sier jeg bare «Skaff deg et bedre verktøy!». Langt de fleste ytelsestestverktøy i dag har opptaksfunksjon som enkelt kan benyttes når en superbruker eller applikasjonsekspert klikker seg igjennom stegene som utgjør et ytelsestestscript. Dersom du tester under det grafiske grensesnittet, f. eks. kaller webtjenester direkte, kan det være til hjelp å benytte støtteverktøy slik som Soap UI i utviklingen.
Når nye script utvikles er det viktig å ta hensyn til at ytelsestestscript skal kunne håndtere feil som vil oppstå under test. Dette er bl.a. ofte knyttet til at forventet svar ikke returneres eller returnert svar gjenkjennes ikke av scriptet. Sørg derfor for at feilhåndtering og robusthet bygges inn i scriptene fra første stund slik at slike situasjoner håndteres.
Think Time/Pacing vil nødvendigvis måtte justeres iht bruksmønster og krav til ytelse, men gjør allikevel et forsøk på å variere Think Time/Pacing i størst mulig grad slik at spiking unngås. Spiking er situasjoner som oppstår under test fordi script står og venter like lenge og så utfører sine handlinger mer eller mindre samtidig. Hvis slik spiking ikke forekommer i produksjonsmiljøet, forsøk å justere de bort ved å variere Think Time/Pacing.
I forbindelse med SOAP- og Webtjeneste script er det en fordel at Pacing varieres i størst mulig grad slik at spiking unngås. F.eks. vil random Pacing med maksimum – minimum verdier kunne benyttes. I script som tester ytelse gjennom et bruker grensesnitt, for eksempel en nettleser, anbefales det å variere Think Time på samme vis som beskrevet over. Sørg for at Think Time, pauser i scriptets eksekvering, speiler bruksmønsteret til brukerne av applikasjonen. Dette vil varierere i stor grad fra individ til individ, så forsøk å finne et fornuftig gjennomsnitt.
Prøvekjør ett og ett script og sørg for at det kjører stabilt etter at alle transaksjonsmålepunkter er lagt inn, session variabler er korrelert og data er parameterisert. Legg i samme åndedrag merke til om miljøet oppfører seg som forventet.
Når du utvikler nye script, tenk hele tiden på hvordan du kan utvikle scriptet slik at det eller deler av det kan gjenbrukes i andre script samt om det er enkle grep som kan øke nytten ved scriptet. F.eks. er det enkelte funksjoner ved scriptet som kan gjenbrukes i andre script, eller kan det benyttes til å lage testdata for deg selv eller andre osv.
Scenario, testmiljø og verifisering
En samling ytelsestestscript som kjøres samtidig under test kalles ofte et ytelsestestscenario. Ytelsestestscenariet inneholder alle testscript, antall Virtual Users, alle konfigurasjoner med mer og scenariet kan til tider bli både stort og komplekst. Det er derfor en god idè å være ekstra nøye med oppsettet.
Etter at ytelsestestscenariet er konfigurert i henhold til lastmodell og testtype, dobbelsjekk innstillingene før test. Det er ofte svært mange settinger i verktøyet, så det er bedre å dobbelsjekke en gang for mye, enn å kaste bort timer på feil testoppsett.
Høy grad av logging i ytelsestestverktøyet, vil kunne påvirke resultatene , så bruk kun full logging under debugkjøringer slik at du lettere finner feil i script, parameterfiler, scenario, testmiljø m.m. Under reell gjennomførings av test, anbefales det å skru av logging fra Virtual Users under testkjøring eller logg kun når det oppstår feil for å redusere at logging påvirker resultatene.
Dersom Virtual Users rampes opp for raskt og på en unormal måte som ikke speiler brukernes innlogging, vil dette potensielt kunne påvirke resultatene utover hele testen. Dersom innlogging ikke er et fokusområde under test, sett tilstrekkelig lang Rampup av Virtual Users så det ikke påvirker kjøreresultatene utover i testen.
Pass på at du har tilstrekkelig med testdata i testmiljøet. Bruk for eksempel et regneark til å beregne hvor mye testdata du vil trenge i løpet av tidsperioden og opprett testdata i testmiljøet i forkant av en test. Tenk gjenbruk og automatisering når du oppretter script el. likn. for å legge inn testdata slik at det går raskt å oppfriske testdata.
Verifiser alltid testmiljø før test startes. Er alle servere oppe, fungerer monitorering og overvåkning som planlagt, er ressursuttak ubetydelig eller er det noen som belaster miljøet, er det noen feil og avvik som må rettes, må servere restartes etc.
Prøvekjør scenario med alle script og 3 VU pr script gruppe uten tenketid eller pacing og avlus eventuelle feil og mangler. Prøvekjør deretter hele scenariet slik det er konfigurert for test i ca 10 minutter. Observer script, scenario og testmiljøet nøye under denne testkjøringen. Hvis det går bra, er scenariet ok og klart til test.
Sjekk at overvåkningsagenter eller verktøy er oppe og kjører. Sjekk loggnivå på relevante servere og at det ikke finnes alvorlige avvik i relevante logger. Sjekk at database performance logging er skrudd på, hvis dette er relevant, og har riktig intervall på snap shots.
Husk å generere nye testdata i parameterfiler før testen startes, dersom scenariet bruker opp testdata.
Testgjennomføring
Delfasen testgjennomføring er hvor selve testingen foregår. Aktiviteten er iterativ, det vil si at det gjennomføres en ytelsestest, resultatet analyseres, feilrettinger/optimaliseringer/justering av scenario utføres og så gjennomføres det en retest inntil et eller flere exit kriterier er oppfylt.
På dette tidspunktet er det viktig at ytelsestestmiljøet kun benyttes til nettopp ytelsestest. Mao. sørg for at du har miljøet for deg selv og at gjennomføring av ytelsestest ikke påvirkes av andre som bruker og belaster miljøet.
Hvis det ikke allerede er kjent hvilken belasting lastgeneratorer takler, pass på at du kan overvåke disse under test. Dersom kontrollermaskinen og/eller lastgeneratorer overbelastes under test, vil dette påvirke testresultatene.
Ha en test logg klar under test, for eksempel en enkel notepad tekstfil som du kan skrive observasjoner i under test.
Underveis i testen bør man sjekke relevante logger og se de opp imot feilsituasjoner som oppstår under testen.
Det burde være innlysende, men sørg for at du har muligheten til å overvåke involverte servere, databaser og andre systemkomponenter i real time og har tilgang på historiske performance data. Ofte kan det være svært verdifult og tidsbesparende å kunne analysere performance data under test og ikke bare etter test.
Ta uttrekk av resultater for minimum 1 time stabil kjøring avhengig av krav til test og sørg for at du fjerner Rampup fra resultatet dersom det ikke spesielt testes for pålogging eller liknende som gjør at Rampup skal være med.
Skriv en oppsummering av testen med nøkkeltall og observasjoner i test loggen. En god test logg har ofte vist seg å være nyttig, særlig hvis man gjennomfører mange tester, sliter med miljø utfordringer osv.
Analyse, optimalisering og retest
Sett av godt med tid til analyse av resultater og ikke vær redd for å involvere andre personer som kan de ulike teknologiene, produktene, programmeringssråk m.m. bedre enn deg. Tør å be om hjelp!
Sammen er vi sterkere, så be om å få opprettet et analyseteam av eksperter, som sammen analyserer resultatene.
Hvis relevant, sammenlikn resultatene fra test med en baselinekjøring, dvs forrige tests resultater, for å evaluere eventuelle ytelsesendringer.
Sannsynligheten for at det eksisterer driftsovervåkning er stor, så be om å få uttrekk fra produksjon og sammenlikn resultatene med statistikk fra produksjon. Juster scenario ved behov.
Identifiser ulike hendelser i testkjøringen ved å analysere grafer, tabeller og logger. Let nøye etter en korrelasjon mellom hendelser slik at du kan årsaksforklare hendelsene og potensielt anbefale tiltak.
Alltid registrer feil og/eller optimaliseringstiltak i avvikhåndteringssystemet slik at alle slike hendelser er dokumentert og enkelt å følge opp. Og lag en liten notis i test loggen.
Sørg alltid for at tuningtiltaket er dokumentert i et avvikhånteringssystem, og at normale versjonsstyringsrutiner følges, dersom det medfører kodeendringer.
Oppdater test logg før retest med bl.a. hensikten med testen og hvilke endringer som er gjort på Systemet/Applikasjon under test.
Prosess og prosessforbedring
En god prosess vil alltid lette arbeidet som skal utføres, og selv en god prosess kan forbedres. Min erfaring er at det er viktig å hele tiden tenke prosesforbedringer, automatiseringer, forenklinger m.m. og implementere de, og deretter evaluere de. Som regel blir det bedre, selv om det motsatte også har hendt.
Bruk versjonsstyring av script, scenarier, parameterfiler, testdatafiler etc der det er mulig og praktisk. Er det ikke tilgjengelig, lag deg et system som fungerer. Kommentèr hva scriptet gjør og beskriv endringer i scriptet. Da er det mye lettere for andre som kommer etter deg å forstå hva scriptet gjør og hva som er endret.
Lag sjekklister for alle aktiviteter som er viktig å ha utført før du kan starte en test. Dette kan være med tanke på testmiljø-, script-, testdata-, rettigheter-,scenario-, overvåkningsrelatert eller andre ting.
Under ytelssestest er det forberedelser og analyse som tar mest tid. Forsøk å automatisere så mye som mulig av gjentakende oppgaver. For eksempel oppdatering av parameterfiler med nye testdata kan nesten alltid automatiseres. Hvis verktøyet kan autogenerere testrapporter og systemeier aksepterer formatet, vil det spare masse tid.
Dokumentèr hvordan ytelsestestprosessen gjennomføres slik at det er lettere for andre å komme i gang.
Konklusjon
Under ytelsestest kan mange ting gå galt, og det henger sammen med at det i mange tilfeller er komplekse systemer som testes. Min erfaringer er at jo mer innarbeidet en velfungerende ytelsestestmetode er, dess større er sannsynligheten for at testen blir vellykket. Implementering av store og små forbedringer, gir en strømlinjeformet og velfungerende metode over tid, og anbefales på det sterkeste. Planlegging og forberedelser er tidkrevende og kostbart, men aktivitetene som inngår må på ingen måte underestimeres eller undervurderes. Legger man ned et skikkelig grundig stykke arbeid i planlegging og forberedelser, er min erfaring at ytelsestesten blir en suksess.