Acceptabla tröskelvärden för prestandakrav

Typewriter-2

Många gånger har jag sett att krav på svarstider för systemet som skall prestandatestas är dåligt specificerade från beställaren. När resultatet från testet presenteras uppstår oftast förvirring över vad som avser vad.

Innan kraven skall verifieras, gärna långt innan de skall verifieras, brukar jag försöka få beställaren att tänka om och se fördelarna med att använda acceptabla tröskelvärden.

Följande definitioner skapar en bättre förutsättning då krav på svarstider skall mätas:

Ange mätvärden baserat på ett tröskelvärde från percentil* istället för medelvärde.
Ange att mätvärden redovisas för en given tidsperiod då förutbestämd transaktionsfrekvens uppnåtts.
* En percentil används med fördel för att visa värde från ett antal mätvärden där percentilen utgör ett krav för acceptabelt tröskelvärde. Av ett antal mätvärden sorteras dessa i storleksordning, där det högsta värdet motsvarar 100% och medianen för mätvärden är 50%. Ur denna lista plockar bestämd percentil ut aktuellt värde. Ett plus är att percentil finns i Excel och då kan ses som ett vedertaget begrepp.

 

 

 

Prestandatesta REST (Json/XML) tjänster för mobila backend med hjälp av Android SDK

Typewriter-2

Ett uppdrag som föll på mitt bord vara att prestandatesta ett mobilt backend system som bygger på ett REST (Json/XML) API. Tjänsterna exponeras publikt för mobila kunder och då förväntas stora transaktionsvolymerna är och kraven på skalbarhet, stabilitet och svarstider är omfattande.

Till en början fans ett arv från prestandatester att tillgå och dessa hade sitt ursprung i manuellt skapade tjänsteanrop baserat på API-dokumentationen. De verktyg som användes för att generera anropen var Firefox med tillhörande RESTclient add-on. Den här add-on är egentligen en RESTful debugger men fungerar utmärkt att använda för att skapa tjänsteanrop med olika förutsättningar och läsning av svar och då direkt i Firefox.
Förutsättningarna är här att man har tillgång till dokument som beskriver hur API anropas och vilka metoder som returneras och hur. En stor nackdel är att man inte i detta läge vet hur och när den slutgiltiga kundapplikationen anropar REST-tjänsterna utan en sekvens med anrop blir en smula syntetiskt, vilket både kan vara en fördel men också en nackdel iom missade anrop som ger en over-head och kanske ökad last på systemet.

Efter lite efterforskning och tips från min kollega på Prolore AB så började jag titta närmare på Android SDK vilket är ett utvecklarhjälpmedel. Verktyget används oftast lokalt på en dator men som kan konfigureras för att fungera i en större testmiljö. Verktyget kan hantera olika versioner API samt att man kan installera Android appar, ett sk Android application package file (APK).

Efter samtal med utvecklare så beslutades att en specialutgåva av ett APK skulle tas fram. I detta APK skulle man kunna välja vilka servrar som skulle anropas från applikationen. Till att börja med installeras Android SDK och sedan uppdaters de API-versioner som skall användas. I en tillhörande manager skapas och konfigureras sedan en Androidemulator som skall användas för att installera APK och därmed köra appen. Installation av APK och även konfiguration vissa operativfiler i Emulator görs med kommandon.

För att kunna prestandatesta RESTful måste man kunna sniffa av tjänsteanropen och vilken metod som används. Det kan vara GET, POST, PUT eller DELETE –metod för tjänsterna. Likaså måste man kunna fånga upp svaren från ett eller fler anrop, vilket kräver att testverktyget har någon form av ramverk som kan hantera dynamiskt data eller sk parametrar. I mitt fall använde jag ett välkänt prestandatestverktyg från HP där det finns ett fördefinierat ramverk för Mobila Protokoll, vilket passade utmärkt i detta fall. Testverktyget kan hantera trafik som spelats in med pcap (packet capture) till fil eller sniffa av trafiken direkt likt en proxy sniffer. Sedan genereras ett testskript med möjlighet att läsa inspelad trafik i form av programerbara funktionsanrop. I testskript kan man skapa parametrar för olika ändamål och ”debugga” innan man slutligen spelar upp testskript för att då generera flera anrop över olika sessioner mot backend.

