Framtagningen av testfall står idag för upp till 70 procent av kostnaden för programvarutestning. Ett forskningsprojekt på Tekniska Högskolan i Jönköping har som mål att förbättra och förenkla detta med hjälp av formella metoder. Docent Vladimir Tarasov från Tekniska Högskolan i Jönköping beskriver här hur arbetet är upplagt.

En viktig aspekt att beakta när man utvecklar programvara är kvaliteten hos den slutgiltiga produkten. För att uppnå en kvalitetsprodukt måste en stor del av utvecklingskostnaderna läggas på kravdefinition och testning av produkten, vilket innebär att man måste genomföra aktiviteter som kan vara besvärliga att planera, tar tid att genomföra och utvärdera och därför resulterar i en extra ekonomisk kostnad för företaget som utvecklar programvaran. Varje förbättring eller förenkling av krav- och testverksamheten ger därför upphov till en minskning i testutgifterna.

På Tekniska Högskolan i Jönköping pågår ett forskningsprojekt med fokus på programvarutestning kallat OSTAG (Ontologibaserad generering av testfall för programvarutestning). Projektet finansieras av KK-stiftelsen och kommer att pågå mellan 2015 och 2017. Projektgruppen från Tekniska Högskolan i Jönköping består av Vladimir Tarasov, He Tan, Muhammad Ismail, Anders Andersson och Anders Adlemo. Dessutom finns industrideltagande från Saab Avionics i Jönköping, AddQ i Göteborg samt konsultföretaget Knowit:s kontor i Jönköping.

Testfall
Målet med projektet är att förbättra och förenkla vissa delar av testningen av programvara genom att använda sig av så kallade formella metoder. I dagens programvaruindustri är stora delar av testningen av ny programvara automatiserade vilket har lett till betydliga besparingar. Det som inte har lyckats automatiseras är framtagningen av testfall. I dagsläget läggs i vissa fall så mycket som 70 procent av kostnaderna för testaktiviteterna på framtagningen av testfall, medan resten läggs på testexekveringen (detta enligt AddQ). Varje förbättring eller förenkling kommer därför direkt att ge upphov till besparingar i testaktiviteten, till exempel en minskning i tiden för att förbereda och köra tester, en ökning av antalet upptäckta fel och en minskning i mängden genomförda, onödiga tester.

Formella metoder
De formella metoder som kommer att användas i projektet är semantiska modeller och ontologier. Ordet ontologi har sitt ursprung i grekiskans on, som kommer från ontos och betyder varande, samt logia, som kommer från logos och betyder ord. Begreppet ontologi har använts i många sammanhang, bland annat för att försöka beskriva vilka egenskaper som ligger i ett tings natur. I det här projektet betecknar en ontologi en formell representation av ett antal koncept inom en domän (i det här fallet programvarutestning) och relationerna mellan dessa koncept. För att åskådliggöra vad man kan beskriva med en ontologi har vi valt mbedmicrocontroller. Följande foton visar exempel på två ARMmbeddevelopment boards.

t v mbedLPC1768, th mbedLPC11U24

En ontologi som beskriver en mbedmicrocontroller på en hög nivå visas i fig 1. I forskningsprojektet har en motsvarande topologi tagits fram som beskriver testning av programvara. Denna beskrivs lite senare.

Fig 1. mbedontologi [bild från Shames & Skipper 2006, Toward a Framework for modeling Space Systems Architectures, SpaceOps 2006 Conference]
klicka här för större bild

Huvudsyftet med projektet är att skapa en metod för att kunna skapa testfall utgående från en ontologi som representerar testningen av ett programvarusystem. Man kan jämföra en ontologi med en relationsdatabas som består av tabeller och relationer mellan dessa. För att ontologin skall vara användbar måste man kunna ställa frågor till den, på samma sätt som man kan göra med SQL-språket för en relationsdatabas. I fallet med en ontologi motsvaras SQL-queries av inferensregler. Dessa regler formaliserar erfarna testares kunskap inom området, och används för att skapa testfall från ontologin.

Målsättningar
OSTAG-projektet har ett antal målsättningar vad gäller forskning, teknik och affärsidé.

Forskningsmål
Skapa en metod för att (halv)automatiskt producera testfall med hjälp av en ontologi som beskriver kraven på ett programvarusystem samt inferensregler som beskriver erfarna testares kunskaper och kompetens.

Tekniskt mål
Utveckla en prototyp av ett verktyg som implementerar metoden för att (halv)automatiskt producera testfall samt därefter experimentera med och finjustera verktygsprototypen.

Affärsidé
Göra testprocessen mer effektiv vad gäller utnyttjandet av resurser, tid och pengar samt att förbättra testtäckningen och dessutom vara en hjälp för oerfarna testare med hjälp av det framtagna verktyget.

Inbyggt system
För att beskriva hur framtagandet av testfall går till kommer ett exempel från en av industrideltagarna att visas. Exemplet består av en hårdvarudel med tillhörande mjukvara, ett så kallat inbyggt system. Det som beskrivs är endast de bitar som är relaterade till mjukvaran och testningen av denna. Fig 2 illustrerar en del av den totala ontologin som endast beskriver ett av många krav som behöver testas och verifieras.

Fig 2. Ontologifragment för en kravspecifikation SRSRS4YY-431
klicka här för större bild

