Tekniker för att testa mjukvara - AddQ

Tekniker för att testa mjukvara 

Analys av testtekniker samt risker med ett mjukvarubaserat börssystem 

2001-05-11 

av 

Stefan Särd 

Dag Wester

Sammanfattning 

Mjukvarubaserade lösningar för att sköta handeln på börser är inget nytt, men en 

hårdare konkurrens, ökad omsättning och krav på nya funktioner gör att bössystemen 

blir allt mer komplexa. Komplexiteten har medfört en ökad svårighet att verifiera 

börssystemens funktionalitet. En stor del av verifieringen består i att genomföra tester 

på systemen. För att testarbetet ska ge önskad effekt är det viktigt att lämpliga 

testtekniker används i rätt omfattning. 

Två fristående studier presenteras, dels en riskanalys och dels en sammanställning av 

testtekniker. I riskanalysen förs resonemang om vilka incidenter som kan inträffa i ett 

börssystem. Sammanställningen av testteknikerna ger en generell bild av de tekniker 

som kan användas för att testa mjukvara. Utifrån de två studierna och en internationell 

standard diskuteras hur börssystemen bör testas för att nå en viss felsannolikhet. Det 

visar sig att inga universallösningar finns att tillgå. För att nå önskad felsannolikhet 

ska testningen ske kontinuerligt under utvecklingen och bygga på en kombination av 

testtekniker som kompletterar varandra. 

NYCKELORD: 

Säkerhetskritiska system, mjukvarubaserade börssystem, riskanalys, riskvärderingsmatris, testtekniker, 

statisk analys, dynamisk analys, strukturell testning, funktionell testning, statistisk testning, 

felsannolikhet, felintensitet. 

__________________________________________________________________________________________ 

Stefan Särd och Dag Wester Industriella informations och styrsystem

Abstract 

Software based solutions for electronic trading platforms are nothing new. However, 

due to stronger competition, more turnover, and new functionality the software-based 

trading platforms used by the stock markets have increased their complexity. This 

increase in complexity has made it more difficult to verify the functionality of the 

platforms. A major part of the verification process consists of testing. Adequate 

testing, using the right techniques, is important in order to ensure the desired effect of 

the verification process. 

In this thesis, two independent studies will be introduced. The first study is a risk 

analysis concerning possible failures of a software based trading platform. The second 

study is a guide to different techniques used when testing software. From these studies 

it is argued, based on an international standard framework, which testing techniques 

might be suitable in order to reach a particular failure probability. When discussing 

these results it is emphasised that there is no obvious solution to the verification 

problem. To achieve a certain failure probability it is essential to use different kinds 

of testing techniques, which complement each other, and to conduct testing over a 

broad part of the development life cycle. 

KEYWORD: 

Safety-critical systems, software based electronic trading platform, risk analysis, risk valuation matrix, 

software testing techniques, static analysis, dynamic analysis, structural testing, functional testing, 

statistical testing, failure probability, failure intensity. 

__________________________________________________________________________________________ 


Förord 

Vi vill här ta tillfället i akt att tacka våra två handledare för deras engagemang, Lars 

Wahlberg på OM Technology och Erik Johansson från institutionen för industriella 

informations- och styrsystem på KTH. De har båda bidragit med värdefull kritik, 

feedback och idéer under arbetets gång. 

Tre studiebesök har genomförts. Mycket uppskattade har de rundvandringar varit då 

vi har fått se JAS-plan och kärnkraftverk på nära håll. Särskilt tack vill vi framföra till 

följande, 

Bo Liwång, som har gett oss en insikt i hur Statens Kärnkraftsinspektion arbetar. 

De personer som vi var i kontakt med vid Forsmarks kärnkraftverk, däribland 

Mattias Hansson som var vår värd under besöket. 

SAAB i Linköping, och då framförallt verifiering- och valideringsteamet för 

styrsystemet av JAS 39 Gripen. 

Slutligen vill vi tacka all personal på OM Technology som har hjälpt oss i vårt arbete. 

Stockholm, maj 2001. 

Stefan Särd och Dag Wester 

__________________________________________________________________________________________ 


Innehållsförteckning 

1 INTRODUKTION .......................................................................................................................................1 

1.1 BAKGRUND................................................................................................................................................1 

1.1.1 Företaget där examensarbetet är utfört ..........................................................................................1 

1.2 SYFTE OCH MÅL.........................................................................................................................................2 

1.2.1 Målgrupp.........................................................................................................................................3 

1.2.2 Avgränsningar.................................................................................................................................3 

1.3 RAPPORTDISPOSITION................................................................................................................................3 

1.4 ORGANISATION..........................................................................................................................................4 

1.5 ARBETSMETOD ..........................................................................................................................................4 

1.5.1 Riskanalys........................................................................................................................................5 

1.5.2 Mjukvarutestning.............................................................................................................................5 

1.5.3 Analys och diskussion......................................................................................................................5 

1.5.4 Intervjuer.........................................................................................................................................6 

1.6 TERMINOLOGI............................................................................................................................................6 

2 RISKER FÖRKNIPPADE MED BÖRSSYSTEM ...................................................................................8 

2.1 VAD ÄR ETT BÖRSSYSTEM .........................................................................................................................8 

2.1.1 Vad karaktäriserar ett börssystem...................................................................................................8 

2.1.2 Aktörer.............................................................................................................................................9 

2.1.3 Ett fiktivt börssystem .....................................................................................................................10 

2.2 GENERELL RISKANALYS ..........................................................................................................................12 

2.2.1 Incidenternas konsekvensgrader ...................................................................................................12 

2.2.2 Incidenternas frekvens...................................................................................................................13 

2.2.3 Riskvärderingsmatris.....................................................................................................................14 

2.3 RISKANALYS FÖR ETT BÖRSSYSTEM ........................................................................................................15 

2.3.1 Definition av konsekvensgrad och frekvens...................................................................................15 

2.3.2 Riskvärderingsmatris.....................................................................................................................16 

2.3.3 Incidenter ......................................................................................................................................17 

2.3.4 Incidenter sorterade efter konsekvensgrad....................................................................................26 

3 MJUKVARUTESTNING .........................................................................................................................27 

3.1 INTRODUKTION........................................................................................................................................27 

3.1.1 Disposition ....................................................................................................................................28 

3.2 TESTNING SOM BEGREPP..........................................................................................................................30 

3.2.1 Testningens syfte ...........................................................................................................................30 

3.2.2 Testningens begränsningar ...........................................................................................................30 

3.2.3 Testningens omfattning..................................................................................................................32 

3.2.4 Testningens utförare......................................................................................................................33 

3.2.5 Testningens faser...........................................................................................................................34 

3.2.6 Funktionell eller strukturell testning .............................................................................................38 

3.2.7 Statisk eller dynamisk analys.........................................................................................................39 

3.2.8 Jämförelse av fel i hård- och mjukvara .........................................................................................41 

3.2.9 Orsaker till att incidenter inträffar................................................................................................43 

3.3 STRUKTURELL TESTNING.........................................................................................................................44 

3.3.1 Flödesterminologi .........................................................................................................................45 

3.3.2 Control Flow Testing (Path Testing).............................................................................................47 

3.3.3 Data Flow Testing.........................................................................................................................50 

3.3.4 Looptestning ..................................................................................................................................52 

3.3.5 Logikbaserad testning (villkorstestning) .......................................................................................54 

3.4 FUNKTIONELL TESTNING .........................................................................................................................55 

__________________________________________________________________________________________ 


3.4.1 Domäntestning ..............................................................................................................................56 

3.4.2 Tillståndstestning ..........................................................................................................................61 

3.4.3 Logikbaserad testning ...................................................................................................................63 

3.4.4 Syntaxtestning................................................................................................................................64 

3.4.5 Transaction flow testing ................................................................................................................65 

3.5 STATISTISK TESTNING..............................................................................................................................66 

3.5.1 Felinjicering ..................................................................................................................................66 

3.5.2 Random testing..............................................................................................................................67 

3.5.3 Feluppskattning med hjälp av dubbla testlag................................................................................69 

3.6 STATISK ANALYS .....................................................................................................................................70 

3.6.1 Granskning och walkthrough ........................................................................................................70 

3.6.2 Inspektion ......................................................................................................................................71 

3.6.3 Formella metoder..........................................................................................................................72 

3.7 ÖVRIGA TEKNIKER...................................................................................................................................74 

3.7.1 Stresstestning.................................................................................................................................74 

3.7.2 Cleanroom testing .........................................................................................................................75 

3.7.3 N-version programmering.............................................................................................................76 

3.7.4 Modellbaserad verifiering (MBV) .................................................................................................78 

3.7.5 Regressionstestning.......................................................................................................................79 

3.8 SAMMANFATTNING..................................................................................................................................81 

3.8.1 Vilka teststrategier används på vilka mjukvarudelar ....................................................................81 

3.8.2 Vem bör testa på vilken nivå .........................................................................................................81 

3.8.3 Sammanställning över testtekniker................................................................................................81 

3.8.4 Sammanställning över vad som uppnås med hjälp av olika testtekniker.......................................83 

4 TESTTEKNIKERS INVERKAN PÅ FELSANNOLIKHET ................................................................85 

4.1 UPPDELNING I KRITIKALITETSNIVÅER ENLIGT IEC 61508 .......................................................................85 

4.2 MJUKVARUVERIFIERING DELVIS BASERAD PÅ IEC 61508........................................................................86 

4.2.1 Översiktlig mjukvaruverifiering ....................................................................................................86 

4.2.2 Verifiering uppdelad i statisk- och dynamisk analys.....................................................................87 

4.2.3 Verifiering i olika faser av testningen ...........................................................................................88 

4.3 IEC 61508 KOPPLAD TILL RISKVÄRDERINGSMATRIS FÖR BÖRSSYSTEM...................................................89 

5 DISKUSSION OCH SLUTSATS .............................................................................................................90 

5.1 DISKUSSION AV ARBETET ........................................................................................................................90 

5.1.1 Börssystemets roll i samhället .......................................................................................................90 

5.1.2 Myndighetens inblandning ............................................................................................................91 

5.1.3 Felsannolikhet för mjukvara..........................................................................................................92 

5.1.4 Mätetal för felbegrepp inom mjukvara..........................................................................................93 

5.1.5 Partitionering och klassificering av mjukvara ..............................................................................93 

5.1.6 Återkoppla testningen till felens ursprung.....................................................................................94 

5.1.7 Kommentarer och förslag på användningssätt av IEC 61508.......................................................94 

5.1.8 Fortsatta studier............................................................................................................................95 

5.2 DISKUSSION RUNT FRÅGESTÄLLNING ......................................................................................................95 

5.2.1 Slutsats ..........................................................................................................................................97 

BILAGOR: 

A. Studie av säkerhetskritiska system 98 

B. Enkätbilaga 105 

C. Riskvärderingsmatrisenkät 112 

D. Konsekvensenkät 115 

ORDLISTA 

REFERENSER 

__________________________________________________________________________________________ 


Tekniker för att testa mjukvara – 

Analys av testtekniker samt risker med ett 

mjukvarubaserat börssystem. 

___________________________________________________________________________ 

1 Introduktion 

Kapitlet ger en introduktion till rapporten som är resultatet av ett examensarbete utfört 

på OM Technology. Bakgrunden och syftet med arbetet presenteras och en 

beskrivning av arbetsgången ges. För att inte begrepp ska missförstås innehåller även 

kapitlet ett terminologiavsnitt. 

1.1 Bakgrund 

Under de senaste decennierna har omsättningen på världens börser ökat kraftigt. På 

Stockholmsbörsen har omsättningen ökat från att under 70-talet uppgå till några 

miljoner kronor per dag till att nu dagligen omfatta tiotals miljarder kronor. 

Omsättningen har i genomsnitt ökat med 39 procent per år under det senaste decenniet 

[OMy99]. Omsättningsökningen, samt en ökad användning finansiella instrument som 

optioner och warrants, har medfört att mängden information som passerar igenom 

börssystemen ökar lavinartat. Den ökande informationsmängden har resulterat i att 

nya och högre krav ställs på börssystemen. 

En viktig förändring som påverkat konkurrenssituationen på de finansiella 

marknaderna är avregleringar och privatiseringar. Då börserna är privatägda 

prioriteras vinstintressen och därmed en effektivisering av handeln. Eftersom samma 

aktie ofta handlas på flera börser ställs också högre krav på att transaktionskostnaderna 

ska vara så låga som möjligt. Samtidigt är det ur konkurrenshänsyn 

mycket viktigt att systemen fungerar, i annat fall kan börserna byta systemleverantör. 

Antalet människor som handlar med aktier ökar ständigt och faktum är att de flesta 

svenskar idag har delar av sitt sparkapital placerat i aktier. Börshandeln är inte 

förenad med risker vad gäller människoliv, som i t.ex. kärnkrafts- och flygbranschen, 

men ett börshaveri kan få stora konsekvenser för såväl den enskilde småspararen som 

de stora finansiella institutionerna. 

Ett led i att identifiera och minimera riskerna i börshandeln är att ha väldefinierade 

metoder för att testa den mjukvara som utgör grunden för börssystemet. Testningen 

under utvecklingsarbetet syftar till att verifiera systemkraven och därigenom påvisa 

att de mjukvarubaserade börssystemen uppfyller kundernas önskemål. 

1.1.1 Företaget där examensarbetet är utfört 

För femton år sedan startade OM den första elektroniska börshandelsplatsen i Sverige. 

Sedan dess har företaget vuxit kraftigt. Idag är OM ett internationellt företag som 

arbetar med att ta fram och driva elektroniska marknadsplatser för aktiehandel och 

andra finansiella instrument. OM driver bl.a. Stockholmsbörsen vars kunder är de 

mäklare som handlar över börsen. 

__________________________________________________________________________________________ 

Stefan Särd och Dag Wester 1(124) Industriella informations och styrsystem




___________________________________________________________________________ 

OM Technology är det affärsområde inom OM som arbetar med att utveckla 

programvaran för de elektroniska marknadsplatserna och för mäklarnas applikationer. 

Kunderna är främst börser runt om i världen. 

För att OM Technology ska fortsätta vara framgångsrikt är det viktigt att deras 

produkter håller hög kvalité. För att förvissa sig om produkternas kvalité utförs 

omfattande testning av mjukvaran. Men det är inte bara antalet tester som är av 

betydelse för att förvissa sig om kvalitén utan även vilka typer av tester som 

genomförs. Denna rapport innehåller en summarisk genomgång av testtekniker för 

mjukvara och föreslår vilka av dessa tekniker som bör prioriteras framför andra. Det 

är en förhoppning att denna rapport ska ge värdefulla idéer till det testarbete som 

genomförs på företaget. 

1.2 Syfte och mål 

De högre kraven leder till en lägre feltolerans och därmed ökar behovet av att kunna 

åtgärda de fel som finns i systemet. En förutsättning för att felen ska kunna åtgärdas 

är att de först lokaliseras. Felen har olika kritikalitet, d.v.s. konsekvenserna av felen 

kan få olika allvarliga följder. Riskerna som de tänkbara felen kan ge upphov till 

påvisas lämpligen med en riskanalys. Ett sätt att hitta felen är att testa mjukvaran. Till 

testarens förfogande finns en uppsjö av testtekniker som alla är mer eller mindre bra 

inom sitt användningsområde. 

Ovanstående fakta leder fram till en arbetsuppdelning i följande tre steg, där varje steg 

representerar ett delmål med en frågeställning. 

• En riskanalys utförs för ett börssystem, där tänkbara incidenter identifieras. En 

frågeställning som genomsyrar riskanalysarbetet lyder som följer. 

Vilken kritikalitet har ett mjukvarubaserat börssystem? 

• En kartläggning och utvärdering av befintliga testtekniker som används inom 

säkerhetskritiska branscher sammanställs. Sammanställningen ska ge svar på 

följande frågeställning. 

Vilka tekniker finns för testning av mjukvara samt vilket resultat ger 

användandet av dessa? 

• De två delmålen leder fram till den analys som ska besvara den slutgiltiga 

frågeställningen. 

Vilka testtekniker förordas givet en viss kritikalitet på mjukvaran? 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

1.2.1 Målgrupp 

Rapporten vänder sig först och främst till företaget där arbetet utförts. Målsättningen 

är att rapporten ska vara skriven så att alla som har en anknytning till 

systemutveckling inom företaget ska kunna ta del av innehållet. Information gällande 

börssystem är skriven på ett sådant sätt att rapporten ska vara begriplig för 

intresserade även utanför företaget. 

1.2.2 Avgränsningar 

Utvecklingen från idé till färdig produkt bör följa en väl definierad arbetsgång för att 

slutprodukten ska bli ett system som fungerar som det var tänkt. Synsättet att alla fel 

kan hittas genom testning och därefter åtgärdas så att systemet blir felfritt är inte 

realistiskt. Ett sådant arbetssätt kräver orimligt stora resurser och är inte särskilt 

kostnadseffektivt [Hei97]. Verifiering och validering tas kortfattat upp, men 

koncentrationen ligger främst på testningen av mjukvara. Utvecklingsprocesser som 

t.ex. kravidentifiering och design behandlas alltså bara översiktligt. 

Med börssystem avses den utrustning som krävs för att kunna bedriva börshandel, 

d.v.s. mjukvara och den tillhörande hårdvaran. Då inget annat sägs syftar begreppet 

börssystem i denna rapport till den mjukvara som systemet är uppbyggt av. En 

avgränsning som gjorts är att arbetet inte behandlar testning av hårdvara. 

1.3 Rapportdisposition 

I rapportens syfte och mål nämndes att examensarbetet är uppdelat i tre steg. Dessa 

steg utgör den röda tråden i rapporten och har lett till att arbetet följer en 

trestegsmodell. 

Steg 1 

Riskanalysarbete 

Steg 2 

Studie av 

testteknike 

r 

Riskvärderingsmatris 

Oacceptabel Oacceptabel Bedömning 

Oacceptabel Bedömning Acceptabel 

Bedömning Acceptabel Acceptabel 

Frekvens 

Sammanställning av 

testtekniker 

Figur 1-1. Den trestegsmodell som legat till grund för examensarbetet. 

__________________________________________________________________________________________ 

Stefan Särd och Dag Wester 3(124) Industriella informations och styrsystem 

Konsekvens 

Steg 3 

Vilka testtekniker förordas givet 

en viss kritikalitet på mjukvaran?




___________________________________________________________________________ 

Vardera av dessa steg utgör ett kapitel i rapporten. I kapitel 2 ges en introduktion till 

riskanalysbegreppet varpå en riskanalys utförs på ett fiktivt börssystem. Arbetet 

mynnar ut i en riskvärderingsmatris. De testtekniker som undersöktes under det andra 

steget sammanställs och presenteras i kapitel 3. I kapitel 4 rekommenderas vilka 

testtekniker som bör användas för att uppnå en viss felsannolikhet i systemet. 

Rekommendationerna bygger på en standard som har studerats. Diskussioner samt 

slutsatser som dragits under arbetets gång presenteras slutligen i kapitel 5. 

1.4 Organisation 

Examensarbetet, som är på 20 poäng, är utfört av Stefan Särd och Dag Wester, båda 

teknologer på civilingenjörsutbildning i elektroteknik vid KTH med inriktning 

industriella informations- och styrsystem. Till examensarbetet var dessutom två 

handledare knutna, dels en ämneshandledare från OM Technology och dels en 

akademisk handledare från KTH. Handledarnas uppgifter var att ge stöd och tips, men 

också kritik. Lars Wahlberg, som är team leader för Test Tools på OM Technology, 

var ämneshandledare. Erik Johansson, snart färdig teknologiedoktor från industriella 

informations- och styrsystem på KTH, stod för den akademiska handledningen. I sin 

forskning har han bland annat studerat säkerhetskritiska system inom bl.a. 

kärnkraftsindustrin. 

1.5 Arbetsmetod 

I detta avsnitt beskrivs de metoder som använts under arbetets gång, d.v.s. metoder 

för hur information har samlats in och analyserats. Det framgår vilken typ av studie 

det rör sig om och tillvägagångssättet för att nå slutmålet. Läsaren bör vara bekant 

med innehållet i rapporten för att fullständigt förstå avsnittet eftersom vissa uttryck 

används som förklaras längre fram. 

Eftersom rapporten innehåller en sammanställning av befintliga testtekniker är det en 

studie med hermeneutiska inslag [Lun99]. Rapporten är både explorativ och 

beskrivande, explorativ eftersom olika kända testtekniker sammanställs och 

beskrivande då intervjuer genomförs som utreder hur de olika teknikerna används i 

verkligheten. Riskanalysen klassificeras som en beskrivande undersökning då den 

beskriver personalens syn på risker för företaget. 

Arbetsmetoderna för de tre steg, som presenterades i Figur 1-1, beskrivs nedan. För 

att styrka vissa bitar i rapporten utfördes också intervjuer. En beskrivning av 

intervjuernas genomförande beskrivs också. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

1.5.1 Riskanalys 

Riskanalysen grundar sig på ett fiktivt börssystem. Anledningen till att riskanalysen 

inte grundar sig på ett riktigt system är att ett sådant system är mycket komplext samt 

för att på så sätt inte exakt behöva beskriva hur systemen på företaget är uppbyggda. 

Inspiration har dock tagits från ett riktigt börssystem varför resultatet från 

riskanalysen i stort sett är direkt applicerbart. 

Varje del av det fiktiva börssystemet analyserades med tanke på vilka incidenter som 

kan följa av olika fel. Arbetet resulterade i en sammanställning av tänkbara incidenter. 

För att göra bedömningar av hur allvarliga incidenterna kan tänkas vara gjordes en 

enkätundersökning på företaget. Sammanställningen av enkäten redovisas i bilaga B. 

Enkäten i sin helhet finns bifogad som bilaga C. 

Då en riskanalys utförs måste även incidenternas frekvenser kalkyleras. Riskanalysen 

fullbordades genom att ta fram en riskvärderingsmatris som relaterar vilka frekvenser 

som accepteras för olika allvarliga incidenter. Även riskvärderingsmatrisen togs fram 

genom en enkätundersökning. Under arbetets gång har också diskussioner och 

intervjuer med personer på företaget genomförts. Enkätsammanställningen finns 

bifogad i bilaga B och enkäten som bilaga D. 

1.5.2 Mjukvarutestning 

Denna del av rapporten beskriver vanligt förekommande testtekniker. Information har 

inhämtats från för ämnet relevant litteratur. Böcker användes för att ge ett brett 

teoretisk underlag medan paper gav information om de senaste vetenskapliga rönen. 

Det är naturligtvis omöjligt att påstå att vi täckt in all relevant litteratur eftersom det 

är ett stort ämne som det skrivits många hyllmeter om. Då vi funnit att många 

författare refererar till varandra anser vi att vi använt oss av de mest framstående 

verken som behandlar testtekniker, och därför gjort en för ett examensarbete fullgod 

litteraturstudie. En ytterligare källa till information angående testtekniker var de 

intervjuer som gjordes i andra säkerhetskritiska branscher. 

1.5.3 Analys och diskussion 

De rekommendationer på vilka testtekniker som bör användas grundar sig så långt 

som möjligt på standarder. Vissa justeringar har dock gjorts för att teknikerna bättre 

ska passa rapportens upplägg. De diskussioner som förs bygger vidare på den 

information som hämtats från litteratur och intervjuer samt funderingar som väckts 

under arbetets gång. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

1.5.4 Intervjuer 

Intervjuer genomfördes med representanter från två olika säkerhetskritiska branscher. 

Dessa var kärnkraft- och flygbranschen. Intervjuerna syftar till att ge information 

inom framförallt två olika områden, dels vilka testtekniker som används men också 

vilken effekt användningen av dessa får på den testande mjukvaran. 

Intervjuerna utfördes enligt en semistandardiserad och strukturerad metod. Med 

semistandardiserad menas att en del av frågorna är gemensamma och obligatoriska för 

samtliga intervjuer. De obligatoriska frågorna kompletteras med följdfrågor för att ge 

en bredare bild av ämnesområdet. Eftersom målsättningen med intervjuerna redan i 

förväg var fastställd är intervjuformen strukturerad. En strukturerad intervju innebär 

bl.a. att det finns ett väl definierat syfte och att frågorna är bestämda innan intervjun 

[Lun99]. 

En sammanställning av intervjuerna finns i bilaga A. 

1.6 Terminologi 

Eftersom samma begrepp kan tolkas på många olika sätt är det viktigt att klargöra vad 

som menas, annars är det lätt hänt att missförstånd uppstår mellan läsare och 

författare. Ordet fel är exempel på ett ord som ofta används med en tvetydig 

betydelse. Eftersom det inte finns några bra översättningar för engelskans fault och 

failure översätts båda dessa ord ofta med det svenska ordet fel. I vanligt tal sägs därför 

ibland att fel inträffar när ett fel exekveras. En lämpligare benämning bör vara att en 

incident uppstår då ett fel exekveras. Nedan följer några definitioner på begrepp 

såsom vi använder dem i rapporten. 

• Fel kan medföra att mjukvarans funktionalitet på något sätt avviker från vad som 

är önskvärt. Fel kan t.ex. vara implementerade i koden om programmeraren har 

programmerat fel eller inte programmerat vad som avsågs. Fel kan också uppstå 

vid tolkningen av luddiga kravspecifikationer. Ett fel är något som kvarstår ända 

tills det åtgärdas. 

• Felintensitet är ett mått på hur mycket fel som finns i koden. En tänkbar enhet är 

antal fel per kodrad. 

• Felsannolikheten anger sannolikheten för att ett fel exekveras. Eftersom ett system 

kan ha många fel som aldrig exekveras behöver inte en hög felintensitet leda till 

en hög felsannolikhet. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Följande figur, inspirerad av [Joh96], visar sambandet mellan några begrepp som 

används i rapporten. Efter figuren ges en förklaring till begreppen. 

Systemets möjliga tillstånd 

Felaktiga tillstånd 

Incident 

Figur 1-2. Av systemets alla tillstånd är några felaktiga. En del av de felaktiga tillstånden kan leda till 

en incident. 

• Då ett programmeringsfel exekveras går systemet in i ett felaktigt tillstånd. När 

systemet befinner sig i ett felaktigt tillstånd behöver det inte nödvändigtvis leda 

till händelser som avviker från specifikationen, men det kan göra det. 

• En incident är en mer eller mindre allvarlig och ospecificerad händelse som kan 

inträffa då systemet befinner sig i ett felaktigt tillstånd, vilket i sin tur är en följd 

av att ett fel har exekverats. En incident är således skillnaden mellan det önskade 

och det verkliga beteendet. 

Sammanfattningsvis kan sägas att alla incidenter beror av fel, men alla fel leder inte 

till incidenter. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

2 Risker förknippade med börssystem 

Kapitlet mynnar ut i den riskanalys som har gjorts för ett fiktivt börssystem. För att 

kunna ta del av riskanalysen presenteras först vad som karaktäriserar ett börssystem 

samt de aktörer som kommer i kontakt med systemet. Efterföljande avsnitt beskriver 

det fiktiva börssystem som ligger till grund för riskanalysen. Innan riskanalysen i 

kapitel 2.3 ges även en generell förklaring till vad en riskanalys är. 

2.1 Vad är ett börssystem 

Ett börssystem kan sägas bestå av den mjuk- och hårdvara som tillsammans utgör en 

elektronisk marknadsplats för värdepapper. Den kommande framställningen fokuserar 

i första hand på börssystemets mjukvarudel. 

För att kunna ta del av den kommande riskanalysen är det bra att först få en inblick i 

vad ett börssystem är samt vilka som kommer i kontakt med systemet. I det här 

kapitlet presenteras några av de förutsättningar som karaktäriserar ett börssystem. En 

presentation av det fiktiva börssystem, som ligger till grund för analysen, presenteras 

också. De exempel på regler och aktörer som förekommer utgår alla från den svenska 

marknaden. 

2.1.1 Vad karaktäriserar ett börssystem 

Som omnämnts i rapportens bakgrund har omsättningen på världens börser ökat 

kraftigt under de senaste decennierna. På Stockholmsbörsen har omsättningen ökat 

från att under 70-talet uppgå till några miljoner kronor per dag till att nu dagligen 

omfatta tiotals miljarder kronor. Omsättningen har i genomsnitt ökat med 39 procent 

per år under det senaste decenniet [Omy99]. Omsättningsökningen samt en ökad 

användning av finansiella instrument som optioner och warrants, medför att mängden 

information som passerar börssystemen ökar lavinartat. En utmärkande egenskap för 

ett börssystem är alltså att det ska klara att hantera stora mängder information. 

Dagens samhälle präglas av en stor tillgång på information som används under en kort 

tidsrymd. Fler och fler affärer över börsen görs på kortare sikt, vilket i sin tur ökar 

kravet på att affärerna ska ske ögonblickligen. Ytterligare ett kännetecken för 

börssystem är därför att de bör kunna köras i realtid. 

Börshandeln är inte förenad med risker vad gäller människoliv, som i t.ex. kärnkrafts- 

och flygbranschen, men ett börshaveri kan få stora konsekvenser för såväl den 

enskilde småspararen som de stora finansiella institutionerna. Stora delar av 

samhällets tillgångar handlas via börsen, vilket föranleder att samhället ställer krav på 

en fungerande handel. Den myndighet som kontrollerar detta är Finansinspektionen. 

Då mer och mer av våra pengar finns investerade i bolag som handlas över börsen 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

ökar vikten av att handeln över börsen fungerar. Eftersom fel i börssystem kan få 

allvarliga ekonomiska konsekvenser skulle det eventuellt kunna klassificeras som 

säkerhetskritiskt. 

Sammanfattningsvis sker alltså börshandeln under realtid på ett säkerhetskritiskt 

system som hanterar stora mängder information. 

2.1.2 Aktörer 

Med aktörer avses de personer och företag som på något sätt är i kontakt med ett 

börssystem. De kan delas upp i följande kategorier. 

• Systemleverantörer 

• Börser 

• Börsmedlemmar 

• Användare 

• Investerare 

Systemleverantör, utvecklar 

programvara till börsen och dess 

medlemmar. 

Börsen, direktkontakt 

med börsmedlemmarna 

Börsmedlem, 

t.ex. en bank 

Användare, mäklare 

anställda av börsmedlem 

Figur 2-1. Börssystemets aktörer och deras relationer till varandra. 

Investerare 

Systemleverantörer utvecklar och tillhandahåller den mjukvara, ibland även hårdvara, 

som behövs för driften av börssystemet. Mjukvaran ska primärt styra systemet där 

handeln sker, men kan också utgöra de användarapplikationer som är gränssnittet 

mellan system och användare. Systemleverantörernas kunder kan vara både börser 

och börsmedlemmar, börser då det gäller hela system och börsmedlemmar då det 

gäller de användarapplikationer som används vid uppkoppling till börssystemet. 

Exempel på systemleverantör i Sverige är OM Technology. 

Börser erbjuder en marknadsplats där handel med olika värdepapper bedrivs. Börsens 

kunder är de som köper och säljer värdepapper direkt över börsen, här benämnda 

användare. Märk att det är skillnad mellan användare och investerare. Aktiehandeln i 

Sverige sker till största del över Stockholmsbörsen. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Börsmedlemmar är de banker och mäklarfirmor som är direkt uppkopplade mot 

börsen. För att bli medlem i Stockholmsbörsen krävs tillstånd från Finansinspektionen 

och börsen. 

Användare av börssystemet är de mäklare som arbetar på banker och mäklarfirmor 

som utgör börsens medlemmar. Användarna är direkt uppkopplade mot börsen. 

Investerare är de privatpersoner eller företag som handlar på börsen via någon 

börsmedlem. De kommer därmed inte i direkt kontakt med börssystemet. Även 

personer som handlar med aktier via Internet räknas till denna kategori eftersom de 

går via en börsmedlem för att lägga in sina ordrar. 

Till aktörer kan även företag räknas, vars aktier handlas på börsen. Det är inte bara 

aktier som handlas över börser, utan även t.ex. obligationer. Alltså kan även staten, 

eftersom den emitterar obligationer, räknas som en typ av aktör. Ska frågan om vilka 

som räknas till aktörer dras till sin spets, kan svaret sägas vara hela samhället. En 

finansmarknad som inte fungerar ger effekter på hela samhällsekonomin. Här nöjer vi 

oss dock med den lite smalare definitionen av aktörer. 

2.1.3 Ett fiktivt börssystem 

Eftersom ett börssystem är mycket komplext samt att viss information kan vara 

känslig, är den kommande analysen tillämpad på ett fiktivt börssystem. Det fiktiva 

börssystemet bygger till en viss del på ett riktigt system, men är klart förenklat. 

Endast den mest grundläggande funktionaliteten presenteras. 

Användare 

Figur 2-2 beskriver arkitekturen hos det fiktiva börssystemet. Därefter följer en 

förklaring till varje ruta i bilden. 

Ordermottagare 

Främre 

orderloggare 

Figur 2-2. Schematisk beskrivning av ett fiktivt börssystem. 

Primärsystem 

Matchare 

Sekundärsystem 

Informationsförmedlare 

Bakre 

orderloggare 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

För att systemet inte ska bli så känsligt för fel i t.ex. hårdvara används ett primär- och 

ett sekundärsystem. Dessa båda delsystem är identiska, d.v.s. de använder samma 

programvara och hårdvara. Fördelen med att ha två delsystem är att sekundärsystemet 

kan ta över driften vid en eventuell hårdvarukrasch i primärsystemet och på så sätt 

minskar risken för ett driftstopp. De båda systemen är geografiskt åtskilda till skydd 

för t.ex. brand, översvämningar och elavbrott. Eftersom det är samma mjukvara i båda 

delsystemen skyddar den redundanta konstruktionen däremot inte mot fel i 

mjukvaran. 

Under normala omständigheter, d.v.s. då båda systemen är funktionsdugliga, körs 

systemen parallellt, s.k. ”hot stand by”. Det primära systemet tar emot information 

från klienten, men både primär- och sekundärsystemet behandlar informationen 

parallellt under körning. Konsekvensen av denna design är att oavsett vilken del i 

systemet som sätts ur funktion så finns ändå exakt samma information i det parallella 

systemet och ingen information går förlorad. 

Användare är personer som har direktkontakt med börssystemet. Hit hör börssmäklare 

som lägger in köp- och säljordrar i systemet. 

Ordermottagaren är en del av börssystemets gränssnitt ut mot användaren. Här tas 

ordrar om hand och det kontrolleras att ordrarna är korrekt ifyllda. En bekräftelse, 

som ger information om den inkomna ordern accepteras eller ej, returneras till 

användaren. Då denna första kontroll av ordern är genomförd skickas accepterade 

