Jämförda versioner

Nyckel

  • Dessa rader lades till.
  • Denna rad togs bort.
  • Formateringen ändrades.

Testscenario vid robusthetsmätningar

Vid robusthetsmätningar vill vi verifiera att resurser inte förbrukas över tid med en bibehållen last. Se Teststrategi för SKLTP komponenter, avsnittet robusthetstest för mer information.

Vid dessa mätningar används ett framtaget lasttest för VP, men dessa körs över längre tid och med en last som skall motsvara normal drift.

Konfiguration av robusthetstester

Se SKLTP VP - Lasttester för information.

Instruktioner för att utföra testerna

1. Förberedelser

Starta JConsole och logga på den/de VP-noder du vill se information för.

2. Konfiguration Gatling

Gatling tester körs enligt den generella instruktionen - ny. Kompletterande information till dessa enligt nedan:

  • Parametrar till testet enligt listan nedan. Anges genom flaggan -D<parameter>=<värde> vid start av testerna.
    • noOfUsers - anger hur många simulerade användare vi skall använda, default är 10.
    • baseUrl - anger URL för vp-tjänsterna, default är https://localhost:20000.
    • testTimeSecs - anger hur länge testet skall köras, default är 30 sekunder.

3. Dokumentation

Dokumentation av robusthetstestet  sker i ett testprotokoll (mall testprotokoll). Spara också utfallet för testet från Gatling genom att zippa hela katalogen där resultatet ligger och bifoga testprotokollet.

Dokumentation skall även ske över CPU-belastningen, minne (speciellt trenden över hur minnet används) under testet, detta görs lämpligen genom att ta en skärmdump av jConsole och då CPU kurvan.

4. Kör mixade happy days och felfall tester, LoadTestVPSomeFail

  1. Börja med att köra en testomgång med låg last (noOfUsers=1) och dokumentera utfallet. (Kör gärna om för att få två oberoende värden)
  2. Räkna ut vilken medelsvarstid som motsvarar en 20-25% ökning.
  3. Kör en ny testomgång med en markant ökning av antalet användare, förslagsvis 40 användare. Verifiera också att CPU-lasten inte går över 60% i snitt under testet.
  4. Korrigera antalet användare för att nå en ca 20-25% ökning av svarstiden och dokumentera efter hand, glöm inte bild över CPU-lasten