Icke funktionella krav inom prestanda

Att kalla ett segt system som inte kan användas för icke funktionellt är i mitt tycke missvisande. Namnsättningen har kommit till på grund av att dessa krav inte har med själva funktionen i systemet att göra. Kraven är dock väsentliga att uppfylla för att systemet ska fungera tillfredsställande för flertal användare i olika situationer.

Vilka icke funktionella krav finns?

• Prestanda

• Stabilitet

• Skalbarhet

• Säkerhet

• Användbarhet (usability)

• Kompatibilitet

Ovanstående områden är några exempel på icke funktionella krav. Men det finns många fler. Jag kommer fortsättningsvis skriva några rader om krav inom prestanda och stabilitet som ligger mig närmast.

Hur utformas kraven?

Först och främst måste kraven vara tydliga, testbara och binära (pass/fail). Att ”systemet ska svara snabbt” är ett mindre bra utformat krav, då det kan tolkas olika. Kraven behöver förankras hos beställare/produktägare, så att man får mandat att lägga resurser på att uppfylla dessa. Det är alltför ofta vi med testerna hittar krav som inte uppfylls, men beslut tas ändå att driftsätta utan åtgärder. Vilket gör att vi spenderar tid och kostnad på felsökning i onödan.

Exempel på prestandakrav

Samtidiga användare

Man behöver fastställa hur många användare som ska nyttja systemet samtidigt. Detta krav är ibland inte så lätt att utforma då ordet “samtidigt” uppfattas olika. Att ett system har 100 000 användarkonton i databasen innebär inte att dessa kommer använda systemet samtidigt. Snarare är det kanske är 100 användare som är påloggade eller har en aktiv session i systemet samtidigt. Av dessa anropa kanske 10 användare en funktion/sida samtidigt.

Genomströmning

Att man använder 100 påloggade användare i ett test behöver inte nödvändigtvis betyda att dessa genererar önskad belastning. För att veta hur användarna skall simuleras bör det också framgå hur många transaktioner eller sidvisningar per tidsenhet som skall användas.

Här kan också fördelningen av lasten framgå på respektive funktion/sida.
Exempel: 50 sidvisningar/sekund med 100 samtidiga påloggade användare. Varav 3 sökningar/sekund.

Svarstider

Att endast använda medelsvarstider som input till kravuppfyllande kan bli missvisande. Medelsvarstider visar ett snitt på alla mätvärden. Vissa anrop kan under en period vara mycket långsammare än kraven men ändå under medelvärdet, vilket gör att man klarar kravet. Använd istället percentil som ett svarstidskrav, till exempel att 95 procent ska klara en svarstid på 1 sekund. Undvik att använda generella svarstidskrav. Att ladda en ny sida på en sajt kan ta 1 sekund medan en sökning på ett stort urval kan få ta längre tid.
Exempel: 95 procent av sidladdningarna ska klara en svarstid på 1 sekund, 95 procent av sökningarna ska klara en svarstid på 5 sekunder. Samtliga svarstider skall dock klara 10 sekunder. 

I regel testar man från samma nät som systemet självt. Det vill säga så mäts svarstiden närmare och utan nätkomponenter som påverkar slutanvändare (såsom routers och brandväggar). Verktygen som används för att mäta svarstiderna mäter inte heller i regel renderingen av sidan på datorn eller mobilen. Sammantaget har vi då ett resultat från testerna som är bättre än vad användarna någonsin kommer att uppleva. Man bör ha med detta i beräkningen av svarstidskraven, alternativt kan man mäta svarstiden på ett mer realistiskt sätt. Det finns tekniker för detta.

Robusthet/stabilitet

System bör klara belastning under lång tid för att undvika oavsiktliga avbrott, avbrott som normalt sett slutar i en incident. Det är vanligt att till exempel minnesläckage gör att systemet inte längre kan användas förrän det startas om. Dessa krav brukar vara viktiga för driftorganisationen. Exempel: Systemet ska ha en drifttid på 20 timmar.

Att systemet fungerar för slutanvändaren trots att delar av systemet får problem bör också testas. Med så kallade avbrottstester eller experimenterande tillstånd i miljön (som Chaos Engineering) under last, kan man påvisa att systemet är stabilt och dess redundans fungerar. Vad händer om ett samband tar 20 sekunder eller kommunikationen till ena datorhallen går ner? Till exempel: Systemet ska vara redundant i alla X komponenter utom sambandet Y.

Skalbarhet

Att ett system ska svara lika snabbt för den första användaren som för användare nummer 300 är viktigt. Användarna har ingen förståelse för att det går trögt då de inte ser de övriga användarna. Att systemet är skalbart innebär att svarstider är konstanta oavsett last till en viss gräns. Denna gräns är systemets begränsning som kan bestå i processorkraft, minne och nätverkskomponenter.
Till exempel: Svarstiderna får maximalt öka med 5 procent tills systemets begränsning är nådd.

Det finns som sagt många andra krav som man bör fastställa (men de har jag inte tagit upp i denna text).

Men - om vi inte har krav då? 

Trots dess betydelse är det vanligt att det inte finns något utformat prestandakrav för ett nytt system. Många gånger får man vända på frågeställningen. Istället för att fråga “Klarar vårt system 50 transaktioner per sekund med 100 samtidiga användare med en svarstid på 1 sekund”?, så kan man fråga sig om det är okej att vi har 1 sekund i svarstid med denna last. 

Detta tillvägagångssätt förutsätter dock att en bra kommunikation med beställaren och en erfaren prestandatestare som känner till vad som kan hända vid olika scenarion. Om inte lasten är definierad i kraven behöver man ta reda på hur den är eller förväntas bli. Ett möte eller en workshop med driften och/eller beställaren kan hjälpa dig att utreda hur mycket och vilken last som beräknas.

Ett tips är att försöka efterlikna en riktig användare i testskripten med väntetider och logik, så att man endast har en belastningsparameter att diskutera med beställaren. Det vill säga antal användare.

Exempel: Om en riktig användare genomför 10 sidvisningar per minut så ska man alltså efterlikna detta. Vid ett lasttest med 1000 virtuella användare kommer man alltså generera 166 sidvisningar/sekund. 

Om svarstiden då blir för lång, exempelvis över 1 sekund, så behöver vi antingen minska antalet virtuella användare alternativt förbättra systemet.

Detta kan genera följande stycke i rapporten:

”Systemet klarar att hantera 350 virtuella användare med en svarstid på under 1 sekund."

”För att klara högre belastningar krävs det att komponenten ”Z” optimeras då detta är begränsningen för närvarande."

Några slutord

Det är inte alltid lätt att utforma icke funktionella krav, så ta gärna hjälp av någon med erfarenhet av prestandatest för just ditt system. Jag hoppas dock att detta blogginlägg har hjälpt dig att reda ut vissa begrepp, belyst vikten av dessa krav och hur de kan formuleras.