ordrar vidare till den främre orderloggaren. 

Den främre orderloggaren tar emot ordrar från ordermottagaren och ger varje order 

ett specifikt sekvensnummer. Ordern skrivs till disk och skickas därefter till både 

sekundärsystemet och matcharen. Eftersom varje order har ett unikt sekvensnummer 

och finns lagrad på disk är det möjligt att återskapa ett visst förlopp av 

orderinmatningar i händelse av att systemet går ner. 

Det är i matcharen som köp- och säljordrar kombineras med varandra. Matcharen 

innehåller alla de regler som styr börshandeln. Ordrar kommer in från främre 

orderloggaren i en viss ordning, enligt ordrarnas sekvensnummer. Väl i matcharen 

jämförs de mot ordrar som ännu inte matchats. Sker en matchning mellan köp- och 

säljorder skickas informationen angående matchningen vidare till bakre 

orderloggaren. Om det däremot inte går att matcha den inkomna ordern får orden 

ligga kvar i primärminnet i väntan på nya ordrar som ska matchas. Ordermatchning 

sker i första hand efter pris och i andra hand efter vid vilken tidpunkt ordern gavs. 

Tidpunkten representeras av sekvensnumret för att undvika identiska tidpunkter. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Den bakre orderloggaren tar emot matchade ordrar från matcharen. De matchade 

ordrarna skrivs till disk och skickas därefter till informationsförmedlaren. Då ordrarna 

lagras både före och efter matcharen är det möjligt att i efterhand köra om en 

ordersekvens om matcharen gått ner eller om matchningsfel befaras ha inträffat. 

Informationsförmedlaren utgör tillsammans med ordermottageren börssystemets 

gränssnitt ut mot användarapplikationen. Om systemet fungerar som det ska får 

förmedlaren identisk information från både det primära- och sekundära systemet. 

Eftersom informationen är identisk kastas det duplikat som sist anländer till 

informationsförmedlaren medan det första skickas vidare till användaren. Beroende på 

vad informationen innehåller skickas den ut till antingen en eller samtliga användare. 

Den enskilde användaren får t.ex. specifik information om sin order och samtliga 

användare får allmän information om att en affär har skett. 

2.2 Generell riskanalys 

En riskanalys för ett mjukvarusystem syftar till att kartlägga vilka typer av risker som 

användandet av systemet medför. I och med att en tydligare bild erhålls om vilka 

risker som finns, kan resurserna för att minska riskerna fördelas på ett effektivare sätt. 

Med begreppet risk avses kombinationen av sannolikheten för att en incident inträffar 

och konsekvensgraden av den inträffade incidenten. 

Risk 

Figur 2-3. Begreppet risk. 

Som detta kapitel kommer att visa mynnar riskanalysen ut i en riskvärderingsmatris. 

Matrisen visar vilka typer av risker som är oacceptabla och vilka risker som inte är 

kostnadseffektiva att förebygga. 

2.2.1 Incidenternas konsekvensgrader 

Då ett fel i systemet uppmärksammas ska den incident som felet kan leda till 

klassificeras efter konsekvensgrad. Omfattande arbete har lagts ner inom bl.a. militära 

organ för att standardisera riskarbetet. Konsekvensgraderna kan delas upp i olika antal 

nivåer. Leveson föreslår att incidenterna delas upp i följande fyra nivåer [Lev95]. 

• Katastrof 

• Kritisk 

• Marginell 

• Obetydlig 

Incidentens 

Incidentens 

= f ( konsekvensgrad , frekvens 

) 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Om det råder osäkerhet angående hur allvarliga följder en incident kan få, bör den 

högre konsekvensgraden användas. Så länge det föreligger tveksamheter är det 

säkrare att ta till lite marginaler. Om det senare visar sig att klassificeringen av 

incidenten är väl tilltagen kan den göras om. 

Tabellen nedan, som till viss del är hämtad ur [Joh96], innehåller en jämförelse som 

visar innebörden av olika konsekvensgrader. Tabellen visar vad ett mjukvarufel kan få 

för konsekvenser i jämförelse med liknande konsekvensgrad för en produktionsanläggning, 

miljön och människan. 

Mjukvaruföretag Produktionsanläggning 

Miljö Människa 

Katastrof T.ex. förlust av flera Förstörd Mycket Dödsfall 

viktiga beställningar 

allvarlig 

som i värsta fall kan 

leda till konkurs 

skada 

Kritisk Stor ekonomisk skada Stor skada, Stor skada Stor skada 

efter t.ex. förlust av förlust av 

eller sjukdom 

viktig order 

viktig order 

Marginell Mindre ekonomisk Mindre Mindre skada Liten skada 

förlust 

skada, förlust 

av mindre 

viktig order 

eller sjukdom 

Obetydlig Försumbar förlust Försumbar Försumbar Mindre ytlig 

skada skada skada 

Tabell 2-1. Beskrivning över vad jämförbara konsekvenser kan innebära för olika kategorier. 

2.2.2 Incidenternas frekvens 

När incidenterna har klassificerats efter konsekvensgrad ska även sannolikheterna för 

att de inträffar bedömas. Dessa bedömningar är ofta svårare att göra och kan därför bli 

lite osäkra. Det kan därför vara bättre att ta det säkra före det osäkra och uppskatta att 

incidenterna förekommer med högre frekvens. Sannolikheten går alltid att uppskatta 

på nytt vid ett senare tillfälle. 

Följande tabell innehåller förklaringar till de termer som används för att beskriva 

frekvens i den kommande framställningen. Lämpligt är att för den specifika 

riskanalysen ange en ungefärlig siffra för varje frekvensnivå. Värdena beror på vad 

det är för system som riskanalysen är tänkt att beröra samt systemets livslängd. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Frekvens Förklaring 

Frekvent Inträffar många gånger under systemets livslängd 

Trolig Inträffar ett flertal gånger under systemets livslängd 

Sannolik Inträffar någon gång under systemets livslängd 

Försumbar Kan möjligen inträffa under systemets livslängd 

Osannolik Förväntas inte inträffa under systemets livslängd 

Tabell 2-2. Riskvärderingsmatrisens frekvensskala 

OBS! Utifrån systemleverantörens syn ökar sannolikheten för att en incident ska 

inträffa om flera likadana system är i drift samtidigt. Om t.ex. tio likadana system är i 

drift ökar sannolikheten för en incident med en faktor tio. En incident som är trolig för 

ett system kan således bli frekvent för ett flertal system. 

2.2.3 Riskvärderingsmatris 

När incidenterna är bedömda efter dels konsekvensgrad och dels sannolikheten för att 

de ska inträffa, kan riskerna värderas utifrån en riskvärderingsmatris. På matrisens 

axlar anges incidenternas frekvens samt konsekvensgrad. Nedan presenteras ett 

exempel på en riskvärderingsmatris. 

Frekvent Trolig Sannolik Försumbar Osannolik 

Katastrof Oacceptabel Oacceptabel Oacceptabel Oacceptabel Bedömning 

Kritisk Oacceptabel Bedömning Bedömning Bedömning Acceptabel 

Marginell Bedömning Bedömning Bedömning Acceptabel Acceptabel 

Obetydlig Bedömning Acceptabel Acceptabel Acceptabel Acceptabel 

Figur 2-4. Exempel på hur en riskvärderingsmatris kan se ut. 

I matrisens celler skrivs de termer som används för att gradera hur allvarlig risken är. 

Antalet uppdelningar kan variera. I detta exempel har följande tre uppdelningar gjorts. 

Oacceptabel: Risken är så allvarlig att den under inga omständigheter kan tillåtas 

inträffa i angivet frekvens- och konsekvensintervall. 

Bedömning: En bedömning måste göras från fall till fall hur kostnadseffektivt det 

är att förebygga risken. 

Acceptabel: Konsekvensen av incidenten är så obetydlig att ingen åtgärd behöver 

genomföras. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

2.3 Riskanalys för ett börssystem 

I det här kapitlet presenteras den riskanalys som gjorts på det fiktiva börssystemet (se 

kapitel 2.1.3). Analysen resulterar i en riskvärderingsmatris som visar hur frekvent 

incidenter får inträffa för att det ska vara acceptabelt. 

Riskanalysen är skriven med utgångspunkt från en av företagets produkter snarare än 

för hela företaget. Det allvarligaste som kan hända med produkten är att förtroendet 

förloras så mycket att varumärket dör. Om utgångspunkten istället hade varit företaget 

är det allvarligaste som kan inträffa att företaget går i konkurs. 

2.3.1 Definition av konsekvensgrad och frekvens 

Nedan definieras begreppen konsekvens och frekvens som utgör kolumn och rad i den 

kommande riskvärderingsmatrisen. Definitionerna av begreppen har ingen direkt 

koppling till något verkligt börssystem, men har tagits fram i samråd med insatta 

personer på företaget. 

Konsekvensgrad Förklaring 

Katastrof Föregås av en allvarlig incident som kan leda till konkurs. 

Varumärket skadas så allvarligt att det blir oanvändbart. Inga nya 

ordrar erhålls och befintliga kunder säger upp avtal. 

Kritisk Varumärket skadas så allvarligt att det inverkar negativt på 

möjligheten att sälja produkten. Enskilda avtal med direkt 

inblandade kunder riskeras sägas upp. 

Marginell Ringa skada på varumärket. Leder inte till minskad försäljning 

men kan medföra vissa direkta kostnader. 

Obetydlig Ej märkbar ekonomisk konsekvens. Visst irritationsmoment för 

enstaka kunder. 

Tabell 2-3. Definition av konsekvensgrad. 

Följande tabell innehåller förklaringar till de termer som används för att beskriva 

frekvens i den kommande riskanalysen. Framställningen bygger på sannolikheten att 

incidenter inträffar per tidsenhet. Det kan diskuteras huruvida valet av den enheten är 

bästa tänkbara. Om två system körs under ett år och det ena utsätts för en mindre 

belastning än det andra kommer troligen fler incidenter att inträffa i systemet med hög 

belastning. Antal incidenter per transaktioner skulle därför kunna vara en bättre enhet. 

Dock är enheten incidenter per tidsenhet mer generell och vanligt förekommande i 

litteratur och standarder, vilket är motivet till att den används här. Definitionerna av 

frekvenser utgår från ett fiktivt börssystem med en uppskattad livslängd på ca 20 000 

drifttimmar, grundat på att systemet används ungefär 3000 timmar årligen under 5 till 

10 år. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Frekvens Förklaring Inträffar ungefär 

antal gånger per 

år 

Frekvent Inträffar många gånger under 

systemets livslängd 

Trolig Inträffar ett flertal gånger 

under systemets livslängd 

Sannolik Inträffar någon gång under 


Försumbar Kan möjligen inträffa under 


Osannolik Förväntas inte inträffa under 


Tabell 2-4. Förklaring av begreppet frekvens för det fiktiva börssystemet. 

Inträffar ungefär 


timme 

> 30 > 10 -2 

3 10 -3 

0,3 10 -4 

0,03 10 -5 

< 0,003 < 10 -6 

OBS! Utifrån systemleverantörens syn ökar sannolikheten för att en incident ska 

inträffa om flera likadana system är i drift samtidigt. Om t.ex. tio likadana system är i 

drift ökar sannolikheten för en incident med en faktor tio. En incident som är trolig för 

ett system kan således bli frekvent för ett flertal system. 

2.3.2 Riskvärderingsmatris 

Nedan presenteras en riskvärderingsmatris för produkten, d.v.s. ett mjukvarubaserat 

börssystem. Riskvärderingsmatrisen är framtagen med hjälp av en enkätundersökning, 

se bilaga B. Motivet till enkätundersökningen var att få med synpunkter från flera 

olika personer med större inblick i hur olika risker och dess konsekvenser kan påverka 

företaget. Enkäten skickades främst till personer som har inblick i vad incidenter kan 

få för ekonomiska följder för företaget. Som exempel på befattningar hos deltagarna 

kan nämnas linjechefer, avdelningschefer och projektledare. 



Kritisk Oacceptabel Oacceptabel Oacceptabel Bedömning Acceptabel 

Marginell Oacceptabel Oacceptabel Bedömning Acceptabel Acceptabel 

Obetydlig Oacceptabel Acceptabel Acceptabel Acceptabel Acceptabel 

Figur 2-5. Den riskvärderingsmatris som enkätundersökningen resulterade i. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

I matrisen skrivs de termer som används för att gradera hur allvarlig risken är. Antalet 

uppdelningar kan variera. I detta exempel har följande tre uppdelningar gjorts. 

Oacceptabel: Risken är så allvarlig att den under inga omständigheter kan tillåtas 

inträffa i angivet frekvens- och konsekvensintervall. 

Bedömning: En bedömning måste göras från fall till fall hur kostnadseffektivt det är 

att förebygga risken. 

Acceptabel: Konsekvensen av incidenten är så obetydlig att ingen åtgärd behöver 

genomföras. 

2.3.3 Incidenter 

Incidenterna har tagits fram utifrån systemleverantörens synvinkel. De flesta 

incidenter berör dock på något sätt samtliga aktörer, d.v.s. systemleverantören, 

börsen, börsmedlemmar, användare och investerare. För samtliga incidenter skapas 

även större eller mindre indirekta kostnader, t.ex. i form av dålig publicitet. Dessa 

indirekta kostnader är svåra att uppskatta till storlek, men de kan vara mycket 

ansenliga och därmed allvarliga. 

För att få en överskådlig framställning har incidenterna delats upp i följande fem 

kategorier. 

1. Störning i handel 

2. Felaktig handel 

3. Användargränssnitt 

4. Informationsflöde 

5. Övriga incidenter 

Samtliga incidenter har tilldelats ett incidentnummer (I.nr) bestående av två siffror. 

Den första siffran anger till vilken kategori incidenten hör och den andra är 

incidentens plats i kategorin. Incidenten I1.1 är således den första incidenten i den 

första kategorin. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Kategori 1. Störning i handel 

En störning i handeln medför att systemet på något sätt inte är tillgängligt för samtliga 

användare. Störningar kan drabba såväl enskilda som samtliga användare. Den 

allvarligaste incidenten i denna kategori är ett handelsstopp av hela systemet, vilket då 

drabbar samtliga användare. 

I.nr Incident Förklaring och bedömning 

I1.1 Handelsstopp i 

hela systemet 

på grund av 

tekniskt fel 

I1.2 Handelsstopp i 

vissa 

orderböcker 

Under drift inträffar ett fel i systemet som leder till att handeln 

stoppas. Nya ordrar kan ej läggas och ordrar som befinner sig i 

systemet kan ej matchas under handelsstoppets varaktighet. 

Tidsestimaten gäller från konstaterat driftsstopp tills att 

marknaden har öppnat igen. Denna incident innebär däremot inte 

att information som finns i systemet går förlorad. 

Ett längre handelsstopp är en allvarlig incident då samtliga aktörer 

på något sätt drabbas. 

• Katastrof – dagar 

• Kritisk – timmar, upp till en dag 

• Marginell – mindre än en timme 

Under drift inträffar ett fel som medför att handeln stoppas för ett 

antal orderböcker. I de orderböcker som ej berörs av felet fortgår 

handeln som förut. 

Konsekvensgraden beror dels på hur många orderböcker som 

berörs samt hur länge handelsstoppet pågår. Konsekvensgraden 

beror också på vilka orderböcker som går ner eftersom olika 

orderböcker har olika omsättning. 

• Kritisk – >90 % av antalet orderböcker under en dag 

• Marginell – 0-90 % av antalet orderböcker under en dag. 

__________________________________________________________________________________________ 


___________________________________________________________________________ 

I1.3 Prestandaförsämringar 

I1.4 Användarapplikationer 

ej anslutna 




Systemets prestanda försämras så att användaren upplever 

fördröjningar vid t.ex. orderläggning. Fördröjningen uppstår då 

köer bildas i systemet och användarapplikationerna tvingas köa 

ordrar i det egna systemet. 

En prestandaförsämring kan uppstå av flera olika anledningar. 

Dimensioneringen av systemet kan vara dåligt tilltagen. Även om 

systemet fungerar till 100 % av normal tps-nivå kan köer uppstå 

vid ovanligt hård belastning. Fördröjningar kan också uppkomma 

p.g.a. att överföringskapaciteten mellan användare och systemet är 

liten. Ingen av dessa anledningar har egentligen med 

börssystemets mjukvara att göra. Användaren bryr sig troligen 

inte om varför fördröjningen uppstår, bara att den existerar. 

Hur allvarlig incidenten är beror på graden av 

prestandaförsämringen samt dess varaktighet. Med förseningar 

menas att det tar några sekunder mer än vanligt att lägga en order. 

Nedan angivna konsekvensgrader gäller under antagandet att 

prestandaförsämringen gäller en viss del av antalet ordrar under en 

handelsdag. 

• Marginell – 30-100 % 

• Obetydlig –

___________________________________________________________________________ 

I1.5 Systemet 

startar ej vid 

initiering 

I1.6 Felaktig 

schemaläggning 




Fel inträffar vid initieringen av systemet vilket medför att det inte 

startar som planerat. 

Under antagandet att felet åtgärdas till börsens öppnande påverkas 

inte användarna och konsekvensgraden blir marginell. Om felet 

inte åtgärdas innan handeln påbörjas inträffar istället incidenten 

handelsstopp (se Handelsstopp p.g.a. tekniskt fel, I1.1) 

• Obetydlig 

Systemet kan befinna sig i olika tillstånd. Ett tillstånd kan t.ex. 

vara tidsintervallet innan handeln startar, när handeln startar eller 

efter att handeln startat. Till dessa olika tillstånd är olika regler 

kopplade som bl.a. anger hur handeln ska bedrivas och vilka 

aktörer som ska få vilken information. Fel kan uppstå i 

schemaläggningen som styr de olika tillstånden. Detta kan 

resultera i en rad olika fel som t.ex. handelsstopp och eller att det 

går att handla när det inte ska vara möjligt. 

Konsekvensgraden kan vara mycket varierande beroende på vilka 

andra incidenter som inträffar på grund av den felaktiga 

schemaläggningen. 

• Marginell – Under antagandet att den felaktiga 

schemaläggningen t.ex. resulterar i en något fördröjd 

handelsstart. 

Tabell 2-5. Incidenter under kategorin ”störning i handel”. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Kategori 2. Felaktig handel 

En felaktig handel påverkar en enskild eller många ordrar. Konsekvensgraden är alltså 

starkt beroende av antalet ordrar som berörs. För enskilda investerare är det 

naturligtvis av större vikt om den egna ordern behandlas på ett felaktigt sätt än om det 

händer någon annan. Inom kategorin felaktig handel kan incidenterna leda till 

specifika engångskostnader. 


I2.1 Order matchas 

felaktigt 

I2.2 Handelsregler 

följs ej 

I2.3 Felaktig 

avgifts- eller 

avrundningsavvikelse 

Ordern omfattar något annat än det användaren önskar köpa eller 

sälja. Det kan bero på att informationen har förvanskats i systemet 

eller fel i matchning mellan köp- och säljorder. 

Om ordrar börjar matchas felaktigt kan det få mycket allvarliga 

konsekvenser eftersom det då rör sig om stora belopp. Omsättning 

under en normal handelsdag brukar uppgå till tiotals miljoner 

kronor per minut. Att ordrar matchas felaktigt under en längre tid 

är inte troligt eftersom en sådan incident ofta är lätt att upptäcka. 

Konsekvensgraderna nedan förutsätter att det går att backa 

tillbaka handeln så att ingen felmatchning sker. Under den tiden 

det tar att backa tillbaka ordrarna ligger systemet nere. 

• Kritisk – från en minut och uppåt 

• Marginell – mindre än en minut 

Om det inte går att backa tillbaka handeln är det naturligtvis ännu 

allvarligare. Skadeståndskrav kan ställas från berörda kunder vid 

annulering av gjorda affärer. Dessutom innebär det mycket dålig 

publicitet. 

• Katastrof – från en minut och uppåt 

• Kritisk – från enstaka ordrar upp till en minuts handel 

Med felaktiga handelsregler menas att ordrar inte matchas enligt 

de bestämmelser som råder. Innebörden kan t.ex. vara att en order 

betjänas trots att dess pris eller tidstämpel inte är den mest 

fördelaktiga. Konsekvensgraden beror på hur många ordrar som 

berörs och i slutändan på annulerings- och ersättningskravens 

storlek. 

• Kritiskt 

• Marginell 

Även en liten avgifts- eller avrundningsavvikelse kan resultera i 

stora belopp om den får råda under lång tid. 

• Kritiskt 

• Marginell 

__________________________________________________________________________________________ 


___________________________________________________________________________ 

I2.4 Order 

försvinner innan 

matchning 

I2.5 Felaktigt ifylld 

order 

accepteras 

I2.6 Felaktig 

prissättning 




Order som accepterats av systemet försvinner innan den hunnit 

matchats med en annan order. Användaren tror att ordern är under 

behandling när den i själva verket inte existerar. 

Incidentens konsekvens beror på hur många ordrar som 

försvinner. Att ordrar försvinner måste dock ses som en allvarlig 

incident, framförallt eftersom förtroendet för systemet skadas. 

Däremot är det kanske mindre troligt att det leder till att stora 

ersättningsbelopp betalas ut. 

• Marginell 

Användaren lägger order som ej är acceptabla, t.ex. säljer aktier 

som ej finns, och ordern går igenom. Denna typ av handelsfel är 

alltid av en allvarlig karaktär. Hur allvarligt det är beror på hur 

stora kostnader som behövs för ersättning och annulering. 

• Kritisk 

Prissättningen av affärerna sker på ett otillåtet sätt. T.ex. att 

prisspreadar blir större än vad de får vara. 

Beroende på hur stora direkta och indirekta kostnader som 

uppkommer är incidenten olika allvarlig. 

• Kritiskt 

• Marginell 

Tabell 2-6. Konsekvenser under kategorin ”felaktig handel”. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Kategori 3. Användarapplikation 

Då användaren ger oavsiktliga kommandon är felet på något sätt antagligen kopplat 

till användargränssnittet. Dessa fel drabbar främst den användare som utför 

felinmatningen. Utvecklaren av användarapplikationen bär inte ensamt ansvar för att 

användaren gör felinmatningar via användargränssnittet, även användaren själv bär en 

stor del av ansvaret. Användarapplikationen måste dock vara lätt att förstå och 

använda. 


I3.1 Användaren 

ger oavsiktliga 

kommandon 


gör felaktiga 

avläsningar 

I3.3 Svårbegriplig 

användarapplikation 

Dåligt användargränssnitt. Knappar och menyer ligger på 

olämpliga ställen vilket orsakar felinmatningar från användaren. 

Tvetydigheter vad gäller funktionalitet i användarapplikationen 

kan medföra att användaren ger kommandon som resulterar i 

oavsiktliga inmatningar. 

• Marginell – användargränssnitt som ofta missuppfattas och 

som leder till feltryckningar. 

Dåligt användargränssnitt. Informationen presenteras på ett 

otydligt sätt. Detta leder till att användaren får en skev bild av vad 

som händer på börsen. 

Om informationen är lätt att missförstå kan det få indirekta 

konsekvenser då användaren inte trivs med användargränssnittet. 

Incidenten är dock inte allvarlig eftersom kostnaden inte direkt 

kan hänföras till börssystemet. 

• Obetydlig 

Användarapplikationen är så krånglig att användaren inte förstår 

hur man använder all funktionalitet. 

Begränsade användarmöjligheter behöver inte betyda ekonomiska 

förluster men skadar förtroendet för systemet. 

• Obetydlig 

Tabell 2-7. Incidenter under kategorin ”användarapplikation”. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Kategori 4. Informationsflöde 

Fel som uppstår i den information som går in i eller ut ur ett börssystem kan leda till 

olika konsekvenser. 


I4.1 För mycket 

information 

når 

användaren 

I4.2 För lite 

information 

når 

användaren 

I4.3 Information om 

index m.m. 

uteblir 

Information som endast är avsedd för en viss adressat skickas ut 

som allmän information. Kritikaliteten beror givetvis på vad det är 

för slags information som visas och under vilken tidsrymd det 

sker. Konsekvensgraderna nedan förutsätter att incidenten berör 

samtliga ordrar. 

• Kritisk – från en handelsvecka och uppåt. 

• Marginell – upp till en handelsvecka. 

Användaren får inte tillräcklig information om status på egna 

ordrar, t.ex. att en order lagts in i systemet eller att en order gått 

igenom. 

Kan leda till att användaren fattar beslut grundade på felaktig 

information som tillhandahållits av börssystemet. Hur allvarlig 

incidenten är beror på hur stora summor det rör sig om. 

• Marginell 

Uppdateringen av t.ex. indexinformation eller annan information 

som berör handeln. Hur allvarlig incidenten är beror på hur länge 

felet får råda. Förtroendet för systemet kan minska, men någon 

direkt kostnad kan inte härledas till felet. 

• Obetydlig 

Tabell 2-8. Incidenter under kategorin ”informationsflöde”. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Kategori 5. Övriga incidenter 

Övriga incidenter, som inte passar in under någon av de ovan nämnda kategorierna, 

presenteras i tabellen nedan. 


I5.1 Ett av de två 

redundanta 

systemen ligger 

nere 

I5.2 Övergången 

mellan de 

redundanta 

systemen 

misslyckas 

I5.3 Korrekt ifylld 

order 

accepteras inte 

Säkerhetskritiska system bygger ofta på redundans, d.v.s. två eller 

flera system körs parallellt. Anledningen är att systemet ska 

fungera oavsett om ett delsystem slutar att fungera. Att ett 

delsystem går ner behöver inte få någon primär konsekvens, men 

så länge som delsystemet är ur drift blir systemet känsligare för fel 

och därmed instabilare. 

• Obetydlig – under förutsättning att felet åtgärdas. 

Då ett hårdvarufel uppstår i systemet ska driften gå över till den 

andra delen av det redundanta systemet. Om övergången inte 

fungerar som den ska kan det i sin tur leda till många andra 

incidenter, t.ex. ett handelsstopp. 

• Marginell 

En order som borde mottagits av systemet behandlas ej. 

Konsekvensgraden beror dels på hur många ordrar som berörs 

samt eventuella ersättningskrav. 

• Marginell 

Tabell 2-9. Incidenter under kategorin ”övriga incidenter”. Här benämns de incidenter som inte är 

lämpliga att sorteras in under de andra kategorierna. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

2.3.4 Incidenter sorterade efter konsekvensgrad 

I kommande tabell har samtliga incidenter sorterats efter konsekvensgrad med de 

allvarligaste incidenterna först. Orsaken till denna sortering är att incidenterna lättare 

ska kunna appliceras på riskvärderingsmatrisen. 

Konsekvensgrad I.nr Incident 

Katastrof I1.1 Handelsstopp i hela systemet på grund av tekniskt fel 

I2.1 Order matchas felaktigt 

Kritisk 

I1.1 Handelsstopp i hela systemet på grund av tekniskt fel 

I1.2 Handelsstopp i vissa orderböcker 

I1.4 Användarapplikationer ej anslutna 


I2.2 Felaktiga handelsregler 

I2.3 Felaktig avgifts- eller avrundningsavvikelse 

I2.5 Felaktigt ifylld order accepteras 

I2.6 Felaktig prissättning 

I4.1 För mycket information når användaren 

Marginell I1.1 Handelsstopp i hela systemet på grund av tekniskt fel 




I1.6 Felaktig schemaläggning 


I2.2 Felaktiga handelsregler 


I2.4 Order försvinner innan matchning 


I3.1 Användaren ger oavsiktliga kommandon 


I4.2 För lite information når användaren 

I5.2 Övergången mellan de redundanta systemen misslyckas 

I5.3 Korrekt ifylld order accepteras inte 

Obetydlig I1.3 Prestandaförsämringar 

I1.5 Systemet startat ej vid initiering 

I3.2 Användaren gör felaktiga avläsningar 

I3.3 Svårbegriplig användarapplikation 

I4.3 Information om index m.m. uteblir 

I5.1 Ett av de två redundanta systemen ligger nere 

Tabell 2-10. Konsekvenserna sorterade efter konsekvensgrad. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

3 Mjukvarutestning 

Ett sätt att hitta fel i mjukvara är att tillämpa någon kombination av testtekniker. 

Syftet med användandet av testteknikerna är att hitta eventuella fel som har smugit sig 

in under utvecklingsprocessen. Det här kapitlet ger en beskrivning av vad som 

egentligen menas med testning och ett antal tekniker som kan användas vid testningen 

av mjukvarubaserade system presenteras. 

3.1 Introduktion 

En del av det arbete som utförs för att verifiera och validera mjukvara kan vara att 

genomföra tester. Med verifiering och validering avses här alla de aktiviteter vars mål 

är att mjukvaran ska stämma överrens med de ursprungliga kraven. Syftet med 

verifiering är att uppnå överensstämmelse mellan varje steg i utvecklingskedjan 

medan validering syftar till att påvisa överensstämmelse mellan systemet och 

beställarens förväntningar. Testning kan användas för att stärka både verifiering och 

validering; verifiering eftersom testning innebär en kontroll av systemet gentemot de 

specifikationer som framställts i tidigare faser av utvecklingen och validering genom 

att testerna demonstreras för beställaren som då kan granska huruvida systemet 

motsvarar förväntningarna. 

Verifiering och validering består som tidigare påpekats inte enbart av testning. Ofta 

används begreppet testning bara för aktiviteter som innebär att kod exekveras, s.k. 

dynamisk analys. En nog så viktig del för av verifierings- och valideringsarbetet är 

den statiska analysen, d.v.s. då kod inte exekveras. 

Strukturell 

testning 

Dynamisk analys 

Funktionell 

testning 

Verifiering och validering 

Statistisk testning 

Figur 3-1. Centrala begrepp som används inom mjukvarutestning. 

Statisk analys 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Dynamisk analys – Till den dynamiska analysen hör sådana testtekniker som bygger 

på att kod exekveras under testförfarandet. Framställning av testtekniker i den här 

rapporten behandlar mestadels dynamiska tekniker, varför en ytterligare uppdelning 

gjorts av dessa enligt nedan. 

Strukturell testning – I den strukturella testningen, som även kallas ”white 

box”-testning eller ”glas-box”-testning, testas mjukvaran utifrån systemets 

design. Gedigen kunskap om mjukvarans design och fullständig tillgång till 

källkoden behövs. 

Funktionell testning – I den funktionella testningen, även kallat ”black box”testning, 

betraktas systemet som en svart låda. Det ställs inga krav på hur 

mjukvaran är implementerad eller designad och någon tillgång till källkod är 

inte nödvändig. Tester utförs genom att systemet matas med lämpliga indata 

varpå resulterande utdata granskas. Funktionell testning innebär att ett 

program testas med avseende på vad det kan göra, inte hur det gör det. Den 

funktionella testningen fokuserar således på mjukvarans tilltänkta beteende 

och inte dess inre struktur. 

Statistisk testning – Det primära syftet med den statistiska testningen behöver 

inte vara att hitta nya fel. Istället används den statistiska testningen till att ge 

ett ungefärligt mått på hur många fel som existerar i mjukvaran. 

Statisk analys – Till skillnad mot den dynamiska analysen exekveras inte någon kod 

under den statiska analysen, varför den egentligen inte hör till begreppet testning. 

Arbetsinsatsen i den statiska analysen koncentreras istället till faserna före 

implementationen, d.v.s. kravidentifierings- och designfaserna. Eftersom koden 

implementeras utefter specifikationer som är skrivna under dessa faser finns det 

mycket att vinna om fel som härrör från kravidentifierings- och designfaserna kan 

minimeras. Fel från de tidigare faserna som fortplantas till koden blir väsentligt dyrare 

att åtgärda än vanliga felkodningar. Även om den statiska analysen inte hör till 

gruppen av testtekniker tas den upp här eftersom användningen kan få en så stor 

inverkan på antalet fel i den färdigutvecklade mjukvaran. 

3.1.1 Disposition 

I kapitel 3.2 ges en introduktion till begreppet testning. Här beskrivs bl.a. syftet med 

testningen och de faser som den vanligtvis är uppdelad i. Kapitel 3.3 till 3.7 ger en 

grundlig förklaring till ett antal testtekniker. Dessa kapitel är främst till för den 

intresserade läsaren som vill ha mer fördjupade kunskaper om testtekniker. Kapitlen 

kan också passa bra som uppslagsverk om information söks om en specifik testteknik. 

I Figur 3-2 visas alla de testtekniker som kommer att beskrivas samt uppdelningen 

efter kapitel. Avslutningsvis sammanfattas alla behandlade testtekniker i kapitel 3.8. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Strukturell 

testning 

Control flow testing 

Data flow testing 

Looptestning 

Logikbaserad testning 

Funktionell 

testning 

Domäntestning 

Tillståndstestning 

Logikbaserad testning 

Verifiering och validering 

Syntaxtestning 

Transaction flow testing 


Felinjicering 

Random testing 

Dubbla testlag 


Granskning 

Walkthrough 

Inspektion 

Formella metoder 

Figur 3-2. Uppdelningen av testtekniker enligt den struktur som följs i kapitel 3.3 till 3.7. 

Övriga 

Stresstestning 

Cleanroom testing 

N-version programming 

Modellbaserad verifiering 

De tre grupperna strukturell, funktionell och statistisk testning innefattar dynamiska 

tekniker och förklaras i kapitel 3.3, 3.4 respektive 3.5. Framställningen av den statiska 

analysen är inte lika omfattande som den dynamiska och behöver därför inte delas 

upp i flera grupper. Den redovisas i sin helhet i kapitel 3.6. Det finns ett antal tekniker 

som vi ansåg vara nog viktiga för att beskriva men ändå svåra att placera in i under de 

nämnda rubrikerna. Dessa tekniker beskrivs i kapitel 3.7 under rubriken övriga 

tekniker. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

3.2 Testning som begrepp 

Innan den grundligare beskrivningen av testteknikerna presenteras kan det vara bra att 

få en övergripande bild av begreppet testning. I detta kapitel beskrivs bl.a. syftet med 

testningen, dess begränsningar, testfaserna samt var i utvecklingen som felen uppstår. 

3.2.1 Testningens syfte 

Varför mjukvara ska testas är en fråga som kan resultera i många olika svar beroende 

på vem som svarar. Då testning inte resulterar i några funna fel uppstår ofta glädje och 

många tolkar det som att koden är felfri. Å andra sidan är det bra om fel hittas 

eftersom det först är då de kan åtgärdas. Testning kan således många gånger leda fram 

till ett lite tvetydigt förhållningssätt. Vi vet alla hur lyckan sprider sig i kroppen efter 

en lyckad kompilering. Från programmerarens sida är förhoppningen att inte hitta 