Testerna utfördes sedan med gott resultat och då beslutade jag att skapa ett ramverk för hur denna ”verktygslåda” av program skulle användas. Integrationen gick mycket smärtfritt och flera personer i organisationen kunde använda verktygslådan efter en kort genomgång.

Det som jag vill uppmärksamma är att vi gick från syntetiska anropssekvenser till att använda en fullvärdig applikation för att skapa testflöden av tjänsteanrop. Det bör tilläggas att vi kombinerar direkta API anrop skapade med Firefox RESTClient och de som genereras via Android SDK via APK.
Att dessutom dessa två verktyg är gratis och kan användas för att med lätthet skapa testflöden i dyra prestandatestverktyg gör inte saken sämre.

 

Kan vi prestandatesta lite nu?

Typewriter-2

Många gånger har jag fått ställa kontrollfrågor till projektledare eller testledare om vad de tror att ett prestandatest är och dess syfte.  Jag har ibland fått vända på “steken” och förklara vad avsikten är med testet är och vilka mål vi skall uppnå och hur. Det verkar ibland vara så att det finns en tro om att ett prestandatest bara är att testa lite för att se att allt är ok och så. Så är det inte riktigt…

Ofta är det övergripande syftet med prestandatester att kontrollera om testobjektet är stabilt, skalbart och kan hantera flera samtida processer. Om testobjektet kan hantera dessa övergripande punkter har det troligen en god design. Naturligtvis måste prestandatesterna tas fram med hänsyn till vad ursprungsfunktionen var på framtagna designen.

Ett testfall i prestandatest är ett flöde eller anrop som skall genomföras mot objektet. Det kan förekomma flera testfall och deras funktion skall vara att generera anrop mot de delar som avses testas. Därefter designas ett scenario som körs och resultatet ger så svar på om testobjektet kan hantera de krav som specificerats. Scenariot kan vara uppsatt för att ge svar på om testobjektet kan hantera exempelvis 5 viktiga testflöden där samtidighet finns. Det kan exempelvis vara skrivning i en och samma tabell i en databas. Det kan vara en samtidighet av kod som exekveras vid inloggning i ett system.

Vi måste använda oss av gemensamma nämnare för att beskriva vad, hur och varförinnan vi tar fram testflöden för testfall, testscenarion för olika testtyper vid prestandatest.
Mitt förslag är att ställa följande frågor; “Varför skall vi prestandatesta, vad skall vi testa och hur?”

Sedan kan vi prestandatesta lite…

Några användbara testtermer vid prestandatest.
Testfall: Affärsflöde, användarflöde, testcase
Testtyp: Maximalbelastningstest, stabilitetstest, samtidighetstest
Testscenario: Urval av viktiga testfall med en belastningsprofil enligt Testtyp. Syftet kan vara att åstadkomma produktionslika antal och typer av anrop.

 

Varför är prestandatestperioden så lång?

Typewriter-2

I mitt nuvarande uppdrag ser jag ofta att projektansvariga upplever testperioden för prestandatest som lång. Jag får oftast ”försvara” tidsplanen och vad som måste genomföras innan vi kan utföra självaste prestandatesterna.

Följande punkter är tidskrävande, men ytterst väsentliga att genomföra inför prestandatesterna:

  • Produktionslik kapacitet i målmiljö som testerna skall utföras i. Den måste eventuellt beställas/hyras in.
  • Produktionslik konfiguration. Det kan vara en klustrad miljö med lastbalanserare. Den skall baseras på korrekta versioner av hårdvara eller mjukvara.
  • Testdata skall vara i paritet med produktionsförhållanden. Det kan vara antalet inloggningskonton, användaruppgifter eller annat data som skapar ”volym” i databaser.
  • Systemet kan vara beroende av externa kopplingar för att fungera. Det kan i sin tur exempelvis krävas att det finns en testmiljö med testdata där också. Eventuellt måste brandväggar öppnas mot extern part. Externa kopplingar kräver i sin tur nogsam planering och samordning mellan parter.

Utöver dessa förberedelser skall man givetvis upprätta testplan där alla förberedelser specificeras. Därefter skapas testskripten och man genomför tester, analyserar testresultat, validerar, omkonfigurerar, regressionstestar med mera.

Komplexa lösningar eller system tar tid att specificera och bygga upp inför ett eller flera prestandatester. Därför är det av yttersta vikt att planera inför test i god tid. En god start är att etablera kontaktyta, läsa in systemkonfigurationen samt beroenden och därefter definiera kravbild med samtliga parter.