Experimentell verifiering av feldetektering och feltolerans

Transkript

1 Experimentell verifiering av feldetektering och feltolerans Projekt P9 inom Forskning och teknikutveckling för anpassning Etablering av experimentmiljö Författare Siv Hermansson Jan Sinclair Dokument Id WP1 1_0.doc Version 1.0 Datum 28 augusti 2000 Tillgänglighet Status FoTA P9 och SESAM Slutlig Granskad av Datum HiSafe AB Östra Palettgatan 5 Tel GSM V FRÖLUNDA e-post hisafe@hisafe.se

2 Dokumentets historik Version Författare Datum Ändringsinformation 0.1 Siv och Jan 14 juni 2000 Ny 0.2 Siv och Jan 28 augusti 2000 Reviderad 1.0 he 28 augusti 2000 Slutlig? HiSafe AB WP1 1_0.doc av 17

3 Innehållsförteckning 1. INLEDNING BAKGRUND MÅL, KRAV OCH BEGRÄNSNINGAR BEGREPP FINT, EN PROVBÄNK FÖR PROV AV PROGRAMENHETER ATT BESKRIVA MODULEN SOM SKALL PROVAS ATT BESKRIVA ETT PROVS MÖNSTER ATT GENERERA PROGRAMTEXT, DIREKTIV OCH DRIFTPROFIL FÖR SAMTLIGA PROVFALL I ETT PROV ATT UTFÖRA PROVET ENLIGT DIREKTIVEN DVS ATT KOMPILERA OCH LÄNKA SAMT LADDA OCH KÖRA VARJE PROVFALL BRUKARFALL KLASSDIAGRAM EXEMPEL PÅ RAPPORTERINGSFÖNSTER I PROVBÄNKEN....16? HiSafe AB WP1 1_0.doc av 17

4 1. Inledning. Etableringen av experimentmiljön har vi gjort genom att göra:?? en modell för provbänken,?? programmera provbänken,?? etablering av SEEMACS på egen dator SUN Solaris 2.8,?? samt köra tester på några funktioner i Pascal/D80. Provbänken består av mjukvara för att systematiskt kunna prova programenheter på dess gränssnitt genom systematisk variation av värden på alla variabler som utifrån påverkar enheten vid anrop. En programenhet är en procedur, en funktion, en metod eller en komponent som kan anropas från ett programspråk. Provningen sker som black box testing av en isolerad enhet per prov. Antalet provfall i ett prov kan bli mycket stort. Framställningen av provfallen och direktiven för provningen måste därför vara självgående efter start. FINT-projektets provbänk fungerar hittills på det sätt att provfallen: - genereras i en dator med Windows - flyttas över till SUN Solaris - programenheterna anropas från Pascal/D80 - kompilering, länkning och körning görs i SEEMACS utvecklingsmiljö. - provningen sker i MACS-simulatorn. Alla grunddata om programenheter och variabler, som behövs för att generera prov av en enhet, lagras i XML format. Provbänken är skriven i Java, med den ambitionsnivå som anges under rubriken Mål, krav och begänsningar.? HiSafe AB WP1 1_0.doc av 17

5 2. Bakgrund. Alla system, med en komplexitet över trivial, i datorer har eller kommer att drabbas av fel (error). Alla fel kommer sig av någon orsak (fault) i mjukvaran eller hårdvaran. Inget fel får leda till ett misslyckande (failure). Det är oomtvistat när människors liv står på spel. Det borde gälla alla system. Speciellt för system vilkas huvudfunktion är något annat än ren datahantering. Inbyggda system där mekaniken är beroende av programvaran och system som kommunicerar meddelande är extra känsliga om ett fel får orsaka ett misslyckande. Eftersom vi måste leva med att felorsaker skapar fel, vill vi stoppa felkedjan nedan innan den leder fram till ett fatalt misslyckande. felorsak feltillstånd felyttring felorsak feltillstånd... Därför behövs det programvara som tolererar, upptäcker och tar hand om fel innan de har givit ett misslyckande. Teknikerna för att bygga sådana system finns men betingar mycket höga kostnader vid utvecklingen. Kostnaderna utgörs till en väsentlig del av de tester, som måste göras för att systemen skall kunna levereras med erforderlig sannolikhet till ett felfritt uppträdande. Felinjicering är en provmetod som är möjlig och lämplig att göra i programvara. Metoden underlättar uttestning och säkrar en moduls tolerans för fel från dess omgivning. Modulens tolerans blir uttestad och säkrad för de fel som har injicerats. Metoden kan på sikt bli ett billigt och praktiskt verktyg. Ett kraftfullt komplement av verktygen för provningen av programvara i framför allt inbyggda system. Det finns än så länge bara några få praktiskt genomförda försök gjorda med felinjicering och mycket metodarbete återstår. Metodarbetet består bl. a. av att i en tillämpad form göra försök med att använda felinjicering för att prova ett systems feltolerans.? HiSafe AB WP1 1_0.doc av 17