några fel, samtidigt som han faktiskt borde bli glad om felen upptäcks. [Kan93] 

formulerar följande ”A test that reveals a problem is a success. A test that did not 

reveal a problem was a waste of time.” Om förhoppningen enbart är att inte hitta 

några fel torde det bästa vara att inte testa överhuvudtaget [Bei90]. 

Frågan är om testaren gör ett bra eller dåligt jobb då han visar att mjukvaran är full 

med fel. Tyvärr finns det många projektledare som snarare bli irriterade än lättade 

över att felen faktiskt uppmärksammas. Det finns exempel på hur testare har 

förbjudits att testa mjukvara för att företaget på så sätt ska klara av att leverera 

mjukvaran vid överenskommen tidpunkt [Kan93]. I vissa enstaka fall kan ett sådant 

förfarande vara acceptabelt. Det handlar helt enkelt om var ribban ska läggas och hur 

många eventuella fel i mjukvaran som kan accepteras. 

En förutfattad mening är att testning ska visa att det inte finns några fel i mjukvaran. 

Problemet är att det aldrig går att visa att programvara är helt felfri, det är endast 

motsatsen som kan bevisas. För att bevisa att mjukvaran är felfri krävs oändligt 

många testfall, samtidigt krävs det bara ett enda för att påvisa att mjukvaran inte 

fungerar som den ska. Redan år 1972 påpekade Dijkstra att ”program testing can be 

used to show the presence of bugs, but not their absence”. Det är ett påstående som i 

hög grad gäller än idag [Gar99]. 

Syftet med testning borde därför vara att påvisa mjukvarans brister istället för att visa 

att den faktiskt fungerar. Genom testarbete kan fel hittas och åtgärdas, på så sätt höjs 

stegvis kvalitén på mjukvaran. Testning bör således ses som en kvalitetsförhöjande 

åtgärd snarare än att påvisa att mjukvaran är felfri. 

3.2.2 Testningens begränsningar 

I samma stund som mjukvara testas finns en risk att testaren invaggas i en falsk 

säkerhet. För hur kan testaren veta att de testfall som genomlöpts verkligen täcker alla 

fel? Är det överhuvudtaget möjligt att testa mjukvara fullständigt? 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Det finns många olika sätt på vilket mjukvara kan genomlöpas, många varianter på 

indata och många anledningar till att hårdvara kan sluta fungera. För att testa alla fall 

som ett större system kan utsättas för krävs näst intill oändligt många testfall. Redan 

1976 undersökte Myers ett program på 100 kodrader och konstaterade att programmet 

kunde genomlöpas på 10 18 unika sätt. Som jämförelse är universums existens endast 

4·10 17 sekunder. I ett annat av hans exempel hävdar han att ett program på endast 20 

kodrader kan genomlöpas på 10 14 unika sätt. En snabb testare skulle kunna testa dem 

alla på en miljard år [Kan93]. Exemplen bör tas med en nypa salt men visar att även 

mindre program kan genomlöpas på många olika sätt. Lite större program kan bestå 

av många tusen kodrader och att testa alla exekveringsmöjligheter med ovanstående 

fakta i bakhuvudet måste anses vara näst intill omöjligt. 

Det är inte bara mängden testfall som begränsar testningen. Ofta är det svårt att testa 

under realistiska förhållanden eftersom den verkliga miljön kan vara svår att simulera 

i en testmiljö. Exempel på svåra miljöer att testa mjukvara i kan vara kärnkraftverk 

eller flygplan som ännu inte har byggts [Lev95]. 

Mängden testfall och svårigheten att testa i en realistisk miljö till trots är det betydligt 

lättare att förutse hur en van användare brukar systemet än att göra detsamma för 

nybörjare. Ovana användare har en förmåga att belasta programmet på de mest 

underliga sätt. Användarnas beteenden kan också skilja sig radikalt från normal drift 

till onormal. Så fort människan har ett finger med i spelet i form av operatörer eller 

användare av systemet så kan vad som helst hända. 

Eftersom hälften av alla fel kan lokaliseras till de specifikationer som ligger till grund 

för testningen går det inte på något sätt att testa sig till en felfri mjukvara [Lev95]. 

Om specifikationerna, som testerna verifieras mot, innehåller felaktigheter kommer 

dessa att fortplantas i den fortsatta utvecklingen. Gediget arbete måste därför läggas 

ner på att kontrollera specifikationernas korrekthet. Detta statiska analysarbete är som 

tidigare påpekats egentligen inte att betrakta som testning. 

Med dagens testtekniker går det bara till en viss gräns att påvisa mjukvaras felfrihet. 

Litteraturundersökningar visar att de flesta är överens om att gränsen för vad som är 

möjligt att nå med testning går någonstans runt 10 -5 incidenter per timme [Gar99]. 

Ofta är kraven på systemen i de säkerhetskritiska branscherna betydligt större än så. 

För särskilt kritiska delar av ett passagerarflyg av typen Boeing 777 tillåts allvarliga 

incident inträffa högst 10 -9 gånger per timme eller en gång på 100 000 driftår [Lit94]. 

Att testa sig till en sådan felosäkerhet måste anses vara omöjligt. 

Sammanfattningsvis kan det slås fast att mjukvara inte går att testa fullständigt 

eftersom det alltid finns omständigheter som begränsar möjligheten att testa. I och 

med det är testningen i sig alltid förknippad med en viss risk. Bara för att ett antal 

testfall har lyckats betyder det inte att mjukvaran fungerar. Låt oss ytterligare belysa 

detta med ett exempel. Antag att du är ute och fiskar i en sjö, och inte får någon fisk. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Kan du då med säkerhet säga att det inte finns någon fisk i sjön? Nej, inte med 

säkerhet. Möjligen kan du dra slutsatsen att det inte finns så mycket fisk i sjön, eller 

att du har fel bete på kroken (om du testar mjukvara skulle dåligt bete kunna jämföras 

med en ineffektiv testteknik). Om du å andra sidan mot förmodan skulle få en fin fisk 

på kroken är sannolikheten liten att just den fisken är den enda i sjön. Alltså, oavsett 

om du hittar fel eller inte är det i stort sett omöjligt att avgöra hur många ytterligare 

fel som existerar. 

3.2.3 Testningens omfattning 

Om vi förutsätter att det i stort sett är omöjligt att testa och åtgärda mjukvara tills den 

blir helt felfri kan en ny frågeställning ställas. Hur mycket resurser ska läggas ner på 

testningen? 

Antalet funna fel i mjukvaran beror på testningens omfattning. Ju större resurser som 

avsätts för testningen desto större är sannolikheten att felen i mjukvaran hittas. Var 

gränsen ska gå för hur mycket resurser som ska läggas på testningen beror helt och 

hållet på vilka krav som ställs på systemet. 

Testningens omfattning 

Kostnad för testning 

Antal kvarvarande 

fel i mjukvaran 

Figur 3-3. Ju större resurser som läggs på testning desto fler fel hittas. Det gäller att hitta en jämvikt 

mellan kostnad och feltolerans. 

Det är enligt Pressman inte ovanligt att mellan 30 och 40 procent av arbetet i ett 

mjukvaruprojekt läggs ner på testningen. Förhållandet mellan testning och övrigt 

arbete i projektet kan dock variera kraftigt mellan olika projekt. I vissa 

säkerhetskritiska system, där människoliv står på spel, kan kostnader som är kopplade 

till testningen vara tre till fem gånger större än projektets övriga kostnader 

tillsammans [Pre97]. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

3.2.4 Testningens utförare 

Liksom andra personer som skapar något är programmeraren inte så mottaglig för 

negativ kritik utan vill hellre visa att koden är korrekt implementerad och att den 

fungerar som den ska. Om någon oberoende person testar programmerarens kod 

koncentreras testningen istället på att hitta eventuella fel. Syftet med den testningen 

skiljer sig något från då programmeraren själv testar koden. Programmeraren blir 

knappast glad om nya fel upptäcks, men fel kommer antagligen alltid att finnas och 

hittar inte testaren dem kommer troligen användaren att göra det [Pre97]. 

Vem bör då egentligen undersöka om den kod som har producerats verkligen 

uppfyller de krav som ställts? Tre vanliga missuppfattningar kan råda. Inget av dessa 

alternativ är att rekommendera [Pre97]. 

1) Den partiske programmeraren testar inte överhuvudtaget. 

2) Testningen lämnas helt över till en opartisk och utomstående testavdelning. 

3) Den oberoende testavdelningen tar vid först efter implementationen. 

Det har visat sig att det finns mycket att vinna om testningen istället sker i samråd 

mellan programmeraren och andra oberoende testare. 

Programmeraren ska genom testning av sin egen kod visa att de moduler och 

funktioner som produceras verkligen stämmer överens med designspecifikationen. 

Eftersom programmeraren är väl insatt i kodens uppbyggnad kan onödiga tester som 

t.ex. genomlöper programmet på likartat sätt elimineras. Det är viktigt att 

programmeraren är medveten om sin dubbla roll som programmerare och testare. 

Programmeraren försöker göra jobbet på enklast möjliga sätt för att klara av tidsmål 

och budget. Då samma person kliver in i testarens roll ska han istället vara 

misstänksam, fientlig och besatt av att försöka få programmet att krascha [Bei90]. 

Det oberoende testlaget tar oftast vid efter att koden har producerats och ska först och 

främst testa att mjukvarans funktioner tillsammans överensstämmer med kraven. 

Testarna kan då vara oberoende av utvecklingen eftersom de inte behöver ha några 

ingående kunskaper om hur koden är implementerad. Att de inte vet hur koden är 

implementerad är såväl en stor styrka som en stor svaghet. De ej insatta testarna har 

vagare föraningar om vad som är rimligt och utför därför tester som programmerarna 

antagligen aldrig skulle komma på tanken att göra. En fördel med att använda 

oberoende testare är att det är lättare att vara nitisk gentemot någon annans kod. En 

programmerare som testar sin egen kod anser ofta att ett test är lyckat om testfallet 

genomlöps utan några problem. Så borde det inte vara. Som påpekats tidigare bör 

nämligen ett lyckat test avslöja fel [Bei90]. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Följande tabell ger en översiktlig bild över vem som bör vara delaktig i de olika 

teststrategierna [Sco95]. 

Programmerare Oberoende testare 

Statisk analys Kan Kan 

Strukturell testning Bör 

Funktionell testning Bör Bör 

Statistisk testning Kan Bör 

Tabell 3-1. Hur olika teststrategier bör/kan användas av programmerare och oberoende testare. 

3.2.5 Testningens faser 

Generellt kan mjukvaruutveckling delas upp i följande fyra faser; kravidentifiering, 

design, implementation samt en integration- eller testfas. Ofta används någon form av 

V-modell där de fyra faserna delas upp i flera mindre faser, se 

Figur 3-4. 

Kravidentifiering 

Översiktlig design 

Detaljerad design 

Implementationsfas 

Figur 3-4. Mjukvaruutveckling gestaltad i en V-modell. 

Integrationstest 

Modultest 

Systemtest 

I den första fasen, kravidentifieringen, analyseras vad systemet ska göra och en 

kravspecifikation tas fram. Utifrån kravspecifikationen görs en översiktlig designspecifikation 

som beskriver vilka moduler som ska bygga upp systemet samt dessa 

modulers funktionalitet. Den översiktliga designspecifikationen ligger till grund för 

framtagandet av den detaljerade designspecifikationen som beskriver hur varje 

enskild modul ska implementeras i detalj. Implementationsfasen innebär att kod 

skrivs utifrån den detaljerade designspecifikationen. Efter implementationen ska de 

dynamiska testerna ta vid. Testerna brukar delas upp i tre steg; modultester, 

integrationstester och systemtester [Bei90]. Resultatet av testerna kontrolleras mot 

krav- och designspecifikationer; modultest mot detaljerad designspecifikation, 

integrationstest mot översiktlig designspecifikation och systemtest mot 

kravspecifikation. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Modultestning 

En modul är den minsta delen av ett program i mjukvarudesignen. Modulerna testas 

och utvärderas gentemot den detaljerade designspecifikationen. Testningen 

undersöker både modulernas funktion och struktur, men strukturella tester används 

mer än funktionella. Innan modultestningen är klar är det viktigt att modulernas 

gränssnitt testas. Om information inte kan komma in och ut ur modulen på ett korrekt 

sätt går det heller inte att fortsätta med de efterföljande integrationstesterna [Pre97]. 

En enskild modul kan vanligtvis inte köras i sin helhet eftersom den vanligtvis inte 

utgör ett körbart program. För att möjliggöra testning måste s.k. drivers och stubs tas 

fram. En stub ersätter underordnade moduler som måste finnas med för att möjliggöra 

exekvering. Den har samma gränssnitt som den ersatta modulen men är i övrigt 

betydligt mindre komplex. En driver ersätter överordnade moduler och kan t.ex. 

utgöras av ett mainprogram som tar in testfall, utför dessa på modulen och levererar 

resultaten av testerna som utdata [Pre97]. 

Testfall 

Stub 

Figur 3-5. Förfaringssätt vid modultestning. 

Driver 

Modul som 

ska testas 

Resultat 

Integrationstestning 

Genom integration sammanlänkas moduler till större mjukvaruenheter eller hela 

program. Integrationstestning har till syfte att upptäcka huruvida de olika modulerna 

samverkar med varandra i överensstämmelse med den översiktliga 

designspecifikationen. Bara för att modulerna fungerar var för sig är det inte säkert att 

de fungerar tillsammans. Exempel på orsaker till fel kan vara globala datastrukturer 

eller att information går förlorad mellan modulernas gränssnitt [Bei90]. 

Innan integrationstestning kan utföras måste naturligtvis de olika modulerna 

integreras med varandra. Integrationen kan göras enligt olika strategier. Typexemplet 

på en mindre bra men tyvärr vanlig strategi är att integrera alla delarna till ett program 

och därefter påbörja integrationstestningen. Nackdelen med denna strategi är att det 

lätt kan bli rörigt om allt för många fel upptäcks. Strategin medför också svårigheter 

att lokalisera vad som egentligen orsakar felen. Integreringen bör istället ske enligt en 

inkrementell strategi. Det betyder att modulerna integreras i mindre delar och att 

tester utförs på smådelar som sedan kopplas samman till större. Genom ett använda en 

inkrementell integrationsstrategi är det lättare att hitta vilka delar av programmet som 

orsakar felen. Nedan presenteras de två vanligaste inkrementella 

integrationsstrategierna top-down integration och bottom-up integration [Pre97]. 

__________________________________________________________________________________________ 


Stub




___________________________________________________________________________ 

Top-Down Integration 

Top-down integration utgår från toppen av modulkontrollhierarkin, d.v.s. 

mainprogrammet M1 i Figur 3-6. Därifrån byggs programmet upp genom att integrera 

underordnade moduler en i taget, antingen på djupet t.ex. M1-M2-M5-M8 eller på 

bredden t.ex. M1-M2-M3-M4. En underordnad modul som inte integrerats men som 

måste finnas med för att möjliggöra exekveringen ersätts med en stub. 

M7 

Figur 3-6. Top-down integration. 

Bottom-Up Integration 

Bottom-up integration utgår från botten av modulkontrollhierarkin och byggs på 

uppåt. Eftersom utgångspunkten är de mest underordnade modulerna finns inget 

behov av stubs som i top-down integration. Här behövs i stället driver som ersätter 

överordnade moduler. En driver kopplar samman underordnade moduler så att de kan 

testas. 

I Figur 3-7 visas hur en bottom-up integration går till. De underordnade modulerna 

delas upp i två grupper. För att testa grupperna behövs en driver för varje grupp, D1 

respektive D2. Då varje grupp är testad kan grupperna sättas samman under den 

överordnade modulen, M2. Då behövs inte längre D1 och D2. Integrations- och 

testarbetet fortgår på likartat sätt ända tills mainprogrammet i M1 har integrerats. 

M3 

Figur 3-7. Bottom-up integration. 

M1 

M2 M3 M4 

M5 

M8 

D1 

M4 

M6 

__________________________________________________________________________________________ 


M1 

M2 

M5 

D2 

Grupp 1 Grupp 2 

M6




___________________________________________________________________________ 

Det finns både för- och nackdelar med top-down och bottom-up integration. Ofta är 

en fördel för den ena strategin en nackdel för den andra. Den största fördelen med topdown 

integration är att den övergripande strukturen på systemet kan testas tidigt. Den 

största nackdelen är att det krävs mycket arbete med stubs. Största fördelen med 

bottom-up är att det inte behövs några stubs och den största nackdelen är att 

programmet som helhet inte existerar förrän alla moduler kopplats samman. 

Då ytterligare moduler integreras med mjukvaran innebär det att den förändras. Då 

förändringar införs bör regressionstester genomföras, se kapitel 3.7.5, för att 

kontrollera att förändringen inte får oönskade effekter. Om det är många moduler som 

ska sättas samman blir det snabbt ett stort antal regressionstester som ska genomföras. 

Det är därför opraktiskt att testa om alla tester som genomförts på programmet vid 

varje förändring. Det viktiga är att de tester som kan upptäcka eventuellt 

nyintroducerade felaktigheter utförs. Problemet att sortera bort de testfall som är 

överflödiga är allt annat än trivialt [Pre97]. 

Systemtestning 

Under integrationsfasen kopplas modulerna samman till ett program. När programmet 

sedan samverkar med bl.a. användare och hårdvara bildas ett system. Systemtestning 

syftar till att upptäcka skillnader som uppkommer gentemot kravspecifikationen trots 

att modultestningen och integrationstestningen genomlöpts utan fel. Det är först nu 

det går att testa hur väl systemet passar in i den miljö där det ska verka. De tilltänkta 

användarna kan prova systemet och se om det uppfyller deras förväntningar. 

Systemtestning utgörs av övergripande funktionalitets- och prestandatester. 

Säkerhetstester, med vilket menas t.ex. systemets skydd mot intrång, är ytterligare 

något som bör täckas in med systemtester [Bei90]. Eftersom säkerheten även är 

beroende av omgivningarna är säkerhetstester på det färdiga systemet i dess rätta 

miljö en viktig del av systemtestningen. Det sistnämnda ligger dock utanför denna 

rapports omfång. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

3.2.6 Funktionell eller strukturell testning 

Som omnämnts tidigare kan testning utföras från en funktionell eller en strukturell 

utgångspunkt. Funktionell testning innebär att ett program testas med avseende på vad 

det kan göra, inte hur det gör det. Sådana tester är inte möjliga att utföra förrän det 

finns någon exekverbar modul eller program att köra. Därför utförs de funktionella 

testerna vanligtvis i någon av projektets senare faser. Eftersom den funktionella 

testningen inte kräver större kännedom och tillgång till källkoden kan en större del av 

den funktionella testningen läggas ut på oberoende testare. 

Strukturell testning är lite av motsatsen till funktionell testning eftersom den istället 

utgår från kodens struktur och uppbyggnad. Eftersom den strukturella testningen 

anknyter till koden är det lämpligt att testningen ligger i anslutning till skrivandet av 

koden. De strukturella testerna kräver kännedom om kodens struktur och därför utförs 

testerna ofta av programmerarna själva. 


Modultest 

Integrationstest Systemtest 

Strukturella tester Funktionella tester 

Figur 3-8. Skeden i projektet då strukturella och funktionella tester bör tillämpas. 

Det kan ibland vara svårt att avgöra vad som ska kategoriseras som funktionell 

respektive strukturell testning. En orsak är att mjukvarusystem ofta byggs i lager 

[Bei90]. Användaren ser bara det yttersta lagret som består av funktionaliteten. Det 

näst yttersta lagret har ur användarens synvinkel mindre att göra med funktionalitet 

och mer att göra med programmets struktur. Om däremot en programmerare som 

bygger det yttersta lagret betraktar det näst yttersta använder han sig av funktioner 

som finns där. För honom består då även det näst yttersta lagret av funktionalitet. Så 

beroende på ur vilken synvinkel programmet betraktas kan ett lager anses vara 

antingen funktionellt eller strukturellt. 

Användandet av funktionella testtekniker ersätter inte nyttan med strukturella tester. 

Strukturella och funktionella testtekniker har nämligen olika för och nackdelar. De är 

olika bra på att hitta olika typer av fel. Strukturell testning tenderar till att upptäcka fel 

som härstammar från själva kodskrivandet medan funktionella tester tenderar att 

upptäcka fel som uppstår då specifikationer tolkats på ett felaktigt sätt. För att få en så 

heltäckande testning som möjligt bör både strukturell och funktionell testning 

genomföras [Per95]. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

3.2.7 Statisk eller dynamisk analys 

Det har visats att fel som kommer från de tidiga faserna, d.v.s. innan 

implementationsfasen, ofta är av allvarligare karaktär än fel som uppkommer i ett 

senare skede av utvecklingen [Jon96]. En studie av IBM visar att det finns mycket att 

vinna om felen hittas och åtgärdas i ett tidigt skede av projektet. Om fel från 

kravidentifieringsfasen ska rättas till i utvecklingens senare faser blir kostnaderna 

betydligt större än om samma fel hade åtgärdats redan då de uppstod. För att 

lokalisera fel som smugit sig in i utvecklingen innan implementationsfasen bör någon 

slags statisk analys tillämpas. 

Testning är en dynamisk aktivitet som innebär att kod exekveras. Den dynamiska 

analysen bör föregås av en statisk analys som innebär att krav och 

designspecifikationer undersöks och analyseras. Den statiska analysen utförs 

vanligtvis före implementationen medan dynamiska aktiviteter som testning utförs 

efter implementationen. 

Statisk analys Dynamisk analys 






Modultest 

Systemtest 

Figur 3-9. Figuren visar vilka faser som lämpar sig för verifiering med statisk analys respektive den 

dynamisk aktiviteten testning. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

I Figur 3-10 presenteras en del av studien från IBM som visar att kostnaden för 

testningen kan skäras ner till en tredjedel om arbete läggs ner på att åtgärda felen 

innan koden har producerats [Per95]. Siffror och resultat i exemplet ska inte tas som 

exakta. Poängen är att åskådliggöra den statiska analysens betydelse och fördelar. 

Testning 

utan statisk analys 

Total 

testkostnad 

Återstående 

antal fel 

0 20 

0 40 

0 60 

480 12 

1680 0 


20 fel 

ÅK = 1 

ÅK = 1 

ÅK = 1 

ÅK = 10 

ÅK = 100 

Design 

20 fel 

Implementation 

20 fel 

Test 

80% felreduktion 

Produktion 

0 fel 

Testning 

med statisk analys 

Återstående 

antal fel 

Total 

testkostnad 

10 10 

15 25 

18 42 

4 182 

0 582 

ÅK = Åtgärdskostnad 

Figur 3-10. Undersökningen från IBM visar att kostnaden för testning kan skäras ner till en tredjedel 

om den dynamiska analysen föregås av en statisk analys. 

Studien visar att vid utvecklingen av ett 1000 kodraders program uppstår 60 fel i de 

tre första faserna. Då statisk analys tillämpas kan hälften av dessa fel lokaliseras och 

åtgärdas redan i de faser där de uppkommer. På så sätt återstår endast 18 av de 60 

felen efter implementationen. Testningen efter implementationen hittar 80 procent av 

de kvarvarande felen. Dessa fel kostar tio gånger mer att åtgärda än om de istället 

hade hittats och åtgärdats tidigare i projektet. Felen som hittas först när programmet 

finns på marknaden kostar hundra gånger mer att åtgärda. Sammanfattningsvis 

konstateras att kostnaderna kan minska avsevärt om statisk analys tillämpas innan 

koden har producerats och de traditionella testerna tar vid. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Ur ett kostnadsperspektiv är det bra om felen hittas så fort som möjligt efter att de 

uppkommit. Idealfallet vore därför att alla fel som uppkom innan kodningen hittades 

via den statiska analysen medan alla fel som uppkommer under själva kodningen 

hittas via den dynamiska analysen. Exemplet ovan belyser fördelar som kan uppnås 

genom att tillämpa statisk analys. Det betyder dock inte att statisk analys kan ersätta 

den dynamiska. I exemplet, liksom i verkligheten, uppkommer det fel även efter de 

faser som vanligtvis berörs av den statiska analysen. Kontentan är alltså att både 

statisk och dynamisk analys har sina fördelar, och bäst resultat erhålls genom att 

använda en kombination av de två. 

3.2.8 Jämförelse av fel i hård- och mjukvara 

Om upptäckta fel rättas till under tidens gång kan det kännas naturligt att tro att 

felintensiteten i ett system minskar med tiden. Antagandet kan dock visa sig vara 

något förhastat. I och med att systemet antas vara näst intill felfritt så används inte 

lika mycket resurser till att förebygga risker och dess konsekvenser då nya versioner 

av systemet utvecklas. En oberättigad ökad tilltro till systemet kan också medföra att 

säkerhetsmarginaler minimeras i tron att de är överflödiga [Lev95]. 

Nedan följer en diskussion angående felintensitet som funktion av tiden för hård- och 

mjukvarusystem. Denna rapport kommer att fokusera på mjukvarusystem. 

Hårdvaruavsnittet finns med för att ge en förståelse för begreppet felintensitet samt 

för att påvisa skillnaden mellan hård- och mjukvara. 

Hårdvara 

Då ny hårdvara utvecklas brukar den vara behäftad med en hel del fel som härrör från 

design- och produktionsfel. Designfelen kan förhoppningsvis justeras utan att alltför 

många nya fel tillkommer. Produktionsfelen reduceras allteftersom 

produktionsapparaten finjusteras. Med tiden minskas således felintensiteten. Men i 

takt med att hårdvaran åldras börjar felintensiteten återigen öka, vilket orsakar den 

s.k. badkarskurvan, se Figur 3-11 nedan [Pre97]. Anledningen till att hårdvaran 

försämras med tiden kan ha flera olika orsaker som t.ex. att materialet åldras eller att 

hårdvaran på annat sätt slits ut. 

Felintensitet 

Figur 3-11. Kurvan, som ofta benämns badkarskurvan, beskriver felintensitet för hårdvara från 

nyutveckling tills den slits ut. 

__________________________________________________________________________________________ 


Tid




___________________________________________________________________________ 

Mjukvara 

Felintensiteten för nyutvecklad mjukvara antar i början ett liknande utseende som för 

nyutvecklad hårdvara. Ofta är även ny mjukvara behäftad med fel orsakade från 

design- och implementationsarbetet. I och med att felen åtgärdas minskas 

felintensiteten på samma sätt som för hårdvaran. I idealfallet bör därför felintensiteten 

för mjukvara fortsätta att minska med tiden, då fler och fler fel rättas till [Pre97]. 

En klar skillnad mellan hård- och mjukvara är att mjukvaran inte åldras på samma sätt 

som hårdvaran. Mjukvara slits inte ut eller blir sämre bara för att den blir åldersstigen. 

Det betyder dock inte att idealfallet i Figur 3-12 är förenligt med verkligheten. Ett 

vanligt dilemma är att nya fel uppstår då gamla rättas till. För varje ny version av 

koden kan felintensiteten öka istället för att minska. Om systemet är komplext kan ett 

åtgärdat fel ibland resultera i en uppsjö nya fel, vilket medför att det i vissa fall kan 

vara klokt att avstå från att rätta till fel. 

Felintensitet 

Idealfallet 

Verklig 

felintensitet 

Större förändring 

av mjukvaran 

Figur 3-12. Felintensitet för mjukvara som funktion av tiden, dels för idealfallet och dels för 

verkligheten [Pre97]. 

Om mjukvaran har använts under lång tid utan att några incidenter inträffat är det lätt 

att tro att inga incidenter heller kommer att inträffa i framtiden. Det är lätt att invagga 

sig i falsk säkerhet då mjukvaran har använts under en lång tid utan modifieringar. De 

yttre förutsättningarna kan däremot förändrats, t.ex. mängden data som ska passera 

genom systemet. Resultatet kan bli att systemet antar nya tillstånd som tidigare inte 

förekommit och därmed ökar sannolikheten för att ett fel uppträder. Observera att det 

inte betyder att felintensiteten i koden ökar, utan istället en ökad sannolikhet för att fel 

kommer att exekveras. 

__________________________________________________________________________________________ 


Tid




___________________________________________________________________________ 

3.2.9 Orsaker till att incidenter inträffar 

En incident kan uppstå av många olika anledningar. Enligt [Joh96] kan incidenter 

huvudsakligen kopplas till följande fyra områden. 

1. Fel i kravspecifikation 

Det är viktigt att det redan från början inte råder några missförstånd mellan kund 

och leverantör. Om kravspecifikationen inte speglar kundens egentliga önskemål 

finns en stor risk att leverantören utvecklar något som kunden inte förväntar sig. 

Leverantören kan stringent följa specifikationerna, och tro att de utvecklar något 

som kunden efterfrågar, när kunden egentligen avsåg något annat. Eftersom det i 

efterhand är mycket kostsamt att gå tillbaka i utvecklingsarbetet är det viktigt att 

åtgärda sådana fel i ett tidigt skede av utvecklingen. 

2. Fel från design- och implementationsfasen 

Majoriteten av felen kommer från design- eller implementationsfasen. Felen kan 

härstamma både från människa eller ett verktyg, t.ex. en kompilator. 

3. Fel i hårdvara 

Till all mjukvara finns någon hårdvara kopplad. Fel kan existera i hårdvaran men 

kan också uppstå om den utsätts för stora påfrestningar. 

4. Fel från operatören 

Eftersom system i slutändan styrs av människan kan också fel uppkomma då 

operatören ger otillåtna kommandon eller på annat sätt utgör fara för systemet. 

Enligt [Hei97] härstammar ungefär hälften av alla fel från arbetet innan 

implementationen. Nedanstående tabell ger en vägledning över hur stor del av felen 

som uppkommer i olika delar av mjukvaruutvecklingen. 

Var felen uppkommer Andel av totala antalet fel 

Arbetet med kravspecifikation 20 % 

Designarbetet 30 % 

Implementationsarbetet 35 % 

Dåligt rättade fel 10 % 

Felaktig dokumentation 5 % 

Tabell 3-2. Felens uppkomst i olika skeden av projektet [Hei97]. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

3.3 Strukturell testning 

Under implementationsfasen programmeras och testas moduler var för sig. Då är 

testningen nära anknuten till programmeringen och görs därför lämpligast av 

programmeraren själv. Många av de testtekniker som används i det här skedet av 

utvecklingen har en sak gemensamt, de fokuserar på systemets inre struktur och inte 

så mycket på modulens tilltänkta funktion. Sådana testtekniker brukar grupperas 

under begreppet strukturell testning, som även kallas ”white box”-testning eller ”glas 

box”-testning. Istället för att fokusera på funktionens in- och utdata undersöks bl.a. 

informationsflödet genom modulen och hur data förändras längs vägen genom 

programmet. 

Det finns vissa fel som med stor sannolikhet enbart kan hittas med de strukturella 

testteknikerna. Att ersätta de strukturella testteknikerna med kombinationer av andra 

tekniker är därför inte möjligt [Sco95]. 

Styrkor 

En av styrkorna med strukturell testning är att delar av programmet kan testas var för 

sig direkt efter implementering. Om testerna visar på fel kan koden modifieras varpå 

testet genomlöps ytterligare en gång. Genom ett iterativt förfarande kan 

programmeraren sänka felintensiteten till en acceptabel nivå. 

Ett problem med de flesta testteknikerna är svårigheten att skapa en uppfattning om 

hur stor del av koden som verkligen har testats. Testaren kan verifiera att tester 

lyckas, men vet ändå ingenting om hur många testfall som måste skrivas för att 

testningen ska bli i stort sett heltäckande. De strukturella testteknikerna är däremot 

uppbyggda på ett sådant sätt att testaren kan få en uppfattning om hur stor del av 

programrymden som har testats. Tester kan t.ex. utföras som exekverar samtliga 

kodrader i programmet. 

Svagheter 

En svaghet med strukturella testtekniker är att de kräver tillgång till källkoden för att 

testfall ska kunna skrivas. Eftersom testerna är så kodnära måste testfallen skrivas om 

så fort koden förändras. De strukturella testteknikerna ställer också höga krav på att 

testaren är väl insatt i programstrukturen [Kan93]. Det är därför ofta svårt för 

oberoende testgrupper att genomföra strukturella tester på ett effektivt sätt, testerna 

utförs istället i de flesta fall av programmerarna själva. 

Disposition 

I det här kapitlet ges först en beskrivning av den terminologi som används för de 

strukturella testteknikerna. Terminologin behandlar huvudsakligen flödesgrafer och 

dess komponenter. Ett kort exempel på ett program med tillhörande flödesgraf 

beskrivs också. Exemplet tillämpas senare på ett flertal av testteknikerna i kapitlet. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Följande testtekniker kommer att presenteras. 

• Control flow testing 

- Nodtestning 

- Grentestning 

- Path testing 

• Data flow testing 

• Villkor/Logiktestning 

• Looptestning 

3.3.1 Flödesterminologi 

Nedan presenteras några termer som används i den kommande framställningen. Hur 

termerna representeras i flödesscheman visas med figurer. Kapitlet avslutas med ett 

komplett flödesschema för ett litet program. Med flöde menas de kodavsnitt som 

exekveras då ett program eller en modul körs. 

En nod är en sekvens av programmet som inte innehåller några förgreningar av flödet. 

Det innebär att om en av sekvensens instruktioner exekveras så exekveras även 

samtliga resterande instruktioner i sekvensen. En sekvens har således en början och 

ett slut, däremellan finns inga möjligheter för några vägval. En sekvensen kan bestå 

av en eller flera instruktioner. 

Figur 3-13. Nod. 

Vid en gren finns det olika alternativ för flödet. Grenen kan vara uppbygd av en ifsats 

med enbart två alternativa vägar, men kan också bestå av ytterligare 

valmöjligheter. 

Figur 3-14. Gren. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Att flödet förenas efter en uppdelning benämns sammanflöde. 

Figur 3-15. Sammanflöde. 

Nedan följer ett exempel hämtat från [Sco95]. I Figur 3-16 visas koden för ett mindre 

program. I Figur 3-17 finns en graf som visar flödet genom programmet. 

Figur 3-16. Exempel på ett program. 

En länk är kopplingen mellan två noder. Ett segment är en sekvens av ett antal länkar 

och noder. I Figur 3-17 kan flödet genom noderna 2, 3, 4, 6 och 7 symbolisera ett 

segment. En path eller väg är ett av de möjliga segmenten som sträcker sig från början 

till slutet av modulen. Om någon av noderna genomlöps mer än en gång innehåller 

vägen en loop. Ett exempel på en väg med en loop är 1-2-3-4-6-2-3-5-6-7-8-9-11. 

