Modell med inbyggd logik i noderna

Grundtanke. Skapa en modell av ett användargränssnitt som trycker på alla knappar. Vi har vårt användargränssnitt, vårt GUI. Det är ett komplicerat GUI, så hur vi modellerar det på ett bra sätt både visuellt och funktionsmässigt.

Visuellt kändes mer och mer som viktigt då modellbaserad testning, MBT, fortfarande är i uppbyggnads- eller förstudiefasen inom företaget. Även om jag förespråkade MBT var det ju inte säkert att alla helt köpt idén, övertalning och förklaring krävs då och för att få så många som möjligt att förstå möjligheterna och kraftfullheten krävs visualisering.

Sättet jag valde, har jag förstått, kanske inte är helt enligt standardpraxis.

Valet blev att låta varje nod representera ett objekt/knapp på GUI’t och inte ett state, och varje edge representera vilka möjliga andra objekt man kan ta sig till.

Varje nod fick då namnet på det objekt som ska tryckas eller få tillträde till. Namnet i sig erhålls ju enkelt via GraphWalker.

Värt att nämna är också att vid tillfället då vi startade inte hade tillgång till det slutliga användargränssnittet. Approachen blev därför på en hög eller grundläggande nivå. Modellerna vi utformar riktar sig mot att stöta på problemen tidigt, hitta lösningar, utvärdera tänkt funktionalitet, prova våra idéer på hur modellen ska byggas upp och testas. Detta för att sedan kunna appliceras på ett mer moget GUI.

Modellen börjar nu formades på ett enligt mig fördelaktigt visuellt sätt. Och dessutom kan den enkelt och visuellt logiskt byggas ut med underliggande sub-modeller efter behov. Det naturliga blev att börja med att modellera huvudfönstret av GUI’t samt väl valda sub-modeller representerade av dom olika tabbarna i GUI’t.

Modellen för toppnivån av GUI’t innehåller samtliga tabbar överst i GUI’t. Från varje individuell tab skall man i sin tur kunna navigera till samtliga övriga tabbar inkl den tab man redan står på. Ett nyckelord lades också till innan objektnamnet för att definiera vilken slags objekt det är frågan om.

Bilderna 1 och 2 nedan illustrerar GUI’t samt modellen för toppnivån. Bild 1 är medvetet suddig, men tabbarna överst i GUI’t borde gå att urskilja.

Bild 1. Användargränssnitt, GUI

Bild 2. Modell av toppnivån

So far so good.

Nu hade vi en grund. En grundmodell att bygga vidare på.

Nu var det dags att lägga till tillämpningar och funktionalitet. Inställningar av värden kan ha givna intervall, knappar kan bete sig på särskilda sätt osv.

Definitionerna av detta vill man ur ovan nämnda visualiseringsskäl ha i modellen. Och tänker man så kändes det naturligt att lägga den informationen under respektive objekt.

Men varför begränsa sig där? Nu har du ett objekt. En inställningsmöjlighet med ett givet intervall.

Hur testar vi den inställningsmöjligheten? Eller kanske snarare hur väljer vi värde för inställningen?

Ytterligare information om hur vi ska välja värden för objektet lades därför till i noden. Och egentligen behöver man inte begränsa sig. All användbar information kan läggas i noden, men för mig är visualiseringsbiten viktig och då vill jag även undvika en ”plottrig” modell. Relevant information som gör modellen och testningen av modellen mer förståelig läggs in i noderna, men fortfarande kan mycket av logiken runt testmetoder implementeras i test scriptet.

I bild 3 visas ett förslag på hur det kan se ut i vårt fall.

Vi har typ av objekt. I det här fallet något som kallas spin buttons, dvs ”pil up” och ”pil ner”  som används för att ställa in ett värde.

Vi har objektnamn.

Vi har information om inom vilket giltigt intervall inställningen är möjlig för objektet.

Och slutligen har vi information om vilken slags metod som vi vill använda för att testa av objektet.

Även i den här sub-modellen ska det vara möjligt att från vilket objekt som helst vilja vilket annat objekt som helst samt sig själv. Man måste då också kunna välja att gå tillbaka till huvudfönstret, i det här fallet genom att gå via tab-objektet.

Bild 3. Sub-modell med testinformation i noderna

Den metod som visas här är en slumpmässig metod. Den går ut på att ett värde slumpmässigt väljs inom giltigt intervall. Andra exempel på metoder är att ha ett fixt värde eller negativ testning.

Beroende på hur man i GraphWalker väljer att gå igenom modellen så kommer du kunna återkomma fler än en gång till noden och på så sätt även automatiskt testa vad som händer om man genomför fler ”knapptryckningar” för värdes inställningar än vad det godkända intervallet tillåter.

Det här är första stegen mot en modell som testar samtliga knapptryckningar på ett GUI. Fördelarna som jag ser det är: Funktionaliteten för godkända testintervall och dessutom vilken testmetod man använder finns inbyggd i modellen. Det medför att det är lätt att ändra inriktning av testningen av olika objekt genom att ändra i modellen, samt kanske mitt huvudsyfte att det ska bli lätt att förklara en funktionalitet i allt mer komplex modell för någon som kanske inte är fullt insatt uppbyggnad av modeller och modellbaserad testning.

About Peter Ahlberg

Peter Ahlberg
Maquet Critical Care

Peter Ahlberg ca 9 års erfarenhet som testingenjör. Sedan Maj 2007 är jag anställd på Maquet Critical Care i Solna och har huvudsakligen arbetat med systemtest av medicintekniska system som ventilatorer och anestesimaskiner. Sedan i höstas 2010 jobbar jag med delsystemtest och mer specifikt test av panelen inkl SW för användargränssnitt. Det är där MBT och testautomatisering kommer in i bilden...