Ontologin beskrivs med hjälp av språket OWL (Web Ontology Language). Genom att applicera inferensregler på denna ontologi kan testfall tas fram. Ett exempel på en inferensregel beskrivs nedan, först på engelska och sedan i programspråket Prolog (som är det språk som används för att exekvera inferensreglerna gentemot ontologin som är beskriven med OWL).

IF the requirement is for a service and a UART controller is to be deactivated

THEN add a call to the requirement service, calls to a writing service and reading service as well as a recovery call to the first service.

Här följer ett exempel på en inferensregel som använder ontologielementen för att genera en del av ett testfall för anrop av servicar.

tc_procedure(Requirement, Procedure) :-
objectPropertyAssertion(requirementForService, Requirement, Service),
objectPropertyAssertion(requiresAction, Requirement, DeactivateUART),
objectPropertyAssertion(actsOn, DeactivateUART, UartController),
classAssertion(uart_controller, UartController),
classAssertion(transmission_service, WriteService),
classAssertion(reception_service, ReadService),
Procedure = [Service, WriteService, ReadService, recovery(Service)].

Inferensreglerna och ontologin fungerar alltså ihop för att generera testfall, vilket illustreras i fig 3.

Fig 3. Den streckade rektangeln visar ontologivägar som används av inferensregeln från exemplet. Alla ontologivägar används för att generera hela testfallet.
klicka här för större bild

Resultatet av detta ”samarbete” blir ett av flera testfall som kan beskrivas i vilket språk som helst, till exempel C++ eller som ett script. För enkelhetens skull visar vi på hur det ser ut om testfallet beskrivs i ett naturligt språk, i det här fallet engelska. Tabell 1 visar likheten mellan resultatet från denna testfallsgenerering och samma testfall som finns beskrivet i ett officiellt testdokument.

Tabell 1. Testfall från ett testdokument (övre delen av tabellen) och motsvarande genererade testfall (undre delen av tabellen)

Test Case & Header: STDRS4YY-114

Test Objective
Test that the service rs4yy_init does all of the following:
*  {deactivate UART}.
*  sets <result> to rs4yy_comTypeCfgError.
if <comType> is out of its valid range

Prerequisite Conditions
According to table below.

Test Inputs
1. According to table below.
2. <uartId> := <uartId> from the rs4yy_init call
3. <uartId> := <uartId> from the rs4yy_init call
4. <comType> := rs4yy_rs422Com

Test Procedure
1. Call rs4yy_init
2. Call rs4yy_write
3. Call rs4yy_read
4. Recovery: Call rs4yy_init

Expected Test Results
1. <result> == rs4yy_comTypeCfgError
2. <result> == rs4yy_notInitialised
3. <result> == rs4yy_notInitialised, <length> == 0
4. <result> == rs4yy_ok

Assumptions and Constraints
All other configuration parameters have valid values.

Test Objective
<comType> is less than minimum value
Prerequisite Conditions
Ry FIFO shall be filled with data
Test Inputs
1. <comType> := minimum value – 1

Test Objective
<comType> is greater than maximum value
Prerequisite Conditions
Ty FIFO shall be filled with data
Test Inputs
1. <comType> := maximum value + 1

Test Objective
<comType> is a large value
Prerequisite Conditions
Ry FIFO and Ty FIFO shall be filled with data
Test Inputs
1. <comType> := 568952

*******************

TEST CASE for the requirement SRSRS4YY-431
Prerequisite Conditions:
fill ryFIFO with data
fill tyFIFO with data
fill ryFIFO, tyFIFO with data

Test Inputs:
1. <communicationType> := min_value – 1
<communicationType> := max_value + 1
<communicationType> := 485053
2. <uartID> := <uartID> from the initializationService call
3. <uartID> := <uartID> from the initializationService call
4. <communicationType> := RS422

Test Procedure:
1. Call initializationService
2. Call writeService
3. Call readService
4. Recovery: Call initializationService

Expected Test Results:
1. <result> == communicationTypeConfigurationError
2. <result> == rs4yyNotInitialised
3. <result> == rs4yyNotInitialised, <length> == 0
4. <result> == rs4yyOk

Som synes så är likheten slående, vilket även företaget som bistod projektet med exemplet medgav. Med detta resultat har projektet visat på möjligheten att generera testfall utgående från formella dokument som kravspecifikationer, testspecifikationer och liknande.

Automatisera
Framtagandet av testontologin och de nödvändiga inferensreglerna har hittills skett manuellt. Målet med OSTAG-projektet var endast att visa på möjligheten att kunna generera testfall på detta formella sätt. Men det inses att detta manuella förfarande i kommer att fungera i en verklig testmiljö utan det måste kunna ske automatiskt. Tanken är därför att ta fram metoder för att automatisera genererandet av testfall och detta kommer att ske i fortsättningsprojektet ASTAG (Automatisk generering av testfall för programvarutestning) under perioden 2017-2020. I det nya projektet kommer samma industrideltagare att vara med på nytt då de insett potentialen hos forskningsresultaten för sina testaktiviteter och de besparingar som finns inom räckhåll.
Vladimir Tarasov, Tekniska Högskolan i Jönköping

Filed under: Embedded, Utländsk Teknik