Början 

Figur 3-17. Flödesgraf till program i Figur 3-16. 

Begin module 1 

L2: x = x +1 2 

y = 7 

L3: if z < 4 3 

then x = 2 * x 4 

else x = x – 1 5 

if z = 0 then go to L2 6 

if y = x – z then go to L3 7 

if z = 2 * z 8 

then y = y – 1 9 

w = 2 * x 

else if z < 2 then go to L2 10 

1 2 3 

6 

End module 11 

4 

5 

__________________________________________________________________________________________ 


7 

8 

10 

Slut 

9 11




___________________________________________________________________________ 

3.3.2 Control Flow Testing (Path Testing) 

Control flow testing har använts på IBM i över tre decennier och är den äldsta av alla 

strukturella testtekniker [Bei90]. Testtekniken baseras på att ett antal lämpliga 

testvägar väljs genom programmet. Förhoppningen är att kombinationen av testvägar 

ska påvisa om det finns några fel i programmodulen som har sitt ursprung i flödet. 

Målsättningen är att testa så många vägar genom programmodulerna att alla möjliga 

fel, som kan härröras till flödet, upptäcks. Om testerna behandlar alla tänkbara 

varianter sägs att fullständig täckning råder. Enligt [Bei90] finns det tre olika nivåer 

av flödestestning. 

1. Nodtäckning (P1) – Fullständig nodtäckning råder då instruktionerna i samtliga 

noder exekveras. Fullständig nodtäckning innebär att alla noder genomlöps. 

Eftersom samtliga noder i Figur 3-17 kan genomlöpas utan att alla segment testas 

(det är till exempel möjligt att testa alla noder utan att länkarna 10-2 och 7-3 

berörs) är nodtäckning den svagaste av de tre nivåerna. 

2. Grentäckning (Pn) – Fullständig grentäckning råder då alla möjliga grenar med 

tillhörande instruktioner genomlöps åtminstone en gång. 

3. Pathtäckning (P∞) – För att nå fullständig pathtäckning måste samtliga vägar från 

början till slutet av modulen genomlöpas. Alla noder, alla möjliga grenar och alla 

loopar (se kapitel 3.3.4) måste exekveras. Fullständig pathtäckning innefattar 

därmed grentäckning och nodtäckning. Pathtäckning är den starkaste nivån vad 

gäller control flow testing. 

Även för mindre moduler finns det ofta många möjliga vägar genom modulen. Varje 

enkel gren fördubblar antalet vägar och varje loop multiplicerar antalet möjliga vägar 

med det antal iterationer som loopen kan åsamka. För komplexa system är det därför i 

stort sett omöjligt att testa alla vägar genom programmet. Att uppnå 100% 

pathtäckning är mer en teoretisk förhoppning snarare än ett realistiskt mål. Det bör 

påpekas att även om testaren mot förmodan skulle lyckas testa alla tänkbara vägar är 

det långt ifrån säkert att modulen är felfri. Fel kan givetvis bero av många andra 

orsaker än fel i flödesvägar. 

Syftet är att hitta fel som är kopplade till de olika vägar som kan genomlöpas då 

programmet körs. Det kan handla om en felsyftning till en gren eller att en if-sats inte 

är uppbyggd som det var tänkt, t.ex. ”IF A is true THEN DO X ELSE DO Y” istället 

för ”IF A is false THEN…” [Bei90]. Då pathtesting tillämpas förutsätts att 

specifikationer är korrekta och att variabler är korrekt definierade. Det förutsätts att 

inga andra fel finns än de som härrör till själva flödet. Flera strukturella 

programmeringsspråk har inbyggda tester för att hitta fel som är kopplade till flödet. 

För sådana språk är vinsten med användandet av pathtesting något mindre än då äldre 

programmeringsspråk, som tillexempel COBOL och FORTRAN, används. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Pathtesting är en testteknik som först och främst används på modulnivå och är inte en 

testteknik som lämpar sig för systemtestning. Tekniken används som regel av 

programmeraren själv innan den eventuellt fortsatta testningen tas över av någon 

testavdelning. För att kunna använda tekniken måste testaren ha fullständig 

information om programmets struktur, d.v.s. ha tillgång till programmets källkod. För 

programmeraren är pathtesting många gånger en av de grundläggande testteknikerna, 

men det är bra om även systemtestare har en viss kunskap om pathtesting eftersom 

denna testteknik ligger till grund för många andra tekniker [Bei90]. 

Vilka vägar ska väljas 

Nedanstående exempel kan vara ganska tungrott och bör främst läsas av den som är 

ute efter en mer detaljerad förståelse för tillvägagångssätt för control flow testing. 

Att testa alla möjliga vägar i ett komplext system är knappast realistiskt. I många 

organisationer och standarder förordas därför endast nodtäckning och grentäckning. 

Som tidigare påpekats innebär inte fullständig nod- och grentäckning att pathtäckning 

råder. 

Det finns många olika tillvägagångssätt då antalet testvägar ska väljas. Exemplet i 

Tabell 3-3, som bygger på programmet i Figur 3-16 nedan med tillhörande flödesgraf 

i Figur 3-17, ska påvisa att de valda vägarna medför nod- och grentäckning. 

Tillvägagångssättet går ut på att börja med den första noden med den kortaste 

tänkbara vägen. Därefter följer nästkommande nod med eventuella testvägar som 

ännu inte behandlats. 

• Börja i nod 1 med den enklaste vägen från början till slut. 

• Fortsätt med den första grenen i nod 3. Två testvägar är möjliga. Den ena 

testvägen har dock redan behandlats under föregående punkt, därför stryks den. 

• Fortsätt på samma sätt med grenarna i nod 6, 7 och 10. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Grenar 

Processlänkar 

Vägar 

1,2,3,4,6,7, 

8,9,11 

1,2,3,5,6,7, 

8,9,11 

1,2,3,4,6,2, 

3,4,6,7,8,9, 

11 

1,2,3,4,6,7, 

3,4,6,7,8,9, 

11 

1,2,3,4,6,7, 

8,10,2,3,4,6, 

7,8,9,11 

1,2,3,4,6,7, 

8,10,11 

3 3-4 3-5 3-4 3-4 3-4 3-4 

6 6-7 6-7 6-2, 6-7 6-7, 6-7 6-7, 6-7 6-7 

7 7-8 7-8 7-8 7-3, 7-8 7-8, 7-8 7-8 

8 8-9 6-7 8-9 8-9 8-10, 8-9 8-10 

10 10-2 10-11 

1-2 * * * * * * 

2-3 * * ** * ** * 

3-4 * ** ** ** * 

3-5 * 

4-6 * ** ** ** * 

5-6 * 

6-2 * 

6-7 * * * ** ** * 

7-3 * 

7-8 * * * * ** * 

8-9 * * * * * 

8-10 * * 

9-11 * * * * * 

10-2 * 

10-11 * 

Tabell 3-3. Testvägar som ska påvisa nod- och grentäckning till flödesgrafen i Figur 3-17. 

För att försäkra sig om att det råder fullständig nod- och grentäckning ska tabellen 

uppfylla två kriterier. 

1. Fullständig nodtäckning uppnås av att alla noder exekveras. Det innebär att alla 

noder finns med i raden för vägar. 

2. Om alla tänkbara länkar genomlöps kommer även alla grenalternativ att 

genomlöpas. I tabellen motsvaras grentäckning av att det finns åtminstone en 

markering för samtliga processlänkar. 

Tabell 3-3 visar att de valda testvägarna uppfyllar både nod- och grentäckning. 

Det går ofta att optimera antalet testvägar. I exemplet ovan ser vi att den första 

testvägen spelar ut sin roll eftersom samtliga grenar och länkar i den testvägen 

återfinns i någon av de andra testvägarna. Även det andra testfallet skulle med enkla 

modifikationer kunna elimineras. För det behandlade exemplet skulle det faktiskt 

räcka med enbart två testvägar om dessa innehåller loopar som medför att alla noder 

och grenar genomlöps. Det finns dock risker med att optimera för mycket, testvägarna 

blir ofta ologiska och svåra att följa. Det är ofta värt att lägga ner lite extra tid på att 

göra fler enkla testvägar än några få komplexa [Bei90]. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

3.3.3 Data Flow Testing 

Data flow testing bygger liksom control flow testing på att lämpliga flödesvägar väljs 

genom programmet. Data flow testing fokuserar på var och hur data förändras längs 

den utvalda vägen. Tekniken är ett bra komplement till control flow testing då 

målsättningen är att höja nod- och grentäckning närmare en fullständig pathtäckning 

[Bei90]. I moderna programmeringsspråk finns det vanligtvis en viss funktionalitet 

inbyggd för att automatiskt hitta fel i dataflödet. 

Rapp och Meyuker [Rap82] motiverade en användning av data flow testing på 

följande sätt: “It is our belief that, just as one would not feel confident about a 

program without executing every statement in it as part of some test, one should not 

feel confident about a program without having seen the effect of using the value 

produced by each and every computation.” 

En förutsättning för att resultatet från data flow testing ska bli pålitligt är att 

flödesvägarna är korrekt valda. Om det finns luckor och tveksamheter i flödesvägarna 

fortlever tveksamheterna i data flow testningens resultat. Ett påvisat fel i testningen 

kan t.ex. bero på att data inte är åtkomligt när de ska eller att data har använts på ett 

felaktigt sätt. 

Dataobjekt kan antingen skapas, förstöras eller användas. Nedan följer en tabell med 

definitioner och förklaringar till de tre begreppen. 

Beteckning Betydelse Förklaring 

S Skapas Ett objekt skapas eller definieras när det används i en 

deklaration eller när det skrivs till vänster om ett lika 

med-tecken, t.ex. x = 17 där x definieras som 17. Att 

skapa något kan också innebära att en fil har öppnats 

eller att någonting har lagrats på en stack. 

F Förstöras Att ett objekt förstörs kan t.ex. innebära att det inte 

längre är åtkomligt, att det tagits bort eller att en fil har 

stängts. 

A Användas En variabel kan användas i beräkningar när den står till 

höger om ett lika med-tecken, som en pekare eller då 

en fil skrivs eller läses. Den kan också användas som 

ett predikat, t.ex. IF A




___________________________________________________________________________ 

ss Troligen ingen skada, men varför definiera ett objekt två gånger i följd? 

sf Troligen ett fel. Varför skapa objektet och förstöra det innan det använts? 

sa Acceptabelt. 

fs Acceptabelt. 

ff Det blir troligen ingen skada av att ta bort ett objekt två gånger. Anledningen till 

att det görs kan dock ifrågasättas. 

fa Ett fel. Det går inte att använda ett objekt som inte längre finns. 

as Troligen inte ett fel. Det är ofta möjligt att definiera ett objekt på nytt. 

af Acceptabelt. 

aa Acceptabelt. 

Även sex enkla sekvenser förekommer. Sekvenserna är uppbygga med någon av de 

tre definitionerna samt ett bindestreck som symboliserar att det är första eller sista 

gången objektet berörs längs vägen. De sex enkla sekvenserna är enligt följande: 

-s Acceptabelt. Det är första gången objektet skapas längs vägen. 

-f Möjligt fel eftersom ett objekt som inte är definierat längs vägen tas bort. Om 

objektet är globalt, d.v.s. om det är definierat utanför modulen, kan det dock 

vara acceptabelt. 

-a Möjligt fel. Dock acceptabelt om objektet är globalt och tidigare definierat. 

s- Möjligt fel. Ett objekt skapas utan att användas. Det kan dock vara acceptabelt 

om det är ett globalt objekt som används av andra funktioner. 

f- Acceptabelt. Det sista som görs längs vägen är att ta bort objektet. 

a- Möjligt fel. Objektet används utan att förstöras längs vägen. Det är dock 

acceptabelt om objektet används i andra funktioner. 

De dubbla och enkla sekvenserna kan tillsammans representera alla möjliga 

dataflöden. Då de enkla sekvenserna inte bildar något egentligt dataflöde kan det 

ifrågasättas om tekniken bör räknas till data flow testing. Till skillnad från de dubbla 

sekvenserna berör de enkla ofta flera moduler varför det snarare är ett slags 

integrationstest [Bei90]. 

Ett exempel 

Vi återgår till programmet i Figur 3-16 för att ge ett exempel. Variabeln x berörs på 

något sätt i noderna 2, 4, 5, 7 och 9. Vi föreställer oss att vägen genom modulen i 

Figur 3-17 är 1-2-3-4-6-7-8-9-11. Den totala sekvensen blir då ”asasaa”. De två första 

bokstäverna i sekvensen ”as” kommer av att i nod 2 används variabeln x för att 

definiera om sig själv. På samma sätt uppkommer sekvensen ”as” i nod 4. Nod 7 och 

9 orsakar sedan varsina respektive ”a”-tecken. Notera att om x är en lokal variabel så 

medför det ett fel eftersom variabeln förutsätts vara definierad utanför den behandlade 

modulen. I övrigt finns det inga kombinationer av den totala sekvensen som är 

uppenbart felaktiga. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Olika nivåer av data flow testing 

Liksom för control flow testing, där pathtäckning är den starkaste nivån, finns olika 

nivåer för data flow testing. Den starkaste nivån testar samtliga vägar för samtliga 

definitioner för samtliga variabler och för samtliga användningsområden. Det säger 

sig självt att det blir många varianter. En strategi som ofta används är att testa 

åtminstone en väg från varje definition till varje användning av variabeln som kan 

kopplas till den definitionen. Ytterligare nivåer som är svagare än de två ovan 

existerar. 

Statisk eller dynamisk data flow 

Data flow testing kan sägas vara antingen en statisk- eller dynamisk analys. Med 

statisk analys, till skillnad från dynamisk analys, menas att källkoden analyseras utan 

att exekveras. I vissa fall kan den statiska analysen byggas in i 

programmeringsspråken så att onödiga fel undviks. Sekvenser som -a och fa kan då 

hittas automatiskt innan sekvensen exekveras. 

3.3.4 Looptestning 

En loop uppstår när en nod exekveras flera gånger. Det finns fyra kategorier av 

loopar: enkla, omslutna, efterföljande och ostrukturerade [Pre97]. 

enkel loop omsluten loop efterföljande loop ostrukturerad loop 

Figur 3-18. Fyra olika typer av loopar. 

Då loopar testas antas liksom vid pathtesting att fel enbart existerar i looparnas flöde. 

Det förutsätts att specifikationer är korrekta och att variabler är korrekt definierade 

samt att inte några beräkningsfel existerar. Fel i loopar brukar uppstå runt minvärdet 

och maxvärdet av de antal iterationer som är möjliga [Sco95]. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Enkel loop 

Följande tester bör göras för enkla loopar, där n är maximala antalet itterationer 

[pre97]. 

1. Hoppa över loopen. 

2. En itteration genom loopen. 

3. Två itterationer genom loopen. 

4. m itterationer genom loopen, där m < n. 

5. n – 1, n, n + 1 itterationer genom loopen. 

Omsluten loop 

Då en omsluten loop ska testas kan testaren utgå från de teststeg som presenterades 

för den enkla loopen. Antalet tester kommer att öka exponentiellt med antalet loopar 

då jämförelsen görs med en enkel loop. [Bei90] föreslår följande arbetsgång. 

1. Börja med att göra tester för den innersta loopen. Testerna kan vara uppbyggda på 

liknande sätt som för den enkla loopen. Övriga loopar sätts till sitt minvärde. 

2. Arbeta utåt och gör tester för nästkommande loop. Sätt övriga loopar till deras 

respektive minvärden. 

3. Arbeta utåt tills alla loopar har testats. 

Efterföljande loop 

Efterföljande loopar är något mellanting mellan enkla loopar och omslutna loopar. 

Om de efterföljande looparna är oberoende av varandra kan de testas på liknande sätt 

som en enkel loop. Om de däremot beror av vartandra måste ett liknande förfarande 

som för de omslutna looparna genomföras. 

Ostrukturerad loop 

En loop blir ostrukturerad då den t.ex. hoppar in mitt i en annan loop. För att testa en 

ostrukturerad loop krävs det i regel alldeles för många testfall för att de ska vara 

igenomförbara. Sådana loopar ska därför om möjligt undvikas [Sco95]. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

3.3.5 Logikbaserad testning (villkorstestning) 

Logikbaserad testning kan klassas som både en strukturell- och funktionell testteknik. 

Den är strukturell om testfallen bygger på programmets design och funktionell om 

testfallen är uppbyggda efter de krav som ställs på systemet i specifikationer. För 

funktionell logikbaserad testning, se kapitel 3.4.3. 

Strukturell logikbaserad testning, här även kallat villkorstestning, är ett sätt att 

designa testfall som verifierar de logiska villkoren i en programmodul. En fördel med 

villkorstestning är att det relativt lätt går att uppskatta hur många testfall som krävs 

för att testa villkoren. Det är en stor fördel eftersom det då går att få en uppfattning 

om hur stor del av programmet som har testats. När t.ex. path testing används är det 

väldigt svårt att göra en sådan bedömning eftersom det är så svårt att uppskata alla 

möjliga vägar genom programmet. 

Villkoren kan antingen vara av enkel eller sammansatt karaktär. Enkla villkor består 

av en boolsk operator (t.ex. OCH, ELLER) eller en relationsoperator (t.ex. >, ≤, ═). 

Sammansatta villkor är uppbyggda av två eller flera enkla villkor, boolska uttryck och 

parenteser. 

Fel kopplade till villkor kan enligt [Pre97] och [Bei90] bero av följande 

• Boolsk operator 

• Boolsk variabel 

• Boolsk parentes 

• Relationsoperator 

• Fel operand används, t.ex. A > X istället för A > Z. 

• Processen längs den interna väg som leder till villkoret är felaktig. 

När det gäller de två sista punkterna lämpar sig data flow testing bättre, se kapitel 

3.3.3. 

En relativt enkel nivå av villkorstestning förespråkar att alla rimliga varianter samt att 

varje enkelt villkor testas minst en gång. Paralleller kan dras till begreppet fullständig 

täckning som introducerades under kapitlet control flow testing, vilket innebär att det 

ovanstående exemplet motsvaras av fullständig grentäckning. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

3.4 Funktionell testning 

Funktionell testning går ut på att funktionaliteten hos mjukvaran testas gentemot de 

funktionella krav som ställs i krav- och designspecifikationer. Då funktionell testning, 

som också kallas ”black-box”-testning, utförs på mjukvara kan programmet liknas vid 

en svart låda. Olika värden matas in i den svarta lådan och utdatan kontrolleras 

huruvida den överensstämmer med specifikationer. Det som undersöks med 

funktionell testning är alltså inte hur programmet är designat och implementerat, utan 

istället om programmet kan utföra rätt saker. 

Funktionell testning innefattar inte bara tester för att verifiera korrekta inmatningar. 

Även s.k. negativ testning räknas till de funktionella testerna. Den negativa testningen 

undersöker att felaktiga inmatningar inte accepteras av systemet. 

För att funktionaliteten ska kunna testas måste programmet vara körbart vilket i sin 

tur kan innebära att hela programmet måste vara färdigimplementerat. Därför lämpar 

sig användandet av funktionell testning framförallt i senare delar av 

implementationsfasen. I vissa fall kan dock funktionell testning även användas för att 

testa enskilda moduler, vilket då kan göras innan programmet är färdigimplementerat 

[Sco95]. 

Styrkor 

Många av fördelarna med funktionell testning kan härledas till att koden inte behöver 

vara bekant för testaren. Den tilltänkta användaren av mjukvaran är troligen enbart 

intresserad av programmets funktionalitet och inte hur det är implementerat. 

Funktionell testning utförs alltså ur användarens perspektiv, vilket möjliggör för 

användarna att vara med och skapa testfall utifrån sina krav på mjukvaran [Hei97]. 

Dessa tester lämpar sig också väl som acceptanstester. Ytterligare en fördel med att 

testningen genomförs utan kännedom om implementationen är att oberoende testare 

kan stå för utförandet. 

Funktionella tester kan användas för att testa flera egenskaper hos mjukvara, t.ex. 

noggrannheten i mjukvarans resultat, prestanda och att mjukvaran kan samverka med 

annan mjukvara på ett korrekt sätt. Många av dessa egenskaper kan vara svåra att 

testa med t.ex. strukturell testning. Om gammal funktionalitet ska finnas kvar i nya 

versioner av ett program kan gamla testfall utnyttjas eftersom dessa utgår från 

funktionaliteten. Därför lämpar sig funktionella tester bra för att kontrollera huruvida 

programmet fortfarande fungerar efter genomförda förändringar. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Svagheter 

Även en del begränsningar kan kopplas till att testaren inte har någon kännedom om 

implementationen. Om det t.ex. finns funktionalitet implementerad som inte finns 

med i specifikationer kan den inte testas [Hei97]. Ytterligare en nackdel med att inte 

känna till koden är att samma kodavsnitt kan testas onödigt många gånger. Testningen 

visar inte heller hur stor del av kodrymden som verkligen har testats. 

Disposition 

Följande funktionella testtekniker kommer att tas upp mer ingående i kapitlet. Domän 

och logikbaserad testning kan även fungera som strukturella testtekniker beroende på 

hur de används. 

• Domäntestning 

• Tillståndstestning 

• Logikbaserad testning 

• Syntaxtestning 

• Transaction flow testing 

3.4.1 Domäntestning 

Ett mjukvaruprogram kan ofta ses som en funktion beroende av ett antal variabler, 

d.v.s. programmets indata [Sco95]. Programmet beter sig på olika sätt beroende på 

vilka indata som det matas med. Många program beter sig på ett liknande sätt för 

vissa typer av indata. I dessa fall kan indatan delas upp i domäner. 

Indata kan sägas ha en viss dimension som är lika med antalet invariabler. Som 

exempel kan styrfunktionen av en termostat användas. Exemplet är enkelt eftersom 

indatan bara består av en variabel, nämligen den rådande temperaturen. Beroende på 

den rådande temperaturen ska termostaten slå på eller av kyl- och värmeaggregatet. I 

exemplet utgör vänsterkolumnen tre domäner där utsignalen från termostaten är 

densamma för respektive domän. 

Temperaturens (t) Utsignal från termostat 

uppdelning i domäner Värmeaggregat Kylaggregat 

t < 20º PÅ AV 

20º ≤ t < 30º AV AV 

t ≥ 30º AV PÅ 

Tabell 3-5. Exempel på domäner och funktionalitet för en termostat. 

Domäntestning (domain testing) innebär att tester genomförs för att visa att 

programmet uppför sig korrekt inom respektive domän och att domänens gränser är 

rimliga. Domäntestningen brukar koncentreras till områdena runt domängränserna. 

Studier har nämligen visat att de flesta domänfelen uppträder nära domängränserna 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

[Bei90]. För att domäntesta den lägre domängränsen i exemplet ovan skulle 

fokuseringen kunna ligga på temperaturerna runt 20º. 

Då domäntestning genomförs förutsätts att programmets funktionalitet är korrekt 

implementerad [Bei90]. Huruvida det är rätt att klassificera domäntestning som en 

funktionell testteknik beror till stor del på hur tekniken används. Om de domäner som 

testas härrör direkt från de krav som ställs i specifikationen är det fråga om 

funktionell testning. Däremot skulle tekniken kunna räknas till strukturell testning om 

de domäner som testas uppkommit som en följd av den valda designen [Sco95]. Det 

förutsätts här att de gränser som definierar domänerna är linjära, vilket är ett vanligt 

antagande inom domäntestningen eftersom det har visat sig att en övervägande del av 

alla domäner begränsas av linjära villkor [Bei95]. 

En domän är som tidigare nämnts en del av den rymd som spänns upp av de variabler 

som utgör programmets indata. Utseendet på domänen beror av vilka villkor som sätts 

upp för dessa variabler. Domänens dimension överensstämmer med antalet variabler 

som utgör indatan. Nedan visas exempel för en- respektive tvådimensionella domäner. 

Det endimensionella fallet grundar sig på termostatexemplet ovan. 

A 

Figur 3-19. A,B och C utgör här domäner med en dimension. Gränserna härrör till domän B. 

Den vita cirkeln är den övre gränsen i domän B. Att gränsen är öppen betyder att 30º 

inte ingår i domänen. Den svarta cirkeln, som utgör den lägre domängränsen, ingår 

däremot i domänen. För de båda angränsande domänerna A och C råder motsatt 

förhållande till de båda gränserna, d.v.s. C:s gräns mot B är sluten och A:s gräns mot 

B är öppen. Domän B begränsas alltså av 20º ≤ t < 30º. 

Figur 3-20. En domän i två dimensioner. 

t = 20º t = 30º 

2 

y 

B 

__________________________________________________________________________________________ 


2 

x 

C 

t




___________________________________________________________________________ 

I en tvådimensionell domän beror indata av två variabler. För Figur 3-20 gäller att de 

båda koordinataxlarna och den lutande linjen ingår i domänen. Det innebär att 

domänens alla tre gränser är slutna, vilket här markeras med att strecken på linjen 

pekar åt det håll som gränsen är sluten åt. Domänen begränsas av villkoren x ≥ 0, y ≥ 

0 och y + x ≤ 2. 

För den kommande framställningen kan det vara bra att känna till följande begrepp. 

Omsluten punkt – En punkt som ligger i samma domän som alla punkter i ett 

godtyckligt litet område runt punkten. En omsluten punkt har med andra ord ingen 

kontakt med någon domängräns. 

Gränspunkt – En punkt som har kontakt med en domängräns. Alla punkter i ett 

godtyckligt litet område runt punkten ligger alltså inte i samma domän. 

Domänfel i en domän med en dimension kan bero av flera olika anledningar. 

• Domängränserna kan vara för höga eller för låga. 

• Gränsen kan vara sluten i fel riktning. 

• Det kan finnas en gräns för mycket eller en för lite. 

Nedan förklaras hur de två förstnämnda felen kan identifieras. Markeringen x i 

tabellerna visar vilken punkt som testas. Den till testpunkten hörande pilen markera 

vilken domän testpunkten hör till och en cirkel markerar domängränsen. 

A B 

Figur 3-21. Ett korrekt exempel. Punkten x tillhör domän B som var avsikten. 

x 

Gränspunkten ovan öppen med avseende på domän A. Gränspunkten tillhör därmed 

domän B, vilket också var avsikten. Domängränsen är således korrekt utplacerad. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

A B 

x 

Figur 3-22. Felaktigt sluten domängräns. Punkten x tillhör felaktigt domän A, istället för domän B som 

var avsikten. 

Avsikten är att punkten x, som sammanfaller med domängränsen, ska tillhöra domän 

B. Domängränsen har felaktigt stängts vilket medför att gränspunkten istället tillhör 

domän A. Det går dock inte att med endast denna testpunkt säkert fastställa att felet 

beror på att domänen är stängd. Samma resultat kan uppkomma med ett domänfel 

enligt exemplet i Figur 3-23. 

A B 

Figur 3-23. En felaktigt utsatt domängräns. Punkten x tillhör nu domän A istället för domän B. 

Figur 3-23 är ett exempel på en för högt utsatt domängräns. Om domängränsen hade 

varit utsatt där det var tänkt, d.v.s. den streckade cirkeln, hade punkt x istället tillhört 

domän B som var avsikten. 

Exemplen från Figur 3-22 och Figur 3-23 visar att det påvisade felet kan bero av flera 

olika anledningar. Det är därför inte alltid möjligt att med endast ett test avgöra varför 

det är fel. Genom att testa en punkt nära punkten x i Figur 3-23 kan slutsatsen dras att 

det inte rör som om en felaktigt sluten gräns, utan i stället en för högt utsatt gräns. 

Exemplen ovan illustrerar tillvägagångssättet för domäntestning. En dimension är 

naturligtvis det enklaste fallet vilket är det enda som kommer att exemplifieras här. Är 

antalet dimensioner fler än två bör istället någon form av hjälpverktyg användas 

[Bei90]. Fler dimensioner kräver fler testfall för att kontrollera att en domän är 

korrekt. Om n är dimensionen på indatan och p är antalet domängränser så krävs det 

som mest (n+1)p testpunkter för att visa att en domäns gränser är korrekta. I vissa fall 

kan man utnyttja skärningspunkter mellan olika gränserna för att få ned antalet 

testfall. På så sätt kan man i bästa fall reducera antalet nödvändiga testpunkter till 2p 

[Bei90]. 

__________________________________________________________________________________________ 


x




___________________________________________________________________________ 

Figur 3-24 visar hur testpunkterna ska placeras för att testa en domän i två 

dimensioner. De svarta cirklarna är gränspunkter och de vita är omslutande punkter, 

d.v.s. de är inte i kontakt med någon domängräns. Enligt beräkningen nedan krävs då 

12 testpunkter. 

( n + 1 ) ⋅ p = ( 2 + 1) 

⋅ 4 = 12 

I den högra bilden utnyttjas skärningspunkterna mellan gränserna för att få ner antalet 

testpunkter till 2p. Reduktion av antalet testpunkter är bara möjlig i vissa fall, 

nämligen om båda gränserna är antingen slutna eller öppna. I exemplet är gränserna 

slutna varför en reduktion är möjlig. Enligt [Bei90] uppträder domänfelen i högre 

utsträckning vid skärningar mellan olika gränser, varför det kan visa sig fördelaktigt 

att utföra tester i just dessa punkter. 

Figur 3-24.Exempel på testpunkternas placering för två likadana tvådimensionella domäner. 

Avslutningsvis presenteras några termer som kan vara bra att känna till för vidare 

litteraturökning. Domäntestning är enligt [Bei90] en testteknik som grundas på 

partition testing. Partition testing försöker, precis som domäntestning, dela upp 

programmets indata i domäner där programmet uppför sig likartat. Genom att testa 

funktionaliteten en gång i varje domän antas sedan programmet vara korrekt för all 

indata. Partition testing är således inte lika omfattande som domäntestning 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

3.4.2 Tillståndstestning 

Tillståndstestning (state testing) innebär att det program som ska testas först 

modelleras med hjälp av tillstånd och övergångarna mellan dessa tillstånd. För att 

återknyta till föregående avsnitt exemplifieras tillståndstestning med 

termostatexemplet från kapitel 3.4.1. Ett programs tillstånd representeras antingen 

med ett tillståndsdiagram som i Figur 3-25, eller med en tillståndstabell, Tabell 3-6. 

För kallt Lagom För varmt 

t < 20º 

Värme PÅ 

t < 20º 

Värme PÅ 

t ≥ 20º 

Värme AV 

20º ≤ t < 30º 

Värme & Kyla AV 

Figur 3-25. Exempel på ett tillståndsdiagram för en termostat. 

De tre fyrkantiga rutorna markerar de tre tillstånd som termostaten kan befinna sig i. 

Pilarna representerar övergångar (transitions) mellan de olika tillstånden. Till varje pil 

hör ett villkor och en utsignal. Villkoret talar om vid vilken insignal som 

transaktionen ska utlösas och utsignalen talar om vad som i sådana fall ska ske. 

Samtliga tre tillstånd har en övergång för alla värden som insignalen kan anta. Notera 

att en övergång inte behöver medföra att tillståndet förändras. Om pilen börjar och 

slutar i samma tillstånd har ingen förändring skett. 

Ett program kan ha ett stort antal insignaler med många möjliga värden. Att rita ett 

tillståndsdiagram för ett större system är svårt och brukar resultera i oöverskådliga 

tillståndsdiagram. Därför lämpar sig tillståndsdiagram främst för enklare modeller 

med några tiotals tillstånd och bara några få insignaler. Om tillståndsdiagrammen blir 

för komplexa kan det vara bättre att använda tillståndstabeller [Bei90]. Nedan 

presenteras en tillståndstabell med samma innehåll som tillståndsdiagrammet i Figur 

3-25. 

Tillstånd t < 20 20 ≤ t < 30 t ≥ 30 

För kallt För kallt 

Lagom 

- 

värme PÅ kyla & värme AV 

Lagom För kallt 

Lagom 

För varmt 

värme PÅ kyla & värme AV kyla PÅ 

För varmt - Lagom 

För varmt 

kyla & värme AV kyla PÅ 

Tabell 3-6. Exempel på en tillståndstabell för en termostat. 

t < 30º 

Kyla AV 

t ≥ 30º 

Kyla PÅ 

t ≥ 30º 

Kyla PÅ 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

I tillståndstabellen representerar varje rad ett tillstånd och varje kolumn ett visst 

villkor för insignalen. Rutorna inne i tabellen innehåller nästa tillstånd (dit pilen hade 

pekat i ett tillståndsdiagram) och utsignalen. 

Modellen över tillstånden och deras övergångar arbetas fram utifrån designspecifikationen, 

vilket möjliggör att modellen kan tas fram redan innan själva 

programmet är skrivet. Det medför att vissa fel kan hittas redan innan programmet är 

körbart [Bei90]. Då tillståndsdiagrammet eller en tillståndstabell ska tas fram är det 

lämpligt att följa arbetsgången nedan. 

1. Börja att analysera indatan och undersök vilka villkor som programmets tillstånd 

kan utsättas för. I tillståndstabellen innebär det att kolumnerna identifieras. 

2. Identifiera de olika tillstånden som modellen ska bestå av, vilket motsvarar 

raderna i tillståndstabellen. 

3. Identifiera utdatan, d.v.s. att tillståndstabellens inre rutor fylls i med avseende på 

kommande tillstånd och resultatet därav. 

Efter att modellen tagits fram ska testfall skrivas. Enligt [Bei90] ska testningen 

genomföras på likartat sätt som för control flow testing, se kapitel 3.3.2, d.v.s. 

åtminstone alla tillstånd och övergångar ska genomlöpas minst en gång. Liksom för 

control flow testing är flera enkla testfall att föredra framför ett stort och mycket 

komplext. 

Innebörden i följande tre punkter ska kontrolleras för varje exekverat testfall [Sco90]. 

• Den sekvens indata som behövs för att genomlöpa den önskade vägen i 

tillståndsdiagrammet. 

• De övergångar eller tillstånd som genomlöps vid användandet av ovan nämnda 

sekvens av indata. 

• Den sekvens av utdata som testfallet är tänkt att generera. 

Mycket av vinsten med att genomföra tillståndstestning visar sig redan innan koden är 

skriven och innan testfallen är redo att köras. En förklaring är att konstruerandet av 

tillståndsdiagram och tillståndstabeller tvingar testaren att analysera designspecifikationerna. 

Uppenbara fel, som att tillstånd är omöjliga att nå eller lämna, kan 

då hittas genom att enbart titta på diagrammet eller tabellen. Det är dock viktigt att 

inte ta sig vatten över huvudet och tro att ett stort och komplext program kan 

moduleras på en detaljrik nivå. [Bei95] hävdar att insignalerna maximalt ska räknas i 

