OnTime nr 1 2003 - Combitech.se

More documents

Recommendations

Info

STRATEGIER FÖR EFFEKTIV TEST 12 Nr 1 mars 2003 Combitech Systems AB
Test av felhantering i distribuerade realtidssystem Allt fler tillämpningar styrs av distribuerade realtidssystem. Mer kritiska tillämpningar leder till behov av mer omfattande test. Ett mått på omfattning av test kan beskrivas som täckning, som vi alltså använder för att kunna planera och rapportera testerna. Vanligtvis använder vi täckning med avseende på krav för att bedöma tillräckligheten. Men kritiska tillämpningar innebär också att systemen i högre utsträckning är konstruerade för att kunna hantera fel. Kravställningen på felhanteringsmekanismer är ofta begränsad. Detta leder till att kravtäckning inte är en framkomlig väg för att försäkra oss om att ett kritiskt system har testats i tillräcklig omfattning. Ett alternativt mått på täckning är då produkttäckning, det vill säga man utgår från den implementerade produkten istället för kraven på den. I artikeln förklaras olika former av test av felhantering med stöd i användbara testfall. Testfallen är baserade på de element som ingår i produkten eller strukturen för ett distribuerat realtidssystem. Vi skapar förtroende med de beskrivna testfallen som förutsättning. Felhanteringsmekanismer För inbyggda realtidssystem är felhantering en väsentlig del av konstruktionen. Denna är oftast bara begränsat kravsatt, antingen som exceptions i use-case eller på formen ”Det ska finnas felhantering”. Att kraven är få och otydliga innebär att de inte har dokumenterats på ett tillgängligt sätt och att en analys av om kraven är uppfyllda inte kan genomföras. Verifiering och validering av felhanteringsmekanismerna måste alltså göras på annat sätt. I dessa mekanismer ingår de delar av systemet som stödjer funktioner som feldetektering (fault detection), felfiltrering (error masking), återhämtning (recovery), omkonfigurering (system reconfiguration) och rapportering. Om dessa mekanismer är ineffektiva eller utför oönskade handlingar kan det ge allvarliga effekter på systemets tillförlitlighet. Nr 1 mars 2003 Combitech Systems AB Även en begränsad minskning av till exempel feldetekteringsförmågan kan ge avsevärda konsekvenser på tillförlitligheten och andra områden. Felhanteringsmekanismer kan inte prövas under normalanvändning med ”rättfall”. Vi måste skapa situationer med konstruerade eller pålagda fel, ”felfall”, för att verifiera att felhanteringsmekanismerna är implementerade. I många fall ingår det att tröskelvärden i felhanteringen måste kalibreras. Exempelvis så ska ingen åtgärd göras för ett visst antal sporadiska fel men fel signaleras vid ett större antal feldetekteringar. Denna kalibrering syftar till att balansera den svåra avvägningen mellan hög säkerhet (signalera för alla fel) och hög tillgänglighet (filtrera bort fel). Ett typiskt exempel är att särskilja mellan brus på en givare och fel i givaren. Slutligen finns det ett behov av att validera att felhanteringen uppfyller kundens behov. Några egenskaper som kan ingå är detekteringsförmåga (sannolikheten att ett fel detekteras givet att det har inträffat), fördröjning till detektering (tiden från att ett fel inträffat tills det är detekterat) och fördröjning till åtgärd (tiden från det att felet är detekterat tills systemet är omkonfigurerat). Vid test av felhantering måste vi alltså på grund av begränsad kravsättning testa i annat syfte än att visa att kraven är uppfyllda. Antagandet att systemet bara ska kunna hantera ”förväntade” indata är inte tillräckligt. I test av alla typer av system ingår det i större eller mindre omfattning att lägga på avvikelser från förväntade situationer, både på gränssnittet och internt. Ett annat ord för denna teknik är felinjicering. När den formaliseras betraktas den som svårtillämpad och exklusiv för säkerhetskritiska tillämpningar. Men med stöd i form av en checklista är vår erfarenhet att den blir tillgänglig och användbar för ett större antal. Testfall Ett stöd vid konstruktion av ”felfall” baserade på produktstrukturen och som även kan AV STIG URSING användas för analys av täckningen av testerna ges i bild 1. • Bussar och I/O gränssnitt o Felaktigt meddelande o Ogiltigt meddelande o Uteblivet meddelande o Felaktigt innehåll i meddelande o Ogiltigt innehåll i meddelande o Felaktigt signalvärde från sensor o Ogiltigt signalvärde från sensor o Utebliven signal från sensor o Hög ogiltig last på buss (babbling idiot) o Ogiltiga fördröjningar på bussen o Kortslutningar och avbrott • Systemstart, omstart, programvaruladdning och nedstängning: o Felaktig eller ogiltig startsekvens o Avbruten startsekvens o Felaktig eller ogiltig omstart o Avbruten omstart o Felaktig eller ogiltig nerladdning o Avbruten laddning o Felaktig nedstängning o Avbruten nedstängning • Funktioner: o Funktionsanrop i ogiltigt tillstånd o Ogiltig interaktion mellan funktioner o Uteblivet anrop av funktion o Överlast (för hög intensitet i funktionsanrop) o Ogiltig svarstid • Nod eller delsystem o Omstart o Frånvaro o Okonfigurerad, felkonfigurerad eller oinitierad o Spänningsavbrott o Inkonsistenta systemtillstånd • Tillstånd och övergångar o Ogiltiga tillstånd o Ogiltiga övergångar o Genvägar mellan tillstånd (sneak paths) • Spänningsmatning o För hög spänning o För låg spänning o Kortvariga avbrott Bild 1:Testfall för felhantering 13
Page 1 and 2: nTimeGER INSIKT I TID Vad är test
Page 3 and 4: Effektiv test - en fråga om överl
Page 5 and 6: 4. Om en mycket ljus bild visas fö
Page 7 and 8: trollers och andra inbyggda system)
Page 9 and 10: • Gör ett urval av vägar som sa
Page 11: • Har jag tänkt igenom de sätt
Page 15 and 16: Miljölagar driver på testutveckli
Page 17 and 18: När fel inte får förekomma För
Page 19 and 20: Kom igång med prediktions- och evo
Page 21 and 22: in, samt antalet fel som rapportera
Page 23 and 24: Mått Beskrivning SDL-pages Antalet
Page 25 and 26: den behöver man inte testa, därf
Page 27 and 28: Kursschema VÅREN 2003 STRATEGIER F

OnTime nr 1 2003 - Combitech.se

Create successful ePaper yourself

Delete template?

Save as template?