6 3. Mål, krav och begränsningar. För provbänken FINT har vi ställt upp följande mål och krav. Mål: 1. Minimal men tillräcklig inrapportering av fakta om varje programenhet. Beskrivningen utgör en del av den normala dokumentationen och skall kunna göras av den som tillverkat enheten. 2. Inrapporteringens resultat skall vara tillräcklig information för automatisk provning med felinjicerade anrop till målsystemet. 3. Underlagsdata som rapporterats in skall till sin struktur och innehåll vara neutralt till olika programmeringspråk inom sfären Pascal/D80, Ada, Java och C Skillnaden mellan olika målsystem skall begränsas till de direktiv som är specifika för målsystemet. 5. Provbänken skall vara förändringsbar och lätt att bygga ut. Krav 1. Alla tillstånd och alla kombinationer av parametervärden skall kunna provas med anrop av enheten. 2. Enhet under test skall kunna sättas i ett givet tillstånd före prov. 3. Ett provmönster skall så långt det är möjligt vara dokumentationen av enheten. 4. Provfall skall genereras automatiskt som ett provprogram för varje uppsättning värden. 5. Provprogram skall automatiskt kunna länkas, laddas och exekveras med direktiv som skapas samtidigt som provprogrammen. 6. Resultatet från varje provfall skall sammanställas och redovisas med den precision som kan erhållas från målsystemet. Begränsningar: 1. Inga prov av gränssnitt mot brukare. 2. Inga prov av enhetens beroenden mot maskinvara 3. Inga prov av enhetens beroenden mot systemprogramvara.? HiSafe AB WP1 1_0.doc av 17

7 I FINT-projeketet är systemanrop en praktisk början av flera anledningar: 1. De direkta anropen till det levererade systemet måste också tolerera fel. 2. För byggaren av tillämpningen utgör dessa anrop den viktigaste byggstenen eller grunden för tillämpningen. 3. Tillämpningens moduler/komponenter/procedurer/funktioner på lägsta nivå har samma struktur som systemanropen. 4. Systemanropen finns tillgängliga.? HiSafe AB WP1 1_0.doc av 17

8 4. Begrepp. Vi försöker att använda enkla och allmänt accepterade begrepp. I detta avsnitt förtydliga deras användning i FINT-projektets provbänk. Leverantören, som kan vara programmeraren av programenheten eller försäljaren av den, levererar en fullständig beskrivning av modulen med dess gränssnitt. Med modul menas programmoduler som metoder, procedurer, funktioner eller komponenter vilka används av programbyggare. Modulens namn är detsamma som anropsnamnet och unikt för den programtext som skall genereras. Enhet, operation och programmodul kan användas som synonymer. Med modulens gränssnitt avses alla variabler ur det anropande programmets perspektiv som kan beröras när enheten anropas. Variabler påverkar utifrån en modul och/eller påverkas av modulen. En variabel bestäms av sin datatyp och sina värdemängder Datatypen beskriver variabelns möjliga värden. Dess värdemängder beskriver för variabeln tillåtna och/eller otillåtna värden. Variabler är parametrar, returparameter eller annan variabel vars innehåll kan påverka eller ändras i modulen. Parametrar har ett ordningsnummer och kan vara referens- eller värdeparametrar. Variabelns namn skall vara unikt inom den modul som beskrivningen omfattar och för den programtext som skall genereras. En modul kan ha flera provmönster. Ett mönsters id särskiljer de olika provmönstren inom en moduls beskrivning. Ett mönster innehåller en text för att kunna generera direktiv och de texter som behövs för att generera programtexten. I mönstret har varje variabel en provvärdemängd, där det kan finnas värden som är tillåtna och otillåtna inom datatypens värdeföråd men också otillåtna värden utanför datatypens värdeförråd. Provmönster är en generisk beskrivning som skall kunna ge samtliga provfall för provning av en enhet. Ett provfall är en programenhet med genererade givna värden på gränssittets variabler.? HiSafe AB WP1 1_0.doc av 17