tiotal och tillstånden i dussin snarare än tusental. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

3.4.3 Logikbaserad testning 

Logikbaserad testning kan klassas som både en strukturell- och funktionell testteknik. 

Den är strukturell om testfallen bygger på programmets design och funktionell om 

testfallen är uppbyggda efter de krav som ställs på systemet i specifikationer. För 

strukturell logikbaserad testning, se kap 3.3.5. 

När det gäller funktionell logikbaserad testning tas ingen hänsyn till hur programmet 

är designat. Fokus läggs istället på vilka krav som ställs på systemet. Testningen 

innebär att alla olika kombinationer av villkor, som programmet kan ställas inför, 

genomlöps. Under testningen kontrolleras att varje kombination av villkor resulterar i 

att programmet handlar på ett korrekt sätt enligt specifikationen. 

Ett vanligt sätt att formulera de logiska villkor som ställs på systemet är att generera 

en s.k. villkorstabell. Syftet med villkorstabellen är att underlätta framtagandet av de 

testfall som ska verifiera att villkoren fungerar som det var tänkt. Nedan följer ett 

exempel på en sådan tabell, hämtad från [Sco95]. 

Beteckning Regel 1 Regel 2 Regel 3 Regel 4 Regel 5 Regel 6 

Villkor 1 J J J N N N 

Villkor 2 J N N J N N 

Villkor 3 N J N - J N 

Handling 1 X 

Handling 2 X X X 

Handling 3 X X 

Handling 4 X X X X 

Tabell 3-7. Villkorstabell som används i den funktionella logikbaserade testningen. “X” innebär att 

den handlingen ska utföras förutsatt att kombinationen av villkor är uppfylld. 

I tabellen representeras de olika kombinationerna av villkor som olika regler. 

Reglerna ska täcka in samtliga fysikaliskt möjliga kombinationer av villkor. Regeln 

specificerar också programmets uppförande för en viss kombination av villkor. Notera 

att regeln som representerar att samtliga tre villkor är uppfyllda (J, J, J) inte finns i 

tabellen. Det kan t.ex. bero på att den kombinationen av villkor är fysikaliskt omöjlig. 

Strecket i regel 4 innebär att programmets uppförande är oberoende av om villkoret är 

uppfyllt eller inte. 

Innebörden i följande tre punkter ska kontrolleras för varje exekverat testfall [Sco90]. 

• Samtliga villkors kombinationer finns representerade i tabellen. 

• Programmet uppfyller de handlingar som specificeras av respektive regel i 

tabellen. 

• Omöjliga fysikaliska villkorskombinationer, som (J, J, J) i exemplet ovan, inte kan 

förekomma. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Då testning utförs med hjälp av villkorstabeller bör testaren börja med att verifiera att 

samtliga villkors kombinationer finns representerade i tabellen. Därefter ska testfall 

skrivas som försäkrar att programmet uppfyller de handlingar som specificeras av 

respektive regel i tabellen. Det bör också kontrolleras att fysikaliskt omöjliga 

villkorskombinationer som (J, J, J) ovan verkligen inte kan förekomma [Sco95]. 

3.4.4 Syntaxtestning 

Ett system kan utsättas för stora påfrestningar i form av underliga indata. Det gäller 

särskilt system som har ett gränssnitt ut mot användare. Av någon anledning finns det 

alltid användare som lyckas mata in de mest osannolika indata. I de flesta fall är det 

inte medvetna felinmatningar från användarnas sida. Problemet är att ett fåtal testare, 

ofta under tidspress, ska testa allt som dessa användare tillsammans kan tänkas utsätta 

systemet för under dess livslängd. Man brukar tala om apfenomenet [Bei90]. Om en 

miljon apor sitter vid en miljon skrivmaskiner i en miljon år, kommer kanske någon 

av dem att skriva ordet Hamlet. Eventuellt är det just det ordet som får systemet att 

krascha. Att testa allt är att betrakta som en omöjlig uppgift. I ett stort system finns 

det alltid någon liten kombination av olika indata som förblir otestad. 

Syntaxtestning handlar om att testa systemets externa inmatningar, från t.ex. 

användare, operatörer eller sensorer, samt alla interna inmatningar mellan olika 

gränssnitt. Syftet med syntaxtestningen är att mata in en mängd korrekta och felaktiga 

inmatningar till systemet och på så sätt upptäcka för vilka inmatningar systemet inte 

reagerar i överensstämmelse med specifikationen. Oönskade händelser kan gestalta 

sig på följande tre sätt [Sco95]. 

• Korrekta inmatningar accepteras inte av systemet. 

• Korrekt inmatning accepteras men behandlas felaktigt. 

• Felaktiga inmatningar accepteras av systemet. 

• Systemet kraschar vid behandling av inmatning, oavsett om denna är korrekt eller 

felaktig. 

Det är inte svårt att förstå att det kan förekomma oändligt många varianter på 

felaktiga eller korrekta inmatningar för komplexa system. Enbart några enkla 

inmatningar kan ge många kombinationer av tester. Därför finns mycket att vinna om 

testerna kan automatiseras. Som tidigare har påpekats finns det ringa möjligheter för 

ett fåtal testare att testa allt som samtliga användare kan tänka utsätta systemet för. 

Syntaxtestning brukar vara en del av de systemtester som görs t.ex. inför ett 

acceptanstest. Det är bra om oberoende testare, vars beteendemönster liknar den 

riktiga användarens, kan deltaga i testet. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

3.4.5 Transaction flow testing 

Utifrån användaren kan en transaktion bestå av ett enkelt kommando. Det kan t.ex. 

vara en variabel som ges ett nytt värde vilket resulterar i att ett par parametrar 

förändras på monitorn. Även om det kan tyckas vara en liten händelse kan det ligga en 

hel del arbete bakom det som syns på monitorn. En enkel instruktion från användaren 

kan resultera i att en mängd processer på många olika datorer påbörjas. En transaktion 

har liksom ett liv en begränsning i tiden. Transaktionen föds via en intern eller extern 

händelse och dör efter att den har åstadkommit det som den var skapad för att göra. 

De flöden, som transaktionerna genererar genom programmet, gestaltas i flödesgrafer 

liknande de som beskrevs i kapitel 3.3.1. En stor skillnad mellan transaktionsflöden 

och de flöden som beskrevs i kapitlet om strukturella testtekniker är att 

transaktionsflöden är uppbyggda efter programmets beteende och inte efter dess inre 

struktur. Det är alltså inte programmets källkod som ska ligga till grund för flödet 

utan istället de krav som ställs på programmet i specifikationer. 

Transaction flow testing görs lämpligast med tekniker liknande de som används vid 

den strukturella control flow testningen, se kapitel 3.3.2. Ett krav är givetvis att 

flödena bygger på transaktionsflöden och inte på de interna strukturerna som i de 

strukturella fallen. Det största arbetet ligger ofta i att ta fram alla möjliga 

transaktionsflöden. Om transaktionsflöden är en del av systemets specifikationer är en 

stor del av arbetet redan gjort [Bei90]. 

Vilka testvägar ska då väljas genom programmet? Svaret skiljer sig en aning från de 

som gavs för control flow testing. Till att börja med bör åtminstone fullständig nod- 

och grentäckning uppfyllas, enligt det arbetssätt som finns förklarat i kapitel 3.3.2. 

Dessa vägar brukar utgöra 80 – 95 % av de totala transaktionsflödesvägarna. Tyvärr 

ligger de flesta felen utanför dessa testvägar. För att komma åt dessa fel bör istället de 

längsta och mest obegripliga vägarna tas fram och undersökas [Bei90]. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

3.5 Statistisk testning 

Statistisk testning avser här testverksamhet som syftar till att resultera i någon form av 

kvalitetsmått på mjukvaran. Tre olika tekniker kommer att presenteras nedan; 

felinjicering, random testing och feluppskattning med hjälp av dubbla testlag. Både 

random testing och felinjicering ger en uppskattning om hur många kvarvarande fel 

som finns i koden. Random testing kan även användas för att få uppskattade värden 

angående mjukvarans tillförlitlighet och tillgänglighet [Gar99]. 

Dessa metoder kan användas för att hitta fel. Det bör dock påpekas att om teknikerna 

enbart används i detta syfte, och inte för att få ett kvalitetsmått, finns det antagligen 

effektivare tekniker att använda. 

3.5.1 Felinjicering 

Målet med felinjicering är att få ett mått på testteknikers förmåga att påvisa fel och att 

få ett mått på hur många fel som kan tänkas finnas kvar i den testade koden [IEC 

61508]. Tekniken bygger på att kända fel injiceras i koden. Programmet exekveras 

och testas med ett antal testtekniker. Antalet injicerade fel och det antal av dessa som 

hittas efter exekveringen används sedan tillsammans med resultatet från testet för att 

bedöma hur många riktiga fel som finns i koden. 

Antal injicerade fel som hittas 

Totala antalet injicerade fel 

Antal verkliga fel som hittas 

Totala antalet verkliga 

fel 

Antag att testningen hittar 100 av de 200 injicerade felen och dessutom 100 verkliga 

fel. Det ger ett förhållande på 0,5 för de felinjicerade felen, vilket innebär att det 

borde finnas ytterligare ungefär 100 verkliga fel i koden. 

Det är viktigt att felen som injiceras liknar de fel som programmerare kan tänkas göra. 

Om lättidentifierade fel injiceras i en kod innehållande mer komplicerade fel kommer 

inte resultatet att bli tillförlitligt [Fri95]. Teknikens största svaghet ligger i svårigheten 

att bedöma vilka fel som ska injiceras. 

Felinjicering kan också innebära att fel injiceras för att se hur systemet reagerar. De 

fel som påträffas med detta förfarande kan annars vara svåra att hitta [Kee95]. 

__________________________________________________________________________________________ 


=




___________________________________________________________________________ 

3.5.2 Random testing 

Det primära i en statistisk testteknik är inte att hitta fel utan snarare att ge ett mått på 

sannolikheten att det finns fel. Random testing är en testteknik som kan räknas till de 

statistiska testteknikerna, men som dessutom används med målsättningen att hitta fel. 

Till skillnad mot många andra tekniker lämnar random testing vissa beslut åt slumpen. 

Tekniken garanterar t.ex. inte att ett visst antal tillstånd exekveras, eller att ett antal 

vägar genomlöps. Istället är det slumpen som får avgöra vilka delar av 

programrymden som ska exekveras. I många andra testtekniker är det testaren själv 

som på det ena eller andra sättet bestämmer vilka indata som ska användas i testerna. 

Random testing bygger istället på att testarnas val ersätts med slumpade värden från 

någon effektiv algoritm. 

Innan en lämplig slumpgenerator slumpar fram värden måste den domän i vilka 

värdena ska gälla bestämmas. De genererade värdena används sedan som indata till 

programmet eller den del av programmet som ska testas. Random testing kan således 

ses som både ett systemtest och ett modultest. Resultatet från det exekverade 

programmet jämförs slutligen med specifikationer som beskriver hur programmet ska 

fungera. Testet sägs misslyckas om något indata leder till ett inkorrekt resultat. 

Exempel på ramdom testing 

Tekniken illustreras med ett enkelt exempel [Ham94]. En funktion som beräknar 

kubikroten av ett heltal garanterar en noggrannhet på 2·10 -5 i intervallet X = [1, 10 7 ]. 

Värdena antas vara likformigt fördelade över intervallet, d.v.s. alla heltal i intervallet 

kan förekomma lika ofta i beräkningen. Ett test som bygger på slumpmässighet och 

som består av 3000 testfall kan då utföras på följande sätt. 

3000 likformigt fördelade heltal genereras i intervallet X med en lämplig algoritm. 

Varje heltal sätts som indata t till funktionen. För varje värde på t beräknas därefter 

kubiken av funktionens utdata, vilket sedan jämförs med t. Om något av de 3000 

testfallen får en mindre noggrannhet än det utlovade 2·10 -5 bör funktionen rättas till. 

Att åtgärda koden och därefter testa bör sedan göras iterativt till målet uppnås och alla 

3000 fall hamnar inom tillåten felmarginal. 

Exemplet ovan är något orealistiskt av två anledningar [Ham94]. 

1. För det första är det sällan så enkelt att slumpa fram lämpliga indata. Ofta är 

indata mer komplexa än heltal inom ett givet intervall. Det är inte heller säkert att 

det finns någon lämplig fördelning som beskriver hur sannolikheten för indata 

varierar längs intervallet. 

2. Det är sällan lika enkelt som i exemplet ovan att jämföra utdata med det tänkta 

beteendet. I många fall kan det bero på att specifikationerna är otydligt 

formulerade, men systemets beteende kan i sig vara så komplext att en jämförelse 

i stort sätt är omöjlig. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Förutsättningar för random testing 

Det finns vissa förutsättningar som bör gälla för att resultatet från testerna ska bli 

tillförlitliga. 

• Modulen eller programmet som testas måste förses med tillräckligt många indata, 

ju fler desto bättre. Många indata leder till att en större del av programrymden 

exekveras, vilket ger ett mer heltäckande resultat. 

• Ett effektivt orakel är ett måste. Eftersom det ofta rör sig om många testfall måste 

oraklet, utan mänsklig inblandning, kunna avgöra om testets utdata 

överensstämmer med det förväntade beteendet. 

• En känd profil över användandet bör finnas som kan översättas till någon lämplig 

sannolikhetsfördelning. 

Vissa kritiker menar att det ofta är svårt att få fram en fördelning som visar hur 

värdena ska slumpas fram. I de fall då det inte finns någon känd fördelning att tillgå, 

brukar istället en likformig fördelning användas. Om antalet värden är tillräckligt stort 

kan denna fördelning till och med visa styrkor som en mer ”riktig” fördelning inte 

gör. Anledningen är att även mindre sannolika värden testas. Erfarenheten visar att en 

nybörjare kan krascha ett program som experter har använt långa tider utan problem 

[Ham94]. Slumpmässiga värden från en likformig fördelning bryr sig inte om vilka 

indata som är mest sannolika. Skumma indata, som representerar nybörjares mindre 

vanliga inmatningar, företräds då också i testet. 

Random testing som statistisk metod 

Vissa standarder kräver t.ex. att 80 % av programmets alla vägar genomlöps i ett test, 

men det finns ingen information om vilka av alla dessa vägar som ska genomlöpas. 

Ett sådant test kan enbart påvisa att 80 % av alla vägar fungerar tillfredsställande. 

Testet visar inte hur resterande 20 % fungerar. 

Ett argument för random testing är att ett lyckat test kan ses som ett statistiskt mått på 

programmets pålitlighet. Eftersom programmet eller funktionen körs i sin helhet, med 

slumpmässiga indata som ska spegla användarprofilen, kan ett mått fås på hur 

programmet fungerar. För mindre avancerade program kan ett test t.ex. visa att fel till 

99 % sannolikhet kommer att uppstå en gång på 10 000 körningar. För ett 

realtidssystem skulle ett test kunna visa att medeltiden mellan fel till 99 % sannolikhet 

kommer vara större än 10 000 timmar. I dessa fall brukar testtekniken även gå under 

namnet Monte Carlo-testning. 

Random testings effektivitet 

Hur effektiv denna testteknik är tvistar de lärde om. [Ham94] menar att random 

testing har visat sig vara en nog så bra teknik som många av de strukturella och 

funktionella testteknikerna när det gäller att påvisa fel. Författaren påpekar dock 

vikten av att många testfall körs för att få ett vedertaget resultat. [Sco95] skriver å 

andra sidan att tekniken är mindre effektiv på att hitta fel än de strukturella och 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

funktionella testteknikerna. Något som de verkar vara överens om är att tekniken kan 

vara ett bra komplement till andra testtekniker. Att enbart använda random testing är 

inte att rekommendera. 

3.5.3 Feluppskattning med hjälp av dubbla testlag 

En ytterligare möjlighet att få ett mått på antalet fel i en mjukvara är att låta två testlag 

testa koden oberoende av varandra varefter de upptäckta felen jämförs. Antag att ett 

program har en viss mängd fel i sig, vilka representeras av den stora cirkeln i Figur 

3-26. De två oberoende testlagen A och B hittar felen inom respektive mindre cirkel. 

Om testlagen hittar samma fel kan det kännas logiskt att de troligen har hittat en stor 

del av det totala antalet fel i mjukvaran. Om testlagen däremot hittar olika fel är 

sannolikheten stor att det kan finnas ytterligare fel i mjukvaran som ännu inte 

upptäckts. 

Totala felrymden 

Av A hittade 

fel 

Av B hittade 

fel 

Figur 3-26. Exempel på en mjukvaras totala felrymd, samt de fel som hittas av testlag A respektive B. 

Tekniken lämpar sig antagligen bäst för att göra grova uppskattningar angående hur 

stor del av antalet fel som upptäckts. Det finns dock en allvarlig brist med tekniken, 

det är inte rimligt att anta att de fel som hittas av testlagen är oberoende av varandra 

eftersom vissa fel är lättare att hitta än andra. Om båda testlagen hittar alla 

lättupptäckta fel var för sig kan det ändå finnas många fel kvar som är svåra att hitta. 

Det är då naturligtvis felaktigt att dra slutsatsen att en stor del av testrymden skulle 

vara täckt. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

3.6 Statisk analys 

Att testa mjukvara är förknippat med att kod på ett eller annat sätt exekveras, d.v.s. 

testning är ett dynamiskt förlopp. Statisk analys innebär att ett program undersöks 

utan att det exekveras, varför det inte är någon egentlig testteknik [Bei90]. Analysen 

kan vara såväl manuell som automatisk. I modernare programmeringsspråk finns 

mycket av den automatiska analysen inbyggd, t.ex. om ett semikolon glöms av 

programmeraren påpekas det av kompilatorn. 

Styrkor 

Eftersom det inte bara är kod som inspekteras så behöver inte analysen knytas till 

någon av projektets faser. Specifikationer kan t.ex. inspekteras långt innan 

implementationsarbetet påbörjas. Det medför att fel och misstag kan upptäckas i ett 

tidigt skede och åtgärdas innan de fått några större konsekvenser. 

Svagheter 

Den största svagheten med statisk analys är att den inte ger någon information om 

mjukvarans beteende vid exekvering. Statiska analysen kan därför knappast ersätta 

den dynamiska testningen utan bör istället ses som ett komplement till denna. Den 

statiska analysen kan också kräva stora arbetsresurser, vilket särskilt gäller i de fall då 

projektspecifika ändamål ska översättas till något automatiskt testverktyg [Sco95]. 

3.6.1 Granskning och walkthrough 

Syftet med granskning och walkthrough är att identifiera problem och fel som kan 

uppstå i projektets första faser. Syftet är således inte att lösa problemen, utan snarare 

att identifiera dem [Kan93]. 

Granskningen äger rum under ett möte ofta bestående av fem till tio deltagare. För att 

inte mötesdeltagarna ska vara partiska är det en fördel om de inte är alltför insatta i 

projektet. Under mötet får t.ex. en systemdesigner redogöra för hur en viss del av 

systemet är tänkt att fungera. Mötesdeltagarna ställer frågor och gör kommentarer på 

eventuella svagheter [Sco95]. 

Standarden IEC 61508 rekommenderar att en granskning ska göras så fort något i 

systemet förändras som kan påverka systemets funktionalitet. Det kan t.ex. handla om 

skapandet av nya applikationer, revisioner i befintlig programvara, prestanda och 

säkerhetsaspekter. 

En fördel med granskningen är att den kan göras i ett tidigt skede av projektet, t.o.m. 

innan koden är skriven. Ju tidigare brister upptäcks, desto lättare och billigare är det 

att åtgärda dem. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

3.6.2 Inspektion 

Inspektion, även ibland kallat Fagan Inspection efter Michael Fagan, är en effektiv 

teknik för att upptäcka fel i projektets tidiga faser. Michael Fagan började skissa på 

tekniken på 70-talet och den har sedan dess utvecklats till att bli en av de effektivaste 

teknikerna för att hitta fel. Det har visats att så mycket som 50 – 70 procent av felen 

kan upptäckas under inspektionsprocessen [Gil93]. 

IEEE Standard Glossary of Software Engineering Terminology definierar inspektion 

som en formell metod där mjukvarans systemkrav, design eller kod detaljgranskas av 

en oberoende person eller grupp för att hitta fel, konflikter med standarder eller andra 

problem. 

Det finns tre olika varianter av inspektioner [Sco95]. En överblick av de tre 

varianterna finns presenterade i Figur 3-27. 

I0: Inspektionen brukar kallas I0 om arbetet fokuserar på att verifiera att funktioners 

beteende överensstämmer med de krav som ställs på systemet. Det är särskilt 

dataflödet mellan olika delar av programmet som undersöks för att påvisa att 

flödena genom systemet är korrekta och att inga deadlock existerar. 

I1: Dessa inspektioner behandlar den översiktliga designstrukturen som t.ex. logiska 

uttryck. 

I2: De inspektioner som utförs under implementationsfasen går under benämningen 

I2. Inspektionen, som även kallas code inspection, fokuserar på översättningen av 

den detaljerade designen till kod. 

Systemkrav 

Inspektion I0 


Inspektion I1 


Inspektion I2 

Kod 

Modul- 

test 

Figur 3-27. Olika typer av inspektioner under projektets livscykel. 


System- 

test 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Samtliga inspektioner ska följa en väl definierad arbetsgång som t.ex. innehåller steg 

som planering, förberedelser, inspektion och uppföljning. Om det behövs kan 

uppföljningen bestå av en helt ny inspektion. 

Inspektion av koden kan även medföra andra fördelar än att specifika fel upptäcks 

[Kan93]. En utomstående som läser igenom koden kan tala om huruvida koden är 

begriplig eller inte. Är koden svår att förstå kan det bero på att den som skrivit koden 

haft problem med att lösa uppgiften och kanske inte lyckats göra det på ett bra sätt. 

Om så är fallet är det stor risk att fel finns i koden. Är dessutom koden svår att förstå 

för en utomstående kommer den vara svår att underhålla och uppdatera eftersom det 

arbetet ofta utförs av andra än de som skrivit koden. 

Inspektion jämfört med testning 

Både inspektion och testning syftar till att hitta eventuella fel så att mjukvarans 

kvalitet kan säkerställas innan den når användaren. Tillvägagångssätten för att nå 

målet skiljer sig dock en aning från varandra. En stor styrka med inspektion är att den 

kan genomföras en lång tid innan kod har producerats. Det går på så sätt att i ett tidigt 

stadium hitta fel, fel som hade varit dyra att åtgärda om de hade hittats i ett senare 

skede av projektet. För att genomföra ett test måste krav- och designspecifikationer 

vara skrivna eftersom specifikationerna ska avgöra huruvida testet har lyckats eller ej. 

Testning å andra sidan har den styrkan att systemet verifieras utefter dess verkliga 

beteende. 

3.6.3 Formella metoder 

Formella metoder används för att utveckla mjukvarusystem genom att tillföra en 

matematisk beskrivning av systemets egenskaper. En formell metod tillhandahåller ett 

ramverk - regler och syntax - för att kunna specificera, utveckla och verifiera ett 

system enligt ett systematisk tillvägagångssätt [Pre97]. 

Formella metoder används framför allt på följande två sätt [Joh96]. 

• För att producera en korrekt och tydlig specifikation. 

• Först för att producera en korrekt och tydlig specifikation, men sedan också för att 

sätta upp bevis för att designen av systemet överensstämmer med specifikationen. 

Användandet av formella metoder syftar till att underlätta framtagandet av otvetydiga 

och konsistenta specifikationer, d.v.s. specifikationer som inte säger emot sig själva. 

Den syntax som används i formella specifikationer är mer lämpad för att skriva 

otvetydigt än vid vanliga textbeskrivningar. För att övertyga sig om att en 

specifikation är konsistent ska matematiska bevis konstrueras. Bevisföringen 

möjliggörs även den av de formella notationer som används i formella metoder 

[Pre97]. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Förutom att användas för specificering och verifiering kan formella metoder, 

åtminstone teoretiskt, användas för att påvisa frånvaron av vissa typer av fel. Exempel 

på fel som kan visas vara obefintliga är de som härrör från implementationsfasen 

[Lit94]. Däremot går det inte att bevisa frånvaron av alla fel. Det går till exempel inte 

att visa att översättningen från en specifikation som är skriven med vanlig text har 

blivit korrekt översatt till den formella notationen som används. 

Det finns en rad olika formella metoder som tillsammans kan delas upp i två 

huvudgrupper. Den ena gruppen består av metoder som används främst för formell 

bevisföring. Den andra gruppen, s.k. model checkers, används för att kontrollera olika 

typer av modeller [Bra00], se också kapitel 3.7.4. Den första gruppen av formella 

metoder ställer höga krav på att användaren är väl insatt i hur formella metoder 

används eftersom utbudet av automatiska hjälpmedel är litet. En av anledningarna till 

att det har varit så svårt att etablera användandet av formella metoder inom industrin 

kan vara att det krävs goda matematiska kunskaper för att få förståelse för metoderna 

[Bow93]. 

I de fall formell verifiering av program har tillämpats har det enligt [Lev95] visat sig 

vara mycket resurskrävande trots relativt enkla program. Dessutom är de bevis som 

konstruerats så komplexa och omfattande att de i sig kan innehålla fel. Även 

publicerade bevis av små algoritmer har visat sig innehålla fel. Matematiska bevis av 

ett programs egenskaper kan vara lika stora som själva programmet, dessutom svåra 

att framställa och förstå [Lev 95]. [Joh96] poängterar dock att formella metoder kan 

ha en positiv inverkan eftersom den framtvingar ett rationellt och disciplinerat 

tänkande. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

3.7 Övriga tekniker 

Här presenteras de tekniker som inte har sorterats in under ovanstående kapitel. 

3.7.1 Stresstestning 

Syftet med stresstestning är att undersöka hur systemet beter sig då det utsätts för 

belastningar utöver det normala. Om systemet fungerar under onormala belastningar 

bör det även göra det under mer normala omständigheter. Den här typen av testning är 

särskilt viktig för säkerhetskritiska system som behandlar stora mängder indata 

[Sco95]. 

Områden som är möjliga att stressa kan t.ex. vara 

• Mängden indata 

• Diskutrymme 

• Minne 

• Mängden utdata 

• Kapacitet på kommunikationslänkar 

• Användaren 

Det primära målet med stresstestning är att verifiera att systemets prestanda- och 

kapacitetskrav uppfylls. Genom att stresstesta runt gränsvärden kan information 

erhållas huruvida de kapacitetskrav som ställs på systemet är uppfyllda. Ofta räcker 

det dock inte att testa runt gränsvärden. Ett sätt att utföra ett stresstest är att belasta 

systemet mer och mer tills det inte längre klarar av att fungera som det var tänkt. 

Genom att undersöka varför och vid vilka belastningar systemet slutar fungera fås 

information om eventuella fel, belastningsgränser, systemets beteende runt dessa 

gränser och systemets förmåga att återhämta sig. 

Att återupprepa samma stresstester är i stort sätt omöjligt för lite större system. Det 

kan bero på att flera simultana aktiviteter sker samtidigt och att de interna tiderna för 

aktiviteterna varierar från gång till gång. Att testerna inte går att återupprepa medför 

att identifieringen av mjukvarufel kan bli besvärligt. Typiska fel som påträffas under 

stresstestning är snarare relaterade till designfrågor än till rena 

programmeringsmisstag [Sco95]. 

En förutsättning för att resultatet ska bli trovärdigt är att testningen utförs i en miljö 

som liknar den som systemet är tänkt att operera i. Om systemet är under utveckling 

kan det därför vara mycket kostsamt och svårt att bygga upp en sådan miljö. Det kan 

dessutom vara svårt att generera så stora mängder indata till systemet som behövs för 

att testet ska bli tillförlitligt. För lite större system är det nödvändigt att dessa indata 

kan genereras på automatisk väg. Att genomföra ett stresstest kräver stora resurser 

och förberedelser. Hur verklighetstrogna dessa tester blir är därför ofta en 

kostnadsfråga [Per95]. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

3.7.2 Cleanroom testing 

Cleanroom testing är en del av IBM:s utvecklingsmetod för mjukvara. Denna 

omdiskuterade metoden skiljer sig en hel del från ett vanlig utvecklingsprojekt med 

faser som t.ex. planering, design, implementation och test. Tanken med cleanroom är 

att koden ska göras rätt från första början. Koden utvecklas utan att exekveras, vilket 

istället görs i en separat fas efter utvecklingen. 

Testningen går till på ett annorlunda sätt. Istället för att utföra tester som ska hitta fel i 

design och kod, är målet med cleanroom testing att validera systemkraven utefter ett 

statistiskt urval av användarfall. För att kunna testa systemet på ett sådant sätt måste 

testgruppen först undersöka hur systemets funktioner kommer att användas och hur 

stor sannolikheten är att respektive funktion exekveras. I följande tabeller ges ett 

exempel hämtat ur [Pre97]. 

Aktivitet Fördelning Intervall 

A 50 % 1-49 

B 15 % 50-63 

C 15 % 64-78 

D 15 % 79-94 

E 5 % 95-99 

Tabell 3-8. Exempel på aktiviteter och deras sannolikhetsfördelning. 

Aktiviteterna delas upp i intervall utifrån sannolikhetsfördelningen. För att generera 

en sekvens av tester slumpas en serie nummer fram med en algoritm, se Tabell 3-9. 

Testerna utförs och resultatet jämförs med systemets specifikationer. 

Slumpad sekvens Sekvens av testfall 

12-94-22-24-45-56 A-D-A-A-A-B 

81-19-31-69-45-9 T-A-A-A-C-A-A 

Tabell 3-9. Två serier av testfall genererade utifrån en slumpad sekvens. 

Det finns motstridiga uppgifter om huruvida cleanroom är en bra metod eller ej. 

Tyvärr finns det inte så mycket empirisk information som visar hur tekniken fungerar 

i verkligheten. De flesta kritiker verkar tycka att tekniken är mycket intressant, men 

som alltid finns det undantag. Boris Beizer, ett välkänt namn inom testning, skriver ”I 

am confident that Cleanroom is, and will remain, an underdeveloped and 

overexposed minority practice.” [Bei97]. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Fördelen med cleanroom testing är att den bygger på statistiska data utifrån 

användarfall, d.v.s. den ska spegla hur systemet är tänkt att användas. Mindre arbete 

utförs under utvecklingsfasen, men istället måste mer omfattande arbete läggas ner för 

att identifiera användarfall och de sannolikhetsfördelningar som ska kopplas till dem. 

En nackdel, liksom i många andra testtekniker, är svårigheten att ta fram ett pålitligt 

orakel [Hei97]. 

3.7.3 N-version programmering 

N-version-, multiversion- och diversifierad programmering är alla namn på en 

designteknik som använts till att utveckla mjukvara för säkerhetskritiska system. I den 

kommande framställningen används endast termen N-version programmering. 

Tekniken innebär att samma funktionalitet utvecklas i flera olika versioner av olika 

utvecklare. Indata exekveras sedan parallellt av de olika versionerna. Resultaten från 

körningarna skickas till en omröstningsfunktion som utifrån de olika resultaten 

bestämmer utdatan från systemet, se Figur 3-28. I vissa fall, då inte exakta värden 

erhålls från de olika versionerna, kan det vara svårt att ta fram en ändamålsenlig 

omröstningsfunktion. 

Indata 

Version 1 

Version 2 

Version 3 

… 

Version N 

Omröstningsfunktion 

Figur 3-28. Schematisk beskrivning av ett N-version system [Hat97]. 

Utdata 

Det kan diskuteras huruvida N-version programmering ska klassificeras som en 

testteknik eller ej. Vanligtvis brukar den klassificeras som en designteknik, men 

beroende på hur tekniken tillämpas kan den också användas för testning. Med testning 

avses ofta arbete som görs för att hitta fel i en redan skriven kod. N-version 

programmering innebär att extra arbete läggs ned på att skriva själva koden eftersom 

det görs flera gånger, vilket alltså motsäger att det är en testteknik. Ett argument som 

talar för att en klassificering som testteknik är att de olika versionerna testas mot 

varandra under exekveringen av systemet. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

N-version programmering går dock att använda som en ren testteknik. Det görs 

genom att konstruera flera versioner av ett program och testköra dessa mot varandra. 

När programmet sedan ska användas exekveras bara en version. Användningssättet 

benämns även som comparison testing och back-to-back testing. 

Idén med att köra delsystem med samma funktionalitet parallellt har använts i 

säkerhetskritiska hårdvarusystem under en längre tid. Denna idé grundar sig på 

antagandet att de komponenter som bildar delsystemen går sönder oberoende av 

varandra. Antagandet är visserligen inte helt korrekt eftersom yttre omständigheter 

kan slå ut systemen samtidigt, men tekniken har ändå visat sig framgångsrik [Hat97]. 

Det är nog inte ett alltför vågat påstående att hårdvarukomponenter åtminstone till 

viss del går sönder oberoende av varandra, se kapitel 3.2.8. 

[Lit87] framställer N-version programmering som en teknik som verkligen lämpar sig 

för säkerhetskritiska system och då även vad gäller mjukvaran. Framställningen görs 

via räkneexempel där de olika programversionerna antas vara oberoende av varandra 

[Lit87]. Antagandet är dock antagligen felaktigt då det gäller mjukvara. Ett av de mest 

omfattande experimenten som genomförts på området visar att antagandet är felaktigt 

med 99 % säkerhet [Kni90], se kapitel 3.2.8. 

N-version programmering utförs efter att designspecfikationen är skriven, vilket 

medför att fel i specifikationen inte hittas. Dessa fel är enligt [Lev95] i majoritet av de 

totala antalet fel som uppkommer under utvecklingen. I [Kni90] påpekas att det inte 

hjälper att utveckla de olika versionerna i olika programmeringsspråk eftersom felen 

ändå tycks bli beroende. Det hjälper inte ens att använda olika algoritmer eftersom fel 

ändå tycks uppstå på samma ställe, nämligen vid domängränser. 

Den differentierade designen kan leda till ett mer tillförlitlig system, men det finns 

också vissa negativa aspekter som bör uppmärksammas. Det krävs större resurser för 

att tillämpa denna teknik, inte enbart vad gäller design och kodning, utan även 

underhåll, uppgradering etc. Systemet blir också komplexare och svårare att förstå sig 

på. Det som vinns i minskat antal inträffade fel får alltså ställas i proportion till de 

ytterligare resurser som krävs för den differentierade designen [Gar99]. 

En ytterligare aspekt är omröstningsfunktionen. Finns inte en effektiv omröstningsfunktion, 

som på lämpligt sätt beräknar det gemensamma utdatat från de olika 

