Page History
| Info | ||
|---|---|---|
| ||
- Hvem er læseren af dette afsnit? - Der mangler definitioner af en række begreber i teksten, herunder endurance-test, ramp-up stress test, spike test mm. - Lav en detaljeret faktaboks. perftest er en gruppe af tests - Det bør præciseres hvilke operationer der skal performancetestes i en service – alle?, læs?, skriv? - Alle med mindre andet aftales, behovet bør vurderes. - Er performance test det samme som en ramp-up/stress test? - perftest er en gruppe af tests - Der mangler noget overordnet om test setup’et, herunder infrastruktur, og testdata - testdata skal hænge sammen på tværs af komponenter. Infrastruktur er en kopi af produktion - Det er ikke kun svartider der er afgørende. Det skal sikres at servicen ikke fejler ved kald. - Tilføj assertion. - En testplan indeholder mere end opskriften på hvordan testen skal udføres. - Med testplan menes den JMeter fil, ikke den store samlede testplan for projektet. + Nævn OAT processen og hvad der sker hvornår. Miljø afklares også på OAT + Beskriv den vmstat mv. der laves. |
...
| Info | ||
|---|---|---|
| ||
En ramp-up-test (stress-test, breakpoint-test eller capacity-test) er en performancetest der sigter efter at finde et systems maksimale ydeevne samt identificere hvilke fejl der opstår i systemet under disse forhold. Testen øger belastningen af systemet i flere iterationer og måler både svartiden og kapaciteten. Dette er den primære performancetest der kræves på NSP for at idræftsætte en komponent. |
...
| Info | ||
|---|---|---|
| ||
En spike-test er en performancetest der undersøger hvorledes et system opfører sig under spidsbelastninger, højere end dem systemet kan forvente under normal drift. |
| Info | ||
|---|---|---|
| ||
Baggrundsdata er data der ligger i en database eller andet storage-system inden performancetest går i gang |
| Info | ||
|---|---|---|
| ||
Testdata er de data der genereres under en performancetest og anvendes som input til en performancetest |
Krav
Der kan stilles krav til performancetesten både af NSP som modtager af komponenten og af fra to sider til hvilke performancetests der skal køres af en komponent der skal idriftsættes på NSP. SDS-projektet som kunde, ifm udviklingen af nye komponenter eller større refactoreringer, stiller krav gennem kravspecifikationen. NSP, som modtager af komponenten og ansvarshavende for driften af denne, stiller krav gennem dette dokument. I det følgende gennemgåes disse krav
...
- Der skal foretages kald af alle komponentens forskellige funktioner der matcher det forventede virkelige brugs-scenarie.
- Antallet af kald til hver funktion skal ske ud fra en redegørelse over det forventede brug
- Input til funktionerne skal være ligeligt fordelt over et stort nok udfaldsrum til at sikre at svartiderne ikke bliver kunstigt lave grundet en "varm" cache mv.
- Baggrundsdata skal være realistiske i både mængde og diversitet.
- Testdata skal hænge sammen på tværs af alle komponenter.
- Hver iteration af testen skal vare længe nok til at kunne give realistiske gennemsnitlige svartider
- Belastningen skal øges for hver iteration af testen.
Vær opmærksom på at alle operationer/funktioner som en komponent udstiller skal performancetestes. Hvis det vurderes at en funktion ikke giver mening at teste (f.eks. grundet meget lav brugsfrekvens) skal det aftales ifm OAT processen om denne funktion kan udelades.
I forhold til baggrundsdata og testdata er det et krav at disse er representativt (mængde og fordeling) på tværs af alle de komponenter som vil indgå i en performancetest. Dvs hvis en ny komponent kalder en eksisterende komponent skal data være relevant og repræsentativt for begge komponenter (Hvis f.eks. MinSpærring kaldes skal der være baggrundsdata der matcher de CPR numre der anvendes som testdata).
Projekt
Sundhedsdatastyrelsen kan ligeledes stille krav til yderligere performancetest i de udbud/kravspecifikationer som ligger bag et udviklingsprojekt. Disse performancekrav kan være følgende:
- At komponenten overholder visse svartidskrav under en bestemt belastning.
- En Endurance test der viser at komponenten ikke "sander til" over tid.
- En Spike test der viser at komponenten kan håndtere udsving i belastningen.
...
En JMeter testplan har et fast antal tråde der kalder komponenten og en veldefineret løbetid som en iteration tager. For at kunne øge belastningen langsomt samt kører testen fra flere samtidige noder indeholder NSP Performance Framework et programmel der synkronisere afvikling på flere noder og øger antallet af tråde mellem hver iteration. Programmet sørger også for at angive hvilken host komponenten kan kaldes på og står for opsamling af logs.
Staging miljø
Alle performance
Roller
I forbindelse med en performancetest findes der en et antal aktører der har forskellige roller undervejs. I det følgende gennemgåes hver rolle og dens aktioner
...