Mall för prestandatestplan

En prestandatestplanmall som kan användas som den är eller modifieras för att passa dina projektbehov när det gäller prestandakrav.

1. Syfte

Syftet med detta avsnitt är att ge en överblick på hög nivå av prestandatestmetoden som ska följas för projekt. Detta måste presenteras för alla berörda intressenter och bör diskuteras för att få enighet.

2. Inledning

Som en del av leveransen av krävs att lösningen uppfyller acceptanskriterierna, både när det gäller funktionella och icke-funktionella områden. Syftet med detta dokument är att ge en översikt för icke-funktionell testning av lösning.

Detta dokument omfattar följande:

• Kriterier för in- och utresa
• Miljökrav
• Volym- och prestandatestmetod
• Aktiviteter för testning av prestanda

3. Inträdeskriterier

Följande arbetsobjekt bör slutföras / avtalas i förväg för att gå vidare med de faktiska prestandatestaktiviteterna:

• Icke-funktionellt testkravsdokument tillhandahållet av , med kvantifierade NFR om möjligt
• Kritiska användningsfall bör testas funktionellt och utan några kritiska fel
• Design arkitektoniska diagram godkända och tillgängliga
• Viktiga användningsfall har definierats och omfattats
• Prestanda testtyper överens
• Installera lastinsprutare
• Alla datainställningar som behövs - t.ex. Lämpligt antal användare skapade i

4. Utgångskriterier

Prestandatestaktiviteten kommer att slutföras när:

• NFR-målen har uppnåtts och prestandatestresultaten har presenterats för teamet och godkänts.

5. Miljökrav

Prestandatesterna körs mot en stabil version av lösning (som redan har passerat funktionstesterna) och utförts på en dedikerad produktionsliknande miljö (pre-prod?) som tilldelats för prestandatestning utan distributioner i den miljön under prestandatestet.

5.1 Lastinjektorer

Det kommer att finnas en eller flera dedikerade 'lastinjektorer' inställda för att initiera den erforderliga belastningen för prestandatestning. Lastinjektorn kan vara en virtuell dator eller flera virtuella datorer som har en instans av JMeter som kör och initierar förfrågningarna.

5.2 Testverktyg

Testverktyg som används för volym- och prestandatestning kommer att vara:

5.2.1 JMeter

Ett testverktyg för öppen källkod. Används huvudsakligen för testning av volym och prestanda.

5.2.2 Splunk

Splunk kommer att användas för loggning (kan använda ett annat verktyg - måste bekräfta med perf testteamet).

6. Volym- och prestandatestmetod

lösningen ska vara tillräckligt effektiv för att hantera följande belastningskriterier.

N.B. Siffrorna i följande tabell är endast för exempel - verkliga värden ska infogas när de är färdiga med NFR-dokument.

6.1 Målservicevolymer

Mål per timme upptäcks från den nuvarande lösningen för [Y2019]. Rensade andra ”exempelvärden” från planmallen.

Eftersom timvärde inte är höga kommer de att tas som mål för fast belastningstest. Skalningsfaktor är TBD just nu.

6.2 Antal användare

Prestandatestning körs med högst 1000 [?] Användare. Användarna skapas i i förväg och vara tillgänglig via Inloggnings-API. Varje begäran loggar in med olika användar-ID.

6.3 Påståenden

JMeter-verktyget kommer att användas för att köra prestandatestskript. Inom skripten kommer det att finnas påståenden om att kontrollera ovanstående mätvärden samt några grundläggande funktionskontroller för att säkerställa att korrekta svar tas emot för varje begäran.

6.4 Lastprofiler

Lastprofilerna bör utformas för att efterlikna en typisk genomsnittlig dagstrafik till webbplats. Observera att trafiken endast fördelas och begränsas till kundens identitets- och åtkomsthanteringsdel på webbplatsen, dvs.

• Logga in
• Registrera
• Återställ lösenord
• Glömt ditt lösenord
• Ställ in kund
• Skaffa kund

Nedan följer en exempelprofil för en dag:

6.4.1 Baslinje

Den första handlingen är att hitta en baslinje. Med endast en användare kommer vi att köra en simulering under en tidsperiod (t.ex. 5 minuter) för att få ett genomsnitt av svarstider för varje slutpunkt. Detta säkerställer att vi med endast 1 användare faktiskt kan uppnå toppförfrågningar per sekund.

6.4.2 Lasttestning

Efter att baslinjemätvärdena samlats in körs samma simulering, som simulerar en belastningsprofil, med ett ökat antal användare för att testa mot målvolymerna. Tanken med detta belastningstest är att testa systemet mot en typisk dagsbelastning, simulera ramp-ups, dagens toppar och ramp-down.

6.4.3 Stresstestning

Målet med stresstestning är att hitta systemets brytpunkt, dvs vid vilken tidpunkt systemet inte svarar. Om automatisk skalning är på plats kommer stresstestet också att vara en bra indikator vid vilken tidpunkt systemet skalas och nya resurser läggs till. För stresstestning används samma simulering som används för belastningstest men med en högre belastning än förväntat.

6.4.4 Spikprovning

Spikprovning introducerar en betydande belastning på systemet på relativt kort tid. Syftet med detta test är att simulera en försäljningshändelse till exempel när ett stort antal användare samtidigt får åtkomst till sitt konto på relativt kort tid.

6.4.5 Blötprovning

Blötprovning kommer att köra ett lasttest under en längre tid. Syftet är att avslöja eventuella minnesläckor och svarsförmåga eller fel under blötestet. Vi använder vanligtvis 80% av lasten (används för lasttestning) under 24 timmar och / eller 60% av lasten under 48 timmar.

6.4.6 Mättnadstestning

Vid mättnadstestning fortsätter vi att öka belastningen stadigt för att avgöra vid vilken tidpunkt systemet inte svarar, dvs. hitta systemets brytpunkt när det gäller belastning.

7. Prestanda testaktiviteter

Följande aktiviteter föreslås ske i ordning för att slutföra prestandatestning:

7.1 Prestanda Testmiljöbyggnad

• Lastinjektorerna ska ha tillräcklig kapacitet och bör hanteras på distans. Platserna för injektorerna bör också komma överens
• Övervaknings- och larmmekanismer i realtid bör vara på plats och bör omfatta applikationen, servrarna liksom lastinjektorerna.
• Applikationsloggar ska vara tillgängliga.

7.2 Användningsfallsskript

• Prestandatestverktyget som kommer att användas är JMeter
• Eventuella datakrav har diskuterats för att användningsfall ska vara skriptade

7.3 Test Scenario Build

• Typ av test som ska utföras (belastning / stress etc)
• Lastprofilen / lastmodellen bör överenskommas för varje testtyp (ramp upp / ner, steg etc)
• Inkorporera tanke tid i scenarierna

7.4 Testutförande och analys

Följande tester ska utföras i följande ordning:

• Baslinjetest
• Ladda test
• Stresstest
• Spikprov
• Blötlägg testet
• Mättnadstest

Helst kommer två testkörningar av varje testtyp att utföras. Efter varje testkörning kan applikationen finjusteras för att öka dess prestanda och sedan börjar ytterligare en testcykel.

7.5 Analys och rapportering efter test

• Fånga och säkerhetskopiera alla relevanta datarapporter och arkiv.
• Bestäm framgång eller misslyckande genom att jämföra testresultaten med prestationsmålen. Om målen inte nås bör lämpliga ändringar göras och sedan startar en annan testkörningscykel. Det är okänt hur många exekveringscykler som behövs för att nå de överenskomna målen.
• Dokumentera och presentera testresultaten för teamet.