versionerna, kan hela tekniken ifrågasättas. Utbildningen på de personer som ingår i 

teamet är också av betydelse. Om alla har samma bakgrund är risken stor att dessa 

personer gör liknande fel. 

[Lev95] hävdar också att den ökade komplexiteten i sig kan medföra att nya fel 

uppkommer. Trots den ökade komplexiteten kan i vissa fall, där mycket höga krav 

ställs på systemet, N-version programmering vara befogad, men det ska inte ställas 

alltför hög tilltro till tekniken. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

3.7.4 Modellbaserad verifiering (MBV) 

Den grundläggande avsikten med modellbaserad verifiering är att med hjälp av en 

selektiv och resultatinriktad användning av formella metoder skapa förenklade 

modeller som används för att identifiera fel snarare än att skapa formella bevis för att 

ett program är korrekt [Glu98]. Tanken med modellbaserad verifiering är följaktligen 

att försöka ta tillvara på många av fördelarna med formella metoder, men samtidigt 

undvika dess nackdelar. Fördelen med formella metoder är att de tillhandahåller ett 

sätt att beskriva funktionaliteten som gör att den kan uttryckas på ett exakt sätt. 

Nackdelen är att det är tidsödande att skapa de bevis som de formella metoderna 

kräver. Modellbaserad verifiering eftersträvar att med hjälp av formella notationer 

konstruera en modell över det program eller den funktionalitet som ska undersökas. 

Den modell som byggs är tänkt att avspegla de aspekter som ska undersökas på ett så 

exakt sätt som möjligt utan att arbete läggs ned på att modellera resterande 

funktionalitet. 

Modellbaserad verifiering kan tillämpas tidigt i utvecklingen. Fördelen är att det då 

går att hitta designfel innan de implementerats. Dessutom kan värdefull information 

erhållas angående vilka delar av programmet som kan bereda svårigheter och därmed 

behöva utsättas för mer rigorös testning [Glu98]. 

Modellen ska återspegla väsentliga drag hos det som modelleras. Att skapa dessa 

förenklade modeller innebär att de viktiga delarna ska avbildas så exakt som möjligt 

medan de mindre viktiga ska abstraheras bort så långt det går. Följande fyra punkter 

bör beaktas innan modellen konstrueras [Glu98]: 

• Formalism – Hur exakta regler ska tillämpas för att beskriva modellen, alltså hur 

formell ska beskrivningen vara? Ökad formalism rekommenderas för 

säkerhetskritiska system. Det är dock dyrt och bör därför inte överdrivas. 

• Abstraktion – Vilka delar ska modelleras noggrant och vilka ska abstraheras bort? 

• Perspektiv – Vems perspektiv av den modellerade funktionaliteten ska modellen 

återspegla? 

• Inskränkningar – Hur stor del av systemet ska modellen omfatta? 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Model checking är ett exempel på hur modellbaserad verifiering kan användas där 

någon form av automatiska verktyg vanligtvis utnyttjas. Verktyget undersöker en 

modell utifrån ett antal specificerade krav som ställts på modellen. Om modellen 

uppfyller kraven svarar verktyget att modellen var korrekt, annars meddelas vad i 

modellen som orsakade att kraven inte uppfylldes. 

Modell 

Förväntade 

egenskaper 

Figur 3-29. Model checking 

Model 

checking 

Acceptans/ 

ej acceptans 

3.7.5 Regressionstestning 

Regressionstestning syftar till att undersöka huruvida förändringar i mjukvara medför 

nya fel. Testningen görs genom att utföra redan gjorda tester ytterligare en gång. 

Syftet med regressionstestning är alltså inte att testa den nya eller förändrade delen av 

mjukvaran, det som istället ska testas är om delar av mjukvaran som inte borde 

påverkas av förändringarna trots allt gör det. 

Regressionstestning medför inte lika mycket arbete utöver själva genomförandet av 

testningen som annan testverksamhet. Anledningen är att de testfall som ska användas 

redan är skrivna eftersom testerna utförts tidigare. Det här gör att arbetsinsatsen kan 

fokuseras kring genomförandet av testerna. Om kostnaderna för regressionstestning 

ska minskas är det således antalet tester som måste minskas. Ett sätt att göra detta kan 

vara att samla ihop flera ändringar som behöver göras, utföra dessa, och sedan 

genomföra regressionstestningen. Fördelen är att det räcker med att genomföra 

regressionstesterna en gång. En nackdel kan vara att om fel upptäcks så är det inte lika 

lätt att veta vilken ändring i mjukvaran som orsakade felet ifråga [Sco95]. 

Det är svårt att veta vilka testfall som kan hitta möjliga nya fel. Följaktligen är det 

också svårt att minska antalet testfall utan att försämra möjligheterna att upptäcka fel. 

En rad olika tillvägagångssätt för detta analyseras i [Gra98]. De mest effektiva (flest 

upptäckta fel per testfall) teknikerna benämns ”Safe Techniques”. Grundtanken 

bakom dessa är att alla testfall som exekverar delar av koden som har förändrats, 

raderas eller lagts till ska testas igen. Det är dock inte givet att det blir billigare med 

dessa tekniker. Det krävs nämligen en betydande arbetsinsats för att få fram vilka 

tester som ska ingå i regressionstesterna. I vissa fall kan det bli billigare att testa om 

alla testfallen, detta gäller speciellt om testerna i hög grad kan utföras automatiskt. Ett 

annat sätt att minska antalet tester är att göra en bedömning huruvida fel i den 

mjukvara som ändrats kan få allvarliga konsekvenser. Om bedömningen blir att det 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

inte kan få allvarliga konsekvenser behöver inte lika rigorös regressionstestning 

genomföras [Sco95]. Ett enkelt och billigt sätt att välja ut vilka testfall som ska 

användas i en sådan situation är att låta slumpen avgöra. 

De testtekniker som används vid regressionstestning är desamma som används vid 

tidigare testning av mjukvaran. Mycket av de arbete som gjordes då kan återanvändas, 

t.ex. testplaner, testfall, miljön som användes till testning och automatiserade tester. 

Det är därför viktigt att testfall m.m. uppdateras då de införda förändringarna tillför 

ny funktionalitet. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

3.8 Sammanfattning 

För att få en överblick av alla presenterade testtekniker finns i detta kapitel en 

sammanfattning i form av några tabeller. 

3.8.1 Vilka teststrategier används på vilka mjukvarudelar 

Testteknikerna delades upp i fyra grupper, där varje grupp benämns som en strategi, 

samt en grupp för de tekniker som inte kan sorteras in i de övriga fyra grupperna. I 

Tabell 3-10 visas vilka av de fyra strategierna som är lämpliga att använda i olika 

skeden av utvecklingen. Generellt sett kan sägas att någon form av statisk analys bör 

användas under hela utvecklingsförloppet. Strukturell testning görs i samband med att 

koden skrivs. För att göra funktionell testning måste det finnas körbara program eller 

moduler. Därför utförs de funktionella testerna i utvecklingens slutskede. Även den 

statistiska testningen bygger på att programmet eller systemet körs i sin helhet, varför 

också den testningen utförs i utvecklingens slutskede. 

Modul Program System 

Statisk analys Bör Bör Bör 

Strukturell testning Bör 

Funktionell testning Kan Bör Bör 

Statistisk testning Bör Bör 

Tabell 3-10. Vilka strategier som bör/kan användas under mjukvaruutvecklingen. 

3.8.2 Vem bör testa på vilken nivå 

Eftersom modulerna oftast testas med strukturella testtekniker, vilket innebär att 

djupare kunskaper krävs om kodens uppbyggnad, är det ofta programmeraren själv 

som testar på modulnivå. Då körbara program eller system ska testas görs det 

vanligen med funktionella testtekniker. De funktionella testerna innebär att program 

testas med avseende på vad de kan göra, inte hur de gör det. Eftersom de funktionella 

testerna inte kräver någon större kodkännedom om hur koden är implementerad kan 

det vara lämpligt att lägga ut den testningen på en oberoende testavdelning. 

Modul Program System 

Programmerare Bör Kan 

Oberoende testare Kan Bör Bör 

Tabell 3-11. Tabellen visar när programmerare och oberoende testare bör/kan delta i testningen. 

3.8.3 Sammanställning över testtekniker 

Innehållet i kapitel 3.3 till 3.7 kan vid första anblicken kännas en aning tungt. Av den 

anledningen har de testtekniker som beskrivs där sammanställts i Tabell 3-12 nedan. 

Tabellen informerar om syftet med respektive testteknik, vad som krävs för att kunna 

använda sig av tekniken samt hur omfattande testning som är lämplig att genomföra 

med den aktuella tekniken. Idén med tabellen är hämtad från [Sco95]. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Teknik Kapitel Syfte Krävs för 

Föreslagen grad av 

genomförande testning/analys 

Strukturella tester 

Control flow 3.3.2 Kontrollera interna flödet. Källkod, detaljerad Grentäckning 

testing (path) 

designspecifikation 

Data flow 3.3.3 Kontrollera att data används och Källkod, detaljerad Alla dubbla och enkla 

testing 

förändras på rätt sätt. 

designspecifikation sekvenser 

Looptestning 3.3.4 Kontrollera interna loopar. Källkod, detaljerad Fokusering på loopens 

designspecifikation gränsvärden 

Logikbaserad 3.3.5 Kontrollera intern logik. Källkod, detaljerad Alla kombinationer av 

testning 

designspecifikation villkor 

Funktionella tester 

Domäntestning 3.4.1 Kontrollera beteendet inom givna Exekverbar kod, Värden inom domänen, 

domäner och att domängränser är kravspecifikation gränsvärden och 

korrekta. 

otillåtna värden 

Tillstånds- 3.4.2 Kontrollera att övergångar mellan Exekverbar kod, Alla tillstånd 

testning 

tillstånd stämmer överens med det 

verkliga användningsområdet. 

kravspecifikation 

Logikbaserad 3.4.3 Kontrollera att logiken stämmer Exekverbar kod, Alla kombinationer av 

testning 

överens med det verkliga 

användningsområdet. 

kravspecifikation realistiska villkor 

Syntaxtestning 3.4.4 Kontrollera externa indata och Exekverbar kod, Alla klasser av indata 

information mellan interna 

gränssnitt. 

kravspecifikation och information 

Transaction 3.4.5 Kontrollera transaktionsflödet. Exekverbar kod, Grentäckning 

flow testing 



Felinjicering 3.5.1 Estimera testteknikers förmåga att Exekverbart kod, Iterativt tills 

påvisa fel samt antalet fel i koden. kravspecifikation, systemkraven är 

profiler över 

tänkbara fel från 

programmerare 

uppfyllda 

Random testing 3.5.2 Estimera antalet fel samt att hitta Exekverbar kod, Iterativt tills 

fel. 

kravspecifikation, systemkraven är 

användningsprofil, 

effektivt orakel 

uppfyllda 

Dubbla testlag 3.5.3 Estimera antalet fel samt att hitta Exekverbar kod, Tekniken 


fel. 

kravspecifikation rekommenderas endast i 

mindre omfattning 

Granskning 3.6.1 Identifiera felaktigheter i projektets Kravspecifikation Ska göras så fort något i 

och 

första faser. 

systemet förändras som 

walkthrough 

kan påverka systemets 

funktionalitet 

Inspektion 3.6.2 Undersöka kod för särskilda Källkod En eller flera 

egenskaper eller för att se om 

inspektioner, 

standarder följs. 

gruppbeslut om 

ytterligare granskning 

ska ske 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Inspektion (I0) 3.6.2 Undersöka den översiktliga 

designspecifikationen med 

kravspecifikationen som referens. 

Inspektion (I1) 3.6.2 Undersöka den detaljerade 

designspecifikationen med den 

översiktliga designspecifikationen 

som referens. 

Inspektion (I2) 3.6.2 Undersöka källkod med den 

detaljerade designspecifikationen 

som referens. 

Formella 

metoder 

3.6.3 Producera en korrekt och tydlig 

specifikation och eventuellt också 

bevis för att designen av systemet 

överensstämmer med 

specifikationen. 

Övriga 

Stresstestning 3.7.1 Undersöka hur robust systemet är 

och hur det beter sig vid ökade 

påfrestningar. 

Stresstestning 3.7.1 Hitta svagheter där systemet inte 

längre kan operera och undersöka 

återuppstartmekanismer. 

Cleanroom 3.7.2 Skapa korrekt kod redan innan 

testningen tar vid. 

N-version 

programming 

Modellbaserad 

verifiering 

(MBV) 

Regressionstestning 

3.7.3 Minska risken för feltolkningar i 

specifikationer och minska risken 

för att felaktigheter uppstår i 

driften. 

3.7.4 Skapa förenklade modeller som 

används för att identifiera fel. 

3.7.5 Kontrollera att förändringar inte 

har påverkat mjukvaran på något 

oväntat sätt. 

Tabell 3-12. Sammanställning över testtekniker. 

Kravspecifikation, 

översiktlig 


Detaljerad 


och översiktlig 


Källkod, detaljerad 


Specifikationer, 

goda matematiska 

kunskaper 

Exekverbar kod, 


Exekverbar kod, 


Statistiska data 

utifrån användarfall 

En eller flera 

inspektioner, 



ska ske 


inspektioner, 



ska ske 


inspektioner, 



ska ske 

Beror på hur högt 

ställda kraven är på 

systemet 

En körning för varje 

omarbetning 

Testa tills svagheter 

inom kravens gränser är 

kartlagda 

Inga rekommendationer 

ges då det finns vitt 

skilda uppfattningar i 

frågan 

Specifikationer Beror på hur högt 


systemet 

Specifikationer, 

kunskaper om 

formella metoder 

Beror på vilka 

teststrategier som 

används 

Beror på hur högt 


systemet 

Fortsätt tills inga nya 

fel påträffas 

3.8.4 Sammanställning över vad som uppnås med hjälp av olika testtekniker 

I Tabell 3-13 listas en rad olika egenskaper som kan uppnås genom att testa med olika 

typer av testtekniker. Innehållet i tabellen ska inte ses som en exakt rekommendation 

utan endast som en form av vägledning för vad olika testtekniker kan bidra med. Idén 

till tabellen är hämtad från [Sco95]. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Karaktärsdrag Frågor som ska besvaras Föreslagna testtekniker 

Acceptans Klarar systemet av de händelser som det kommer att Funktionella 

utsättas för i verkligheten? 

(Do, Ti, Lb, Sy, Tf) 

Tillgänglighet Hur mycket kommer systemet att vara nere p.g.a. 

• dålig pålitlighet? Statistiska (Fi, Ra) 

• överbelastning? Övriga (St) 

Pålitlighet Hur stor är sannolikheten att det inträffar en incident under 

en given exekveringstid? 

Robusthet Finns tillräckligt stöd för återhämtning efter inträffad 

incident? 

Statistiska (Ra) 

Statisk analys (In, Gw) 

Övriga (St) 

Tolereras felaktiga transaktioner? Funktionella (TF, Sy) 

Tolereras felaktiga inmatningar? Funktionella (Do, Sy) 

Behandlas oväntade tillstånd riktigt? Funktionella (Lb, Sy) 

Hur klarar systemet hög belastning? Övriga (St) 

Prestanda Är tidskrav på enskilda moduler uppfyllda? Strukturella (Cf, Lo) 

Hur påverkar extremvärden prestanda? Funktionella (Do) 

Är tidskrav på enskilda moduler uppfyllda? Strukturella (Cf, Lo) 

Fullständighet Behandlas alla krav i designen? Statisk analys 

(Gw, In, Fm) 

Är implementationen fullständig med avseende på 

designspecifikationer? 

Statisk analys (In) 

Noggrannhet och 

riktighet 

Har alla kombinationer av villkor och domängränser 

behandlats? 

Funktionella (Do, Lb, Sy) 

Behandlas alla möjliga transaktioner? Funktionella (Tf) 

Behandlas alla möjliga tillstånd? Funktionella (Ti) 

Är interna beräkningar tillräckligt noggranna och riktigt 

gjorda? 

Strukturella (Df) 

Är slutresultaten riktigt beräknade och tillräckligt exakta? Funktionella (Tf) 

Komplexitet Är implementationslösningar onödigt komplexa? Statisk analys (Gw, In, Fm) 

Validering Råder spårbarhet mellan krav, design och implementation? Statisk analys (In, Fm) 

Har lämpliga implementationslösningar valts? Statisk analys (In, Fm) 

Överensstämmer programstruktur med designen? Strukturella (Cf, Df, Lo, Lb) 

Överensstämmer programmets funktionalitet med de 

funktionalitetskrav som finns i kravspecifikationen? 

Uppför sig systemet korrekt vid hög belastning? Övriga (St) 

Har förändringar i mjukvaran medfört oönskade effekter? Övriga (Rg) 

Funktionella 

(Do, Ti, Lb, Sy, Tf, Nv, Mb) 

Cf Control flow testing In Inspektion Rg Regressionstestning 

Df Data flow testing Lb Logikbaserad testning Sy Syntaxtestning 

Do Domäntestning Lo Looptestning St Stresstestning 

Fi Felinjicering Mb Modellbaserad verifiering Ti Tillståndstestning 

Fm Formella metoder Nv N-version programmering Tf Transaction flow testing 

Gw Granskning och walkthrough Ra Random testing 

Tabell 3-13. Sammanställning över vad som uppnås med hjälp av olika testtekniker. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

4 Testteknikers inverkan på felsannolikhet 

IEC 61508 (Functional safety of PE safety-related systems) är en standard som 

behandlar aspekter som bör beaktas då programmerbar elektronik används i 

säkerhetskritiska system. Standarden behandlar hela den säkerhetskritiska livscykeln, 

från krav till verifiering- och valideringsarbete. Det ges bl.a. förslag på vilka typer av 

testtekniker som bör användas för att uppnå en önskad felsannolikhet i systemet. Det 

är på sin plats att påpeka att standarden är mycket kontroversiell och att den version 

som använts för denna rapport inte är en färdigreviderad utgåva av standarden. I den 

här rapporten kommer endast vissa delar av standarden att presenteras. För att få en 

helhetsbild hänvisas till den fullständiga standarden. 

Anledningen till att standarden tas upp här är att den speglar aspekter som kan vara 

viktiga att ha i åtanke vid utveckling av ett mjukvarubaserat börssystem. I kapitel 4.3 

presenteras en koppling mellan vilka testtekniker som bör användas för riskanalysens 

olika frekvensgrader. Tanken är att kopplingen ska ge förslag och rekommendationer 

på vilka typer av testtekniker som bör tillämpas för att nå en acceptabel felsannolikhet 

i systemet. Det kan sägas att i detta kapitel kopplas riskanalysen i kapitel 2 ihop med 

sammanställningen av testtekniker i kapitel 3. Kopplingen är gjord utifrån IEC 61508. 

Det bör påpekas att en sådan koppling är svår att göra. De siffror och resultat som 

presenteras ska inte ses som exakta eller som den enda möjliga lösningen. 

4.1 Uppdelning i kritikalitetsnivåer enligt IEC 61508 

För att kunna ge rekommendationer för hur utvecklingsarbetet bör ske delar 

standarden först upp kritikaliteten i fyra olika nivåer. Kritikalitetsnivåerna, som 

härefter benämns SIL (Safety Integrity Level), anger sannolikheten för en allvarlig 

incident per timme. 

Safety Integrity Sannolikhet för en allvarlig 

Level 

incident per timme 

4 ≥ 10 -9 till < 10 -8 

3 ≥ 10 -8 till < 10 -7 

2 ≥ 10 -7 till < 10 -6 

1 ≥ 10 -6 till < 10 -5 

Tabell 4-1. Uppdelning i kritikalitetsnivåer enligt IEC 61508. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

4.2 Mjukvaruverifiering delvis baserad på IEC 61508 

I detta kapitel ges rekommendationer huruvida olika testtekniker kan vara användbara 

under olika skeden av mjukvaruutvecklingen. Rekommendationerna är delvis 

grundade på standarden IEC 61508. I vissa fall har justeringar gjorts för att 

rekommendationerna bättre ska passa upplägget i denna rapport. 

Det bör påpekas att en koppling mellan testtekniker och förmågan att hitta fel är 

mycket svår att göra. Vissa typer av testtekniker kan vara särskilt lämpade för 

särskilda mjukvarusystem. Standarden påpekar även den svårigheten och menar att 

det knappt är möjligt att göra en exakt analys över hur incidenter ska förhindras 

inträffa. Tabellerna nedan ska därför ses som en riktlinje och inte som en precis 

vetenskap. 

I tabellerna förekommer följande förkortningar. 

SIL Safety Integrity Level, se Tabell 4-1 för definitioner. 

SR Tekniken/strategin är starkt rekommenderad för den berörda SIL-nivån. 

R Tekniken/strategin är rekommenderad för den berörda SIL-nivån. 

- Ingen rekommendation ges varken för eller emot ett användande av 

tekniken/strategin. 

4.2.1 Översiktlig mjukvaruverifiering 

Tabell 4-2 ger en övergripande bild av mjukvaruverifieringen. Den övre delen av 

tabellen visar testningens olika strategier och den undre visar testningens livscykel. 

Tabellen hänvisar i sin tur till andra tabeller längre ner i kapitlet. 

Mjukvaruverifiering 

Strategi Referens SIL 1 SIL 2 SIL 3 SIL 4 

Statistisk testning Kap 3.5 - R R SR 

Statisk analys Tabell 4-3 R SR SR SR 

Dynamisk analys Tabell 4-4 R SR SR SR 

Testningens livscykel 

Modultest Tabell 4-5 

Integrationstest Tabell 4-6 

Systemtest Tabell 4-7 

Tabell 4-2. Mjukvaruverifiering. 

I de första faserna av mjukvaruutvecklingen är statisk analys den viktigaste 

verifieringsstrategin. Då kod har producerats och någonting är exekverbart 

koncentreras istället testningen på den dynamiska analysen. Verifieringen blir sällan 

bra om enbart en av strategierna används. Det är kombinationen av flera olika 

strategier som leder fram till en lyckad mjukvaruverifiering. För att uppnå en SILnivå 

i tabellen ovan bör alla tre nämnda strategier användas. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

4.2.2 Verifiering uppdelad i statisk- och dynamisk analys 

Tabell 4-3 och Tabell 4-4 behandlar verifieringens uppdelning i den statiska och 

dynamiska analysen. Till den statiska analysen hör sådan verifiering då moduler eller 

program inte exekveras. Tekniker som brukar räknas till den statiska analysen är 

granskning, walkthrough, inspektion och formella metoder. Tabellen innehåller några 

tekniker som i tidigare kapitel är insorterade under den dynamiska analysen. Även om 

dessa tekniker vanligtvis räknas till den dynamiska analysen kan de utföras statiskt, 

d.v.s. utan att moduler eller program exekveras. De kapitel som dessa tekniker 

hänvisar till bygger på ett dynamiskt synsätt, men teorin går hand i hand och någon 

närmare beskrivning under det statiska kapitlet har därför inte gjorts. 


Teknik Referens SIL 1 SIL 2 SIL 3 SIL 4 

Granskning och walkthrough Kap 3.6.1 SR SR SR SR 

Inspektion Kap 3.6.2 - R R SR 

Formella metoder Kap 3.6.3 - R R SR 

Control flow analysis Kap 3.3.2 R R SR SR 

Data flow analysis Kap 3.3.3 R R SR SR 

Domänanalys Kap 3.4.1 R R SR SR 

Tabell 4-3. Statisk analys. 

Den dynamiska analysen karaktäriseras av att en modul eller ett program exekveras. I 

tabellen ovan ges en översiktlig rekommendation över vilka testtekniker som bör 

användas för olika SIL-nivåer. Då strukturell och funktionell testning benämns syftar 

det till samtliga tekniker som beskrivits i kapitel 3.3 respektive 3.4. Det är således inte 

två specifika testtekniker utan ett samlingsnamn över ett antal testtekniker som 

används på liknande sätt. Den strukturella testningen grundar sig på systemets interna 

struktur medan funktionell testningen verifierar att systemets beteende 

överensstämmer med specifikationerna. 

Dynamisk analys 


Strukturell testning Kap 3.3 R SR SR SR 

Funktionell testning Kap 3.4 R SR SR SR 

Felinjicering Kap 3.5.1 - R R R 

Stresstestning Kap 3.7.1 R R R SR 

Tabell 4-4. Dynamisk analys. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

4.2.3 Verifiering i olika faser av testningen 

Följande tre tabeller ger rekommendationer för vilka tekniker/strategier som bör 

användas för olika kritikalitetsnivåer i de tre testfaserna modultestning, 

integrationstestning och systemtestning. Det är på sin plats att återigen påpeka att 

verifieringen bör utgöras av en kombination av strategier. 

Modultestning 


Strukturell testning Kap 3.3 SR SR SR SR 

Funktionell testning Kap 3.4 R R SR SR 


Tabell 4-5. Modultestning. 

Integrationstestning 


Strukturell testning Kap 3.3 R R R SR 

Funktionell testning Kap 3.4 SR SR SR SR 


Tabell 4-6. Integrationstestning. 

Systemtestning 


Funktionell testning Kap 3.4 SR SR SR SR 

Statistisk testning Kap 3.5 R R SR SR 

Stresstestning Kap 3.7.1 R R R SR 

Tabell 4-7. Systemtestning. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

4.3 IEC 61508 kopplad till riskvärderingsmatris för börssystem 

De SIL-nivåer som benämns i föregående kapitel anger sannolikheten för att en 

allvarlig incident ska inträffa per timme. Eftersom en liknande definition används för 

definitionen av frekvensskalan i den riskanalys som gjordes i kapitel 2.3, borde det 

därför gå att koppla riskvärderingsmatrisens frekvensskala till SIL-nivåerna. 

Figur 4-1 presenterar en koppling mellan IEC 61508:s SIL-nivåer och riskanalysens 

frekvensgrader i kapitel 2.3.1. Eftersom sannolikheten för att ett fel inträffar ökar om 

flera likadana system finns i drift samtidigt, tas även tio och hundra börssystem med i 

tabellen. Det är antagligen inte rimligt att hela hundra system finns i drift samtidigt, 

tio system är en mer rimlig siffra. 

10 -2 10 -3 10 -4 10 -5 10 -6 10 -7 10 -8 10 -9 

IEC 61508 SIL 1 SIL 2 SIL 3 SIL 4 

1 system Frekvent Trolig Sannolik Försumbar Osannolik 



Figur 4-1. Koppling mellan SIL-nivåer och frekvensskalan i riskanalysen för ett börssystem. Enheten i 

figuren är antal fel per timma. 

Det framgår tydligt att definitionerna av SIL-nivåerna är högt ställda i förhållande till 

definitionen av börssystemets frekvensskala. För att komma upp till SIL 1 då tio 

system är i drift måste frekvensgraden vara sannolik. 

Genom att applicera kapitel 4.2 på riskanalysen kan förslag erhållas som säger hur 

börssystemet ska testas för att incidenter inte ska inträffa oftare än vad som 

accepteras. Ett exempel får illustrera hur appliceringen kan gå till. 

Konsekvensen av ett handelsstopp på ett par timmar klassificeras som kritiskt. Enligt 

riskvärderingsmatrisen i kapitel 2.3.2 måste en sådan händelse betraktas som osannolik för att 

risken ska accepteras. Kopplingen till SIL-nivåer erhålls ur Figur 4-1. I tabellen kan det avläsas att 

om tio system är i drift klassificeras ett handelsstopp på ett par timmar som SIL-nivå 2 eller 3. 

Genom att titta i kapitel 4.2 kan slutligen råd fås om vilka testtekniker som bör användas för att 

uppnå SIL-nivå 2 eller 3, d.v.s. för att uppnå en acceptabel risknivå för den berörda konsekvensen. 

Liknande förfarande kan användas för andra incidenter i riskanalysen. Det bör dock 

påpekas att resultatet enbart ska ses som en ungefärlig fingervisning. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

5 Diskussion och slutsats 

I detta kapitel reflekteras det över slutsatser och iakttagelser som har uppdagats under 

arbetets gång. Först ges några punkter som diskussionerna kretsar runt. 

• Börssystemets roll i samhället 

• Myndighetens inblandning 

• Begreppet felsannolikhet för mjukvara 

• Mätetal för felbegrepp inom mjukvara 

• Partitionering och klassificering av mjukvara 

• Återkoppla testningen till felens ursprung. 

• Kommentarer och förslag på användningssätt av IEC 61508 

• Fortsatta studier 

Kapitlet avslutas med ett resonemang runt den frågeställning som presenterades i 

början av rapporten. 

5.1 Diskussion av arbetet 

Nedan förs diskussioner som inte direkt leder fram till svaret på frågeställningen. De 

utgör likväl en viktig del av rapporten. 

5.1.1 Börssystemets roll i samhället 

Det kan diskuteras om ett börssystem bör klassas som ett säkerhetskritiskt system. I 

de flesta fall leder allvarliga incidenter i säkerhetskritiska system till fara för 

människoliv. Enligt ovanstående är det tveksamt om ett börssystem bör klassas som 

säkerhetskritiskt eftersom det inte utgör någon primär fara för människoliv. Men 

påståendet att säkerhetskritiska system enbart ska beröra människoliv är kanske inte 

så väl genomtänkt. Ett säkerhetskritiskt system skulle istället kunna vara ett system 

som på något sätt utgör fara för människan och det samhälle hon lever i. Med den 

definitionen innefattas även system som på något sätt kan utsätta t.ex. miljön för fara, 

men även system vars konsekvenser kan utgöra ekonomisk fara för samhället. 

Omsättningen på Stockholmsbörsen uppgår till tiotals miljarder kronor per dag 

[OMy99]. Med dessa fakta i bakgrunden är det inte svårt att förstå att det finns stora 

ekonomiska risker förknippade med börssystem. Då fel uppstår kan de få vidsträckta 

konsekvenser som inte enbart drabbar börssystemets leverantör, även den enskilde 

människan eller hela samhället kan drabbas. Ett börssystem är således förknippat med 

stora ekonomiska risker varför det också kan anses vara säkerhetskritiskt. 

Begreppet varumärke återkommer i riskanalysens konsekvensgrader, se kapitel 2.3.1. 

Vissa liknelser kan göras mellan varumärket och människoliv, som är den mer vanligt 

förekommande definitionen för säkerhetskritiska system. Varumärket kan liksom 

människan skadas och om förtroendet för systemet av någon anledning skadas så 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

allvarligt att en fortsatt användning och försäljning blir omöjlig kan det i analogins 

namn sägas att varumärket dör. Dock medför inte ett dött varumärke något som är 

samhällskritiskt. Ett dött varumärke drabbar främst företaget och inte samhället i 

övrigt. 

5.1.2 Myndighetens inblandning 

Under de senaste åren har förutsättningarna för handel med värdepapper genomgått 

stora förändringar. Omsättningen ökar kraftigt från år till år samtidigt som 

investerarna och aktörerna blir allt fler. En av anledningarna till det ökande antalet 

investerare är att antalet privatpersoner som handlar över börsen tilltar. Idag har de 

flesta medborgarna någon form av besparing knuten till börsen. Det kan vara 

besparingar i en aktieportfölj men också aktierelaterade pensionsbesparingar. 

Eftersom så många människor på något sätt är i kontakt med börsen kan en allvarlig 

incident få stora konsekvenser. Ofta räcker det med att en allvarlig incident inträffar 

för att trycket ska öka på politiker som i sin tur påverkar myndigheterna. Detta 

tillsammans med det faktum att förutsättningarna för börshandeln hela tiden 

förändras, kan leda till att högre krav kommer att ställas på börssystemen även från 

myndigheternas sida. 

I Sverige är det Finansinspektionen som ska bidra till finanssektorns stabilitet och 

effektivitet samt verka för ett gott konsumentskydd. Här kan en parallell dras till 

Statens kärnkraftsinspektion (SKI) vars uppgift är att agera som en övervakare och 

pådrivare för att kraftbolagen själva tar ansvaret att upprätthålla en hög säkerhetsnivå 

på kärnkraftverken. Syftet med myndigheten SKI:s arbete är framför allt att få 

kraftbolagen att tänka igenom sina arbets- och utvecklingsprocesser till skillnad från 

Finansinspektionen som däremot inte alls lägger sig i de arbetsmetoder som används 

vid utvecklingen av börssystem. Det är dock inte omöjligt att finansinspektionen i 

framtiden kommer få ökade befogenheter och därmed agera på liknande sätt som SKI 

när det gäller att driva på för att säkerställa hög kvalité på mjukvaruutvecklingen av 

börssystemen. För att belysa vart utvecklingen är på väg följer ett citat ur 

Finansinspektionens verksamhetsplan för år 2001: 

”Värdepappershandelns samhällsekonomiska betydelse kommer allt mer i fokus 

samtidigt som Internet och annan ny teknik och nya metoder i handeln kräver 

anpassning av tillsyn och övervakning… 

…Tillsynsmetodiken avseende börser och andra marknadsplatser är därför under 

utveckling. En mycket viktig del i den nya börstillsynen är kontrollen av de 

operationella riskerna i börser och clearingorganisationer, främst inom OMgruppen.” 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

5.1.3 Felsannolikhet för mjukvara 

En svaghet med kopplingen mellan riskvärderingsmatrisen och testteknikerna som 

görs via standarden IEC 61508 i kapitel 4.3 är att den bygger på begreppet 

felsannolikhet, d.v.s. incidenter per tidsenhet. Det bör påpekas att även sannolikheten 

för s.k. ’fail on demand’ tas upp, som används för system vilka inte är i kontinuerlig 

drift. Eftersom börssystem är i kontinuerlig drift används inte detta mätetal här. 

Det kan diskuteras om det överhuvudtaget är möjligt att ange felsannolikhet för 

mjukvara. I kapitel 3.2.8 samt i bilaga A.2 framhävs att mjukvara inte slits på samma 

sätt som hårdvara. För system baserade på hårdvara beräknas felsannolikheten 

utgående från statistik på felsannolikhet relaterat till varje enskild komponent som 

ingår i systemet. Statistiken talar då om hur stor sannolikheten är att en viss 

komponent är utsliten, alltså innehåller fel, givet en viss användning. Sådana 

beräkningar är betydligt svårare att göra för mjukvara då den inte åldras och slits. Fel i 

mjukvara finns där redan från början vilket innebär att det alltså inte är slumpen som 

avgör när den slitits ut och fel uppstår. Det som däremot talar för att ange 

felsannolikhet för mjukvara är att mjukvara kan används på många olika sätt och 

utsätts för många olika värden på indatan. Därför är det en viss sannolikhet att 

programmet ska använda en viss kombination av indata, vilket medför en viss 

sannolikhet för att ett fel exekveras. 