9 5. FINT, en provbänk för prov av programenheter. FINT har fyra funktioner. 1. Att beskriva modulen som skall provas. 2. Att beskriva ett provs mönster. 3. Att generera programtext, direktiv och driftprofil för samtliga provfall i ett prov. 4. Att utföra provet enligt direktiven dvs att kompilera och länka samt ladda och köra varje provfall. Beskriv modulen som skall provas Beskriv ett provs mönster Generera programtext och direktiv samt en eventuell driftprofil Utför provet, dvs kompilera, länka, ladda och köra varje provfall. Jämför även med fig 2 i WP2.? HiSafe AB WP1 1_0.doc av 17

10 5.1 Att beskriva modulen som skall provas. Med leverantören avses den person eller de personer som är ansvariga för att modulen är korrekt och gör vad den skall. Leverantören definierar modulens namn, samtliga variabler med datatyp samt variabelns tillåtna och otillåtna värden. Modul 1:n provmönster 1:n variabel 1:n värden tillhör en eller flera av följande variabelns tillåtna värden variabelns otillåtna värden provvärde i ett mönster datatypens definitionsområde 1 : 1 1:n datatyp? HiSafe AB WP1 1_0.doc av 17

11 5.2 Att beskriva ett provs mönster. Med provets mönster som underlag skall samtliga provfall kunna genereras. Provaren använder en befintlig eller nyskriven programkod där operationen anropas. Koden före anropet utgör prefixet i mönstret och koden efter är suffixet. Programkoden i prefixet och suffixet är likadan för samtliga provfall. För var och en av de variabler som utgör gränssnittet till programenheten rapporterar provaren de värden den skall provas för. Normalt sätter provaren värdena enligt eqvivalens metoden, för att få provfall runt variabelns tillåtna extremer. Provaren kan också låta en variabel vara konstant, utelämna den, ange fel ordning om det är en parameter eller sätta variabelns datatyp till fel definition. Provmönster till en modul 1:n direktiv driftprofil variabel prefix 1:n värden suffix provvärde i ett mönster I provmönstret skall också finnas underlag för att göra direktiven till körningen av provfallen, likaså för eventuell driftprofil till provet. Både direktiv och driftprofil bestäms helt av den miljö proven sker i.? HiSafe AB WP1 1_0.doc av 17

12 5.3 Att generera programtext, direktiv och driftprofil för samtliga provfall i ett prov. Provaren startar generatorn för ett mönster. Generatorn skapar koden som skall vara mellan prefixet och suffixet. I koden som skapats sätter generatorn variabelvärdena, gör anropet av operationen samt tar hand om eventuella resultat. Det blir en separat källkod, som är en kompilerbar enhet för varje provfall. På motsvarande sätt byggs direktiven och eventuell driftprofil upp från mönstret. Provmönster Generator En programtext En programtext per provfall En programtext per provfall per provfall Direktiv för provningen? HiSafe AB WP1 1_0.doc av 17

13 5.4 Att utföra provet enligt direktiven dvs att kompilera och länka samt ladda och köra varje provfall. I de enkla provfall vi kört i MACS simulatorn var det nu endast att starta direktiven och för varje provfall genomfördes kompilering, länkning, laddning och en exekvering av modulen som skulle provas. Resultatet av kompileringen, länkningen och exekveringen skrivs i ordinarie loggfil. För varje provfall Direktiv Kompilering Länkning Laddning/körning i målmaskinen Programtext? HiSafe AB WP1 1_0.doc av 17

14 6. Brukarfall. Modul Leverantör Mönster Generering Provare Körning Resultat? HiSafe AB WP1 1_0.doc av 17

15 7. Klassdiagram. Supplier (from Use Case View) Tester (from Use Case View) create create startar Module support Patterns 1..* use Generator 1 1..* 1 create analyze create create 0..* Variable 0..* 1..* 0..* ProgramText Direktive Driftprofil 1..* Logg 1 1..* Pekas ut av direktivet kompileras laddas och länkas. read read Datatype 1 1..* Values write write TestCase Target (from Use Case View) De för modulen tillåtna värdena läggs i en sträng och tolkas beroende på datatyp De för mönstret önskade provvärdena läggs i en sträng och tolkas beroende på datatyp Specifikt för modulernas hemmasystem read Transmitter (from Use Case View)? HiSafe AB WP1 1_0.doc av 17

16 8. Exempel på rapporteringsfönster i provbänken. I figur 1 visas första bilden till beskrivningen av modulen max. Inrapporteringen av beskrivningen har gjorts i enlighet med trädstrukturen i vänstra delen av figur 1. figur 1? HiSafe AB WP1 1_0.doc av 17

17 Om vi öppnar för den första variabeln in1 får vi möjlighet att rapportera enligt figur 2. figur 2 I figur 3 kan vi starta generering av provfall i enlighet med Mönstret prov. Figur 3? HiSafe AB WP1 1_0.doc av 17