Software plus Services, vad innebär det för test?

Alla som har prövat vet vilken utmaning det är att testa tjänster som bygger på moln baserade plattformar (PaaS). Utmaningen består i att du inte har någon detaljerad kontroll över vad som händer i plattformen, när uppdateringar sker m.m. Det är även svårt att verifiera de skickade meddelandena till och från tjänsten samt att ha tillräckligt mycket relevant testdata i plattformen. Du är även helt beroende av att plattformen är tillgänglig och färdigutvecklad från önskad testdag ett.

Är sedan din tjänst en tjänst som även används av mashup tjänster (En tjänst som bygger på att knyta samman andra tjänster) så kan den tidiga test problematiken liknas vid API testning. Du vet inte exakt hur din tjänst kommer att försöka användas trots att anropen finns definierade

Dessa problemställningar (och många många fler…) ställs du inför om du testar en Cloud Computing tjänst som skall vara tillgänglig som Software as a Service (SaaS). Om vi sedan tittar på hur du testar en Software plus Services (S+S) lösning så kvarstår samma problemställningar men i en mycket komplexare form då antalet möjliga användningsområden och kombinationer ökar exponentiellt.

S+S innebär i korthet att tjänsten finns tillgänglig både som SaaS och som ”tjock” lokal klient. Både SaaS tjänsten och klienten bygger på och anroppar samma plattform. Det kan dessutom finnas klienter till en mängd olika plattformar så som mobiltelefoner, spelkonsoller, smartphones, olika operativsystem m.m.

Ett tydligt exempel (inspererat av Ken Johnson) på en S+S lösning är Windows Live Mail (WLM). WLM finns tillgängligt i molnet som SaaS tjänst, men har även tjocka klienter(Outlook windows, Outlook mobile m.m.) som  stödjer ett stort antal plattformar.

Bilden är hämtad från Microsoft.

WLM exemplet visar också att tjänster sällan är fristående utan ofta beroende av andra tjänster. I vårt fall integrerar e-mail tjänsten med Windows Live ID Service (som är en separat tjänst) för autentiseringen.

Kortfattat kan man säga att S + S strävar efter att bearbetar datat där det är mest gynnsamt för användaren och användarens upplevelse. Bearbetningen sker lokalt om tillräcklig bearbetnings kapacitet finns eller i molnet om lokal bearbetnings kapacitet saknas. Det omvända förhållandet gäller förstås när uppkopplings-hastighet är den begränsande faktorn.

Hur testar vi S+S?

Från vår testhorisont så betyder detta förstås att komplexiteten och antalet testkombinationer ökar exponentiellt.

Bilden är hämtad från Microsoft.

Denna ökande komplexitet kräver att vi kan testa tjänsten fristående i från plattformen, samt minska antalet kombinationer att testa så mycket som möjligt. Som vanligt är ingenting nytt under solen och teknikerna och angreppssätten vi använder för att uppnå detta, är i mångt och mycket samma som de vi använder/borde använda vid test av SOA tjänster. Och om vi skall vara riktigt ärliga och historiska, så påminner dessa om angrepsätten och teknikerna som togs fram för att testa Client/Server lösningar på hedenhös tid. Det jag i första hand tänker på är användandet av inspektion, emulatorer och klassificeringsträd (classification trees).

Emulatorer

Det är ofta ett måste, i synnerligt om projektet är agilt, att kunna testa tjänsten och dess integrationer redan tidigt under utvecklingsarbetet. Detta kräver att vi  emulerar plattformen och på sådant sätt gör tjänsten oberoende av i vilket tillstånd plattformen är. Emulering utesluter även  felkällor från plattformen under de tidiga testerna.

När det gäller tester av tjänsternas integration så hittas bland annat felaktiga xml meddelanden på en tidig testnivå, oftast långt innan de fullständig integrations testerna av praktiska skäll skulle kunna utföras.

Bilden är hämtad från Microsoft.

Antalet tester som behöver köras mot den verkliga plattformen minskar också betydligt genom att men gentemot emulatorn granskat och verifierat hur tjänstens utgående trafik ser ut. Även skillnader i trafiken beroende på vilken plattform/klient som används identifieras. Efter denna granskning och identifiering, kan de olika plattformarna och klienterna som behöver testas oftast minimeras enligt equivalence class principen. Detta gäller förstår inte de högre testnivårna där affärsflöden, slutanvändar-nyttan och slutanvändar-upplevelsen skall testas, då behöver vi fortfarande köra hela flöden från samtliga plattformar och klienter.

Emulatorn bör förutom att emulera plattformen även logga all in och utgående trafik från tjänsten. Detta för att kunna granska och därmed verifiera medelande formaten från och till tjänsten. Det är lätt att glömma att granskning är en effektiv form av testning. Dessa granskningar av meddelande bör försås även göras när man testar mot den skarpa plattformen.

Emulatorn kan för att vara riktigt effektiv vara testdata driven, detta för att kunna variera emulatorns svar mot klienten. Varje ny emulator funktionalitet måste dock noga övervägas då funktionaliteten i emulatorn i sig behöver testas och förvaltas för att vara relevant.

Klassificeringsträd

För att minska antalet testfall men ändå täcka in tillräckligt många kombinationer och negativa testfall när det gäller anrop från klienterna till tjänsten så tycker jag att det fungerar utmärkt att använda sig av klassificeringsträd tekniken. 

Klassificeringsträd ger inte bara en oslagbar visuell bild över de möjliga kombinationerna utan underlättar framför allt när det gäller att hitta negativa testfall. Negativa testfall blir extra viktigt vid test av tjänster som används av mashup tjänster då du vet inte exakta hur din tjänst kommer att försöka användas trots att anropen finns definierade Det är även väldigt tydligt att med hjälp av trädet visa utvecklare och kravställare var och när det gick fel.

Hur man använder klassificeringsträd skulle i sig vara föremål en intressant artikel och ingenting jag mäktar med att gå in på i denna artikel. Vill du veta mera så kan du tills en sådan artikel dyker upp här på TestZonen, titta på dessa uppsatser/presentationer.

Det grundläggande om klassificeringsträd finns att läsa i Ansur Mahmood Amjad D uppsats ISTQB: Black Box testing Strategies used in Financial Industry for Functional testing, http://www.bth.se/fou/cuppsats.nsf/all/ef886828f9f542c6c1257620003722ab/$file/Master.pdf

Exemplet som Ansur Mahmood Amjad använder är med största sannolikhet hämtat från Julie Gadiner som har hållit fördrag med just detta exempel länge. En sådan presentation finner du här, http://www.bcs.org//upload/pdf/classification-trees.pdf

Om du vill se ett exempel på hur klassificeringsträd använd i en moln baserad tjänst så hittar du det i min presentation om tester i molnet, http://www.prolore.se/sast090916_cloud.pdf

Glöm inte häller att läsa artikeln om hur du kan utnyttja tjänsterna i molnet för din testning.