I bilaga A.2 framgår den syn som SAAB har på felsannolikhet för mjukvara då de 

utvecklar mjukvara till sina flygplan. Deras åsikt är att antingen är mjukvaran felfri 

vilket ger en felsannolikhet på 0 % eller så innehåller den fel vilket medför en 

felsannolikhet på 100 %. Vilket alternativ som antas gälla beror på hur omfattande 

verifiering och validering som genomförts. Standarden RTCA/DO-178B som används 

flitigt på SAAB, se bilaga A.3, förkastar dock inte begreppet felsannolikhet för 

mjukvara. Dock påpekas att det vid tidpunkten då standarden skrevs inte fanns några 

metoder som var lämpliga för att uppskatta felsannolikhet för de låga nivåer som 

krävs för säkerhetskritiska system. 

I bilaga A.1 framgår hur problemet med felsannolikhet för mjukvara tacklats av 

Forsmarks kraftbolag. De anser att det inte går att garantera helt felfri mjukvara. För 

att kringgå det problemet används inte enbart mjukvara i system som är av största vikt 

för kärnkraftverkets säkerhet. 

Felsannolikhet för mjukvara är ett begrepp som är betydligt mindre accepterat än för 

hårdvara. Det tycks idag inte finnas några entydiga svar på frågan hur mjukvara ska 

utvecklas eller testas för att möjliggöra användandet av felsannolikheter vid så låga 

nivåer som krävs för de mest säkerhetskritiska tillämpningarna. Av denna orsak råder 

viss tveksamhet till att införa mjukvarubaserade lösningar i dessa branscher. Det blir 

mycket dyrt, om ens möjligt, att verifiera och validera säkerhetskritiska system i en 

sådan utsträckning som krävs. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

5.1.4 Mätetal för felbegrepp inom mjukvara 

Det finns även andra mätetal än felsannolikhet, d.v.s. antal incidenter per tidsenhet, 

som kan användas för diskussioner kring mjukvarans grad av verifiering och 

validering. Exempel på mätetal kan till exempel vara antal fel per kodrad eller om det 

gäller börssystem antalet incidenter per transaktion. 

Låt oss jämföra mätetalet antal incidenter per transaktion med mätetalet som används 

i rapporten, d.v.s. antal incidenter per tidsenhet. Antag att det finns två identiska 

börssystem som används under lika lång tid. Antag också att samma fel finns i den 

kod som utgör systemen. Om det första systemet utsätts för mycket hårdare belastning 

än det andra är det troligt att sannolikheten ökar för att fel exekveras i det första 

systemet. Om belastningen varierar kraftigt är det måhända bättre med ett mätetal som 

tar mer hänsyn till hur mycket systemet verkligen används. Ett sådant mätetal kan då 

vara antal incidenter per transaktion. Anledningen till att mätetalet incidenter per 

tidsenhet ändå används i rapporten är dels att framställningen blir mer generell, men 

framförallt är det mätetalet betydligt mer förekommande i litteraturen. 

Vi har i denna rapport fokuserat på mätetal kring tillförlitligheten för ett börssystem, 

d.v.s. fel gentemot specifikationen. Andra mätetal som kan vara av intresse är 

systemets tillgänglighet, d.v.s. uptime, och medeltiden till fel. Uptime är ett mätetal 

som kunder ofta ställer krav på. Att försöka påvisa vad testtekniker kan tänkas få för 

inverkan på uptime är dock något som ligger utanför denna rapport. För att göra en 

sådan koppling krävs inte bara att testteknikers inverkan på felsannolikheter kartläggs, 

det krävs också kunskaper om hur mycket de fel som förekommer eventuellt påverkar 

uptime. Ett fel behöver ju inte leda till att systemet går ner. 

5.1.5 Partitionering och klassificering av mjukvara 

En gemensam nämnare för mjukvaruutvecklingen, som framkom under studiebesök 

inom flyg- och kärnkraftbranschen, är fördelarna med att klassificera mjukvara efter 

kritikalitetsnivå. För att det ska vara givande bör mjukvaran först partitioneras, d.v.s. 

delas upp i olika delar. Varje partition kan sedan klassificeras efter hur kritisk 

funktionalitet som ingår i den partitionen. Syftet med att partitionera mjukvara är att 

fel som finns i en partition inte ska sprida sig vidare och påverka funktionalitet inom 

andra partitioner. Felens konsekvenser ska alltså begränsas till den egna partitionen. 

Ett resultat av detta är att olika nivåer av felsannolikhet kan accepteras för olika 

partitioner av mjukvaran. 

Kan inte mjukvaran partitioneras, d.v.s. om följderna av eventuella fel inte går att 

kapsla in, kan det vara farligt att försöka klassificera mjukvaran efter olika 

kritikalitetsnivåer. Anledningen är att det kan uppstå en falsk säkerhet att kritisk 

funktionalitet är väl testad fast så inte är fallet. Incidenter kan tänkas inträffa i den 

kritiska funktionaliteten eftersom den är beroende av annan mindre kritisk 

funktionalitet som genomgått mindre rigorös testning. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Efter resonemanget om felsannolikheter i kapitel 5.1.3 är det kanske inte rimligt att 

klassificera olika delar av mjukvaran efter klasser med exakta definitioner av 

felsannolikhet, som t.ex. SIL-nivåerna i kapitel 4.1. Däremot kan olika delar av 

mjukvaran klassificeras efter hur allvarliga konsekvenser ett eventuellt fel i den 

partitionen kan leda till. Sådana klassificeringar görs t.ex. både i flyg- och 

kärnkraftbranschen. En vinst med att klassificera mjukvaran är att den kan bidra till en 

effektivisering genom att inte onödigt mycket arbete läggs ner på att verifiera och 

validera mindre viktiga partitioner. Om en klassificering inte är möjlig måste 

verifiering och validering göras för hela mjukvaran på den nivån som krävs för den 

mest kritiska delen av systemet. 

5.1.6 Återkoppla testningen till felens ursprung 

När tester genomförts på ett program och ett antal fel har lokaliserats som 

förhoppningsvis också åtgärdats är det viktigt att följa upp felen. Bara för att felen är 

åtgärdade ska de inte falla i glömska utan att man lärt sig något av de misstag som 

begåtts. Går det att reda ut varför felen uppstod kan brister i utvecklingsarbetet lyftas 

fram. På så sätt kan testningen användas till att förbättra utvecklingsarbetet så att inte 

samma fel görs om i framtiden. 

5.1.7 Kommentarer och förslag på användningssätt av IEC 61508 

I kapitel 4.3 relateras SIL-nivåer till en riskvärderingsmatris genom att dess 

frekvensgrader mappas mot den definition som IEC 61508 använder för de olika SILnivåerna. 

Det kan argumenteras huruvida det är rätt att använda standarden på ett 

sådant sätt. Definitionen av SIL-nivå 4 anger att en allvarlig incident endast får 

inträffa 10 -9 gånger per timme, se Tabell 4-1. I rapporten har det påpekats att det inte 

går att nå en lägre felsannolikhet än 10 -5 incidenter per timme enbart grundat på 

testning. Det finns därför inte några bevis för att en användning av SIL-nivåerna 

verkligen ger de låga felsannolikheterna som standarden hävdar. Standarden är 

dessutom inte enbart utformad för mjukvarubaserade börssystem vilket förordar en 

restriktiv användning. 

Med ovanstående resonemang i åtanke är det kanske lämpligare att använda SILnivåerna 

på ett annat sätt. Ett sätt att dra nytta av SIL-nivåerna kan vara att jämföra 

IEC 61508:s rekommendationer med de testtekniker som används under testningen. 

På så sätt kan en uppfattning fås om var på SIL-skalan testningen ligger. Om det 

uppenbaras att vissa delar av verifierings- och valideringsarbetet inte uppnår den 

önskade SIL-nivåns rekommendationer kan det vara lämpligt att lägga mer resurser på 

just den delen. Går det inte att identifiera några speciella delar av utvecklingsarbetet 

som avviker från eftersträvad SIL-nivå kan nivåerna ändå utnyttjas. Detta genom att 

antingen höja eller sänka målsättningen en SIL-nivå. Istället för att stirra sig blind på 

de siffror som anger de olika SIL-nivåerna borde således nivåerna jämföras mot 

varandra. Det kan göras utan hänsyn till SIL-nivåernas felsannolikheter eftersom 

nivåerna då används relativt varandra. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

5.1.8 Fortsatta studier 

I några av kapitlen bereder rapporten väg för nya frågeställningar. Anledningen till att 

svaren till dessa frågeställningar inte behandlats mer ingående beror helt på att tiden 

för genomförandet av examensarbetet inte tillåter sådana utsvävningar. Nedanstående 

punkter är förslag på områden där fortsatt arbete kan vara av intresse. 

• Partitionera systemet och klassificera de olika partitionerna efter kritikalitatsnivå. 

• Undersök vilka aktiviteter som görs idag angående verifiering och validiering. 

Koppla eventuellt resultatet av undersökningen till någon standard som 

klassificerar mjukvara efter kritikalitetsnivå. 

• Testning, som den här rapporten fokuserar på, är en av aktiviteterna för att 

verifiera och validera. En liknande studie kan kanske göras för andra aktiviteter 

såsom design eller kravhantering. 

• Kartlägga fel som uppkommit i produktionen. Hur upptäcktes dessa fel, finns 

några gemensamma nämnare som kan tas tillvara i testarbetet. Går det att utifrån 

en sammanställning av gamla fel identifiera områden som borde genomgå 

utförligare testning. 

5.2 Diskussion runt frågeställning 

Det finns vitt skilda meningar om hur mjukvara ska testas. Hur stora resurser som 

används till testningen skiljer sig framförallt mellan olika branscher, men även mellan 

företag inom samma bransch. Något som reglerar testningens omfattning är vilka krav 

som ställs på mjukvaran. Hemsidor på Internet har vi t.ex. vant oss vid att de inte 

alltid fungerar. I börssystem, och andra system som bygger på säkerhetskritisk 

funktionalitet, ger kravbilden helt andra förutsättningar. Användarna, men även 

samhället som på ett eller annat sätt påverkas av systemet, förväntar sig att det 

fungerar. 

Även om vi bortser från branschernas skilda förutsättningar finns det ändå många 

olika tillvägagångssätt för att kontrollera mjukvarans beskaffenhet. Hur testningen ska 

gå till och vilka tekniker som ska användas finns det delade uppfattningar om. Det 

finns inte någon teknik som ensam kan hitta alla felen i mjukvaran, d.v.s. inga ’silver 

bullets’ existerar [Bei90]. Det finns inte heller någon universallösning i form av en 

kombination av testtekniker som skulle vara mest lämpad för olika typer av 

mjukvarusystem. Anledningen är att förutsättningarna för hur systemen ska fungera 

skiljer sig så mycket från varandra. En kombination av testtekniker som lämpar sig 

mycket bra för en typ av system är inte automatiskt lämplig för ett annat. 

Om tidsbrist uppstår under mjukvaruutvecklingen kan det vara lätt hänt att det slarvas 

med den statiska analysen. Projektledaren vill snabbt komma upp på banan och sätta 

igång. En uppenbar risk med ett sådant arbetssätt är att de specifikationer, som ligger 

till grund för implementationen, blir tvetydiga och oklara. Utvecklarna skapar då 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

något som de själva anser är korrekt men som i själva verket kanske inte alls 

överensstämmer med den egentliga avsikten. En diffus formulering i en specifikation 

kan leda till att fel uppstår i kommande faser. Felen kan i sin tur förorsaka fler fel 

vilket resulterar i en kaskad av nya fel, se Figur 5-1. 


Figur 5-1. Om ett fel uppstår tidigt i utvecklingen kan det leda till att flera följdfel uppstår i kommande 

utvecklingsfaser. Det bör också poängteras att dessa fel kan vara svåra att hitta eftersom testerna 

utförs mot de eventuellt felaktiga specifikationerna. 

Att i ett senare skede av projektet gå tillbaka och rätta till fel som uppstått i de tidigare 

faserna har visat sig vara mycket kostsamt [Per95], se Figur 5-2. Det är därför särskilt 

viktigt att det statiska analysarbetet i projektets första faser tas på fullaste allvar. 

Relativ kostnad för att åtgärda ett fel 

1 



3-6X 

10X 

Design Implementation 


15-70X 


40-1000X 

Testning Drift 

Figur 5-2. Kostnaden för att åtgärda ett fel ökar ju längre utvecklingen pågår utan att felet hittas 

[Gil93]. Kostnaden anges relativt kostnaden för ett fel som hittas i kravidentifieringen. 

__________________________________________________________________________________________ 





___________________________________________________________________________ 

Även om stora resurser satsas på den statiska analysen räcker antagligen inte det för 

att erhålla en pålitlig mjukvara med en acceptabel felintensitet. Den statiska analysen 

bör följas av en dynamisk analys, d.v.s. testning som utgår från exekvering av 

programkod. Här finns en uppsjö av olika testtekniker som alla är mer eller mindre 

bra på sina respektive områden. Trots att det under lång tid har tvistats om vilka 

tekniker som är att föredra finns ännu inte något entydigt svar att tillgå. De flesta 

verkar vara eniga om att de funktionella testerna är en viktig del av verifieringsarbetet 

eftersom det är via dessa som systemet testas mot de ursprungliga kraven. 

Användandet av de strukturella testerna, som verifierar kodens uppbyggnad, behöver 

t.ex. enligt standarden RTCA/DO-178B inte vara lika omfattande för mindre kritisk 

funktionalitet. 

Var i projektets skede som tyngdpunkten i verifieringen ska läggas ner skiljer sig från 

mjukvara till mjukvara. Det viktiga är att ha en kontinuerlig verifieringsprocess, från 

att arbetet med kravspecifikation påbörjas till att den slutgiltiga produkten är färdig, 

och att hitta en kombination av testtekniker som passar det specifika systemet. 

5.2.1 Slutsats 

Rapportens frågeställning lyder, 

Vilka testtekniker förordas givet en viss kritikalitet på mjukvaran? 

Rapporten innehåller inte några klara och tydliga svar på frågeställningen eftersom 

det inte finns någon universallösning som passar alla mjukvarubaserade börssystem. 

Testtekniker är mer eller mindre bra på sina respektive användningsområden. 

Teknikerna hittar olika typer av fel varför det är viktigt att testa mjukvaran på olika 

sätt. Det är först när en kombination av testtekniker används som en någorlunda 

heltäckande verifiering är möjlig. Att fullständigt testa mjukvaran är som tidigare 

påpekats dock omöjligt. 

Svårigheten med begreppet felsannolikhet för mjukvara har redan diskuterats. Det är 

naturligtvis svårt att ange hur en mjukvara ska testas för att en viss felsannolikhet ska 

uppnås. Från den koppling som presenteras i kapitel 4.3 kan rekommendationer av 

lämpliga testtekniker fås för olika kritikalitetsnivåer. Det bör påpekas att kopplingen 

mellan felsannolikhet och testtekniker inte ska ses som varken en exakt eller den enda 

möjliga lösningen på frågeställningen. Kopplingen och mjukvaruavsnittet ska mer ses 

som en guide över befintliga testtekniker samt hur dessa kan användas. 

__________________________________________________________________________________________ 


Bilaga A 

A. Studie av säkerhetskritiska system 

I denna bilaga presenteras de studier som gjorts inom flyg- och kärnkraftbranschen. Syftet 

med studierna är att få en inblick i hur verifiering och validering av mjukvara går till i andra 

säkerhetskritiska branscher och att se om de kunskaper som inhämtats från 

litteraturundersökningar även är gångbara i verkligheten. 

Kärnkraftbranschen representeras här främst av Forsmarks kraftgrupp som driver Forsmarks 

kärnkraftverk i norra Uppland. Inom kärnkraften ställs det mycket höga krav på säkerheten 

eftersom ett kärnkrafthaveri skulle kunna få mycket allvarliga konsekvenser och drabba 

många människor. Ett besök på SKI, Statens Kärnkraftsinspektion, har också gjorts för att få 

myndighetens syn på verifiering och validering av mjukvara. 

Flygbranschen representeras av SAAB i Linköping där utvecklingen av JAS 39 Gripen sker. 

Ett militärt flygplan består av en hel del mjukvara som det ställs höga krav på. Styrsystemet är 

ett exempel på en kritisk applikation som genomgår omfattande verifiering och validering 

under utvecklingsarbetet. Bilagan avslutas med en sammanfattning av RTCA/DO-178B som 

används som en standard inom flygbranschen. 

A1. Kärnkraftbranschen 

Eftersom dagens kärnkraftreaktorer har en konstruktion som härstammar från 60-talet har nu 

säkerhetssystemen börjat moderniserats. En konsekvens av detta är att en viss övergång börjar 

ske från hårdvarubaserade till mjukvarubaserade system. De hårdvarubaserade 

säkerhetssystemen kommer fortfarande att finnas kvar som en backup ifall de 

mjukvarubaserade slutar fungera. Datorsystemen är mer att betrakta som hjälpsystem. Idag 

finns det inte någon säkerhetskritisk kärnkraftfunktionalitet som enbart bygger på 

mjukvarulösningar. 

Att ha flera olika system som ska utföra samma uppgift är något som är vanligt inom 

kärnkraften. På Forsmarks kärnkraftverk finns det fyra uppsättningar av det mesta som är 

säkerhetskritiskt. Uppsättningarna har olika tekniska lösningar för att inte samma fel ska 

drabba flera system. Säkerhetssystemen är dessutom placerade på olika platser i anläggningen 

för att t.ex. en brand inte ska slå ut samtliga system. 

Säkerhet i tre nivåer 

Säkerheten i kärnkraftanläggningarna brukar delas upp i olika nivåer. Med dessa nivåer i 

åtanke ska kärnkraftanläggningar konstrueras och drivas efter bästa möjliga skydd mot dels 

tekniska fel och dels icke kontrollerbara yttre händelser som brand, blixtnedslag, sabotage 

mm. Om något oväntat inträffar har operatörerna relativt gott om tid för att vidta åtgärder. 

Skulle ett fel uppstå kan säkerhetssystemen automatiskt stoppa reaktorn vilket ger 

operatörerna möjlighet att analysera situationen innan manuella åtgärder vidtas. 

Säkerheten är uppbyggd i tre nivåer. Om den första nivån passeras ska säkerheten 

upprätthållas av den andra nivån och på liknande sätt ska den tredje nivån upprätthålla 

säkerheten om den andra nivån passeras. 

__________________________________________________________________________________________ 


Bilaga A 

• Förebygga fel 

Den mest grundläggande nivån innebär att anläggningens konstruktion är bra och noga 

kontrollerad, att personalen är välutbildad och att arbetsrutinerna för drift och underhåll 

fungerar som de ska. Syftet är att förebygga felen så att de inte uppstår. 

• Motverka att fel leder till haveri 

Om det trots allt finns fel som exekveras så att den första nivån passeras ska felet ändå inte 

leda till ett haveri. För att motverka felet finns övervaknings- och säkerhetssystem som 

alltid är dubbla eller ofta flerdubbla. Om det första inte fungerar tar något av 

reservsystemen vid. 

• Lindra konsekvenserna av ett haveri 

Den sista nivån ska ta vid om de båda första passerats. Även om alla säkerhetssystem slås 

ut och om bränslehärden smälter ska reaktorinneslutningen, som är en kraftig byggnad av 

stål och betong, hålla kvar alla de radioaktiva ämnena i inneslutningen. 

Standarder och klassificering 

Det är huvudsakligen två standarder som används inom kärnkraftbranschen för utveckling av 

mjukvara, IEC 60880 och IEC 61226. IEC 60880 behandlar aspekter då datorer används för 

säkerhetskritiska funktioner i kärnkraftverk. Standarden tillhandahåller krav för varje steg i 

utvecklingsprocessen. 

I standarden IEC 61226 presenteras en metod för att klassificera olika kritiska delar av 

systemen. Inga sannolikhetsuppdelningar liknande SIL-nivåerna i IEC 61508 görs, klasserna 

definieras istället utefter vilken inverkan funktionaliteten har på säkerheten. Klassificeringen 

görs i fyra nivåer som benämns med en bokstav från A till D, där A betecknar klassen med de 

högsta kraven. Ett annat sätt att dela upp funktionaliteten är att använda en annan standard 

som bl.a. används på Forsmarks kärnkraftverk. Klasserna benämns här 1E, 2E och 3E där 1E 

är den mest kritiska. Definitionerna av dessa klasser och IEC 61226 påminner om varandra, 

men de är inte direkt jämförbara. På Forsmarks kärnkraftverk har beslut tagits om att inte 

tillämpa klassificeringen enligt IEC 61226. Det blir helt enkelt för dyrt och komplicerat att 

klassa om anläggningen. Vid kärnkraftverket i Oskarshamn är målsättningar däremot att 

använda IEC 61226 vid större moderniseringar. 

Forsmarks brandlarmsystem 

På kärnkraftverket i Forsmark är en stor del av säkerhetssystemen fortfarande 

hårdvarubaserade, även om det finns en hel del mjukvara kopplat till hårdvaran. Det finns inte 

så mycket säkerhetskritisk funktionalitet som nästan helt är mjukvarubaserade. Ett exempel 

där mjukvaran har en avgörande betydelse är dock brandlarmsystemet. Systemet är klassat 

som 3E, d.v.s. det är inte så kritiskt för verksamheten. En brand är givetvis mycket allvarlig, 

men eftersom inte brandlarmsystemet är involverat i själva styrsystemet klassas det efter 

mindre kritikalitet. I figur 1 visas den utvecklingsmodell som mjukvaran är framtagen efter. 

__________________________________________________________________________________________ 


Systemtestspecifikation 

Specifikation Systemtest 

Övergripande 

konstruktion 

Moduldesign 

Integrationstestspecifikationer 

Modultestspecifikationer 

Implementation 

Modultest 

Integration 

Figur 1. Utvecklingsmodell för brandlarmsystem i Forsmarks kärnkraftverk. 

Bilaga A 

Mjukvaran är inte utvecklad av Forsmarks kraftgrupp själva utan inköpt från ett annat företag, 

vilket medför att modul- och integrationstester inte utförs av Forsmarks kraftgrupp. Även om 

Forsmark enbart deltar aktivt i början och slutet av utvecklingen så ställs ändå höga krav på 

att utvecklingsföretaget arbetar efter lämpliga och väl definierade metoder, vilka kontrolleras 

av Forsmarks kraftgrupp. 

Det avsätts relativt stora resurser på att granska och ta fram tydliga specifikationer. Det har 

visat sig att det finns mycket att vinna både i tid och resurser om specifikationer är tydliga. 

Det gäller särskilt kravspecifikationen. Om tvetydigheter smyger sig in redan i 

kravspecifikationen fortplantas felen i det fortsatta arbetet. Dessa felaktigheter är mycket 

svåra att upptäcka eftersom verifieringen då sker mot en felaktig specifikation. Ett sätt att få 

entydiga specifikationer skulle kunna vara att använda formella metoder, vilket dock inte är 

något som används i dagsläget på Forsmarks kärnkraftverk. Anledningen är främst att de 

standarder som används ännu inte behandlar sådana tekniker. Om formella metoder stöds av 

kommande standarder finns ett stort intresse för att börja använda dem hos Forsmark. 

Myndigheten SKI:s arbete 

Eftersom kärnkraftverksamheten kan få så allvarliga konsekvenser för samhället finns det en 

myndighet som ska se till att arbetet på kärnkraftverken håller en hög säkerhetsnivå. Eftersom 

det nu sker en moderniseringen av säkerhetssystemen arbetar SKI, Statens 

kärkraftsinspektion, även en hel del med säkerhetsfrågor för mjukvara. 

SKI:s arbete skiljer sig mycket från motsvarande amerikanska myndighet NRC, Nuclear 

Regulatory Commission. Den amerikanska myndigheten lägger sig i arbetet och ska t.ex. 

godkänna säkerhetslösningarna, vilket innebär att kraftbolagen kan lägga över en del av 

konstruktörsrollen på myndigheten. Det är inget arbetssätt som SKI eftersträvar eftersom det 

kräver mycket stora resurser från myndighetens sida. 

__________________________________________________________________________________________ 


SAT

Bilaga A 

SKI tar inte något ansvar för att kärnkraftverken uppnår en tillräcklig säkerhet. Myndighetens 

uppgift är istället att agera som en övervakare och pådrivare för att kraftbolagen själva tar det 

ansvaret. SKI är således ingen myndighet som ska godkänna säkerhetslösningar eller som ger 

tydliga krav på hur saker ska göras. De ställer t.ex. inga särskilda krav på vilka typer av 

testtekniker som ska användas vid testförfarandet. Syftet med myndighetens arbete är snarare 

att få kraftbolagen att tänka igenom sina arbets- och utvecklingsprocesser än att göra en 

heltäckande granskning av deras verksamhet. 

Istället för att grunda undersökningar på tillförlitlighetssiffror koncentrerar sig SKI på 

kraftbolagens utvecklingsprocesser. Anledningen är att det enligt SKI inte går att räkna fram 

tillförlitlighet för mjukvara. 

Concept 

Requirements 

Hazard analysis Planning 

Realisation 

Figur 2. Faser som ligger till grund för SKI:s granskning av utvecklingsprocessen. 

Installation 

Specifikation Design 

Validation Maintenance 

Ovanstående faser, som är framtagna med hjälp av IEC 61508, fungerar som stöd för SKI då 

de undersöker huruvida ett kraftbolag följer en tillräckligt väldefinierad utvecklingsprocess. 

SKI ställer för var och en av de ovanstående faserna lämpliga frågor till kraftbolagen. Genom 

att kraftbolagen får motivera varför de gör på ett visst sätt tvingas de mer eller mindre att se 

över sina egna processer samtidigt som SKI kan kontrollera att processen är väl genomtänkt. 

Bo Liwång på SKI framhäver två anledningar till varför de tre första faserna är särskilt 

viktiga; dels att det är dyrt att i ett sent skede av utvecklingen rätta till fel som uppkommer 

tidigt i utvecklingen men också att så mycket som tre fjärdedelar av alla fel härstammar från 

dessa tre faser. 

A2. Flygbranschen 

Under studiebesöket på SAAB diskuterades verifierings- och valideringsprocessen för 

styrsystemet till JAS 39 Gripen. Utvecklingen av flygplanets mjukvara sker i 

överensstämmelse med den militära standarden RTCA/DO-178B som i valda delar beskrivs 

kortfattat i kapitel A3. Standarden delar upp mjukvaran i fem kritikalitetsnivåer beroende på 

hur allvarliga konsekvenser ett fel i respektive mjukvarudel kan tänkas få. Styrsystemet har 

klassificerats som kritikalitetsnivå A, vilket är den nivå som det ställs högst krav på. 

SAAB använder sig av haveririskbidrag för att fördela resurserna till utvecklingen. Det 

medför att mer resurser anslås till delar av systemet som bedöms ha hög kritikalitetsnivå. För 

A-klassificerad mjukvara antas felsannolikheten vara noll medan den för mjukvara av klass B 

och lägre antas vara 100 procent. Anledningen till att mjukvaran antingen anses vara felfri 

eller behäftad med fel till 100 procents sannolikhet beror på svårigheten att bedöma 

felsannolikhet för mjukvara. Svårigheten beror främst på att mjukvara inte åldras och slits ut 

på samma sätt som hårdvara. 

__________________________________________________________________________________________ 


Bilaga A 

Verifierings- och valideringsprocess för styrsystemet 

Figur 3 visar utvecklingsprocessen för att ta fram en ny version av styrsystemet. Det första 

steget är att definiera kraven som anger vad den nya versionen ska innehålla. Därefter ska 

utvecklings- och implementationsarbetet påbörjas. Utvecklingsarbetet sker med ett visst mått 

av diversifiering genom att två versioner av mjukvaran produceras. Den ena versionen består 

av automatgenererad C-kod och den andra är manuellt skriven ADA-kod. Det är endast ADAkoden 

som används i det riktiga styrsystemet för JAS planen, C-koden används bara för 

automatiska tester på ADA-koden. Efter implementeringen genomförs verifiering av 

mjukvaran vilket innebär kontroller av att införda ändringar verkligen har avsedd effekt och 

att ändringarna inte medför några oönskade effekter. Under verifieringen kontrolleras även att 

all kod har exekverats. Utvecklingsfasen omfattar också modultester och kontinuerlig 

granskning av arbetet. 

Utvecklingsfas Valideringsfas Flygprov 

Modultest och kodgranskning 

Krav och definitioner 

Verifiering 

Utveckling / Implementering 

Validering 

Flygprov 

Figur 3. Utvecklingsprocess som används av SAAB för att utveckla en ny version av styrsystemet. 

Utmärkande för utvecklingsprocessen är att de mjukvarubaserade modellsimuleringarna har 

möjliggjort en högre grad av automatisering. En övergång från manuell till automatisk 

simulering gör att simuleringarna kan utföras i icke-realtid. Det i sin tur medför att mer 

omfattande simulering kan hinnas med. Simuleringarna har blivit billigare och 

teckningsgraden högre. Simuleringarna har också kunnat göras i ett tidigare skede än förut, 

vilket har resulterat i att fel konstateras och åtgärdas innan de fortplantats i utvecklingen. 

Efter utvecklingsfasen tas ett beslut om projektet är moget för att övergå till valideringsfasen. 

I valideringsfasen genomförs både felsimuleringar och simuleringar av flygegenskaper. Under 

de senaste åren har simuleringarna av flygegenskaperna övergått från att ha utförts med hjälp 

av en provförare och simulator med hårdvara till att mer och mer utföras med hjälp av 

mjukvarubaserade modellsimuleringar av styrsystemet tillsammans med pilotmodeller. Det 

har inneburit en högre grad av automatisering av både genomförande och utvärdering av 

simuleringarna. Under den ca tre månader långa valideringsfasen är ytterligare förändringar av 

koden inte tillåten. Skulle några oacceptable fel hittas måste utvecklingsfasen genomlöpas 

ytterligare en gång. Om det skulle ske är det att betrakta som ett misslyckande. 

Efter valideringen är det slutligen dags för flygprovet som är det sista steget innan leverans. 

Där kontrolleras den nya versionen tillsammans med de övriga systemen. 

__________________________________________________________________________________________ 


Bilaga A 

A3. RTCA/DO-178B 

RTCA är en sammanslutning av amerikanska organisationer som alla är relaterade till 

flygbranschen. Sammanslutningen verkar för att hitta pålitliga tekniska lösningar rörande 

problem med tillämpningar av telekommunikation och elektronik inom flygbranschen. 

RTCO/DO-178B, ”Software Considerations in Airborn Systems and Equipment 

Certification”, är ett dokument som används som en standard inom den militära flygindustrin 

där den tillhandahåller riktlinjer för hur utvecklingen av mjukvara bör gå till. 

Rekommendationerna ska underlätta framtagandet av mjukvara med rätt funktionalitet 

samtidigt som mjukvaran ska uppfylla de högt ställda säkerhetskraven. 

Anledningen till att RTCO/DO-178B nämns i denna bilaga är att den behandlar utvecklingen 

av säkerhetskritisk mjukvara. Dessutom används den av SAAB vid utvecklingsarbetet av JAS 

39 Gripen. Eftersom SAAB:s verifierings- och valideringsprocess för flygplanets styrsystem 

presenterades i föregående avsnitt är det lämpligt att även presentera det dokument som ligger 

till grund för deras arbetsprocess. Standarden behandlar utvecklingsarbetet från specifikation 

till och med att produkten är färdig och levererad. I denna bilaga avgränsas dock 

framställningen till att gälla verifikationsprocessen med ett klart fokus på själva testprocessen. 

I övrigt hänvisas läsaren till hela RTCO/DO-178B. 

Uppdelning i kritikalitetsnivåer 

Standarden förespråkar att olika delar av mjukvaran klassificeras efter kritikalitetsnivå. Ju 

högre kritikalitetsnivå en mjukvarudel anses ha desto högre krav ställs på 

utvecklingsprocessen av den mjukvaran. Med kritikalitetsnivå avses här hur allvarliga de 

tänkbara konsekvenserna kan bli om systemet går in i ett felaktigt tillstånd. Ett felaktigt 

tillstånd inträder då ett fel exekveras och innebär att systemet inte uppför sig som förväntat. 

Fem olika nivåer av mjukvara definieras med benämningarna A till E, där A är den mest 

kritiska och E den minst kritiska. En mjukvara som kan leda till flera olika felaktiga tillstånd 

ska klassificeras efter det allvarligaste av dessa tillstånd. Om en mjukvarudel som 

klassificerats med A går in i ett felaktigt tillstånd innebär det att en fortsatt flygning eller 

landning inte längre kan genomföras på ett säkert sätt. Ett felaktigt tillstånd i en mjukvarudel 

som klassificerats enligt nivå E får ingen effekt på möjligheterna att manövrera planet och 

medför inte heller någon fara för den fortsatta flygningen. 

Notera att de olika kritikalitetsnivåerna inte är kopplade till siffror angående felsannolikhet för 

de olika mjukvarudelarna. Då RTCO/DO-178B togs fram undersöktes metoder för att 

uppskatta felsannolikheten i mjukvara efter verifieringsprocessen. Denna undersökning 

resulterade i konstaterandet att de då kända metoderna för att uppskatta felsannolikhet inte var 

tillräckligt pålitliga vid de höga nivåer som krävdes. 

Kort om verifiering enligt RTCO/DO-178B 

Det övergripande syftet med verifieringsprocessen är att upptäcka och rapportera fel som 

uppkommit under utvecklingsprocessen. Att åtgärda felen hör inte till verifieringen utan är en 

aktivitet som ingår i utvecklingsprocessen. 

Verifiering av mjukvaran uppnås genom en kombination av granskning, analys, framtagandet 

och exekverandet av testfall. Granskningen resulterar i en bedömning angående noggrannhet, 

fullständighet och verifierbarhet. Samma aspekter verifieras genom analysarbetet men 

__________________________________________________________________________________________ 


Bilaga A 

resultatet blir inte en bedömning utan en repeterbar beviskedja. Framtagandet av testfallen kan 

ge ytterligare information huruvida kraven är fullständigt uppfyllda. Exekveringen av 

testfallen erbjuder en möjlighet att demonstrera en överensstämmelse med kraven. 

Verifieringsprocessen kan brytas ned i mindre delar, en för varje fas i utvecklingsarbetet från 

det att kraven specificeras till implementationsfasen. Det gäller oavsett hur många faser 

utvecklingsarbetet har. Målet med varje del är att verifiera arbetet i respektive fas. I de tidiga 

faserna består verifieringsarbetet av att granska och analysera resultatet av det arbete som 

gjorts i respektive fas. Då koden är skriven tillkommer även testarbetet som en 

verifieringsaktivitet. 

För att uppfylla kraven för de högsta kritikalitetsnivåerna rekommenderas att både omfattande 

strukturell och funktionell testning genomförs. På de lägre nivåerna läggs mindre vikt på 

strukturell testning, den är dock inte helt borttagen men den behöver inte ha samma höga 

teckningsgrad. Funktionell testning bör däremot användas även på de lägre nivåerna. På den 

lägsta nivån räcker det att endast genomföra övergripande funktionella tester som verifierar att 

systemkraven är täckta. 

Generellt kan sägas att det görs lättnader för de lägre kritikalitetsnivåerna vad gäller bl.a. 

• Verifikation av lågnivåkrav. 

• Verifikation av mjukvaruarkitekturen. 

• Testningens täckningsgrad. 

• Graden av oberoende för de olika verifieringsaktiviteterna. 

• Verifieringsaktiviteter som överlappar varandra genom att de hittar samma typer av fel. 

• Tester angående störningskänslighet. 

__________________________________________________________________________________________ 


Bilaga B 

B. Enkätsammanställning 

Syftet med enkätundersökningarna är att öka rapportens trovärdighet genom att tillföra 

synpunkter och bedömningar från ett flertal insatta personer. Den här bilagan innehåller en 

sammanställning och utvärdering av resultaten från de två enkäter som använts för att styrka 

vissa delar i riskanalysen. Dessa delar är 

• riskvärderingsmatrisens specifika utseende för företaget. 

• vissa incidenters uppdelning i konsekvensgrader. 

Två typer av enkäter har använts; en riskvärderingsmatrisenkät och en konsekvensenkät. De 

båda enkäterna behandlas var för sig i de två kommande kapitlen. 

Riskvärderingsmatrisenkäten återfinns i sin helhet som bilaga C och konsekvensenkäten i 

bilaga D. 

B1. Resultat och tillvägagångssätt för riskvärderingsmatrisenkät 

Då en risk uppskattats efter både frekvens och konsekvensgrad kan den placeras in i en 

riskvärderingsmatris. Matrisen talar om vilka kombinationer av konsekvensgrader och 

frekvenser som är acceptabla och vilka som är oacceptabla. Utseendet på 

riskvärderingsmatrisen bör därför återspegla de krav som ställs på börssystemet. Syftet med 

enkätundersökningen är att få fram en trovärdig riskvärderingsmatris som kan sägas 

representera företagets syn på vilka risker som är acceptabla och vilka som är oacceptabla. 

Undersökningens deltagare 

Enkäten skickades främst till personer som har inblick i vad incidenter kan få för ekonomiska 

följder för företaget. Som exempel på befattningar hos deltagarna kan nämnas linjechefer, 

avdelningschefer och projektledare. Enkäten skickades ut till åtta personer varav fem svarade. 

Strategi för utvärdering 

Det har varit ett mål att samtliga av undersökningens deltagare ska vara så insatta i hur olika 

incidenter påverkar företaget att de kan göra en värdefull ekonomisk bedömning av dessa 

incidenter. Svaren från undersökningens deltagare viktas därför lika mycket. 

Nedan följer en beskrivning i tre steg hur utvärderingen går till. 

1. Efter att enkäterna har samlats in sammanställs alla svar i en tabell. Varje cell i tabellen 

kommer att innehålla O, A och B (oacceptabel, acceptabel eller att en bedömning måste 

ske från fall till fall) i samma antal som enkätundersökningens deltagare. 

2. Från varje cell tas två extremvärden bort för att på så sätt eliminera svar som skiljer sig för 

mycket från mängden. 

3. Det slutgiltiga svaret blir det alternativ som flest respondenter har valt, efter att 

extremvärdena eliminerats. Om det inte finns något alternativ som är i majoritet klassas 

resultatet som ett B. 

I efterhand kunde det konstateras att enkäten antagligen inte var konstruerad på bästa tänkbara 

sätt. En anledning är att riskvärderingsmatrisen innefattar för få valbara alternativ. Det borde 

funnits fler alternativ att välja mellan på båda axlarna för att inte respondenterna skulle 

påverkas så mycket av enkätens utformning. 

__________________________________________________________________________________________ 


Bilaga B 

Resultat 

I tabellen nedan redovisas svaren från undersökningens deltagare. De två extremvärdena som 

inte ska ingå i värderingen har sorterats bort och det är således de tre bokstäverna i mitten som 

kommer att användas i värderingen enligt steg tre. 


Katastrof OOOOO OOOOO OOOOO OOOOB OBBAA 

Kritisk OOOOO OOOOO OOOBB OBBAA OBAAA 

Marginell OOOOO OOOOB BBBAA AAAAA AAAAA 

Obetydlig OOOBA BAAAA BAAAA AAAAA AAAAA 

Tabell 8. Samtliga respondenters svar. 

Eftersom det alltid är ett av alternativen i varje cell som är i majoritet råder det aldrig några 

tveksamheter över vilket alternativ som ska bli slutresultatet. Den slutgiltiga riskvärderingsmatrisen 

som enkätundersökningen skulle resultera i redovisas i Tabell 9. 



Kritisk Oacceptabel Oacceptabel Oacceptabel Bedömning Acceptabel 

Marginell Oacceptabel Oacceptabel Bedömning Acceptabel Acceptabel 

Obetydlig Oacceptabel Acceptabel Acceptabel Acceptabel Acceptabel 

Tabell 9. Riskvärderingsmatrisen som enkätundersökningen resulterade i. 

__________________________________________________________________________________________ 


Bilaga B 

B2. Resultat och tillvägagångssätt för konsekvensenkät 

Det är svårt att avgöra hur allvarliga följder en viss incident kan få för ett företag. Därför 

involverades några mer insatta personer för att hjälpa med denna bedömning. 

Enkätundersökningen omfattar inte riskanalysens samtliga incidenter. De incidenter som inte 

är medtagna i enkäten bedöms av examensarbetarna själva utgående från den referensbild som 

enkätundersökningen resulterar i. 

Undersökningens deltagare 

Enkäten skickades till personer med olika typer av befattningsområden inom företaget. 

Anledningen till att så vitt skilda personer deltar i undersökningen är att incidenter kan tolkas 

på så olika sätt, dels vad de får för tekniska följder för systemet och dels vad de får för 

ekonomiska följder för företaget. Personer med höga befattningsområden har sällan lika 

ingående förståelse som t.ex. utvecklare vad konsekvenser, som bygger på tekniska fel, kan få 

för inverkan på systemet. De kan däremot ha en bättre ekonomisk förståelse för vad 

konsekvenser kan ha för inverkan på företaget. Tanken är att resultatet från deltagarna ska 

komplettera varandras bidrag och ge en mer rimlig bedömning av incidenter. 

Enkäten skickades ut till 20 personer och hade en svarsfrekvens på ungefär 50 procent. Det 

var främst personer med lite högre befattningar som tog sig tid och svarade. 

Berörda incidenter 

De incidenter som har använts i enkätundersökningen har valts med tanke på att de ska utgöra 

en referensbild för bedömningen av de övriga incidenterna i riskanalysen. 

Incidenterna är i stort sett direkt tagna från rapportens riskanalys. I några fall har vissa 

justeringar gjorts för att de bättre ska kunna anpassas till enkäten, men innebörden av 

incidenterna har dock inte ändrats. De berörda incidenterna från kapitel 2.3.3 är; I1.1, I1:3, 

I2:1, I3:1 och I4:1. 

Strategi och sammanställning av enkäternas resultat 

Sammanställningen av resultaten redovisas i de sex tabellerna nedan som är tagna direkt från 

enkäten. Varje tabell motsvarar en av riskanalysens incidenter. I tabellerna presenteras hur 

svaren är fördelade mellan de olika konsekvensgraderna. I och med att det är tillåtet att sätta 

flera kryss för varje rad i tabellerna kan antalet kryss på varje rad variera. Antalet kryss i en 

ruta delas med det totala antalet kryss som finns för den aktuella raden och resultatet 

presenteras i procent. 

__________________________________________________________________________________________ 



I1.1 Handelsstopp 

på grund av 

tekniskt fel 

Fråga 1 – Handelsstopp på grund av tekniskt fel. 

Bilaga B 


stoppas i samtliga orderböcker. Nya ordrar kan ej läggas och 

ordrar som befinner sig i systemet kan ej matchas. Incidenten 

innefattar däremot inte att information som finns i systemet går 

förlorad. 

Bedöm hur allvarlig incidenten är utifrån handelsstoppets varaktighet. 

Katastrof Kritisk Marginell Obetydlig 

Flera dagar 70 % 30 % 

En dag 11 % 89 % 

Ett par timmar 78 % 22 % 

30 min 11 % 89 % 

5 min 56 % 44 % 

Respondenterna är tämligen överens i sina bedömningar. Vid bedömningen av ”flera dagar” är 

personer med högre befattning i majoritet på bedömningen katastrof. Desamma gäller för 

bedömningen obetydlig på ”5 min”. Generellt sett kan sägas att personer med högre befattning 

i större utsträckning vågar använda hela spannet av konsekvensgrader i sina bedömningar, 

medan de andra håller sig till de två mittalternativen. 

__________________________________________________________________________________________ 




Fråga 2 – Prestandaförsämringar. 


fördröjningar vid t.ex. orderläggning. 

Bilaga B 



systemet fungerar till hundraprocent av normal tps-nivå kan köer 

uppstå vid ovanligt hård belastning. Fördröjningar kan också 

uppkomma p.g.a. att överföringskapaciteten mellan användare och 

systemet är liten. Användaren bryr sig troligen inte om varför 

fördröjningen uppstår, bara att den existerar. 

Bedöm konsekvensgraden då en viss del av antalet ordrar under en dag utsätts 

för förseningar. Med förseningar menas att det tar några sekunder mer än 

vanligt att lägga en order. 

Andel ordrar som 

försenas 


100 % 25 % 75 % 

50 % 22 % 67 % 11 % 

10 % 22 % 78 % 

Majoriteten är överens. Där bedömningen avviker kan inga särskilda slutsatser dras. 

__________________________________________________________________________________________ 




felaktigt 

Fråga 3 – Order matchas felaktigt. 

Bilaga B 

Användaren köper/säljer någonting annat än vad ordern omfattar. 

Det kan t.ex. bero på att informationen har förvanskats i systemet 



konsekvenser eftersom det då ofta rör sig om stora belopp. 

Omsättning under en normal handelsdag brukar uppgå till tiotals 

miljoner kronor per minut. 

Bedömningen ska göras för två fall. I det första fallet förutsätts att det är 

möjligt att backa tillbaka alla felaktiga ordrar. 


30 min 25 % 75 % 

10 min 88 % 12 % 

1 min 55 % 45 % 

Enstaka order 12 % 63 % 25 % 

I det andra fallet ska bedömningen göras då det inte är möjligt att backa tillbaka 

ordrarna. 


30 min 100 % 

10 min 83 % 17 % 

1 min 33 % 67 % 

Enstaka order 67 % 33 % 

Hur incidenten ska bedömas då ordrar matchas felaktigt går något isär. Vissa upplever 

incidenten, då det inte är möjligt att backa tillbaka ordrarna, något överflödig. De menar att en 

sådan incident inte kan inträffa. Här bör det påpekas att risken alltid finns. Den kanske inte är 

så stor, men att säga att det inte kan inträffa är att lova för mycket. Eftersom dessa personer 

inte har bedömt incidenten utefter dess verkliga mening har svaret från dessa personer inte 

vägts in i bedömningen. Antalet deltagande för den undre tabellen är således något lägre än 

för de övriga tabellerna. Respondenterna är mer överens i sina bedömningar av 

felmatchningar som får råda under en lite längre tidsrymd än för enbart några enstaka ordrar. 

__________________________________________________________________________________________ 





kommandon 

Fråga 4 – Användaren ger oavsiktliga kommandon. 

Bilaga B 

Dåligt användargränssnitt. Knappar och menyer ligger på fel 

ställen jämfört med vad användaren förväntat sig, vilket orsakar 

felinmatningar från användaren. Tvetydigheter vad gäller 

funktionalitet i användarapplikationen kan medföra att användaren 

ger kommandon som resulterar i oavsiktliga inmatningar. 

Hur allvarligt är det om SAXESS Trade’s användargränssnitt medför en 

felaktig inmatning från användarens sida? 

Majoriteten är överens om att incidenten ska bedömas som marginell. En respondent påpekar 

dock att det förutsätter att en dialog finns med användaren så att bristerna i användargränssnittet 

kan åtgärdas. 



information 

når 

användaren 

Fråga 5 – För mycket information når användaren. 


Felaktig inmatning 78 % 22 % 


som allmän information. 

Det finns ett fel i systemet som gör det möjligt för en användare att få för 

mycket information om ordrar. Hur ska ett sådant fel bedömas om det förutsätts 

att incidenten berör samtliga ordrar för de två övre tidsintervallen? 


Några veckor 89 % 11 % 

En dag 40 % 60 % 

Enstaka ordrar 55 % 45 % 

Meningarna går något isär för de kortare tidsintervallen. Det kan bero på att incidenten är 

något tvetydig. Det framgår inte lika tydligt som för de andra incidenterna vad som egentligen 

berörs. 

__________________________________________________________________________________________ 


Bilaga C 

C. Riskvärderingsmatrisenkät 

Syftet med riskvärderingsmatrisen är att den ska representera BU SAXESS syn på risker. 

Genom att applicera de risker som uppdagas på riskvärderingsmatrisen, kan en vägledning fås 

huruvida risken är acceptabel eller ej. Tabell-1 nedan är ett exempel på en ej helt ifylld 

riskvärderingsmatris. 


Katastrof Oacceptabel 

Kritisk Bedömning 

Marginell 

Obetydlig Acceptabel 

Tabell-1. Exempel på hur en riskvärderingsmatris kan se ut. I en riktig matris ska samtliga fält vara ifyllda. 

Riskvärderingsmatrisen innehåller en konsekvensskala och en frekvensskala. 

Konsekvensskalan anger hur allvarliga följderna blir om risken inträffar och frekvensskalan 

anger hur ofta det kan tänkas ske. Definition av begreppen konsekvens och frekvens 

presenteras på nästa sida. 

Det bör här påpekas att även i de mest säkerhetskritiska branscher accepteras risker som kan 

leda till katastrofer, dock accepteras de endast på mycket låga frekvensnivåer. Inom civilflyget 

klassas händelsen att ett plan störtar naturligtvis som en katastrof. Ändå accepteras att plan 

störtar p.g.a. tekniskt fel med en frekvens på 10 -9 flygtimmar. Det är nämligen inte möjligt att 

bedriva verksamheter utan att utsättas för någon form av risk. Risker kan i och för sig alltid på 

ett eller annat sätt minskas, men ofta leder det till stora kostnader. Frågan är på vilken nivå 

man ska lägga sig. 

__________________________________________________________________________________________ 


Definition av konsekvensgrad 

Nedan definieras begreppet konsekvens som utgör kolumnen i riskvärderingsmatrisen. 


Katastrof Förtroendet för SAXESS skadas så allvarligt att varumärket blir 

oanvändbart. Inga nya ordrar erhålls och befintliga kunder säger 

upp avtal. 



inblandade kunder riskerar att sägas upp. 





Tabell-2. Definition av konsekvensgrad. 

Bilaga C 

Definition av frekvens 

Följande tabell innehåller förklaringar till de termer som används för att beskriva frekvens. 

För att ge ett exempel har ett börssystem med en uppskattad livslängd på totalt 20 000 

drifttimmar legat till grund för framtagandet av frekvenserna. I de fall då fler system finns i 

drift ökar sannolikheten att felen inträffar. Det är dock ingenting som ska vägas in i detta 

skede av riskanalysen. Denna enkät behandlar således ett SAXESS-system. 

Frekvens Förklaring Inträffar ungefär 


år 

Frekvent Inträffar många gånger under 


Trolig Inträffar ett flertal gånger 

under systemets livslängd 

Sannolik Inträffar någon gång under 


Försumbar Kan möjligen inträffa under 


Osannolik Förväntas inte inträffa under 


Tabell-3. Definition av begreppen som anger frekvens. 

Inträffar ungefär 


timme 

30 10 -2 

3 10 -3 

0,3 10 -4 

0,03 10 -5 

0,003 10 -6 

__________________________________________________________________________________________ 


Bilaga C 

Uppgift 

Till att börja med vill vi veta vilken befattning Du har. Genom att få in svar från personer med 

olika befattningsområden kan eventuella skillnader i synen på risker påvisas. Var vänlig och 

beskriv med några ord Din befattning och Dina ansvarsområden. 

___________________________________________________________________________ 

___________________________________________________________________________ 

Uppgiften för Dig som deltar i undersökningen är att fylla i en riskvärderingsmatris för BU 

SAXESS, d.v.s. hur risker i systemet borde värderas då en definition av frekvens och 

konsekvensgrad redan finns. 

Fyll i de tomma rutorna i tabell-4. Definition av frekvens och konsekvensgrad finns i tabell-2 

och tabell-3. Markera de rutor som är acceptabla med A och rutor som är oacceptabla med O. 

De rutor där en bedömning är svår att göra kan klassificeras med B, vilket innebär att en 

bedömning får göras från fall till fall. Antalet rutor som klassificeras med B bör hållas nere. 

Efter tabellen finns plats för eventuella kommentarer. 

Katastrof 

Kritisk 

Marginell 

Obetydlig 


Tabell-4. Matris som fylls i av respondenten. Acceptabla risker markeras med A, bedömning med B och 

oacceptabla med O. 

Kommentarer:_______________________________________________________________ 

___________________________________________________________________________ 

___________________________________________________________________________ 

___________________________________________________________________________ 

Om det finns några oklarheter är Ni varmt välkomna att diskutera dessa med oss via mail eller 

personligen. Vi sitter i "konsultrummet", d.v.s. hörnrummet Norrlandsgatan/Kungsgatan, 

rumsnummer 5011. 

Stort tack för Er medverkan, 

/Stefan Särd och Dag Wester 

__________________________________________________________________________________________ 


Bilaga D 

D. Konsekvensenkät 

Till att börja med vill vi veta vilken befattning Du har. Genom att få in svar från personer med 

olika befattningsområden kan eventuella skillnader i synen på risker påvisas. Var vänlig och 

beskriv med några ord Din befattning och Dina ansvarsområden. 

___________________________________________________________________________ 

___________________________________________________________________________ 

Nedan följer en tabell innehållande definitioner av de konsekvensgrader som används i 

enkäten. 


Katastrof Förtroendet för SAXESS skadas så allvarligt att varumärket blir 

oanvändbart. Inga nya ordrar erhålls och befintliga kunder säger 

upp avtal. 



inblandade kunder riskerar att sägas upp. 





Tabell-1. Definition av konsekvensgrad. 

__________________________________________________________________________________________ 


Bilaga D 

Uppgift 

Enkäten är uppdelad i två delar. Den första delen är tänkt att styrka bedömningen av vissa 

incidenter. Den andra delen finns med för att förslag ska kunna ges på incidenter som ännu 

inte är uppmärksammade. 

Del 1 

Nedan följer några incidenter som vi gärna vill ha hjälp med att bedöma. Incidenterna 

beskrivs kortfattat varpå själva bedömningen ska ske. Din uppgift är att sätta ett kryss för 

varje rad i tabellerna. Om tveksamhet råder kan även flera kryss sättas per rad. Efter tabellen 

finns utrymme för egna kommentarer om sådana vill ges. Konsekvensgraderna är definierade i 

tabell-1. 

Incidenterna ska bedömas efter hur allvarliga de är om de inträffar en gång. Hur ofta 

incidenterna kan tänkas inträffa bedöms i ett annat skede av riskanalysen och således inte i 

denna enkät. 


I1.1 Handelsstopp 

på grund av 

tekniskt fel 


stoppas i samtliga orderböcker. Nya ordrar kan ej läggas och 

ordrar som befinner sig i systemet kan ej matchas. Incidenten 

innefattar däremot inte att information som finns i systemet går 

förlorad. 

Bedöm hur allvarlig incidenten är utifrån handelsstoppets varaktighet. 

Flera dagar 

En dag 

Ett par timmar 

30 min 

5 min 

Fråga 1 – Handelsstopp på grund av tekniskt fel. 


Kommentarer:________________________________________ 

____________________________________________________ 

____________________________________________________ 

__________________________________________________________________________________________ 




Fråga 2 – Prestandaförsämringar. 


fördröjningar vid t.ex. orderläggning. 

Bilaga D 



systemet fungerar till hundraprocent av normal tps-nivå kan köer 

uppstå vid ovanligt hård belastning. Fördröjningar kan också 

uppkomma p.g.a. att överföringskapaciteten mellan användare och 

systemet är liten. Användaren bryr sig troligen inte om varför 

fördröjningen uppstår, bara att den existerar. 

Bedöm konsekvensgraden då en viss del av antalet ordrar under en dag utsätts 

för förseningar. Med förseningar menas att det tar några sekunder mer än 

vanligt att lägga en order. 

Andel ordrar som 

försenas 

100 % 

50 % 

10 % 


Kommentarer:________________________________________ 

____________________________________________________ 

____________________________________________________ 

__________________________________________________________________________________________ 




felaktigt 

Fråga 3 – Order matchas felaktigt. 

Bilaga D 

Användaren köper/säljer någonting annat än vad ordern omfattar. 

Det kan t.ex. bero på att informationen har förvanskats i systemet 



konsekvenser eftersom det då ofta rör sig om stora belopp. 

Omsättning under en normal handelsdag brukar uppgå till tiotals 

miljoner kronor per minut. 

Bedömningen ska göras för två fall. I det första fallet förutsätts att det är 

möjligt att backa tillbaka alla felaktiga ordrar. 

30 min 

10 min 

1 min 

Enstaka order 


I det andra fallet ska bedömningen göras då det inte är möjligt att backa 

tillbaka ordrarna. 

30 min 

10 min 

1 min 

Enstaka order 


5.2.1.1.1.1.1.1.1 

Kommentarer:________________________________________ 

____________________________________________________ 

____________________________________________________ 

__________________________________________________________________________________________ 





kommandon 

Fråga 4 – Användaren ger oavsiktliga kommandon. 

Bilaga D 

Dåligt användargränssnitt. Knappar och menyer ligger på fel 

ställen jämfört med vad användaren förväntat sig, vilket orsakar 

felinmatningar från användaren. Tvetydigheter vad gäller 

funktionalitet i användarapplikationen kan medföra att användaren 

ger kommandon som resulterar i oavsiktliga inmatningar. 

Hur allvarligt är det om SAXESS Trade’s användargränssnitt medför en 

felaktig inmatning från användarens sida? 

Kommentarer:________________________________________ 

____________________________________________________ 

____________________________________________________ 



information 

når 

användaren 

Felaktig inmatning 


som allmän information. 

Det finns ett fel i systemet som gör det möjligt för en användare att få för 

mycket information om ordrar. Hur ska ett sådant fel bedömas om det förutsätts 

att incidenten berör samtliga ordrar för de två övre tidsintervallen? 

Några veckor 

En dag 

Enstaka ordrar 

Fråga 5 – För mycket information når användaren. 



Kommentarer:________________________________________ 

____________________________________________________ 

____________________________________________________ 

__________________________________________________________________________________________ 


Bilaga D 

Del 2 

Från denna del hoppas vi kunna få förslag på ytterligare incidenter som ännu inte har 

uppmärksammats. Nedan ges ett antal incidenter på rubriknivå. Om Du har förslag på 

ytterligare incidenter som bör finnas med får Du gärna nämna dessa nedan. 

Störning i handel 

I1.1 Handelsstopp i hela systemet på grund av tekniskt fel 




Felaktig handel 


I2.2 Handelsregler följs ej 


I2.4 Order försvinner innan matchning 

I2.5 Order försvinner efter matchning 

I2.6 Felaktigt ifylld order accepteras 


Användargränssnitt 

I3.1 Användaren ger oavsiktliga kommandon 

I3.2 Användaren gör felaktiga avläsningar 

I3.3 Svårbegriplig användarapplikation 

Informationsflöde 


I4.2 För lite information når användaren 

I4.3 Information om index m.m. uteblir 

Övriga incidenter 

I5.1 Instabilare system (det ena av de två systemen är ej i drift) 

I5.2 Korrekt ifylld order accepteras inte 

Kommentarer:________________________________________________________________ 

___________________________________________________________________________ 

___________________________________________________________________________ 

Om det finns några oklarheter är Ni varmt välkomna att diskutera dessa med oss via mail eller 

personligen. Vi sitter i "konsultrummet", d.v.s. hörnrummet Norrlandsgatan/Kungsgatan, 

rumsnummer 5011. 

Stort tack för Din medverkan, 

/Dag Wester och Stefan Särd 

__________________________________________________________________________________________ 


Ordlista 

Ord Förklaring 

Aktörer De personer och företag som på något sätt kommer i kontakt med ett 

börssystem, se kapitel 2.1.2 

Användarapplikation Applikation där användaren kan lägga order i systemet. 

Användare En person som lägger order i systemet och som då agerar säljare eller 

köpare. 

Börssystem Ett börssystem kan sägas bestå av den mjuk- och hårdvara som 

tillsammans utgör en elektronisk marknadsplats för värdepapper. 

Deadlock Ett tillstånd då systemet låser sig vilket innebär att en fortsatt drift av 

systemet är omöjligt tills felet åtgärdas eller systemet startas om. 

Driver Ersätter överordnade moduler som krävs för att en funktion ska kunna 

kompileras. Drivers är vanliga vid bottom-up integration, se kapitel 3.2.5. 

Fel Fel kan medföra att mjukvarans funktionalitet på något sätt avviker från 

vad som är önskvärt. Fel kan t.ex. vara implementerade i koden om 

programmeraren har programmerat fel eller inte programmerat vad som 

avsågs. Fel kan också uppstå vid tolkningen av luddiga 

kravspecifikationer. Ett fel är något som kvarstår tills det åtgärdas. 

Felintensitet Anger hur mycket fel som finns i koden. En tänkbar enhet skulle kunna 

vara antalet fel per kodrad. 

Felsannolikhet Sannolikheten att ett fel exekveras vilket kan medför att en incident 

inträffar. 

Finansiella instrument Används i rapporten med samma betydelse som värdepapper. 

Företaget Då ordet företaget nämns syftar det på företaget där examensarbetet är 

utfört, d.v.s. OM Technology. 

GUI Graphical Unit Interface, det grafiska gränssnittet mellan användare och 

system. 

Hermeneutik Ett forskningsideal där huvudsyftet är att tolka och förstå. 

Incident En incident är en mer eller mindre allvarlig och ospecificerad händelse 

som kan inträffa då systemet befinner sig i ett felaktigt tillstånd, vilket i sin 

tur är en följd av att ett fel har exekverats. En incident är således skillnaden 

mellan det önskade och det verkliga beteendet. Se Figur 1-2. 

Katastrof Definition på konsekvensgrad i riskanalysen, se Tabell 2-3. 

Konsekvensgrad Benämning på hur allvarlig en konsekvens är. I rapporten finns fyra 

konsekvensgrader; katastrof, kritisk, marginell och obetydlig. Se kapitel 

2.2.1 för generella definitioner och kapitel 2.3.1 för definitioner anpassade 

till ett börssystem. 

Kritisk Definition på konsekvensgrad i riskanalysen, se Tabell 2-3. 

Mäklare Person som handlar värdepapper för någon annans räkning. 

Marginell Definition på konsekvensgrad i riskanalysen, se Tabell 2-3. 

Matchning Säljare och köpare kommer överens om en affär i ett värdepapper samt pris 

och andra villkor. I de fall då handeln går via en elektronisk börs sker 

matchningen automatiskt utan säljaren eller köparens inblandning. 

Bilaga D 

__________________________________________________________________________________________ 


Obetydlig Definition på konsekvensgrad i riskanalysen, se Tabell 2-3. 

Option Avtal som sluts ögonblickligen där avtalet ger optionsinnehavaren rättighet 

till framtida köp eller försäljning av en underliggande vara. För denna 

rättighet betalar optionsspekulanten en premie till den som tar på sig 

skyldigheten att köpa eller sälja. 

Orakel Ett orakel är något som beslutar om resultatet av ett testfall är korrekt eller 

inte. Oraklet kan vara t.ex. en människa men båstår oftare av en automatisk 

och datoriserad beslutsväljare. Ett effektivt orakel är särskilt viktigt då 

många automatiska tester ska utföras. 

Order En beställning av köp eller försäljning av värdepapper. 

Orderbok Innehåller samtliga order i ett visst värdepapper, sorterade efter pris och 

tid. 

Prisspread Skillnaden mellan köp- och säljkurs för ett specifikt värdepapper. 

Risk Med begreppet risk avses kombinationen av sannolikheten för att en 

incident inträffar och konsekvensgraden av den inträffade incidenten, se 

Figur 2-3. 

Robusthet Grad av kraschbenägenhet. 

Säkerhetskritisk bransch Företag inom säkerhetskritiska branscher utvecklar system som på något 

sätt kan utgöra fara eller få allvarliga konsekvenser för människan eller 

samhället. Farorna kan vara både av fysisk eller ekonomisk karaktär. 

Stub Ersätter underordnade moduler som krävs för att en funktion ska kunna 

kompileras. Stubs är vanliga vid top-down integration, se kapitel 3.2.5. 

Termin Avtal om köp eller försäljning av en underliggande vara vid en bestämd 

tidpunkt i framtiden, till ett i förhand bestämt pris. Båda parter är skyldiga 

att fullfölja avtalet. 

Tps-nivå 

Transaktioner per sekund. Antalet transaktioner som behandlas av systemet 

per sekund. 

Transaktion Order som läggs eller ändras i systemet. Kan t.ex. innebära att en köporder 

läggs in i systemet men också samtliga förändringar som berör 

ordern under dess behandling. 

Validering Kontroll av att systemet överensstämmer med beställarens förväntningar. 

Verifiering Kontroll av att det finns en överensstämmelse mellan varje steg i 

utvecklingskedjan. 

Värdepapper Det som handlas på börsen. Kan t.ex. vara aktier, obligationer, konvertibler 

och warrants. 

Warrant En option som sträcker sig under en längre tidsperiod. 

Bilaga D 

__________________________________________________________________________________________ 


Referenser 

Böcker och Paper: 

[Bei90] Beizer, B: Software Testing Techniques, Van Nostrand Reinhold, 1990. 

[Bei95] Beizer, B: Black-Box Testing, John Wiley & Sons, 1995. 

[Bei97] 

[Bow93] 

[Bra00] 

[Fri95] 

Beizer, B: Cleanroom Process Model: A Critical Examination, IEEE, 1997. 

Bowen, J och Stavridou, V: Safety-critical systems, formal methods and standards, 

Software Engineering Journal, 1993. 

Bratteby-Ribbing, I: Handbok för Programvara i säkerhetskritiska tillämpningar, FMV, 

2000. 

Friedman, M. Voas, J: Software Assessment, John Wiley & Sons, 1995. 

[Gar99] Gardiner, S: Testing Safety-Related Software, Springer, 1999. 

[Gil93] Gilb, T: Software Inspection, Addison-Wesley, 1993. 

[Glu98] 

[Gra98] 

[Ham94] 

[Hat97] 

Gluch, D.S och Weinstock, C.B: Model-Based Verification: A Technology for Dependable 

System Upgrade, Software Engineering Institute, 1998. 

Graver, T.l, Harrold, M.J, Kim, J.M, Porter, A, Rothermel, G: An Empirical Study of 

Regression Test Selection Techniques, IEEE, 1998. 

Hamlet, R: Random testing, Wiley, 1994. 

Hatton, L: N-Version Design Versus One Good Version, IEEE, 1997. 

[Hei97] Heiser, J.: An Overview of Software Testing, IEEE, sid 204-211, 1997. 

[Joh96] Johansson, E.: Safety-Critical Control System – The Challenge of Migrating from 

Hardware to Software, part B, Industrial Control Systems, 1996. 

[Jon96] Jones, C: Applied Software Measurement, McGraw-Hill, 1996. 

[Kan93] Kaner, C, Falk J, Quoc Nguyen H: Testing Computer Software, Sec. Edition, Van 

Nostrand Reinhold, 1993. 

[Kee95] 

[Kni90] 

Keene, S: Software Safety Initiatives, Quality and reliability engineering international, vol 

11, 1995. 

Brilliant, S.S. Knight, J.C. Leveson, N.G.: Analysis of Faults in an N-Version Software 

Experiment, IEEE Transactions on Software Engineering. Vol. 16 No 11, 1990. 

[Lev95] Leveson, N: Safeware: System Safety and Computers, Addison-Wesley, 1995. 

[Lit87] 

[Lit94] 

Littlewood, B: Software Reliability, Blackwell Scientific Publication, 1987. 

Littlewood, B: Learning to Live with Uncertainty in our Software, Centre for Software 

Reliability, City University Northampton Square, IEEE, 1994. 

[Lun99] Lundahl, S: Utredningsmetodik för samhällsvetare och ekonomer, Studentlitteratur, 1999. 

[OMy99] OM Gruppen: Årsredovisning 1999. 

Bilaga D 

__________________________________________________________________________________________ 


[Per95] Perry, W: Effective Methods for Software Testing, John Wiley & Sons, 1995. 

[Pre97] Pressman, R.S: Software Engineering – A Practitioner´s Approach, Fourth Edition, 

McGraw-Hill, 1997. 

[Rap82] Rapps, S och Weyuker, E.J: Data flow analysis techniques for test data selection. Sixth 

International Conference on Software Engineering, Tokyo, Japan, 1982. 

[Sco95] Scott, J.A: Testing existing software for safety-related applications. Revision 7.1, 

Lawrence Livermore National Lab. 1995. 

Internet: 

[wwwFK] http://www.vattenfall.se/webb99, Säkerhet i tre nivåer för kärnkraftsanläggningar. 

Standarder: 

[IEC 61508] Functional Safety of PE Safety-related Systems, IEC, 1996. 

[RTCA/DO-178B] Software Consideration in Airborn Systems and Equipment Certification, RTCA, 

1992. 

Studiebesök: 

Datum Plats Kontaktperson 1 

010330 Saab, Linköping Johan Enhagen 

010405 SKI, Stockholm Bo Liwång 

010410 Forsmarks kärnkraftverk Mattias Hansson 

1 Under studiebesöken på Saab och Forsmarks kärnkraftverk fördes diskussioner med ett flertal personer. 

Bilaga D 

__________________________________________________________________________________________

Tekniker för att testa mjukvara - AddQ

Create successful ePaper yourself

Delete template?

Save as template?