Vad är test av mjukvara? Och varför är det så svårt? sid 6. Kom igång med prediktions- och evolutionsmodeller sid 19

Transkript

1 ntimeger INSIKT I TID T E M A : S T R A T E G I E R F Ö R E F F E K T I V T E S T Nr 1 mars 2003 Vad är test av mjukvara? Och varför är det så svårt? sid 6 Kom igång med prediktions- och evolutionsmodeller sid 19 Krav och tester: Sju myter om felande länkar sid 24 Inbjudan till OnTime-seminarium om Test, se baksidan

2 Innehåll OnTime ska ge insikt i tid OnTime är en branschtidning som tar upp olika aspekter och nyheter inom området utveckling av inbyggda realtidssystem. OnTime ska ge möjlighet att ställa olika perspektiv mot varandra, och samtidigt visa helheten i teknikoch samhällsutveckling. Redaktion Ansvarig utgivare Christer Hoberg, vd Redaktionsråd Göran Carlzon, Erichs Communications Anders Magnusson, Göteborg Per-Ola Malm, Malmö Anders Åström, Linköping Reportage Sven Wennerström Redaktör Eva Holmquist, Jönköping eva.holmquist@combitechsystems.com Nätvariant av OnTime Ledare...3 Krav och risk vår ledstjärna i mörkret...4 Vad är test av mjukvara? Och varför är det så svårt?...6 Test av felhantering i distribuerade realtidssystem...13 Miljölagar driver på testutvecklingen...15 När fel inte får förekomma...17 Kom igång med prediktionsoch evolutionsmodeller...19 Krav och tester: Sju myter om felande länkar...24 Vårt område är inbyggda system.vi kommer aldrig att gå utanför detta område och måste därför behärska inbyggda system bättre än någon annan.våra uppdragsgivare kallar in oss när de står inför sin tuffaste uppgift: bryta ny mark, gå in på främmande teknikområden eller skapa nytt liv i ett projekt som gått snett. Vår affärsidé bygger på att tillföra våra uppdragsgivare nytt kunnande och effektivare metoder inom systemutveckling i kombination med överföring av den erfarenhetsbaserade, tysta kunskapen. För detta har vi utvecklat en metodik som gör att vi successivt för över vårt kunnande till uppdragsgivarens organisation.vi blir därmed så småningom överflödiga inom det dagliga jobbet, vilket som sagt är en del av vår affärsidé vår plats är först och främst inom de delar av projektet där de nya vägvalen är många och svåra. Jönköping (lokalkontor:växjö, Karlskrona, Ulricehamn) Box Jönköping Tel Fax Malmö (lokalkontor: Helsingborg) Box Malmö Tel Fax Göteborg (lokalkontor:trollhättan) Mölndalsvägen 30C Göteborg Tel Fax Stockholm (lokalkontor: Uppsala) Box Stockholm Tel Fax Linköping (lokalkontor: Örebro,Västerås) Teknikringen 9 SE Linköping Tel Fax München Leopoldstr. 236 DE München,TYSKLAND Tel Fax E-post info@combitechsystems.com Hemsida Produktion Erichs Communications AB, Linköping Grafisk design PO.Annonsbyrå AB Tryck NRS-Tryckeri 2 Nr 1 mars 2003

3 LEDARE Effektiv test en fråga om överlevnad Den intellektuella utmaningen kring test blir allt större i och med att de system som utvecklas blir allt mer komplexa. System kommunicerar med system. Mängden gränssnitt och möjliga kommunikationsvägar ökar. Allt detta innebär att informationsmängden, som måste hanteras av de organisationer som utvecklar systemen, ökar lavinartat. För dem som arbetar med test blir det allt svårare att fastställa vad som ska testas och hur det ska testas. Framför allt tar det mer tid, något som står i direkt konflikt med de nya ledorden för systemutveckling: snabbare, bättre, billigare. Något som var mycket tydligt på förra årets EuroSTAR (Software Testing and Review) var att kraven på reducerade kostnader för test blir mer och mer påtagliga. Otaliga deltagare vid konferensen presenterade modeller för att visa nyttan med test, ett resultat av att kostnaderna allt mer ifrågasätts. Lättviktsmodeller som Exploratory Testing där man gör avkall på formalitet och process till förmån för att åstadkomma resultat är på stark frammarsch. Viktigt fokusera rätt Vi står således inför ett mycket intressant problem. Trots ökande komplexitet och informationsmängd, vilket implicerar mer arbete, måste vi minska kostnaderna för test. Effektiviteten måste höjas så att vi hittar fler fel till samma kostnad (eller samma mängd fel till reducerad kostnad). När komplexiteten och mängden information ökar blir det allt viktigare att fokusera testerna rätt. De resurser som står till förfogande måste spenderas på ett sätt som medför att man får bra retur på investeringen, det vill säga att många fel upptäcks. Därför blir det allt viktigare med väl genomtänkta strategier för test. Samtidigt ökar betydelsen av kvalitativa tester i stället för kvantitativa tester. I en bra teststrategi ligger att testa rätt saker och att testa dem på rätt sätt. För att kunna testa rätt saker krävs kontroll och kunskap. Kontroll på kraven för systemet, de risker som är associerade med systemet, kunskap om hur systemet ska användas, hur systemet inte ska användas etc. För att testa på rätt sätt krävs det att man behärskar metoder som kan användas för att skapa relevanta testfall, baserat på den information som samlats in om systemet. Som alla vet finns det ett oändligt antal möjliga testfall även för relativt enkla system. För att vara effektiv krävs det därför att rätt testfall väljs. Felprioriteringar vanliga Verifiering och validering utgör ibland upp till 70 procent av projektens budget i många organisationer. Om man betänker att färre än 25 procent av de projekt som genomfördes i USA 1995 levererades enligt tidplan och budget (något som borde kunna fungera som riktmärke även för Sverige), borde test vara en prioriterad verksamhet. Verkligheten är allt som oftast annorlunda. Verifiering och validering genomförs många gånger av relativt oerfarna och ofta lågutbildade personer. När problem med effektiviteten upptäcks blir lösningen ofta att skapa nya processer, men utan att ha rätt resurser spelar det ingen roll hur bra processen är (om man aldrig tidigare bakat en kaka är sannolikheten relativt liten att man lyckas som konditor ). En nyckelfaktor till effektivitet är således erfarenhet och kunnande, en viktig insikt som många organisationer tyvärr inte gjort. Leverans enligt tidplan och budget För de organisationer som lyckas kombinera den formella kunskapen representerad av processer, metoder och tekniker med den tysta kunskapen som utgörs av erfarenhet, intuition och känsla, finns det stora möjligheter att genomföra effektiv test. Effektiv test skapar förutsättningar för upptäckt av fler fel till lägre (eller samma) kostnad, vilket kan medföra bättre produkter som levereras enligt tidplan och budget! I detta nummer av OnTime presenteras ett antal artiklar fokuserade på strategier för effektiv test som förhoppningsvis väcker tankar och ger inspiration. Trevlig läsning! Thomas Ericson Senior System Engineering Consultant Nr 1 mars

4 AV THOMAS ERICSON Krav och risk vår ledstjärna i mörkret Effektiva tester är en nödvändighet för att reducera de stora kostnader i projekt som associeras med verifiering och validering. Aktiviteter som kan utgöra upp till 70 procent av en projektbudget kräver fokus och noggrannhet! Test ligger på kritiska linjen, det vill säga påverkar leveransdatum direkt ifall testverksamheten blir försenad. Det innebär att vi inte har tid att påbörja den tidspressade testfasen med att börja fundera på hur vi ska testa och vad. Det arbetet måste påbörjas redan när projektet startas. I denna artikel väljer vi att fokusera på några aspekter av test som är kritiska för att just effektivisera testverksamheten. Tidig test En av de mest fundamentala strategier som kan anammas för att effektivisera, inte bara test utan hela projekt, är tidig test. Test har tyvärr traditionellt betraktats vara något som tar vid när utvecklingen (enligt en vattenfallsmodell) är färdig, vilket är ett förhållningssätt som tyvärr fortfarande finns kvar i många organisationer. Detta medför att test blir en reaktiv, istället för proaktiv, disciplin, det vill säga testningen syftar endast till att detektera fel, istället för att förhindra att de införs från första början. Att betrakta test som något som är aktuellt först i slutet av ett projekt medför också ofta att test under de tidiga faserna, modultest och integrationstest genomförs slarvigt (om de alls genomförs). Otaliga är de projekt där slarvet under de tidiga faserna, i ivern att komma till leverans, fått betalas dyrt i form av grova förseningar. Att försöka integrera/testa ett system där man slarvat med modultesterna är som att försöka tillreda en måltid där flera av ingredienserna passerat sitt bäst före-datum! Något som ofta blir väldigt tydligt vid en genomgång av den dokumentation som finns om test på olika nivåer, är att det i många organisationer genomförs mängder med aktiviteter i onödan. Ett annat problem är att man ofta testar för dyrt; systemkrav som kan testas effektivt och uttömmande på modultestnivå testas på systemnivå till stor kostnad. Något som med framgång introducerats i ett flertal organisationer är Master Test Planning (MTP). MTP syftar till att distribuera alla verifierings- och valideringsaktiviteter över de olika testnivåerna, från modultest via ett eller flera integrationssteg till systemtest. Fokus ligger på att verifiera kraven så tidigt som möjligt, till så låg kostnad som möjligt. Ju tidigare kraven kan testas, desto större konfidens i produkten när det väl är dags för systemtest! Systemkraven på en Watchdog kan till exempel testas relativt enkelt i en simulerad miljö under ett modultest, medan det kan vara kostsamt och tidsödande att testa på systemnivån. I detta fall bör det uttömmande testet genomföras under modultestet, och stickprov genomföras under integrations- och systemtesten. Framförallt är det viktigt att synliggöra för alla som arbetar i projektet hur och på vilken testnivå allt ska testas för att undvika redundans, och då är MTP utmärkt. Kravbaserad test Bland det mest kostnadseffektiva man kan göra är att få kraven så välformulerade och realistiska som möjligt. Redan när kraven för projektet etableras måste förberedelserna för systemtesterna initieras. Ett naturligt första steg är att låta testarna delta vid granskningar av kraven. En viktig egenskap hos krav är att de ska vara verifierbara, det vill säga att det går att skapa testfall för att testa kraven. Det är något som de som arbetar med test är synnerligen lämpade att avgöra. Eftersom testarna måste kunna kraven är det också kostnadsoptimerande att använda testare som granskare. Om man dessutom påbörjar arbetet med att planera hur kraven ska verifieras, upptäcker man ofta krav som inte är verifierbara i praktiken. När kraven börjar sätta sig ska systemtestfallen förberedas på allvar. Oavsett hur mycket man ansträngt sig med att etablera kraven, är det först när man börjar använda kraven som innebörden och konsekvenserna av dem uppdagas. Beroenden som man inte visste fanns, krav som saknades, krav som är motstridiga, krav som är orimliga etc. Denna typ av problem måste hanteras tidigt, eftersom det oftast blir kostsamt att hantera dem senare i projektet. För att kunna genomföra rättvisande tester krävs att en representativ testmiljö etableras. Detta är ett tidsödande arbete som måste initieras tidigt. Jag har själv skamset fått erkänna två veckor innan ett viktigt test att vi med de verktyg vi hade att tillgå skulle behöva drygt 46 år för att förbereda för testet. Ibland är det också nödvändigt att använda verktyg för att till exempel lasta systemet. Som exempel kan nämnas ett system som skulle kunna hantera datapaket per sekund. Vi hade inte tillräckligt med utrustning för att kunna generera det antalet datapaket på ett normalt sätt. Inte heller kunde vi säkerställa vilken sekund som datapaketen genererades. Vi var därför tvungna att utveckla ett verktyg som kunde skicka in rätt antal datapaket vid rätt tidpunkt. Utveckling av verktyg är tidsödande och riskfyllt. Om det ändå behövs vill man veta om det tidigt under projektet. Riskbaserad test Test (och alla andra kvalitetssäkrande åtgärder) handlar främst om att reducera risker. Det innebär att man behöver ta fram en riskanalys. För test finns sedan två viktiga parametrar att beakta; dels hur stor påverkan fel får på systemet om det inträffar, och dels hur stor risk är det att ett fel i verkligheten inträffar. Tänk er fyra olika fel i en digital tv-box: 1. I menyn för att sätta upp lösenordsskydd för vissa kanaler finns det ett stavfel. 2. Om man byter direkt från kanal 31 till kanal 4 och sedan till kanal 6 låser sig hela tv-boxen och måste startas om. 3. Om du tittar på kanal 3 kan du inte få fram information om vad som visas på kanalen. 4 Nr 1 mars 2003

5 A B C D E F G H I J K L M N O P Bild1:Tjänstestruktur för meddelandehanteringssystem. 4. Om en mycket ljus bild visas försvinner ljudet. Fel 1 inträffar varje gång du går in i den menyn. Det har dock mycket liten påverkan på systemet när det inträffar. Sannolikheten är antagligen liten att användaren överhuvudtaget upptäcker felet. Fel 2 inträffar bara om du gör tre kanalbyten efter varandra och bara när du byter 31 -> 4 -> 6. Sannolikheten att användaren gör just den kombinationen är liten, men felet inträffar varje gång du gör just den sekvensen. Påverkan på systemet är oerhört stor, hela systemet kan låsas. Sannolikheten att användaren försöker se information om vad som visas på kanalen är ganska stor. Felet påverkar enbart en extrafiness i systemet och samtliga huvudfunktioner fungerar fortfarande. Alltså har det en liten påverkan på systemet. Fel 4 är mycket allvarligt. Det påverkar en huvudfunktion, det vill säga ljudet. Det är också ganska sannolikt att en mycket ljus bild visas. Det är också ett fel som påverkar användaren av systemet. Alla fel av samma typ som fel 4 måste du hitta i ditt system. I övrigt fokuserar du testerna för att hitta de fel som har stor påverkan på systemets huvudfunktioner och de fel som har stor sannolikhet att användaren stöter på. För att kunna hitta de fel som har stor sannolikhet att användaren stöter på kan man använda så kallade användningsprofiler. Användningsprofiler Användningsprofiler handlar om att etablera statistiska modeller som beskriver ett systems användande. Baserat på dessa modeller kan sedan testerna fokuseras på de delar av systemet som har högst sannolikhet att användas, det vill säga delar i vilka fel skulle ha stor synlighet. Detta är en av grundtankarna bakom statistical usage testing. Ett exempel på detta kan vara ett meddelandehanteringssystem som hanterar meddelanden via fast eller mobilt telenät. Systemets tjänstestruktur, det vill säga den funktionalitet som systemet erbjuder en användare, kan överföras till exempelvis en grafisk representation. Det finns ett antal möjliga alternativ, till exempel lämna meddelande, hämta meddelande, ändra användarinställningar (fraser, PIN-kod), hämta samtalsinformation etc. Alla dessa alternativ svarar mot val i en meny, och en grafisk representation kan utgöras av ett träd som beskriver menystrukturen (se bild 1). Baserat på dessa möjligheter sätts sannolikheter, baserat på driftstatistik hos tidigare system eller intervjuer med potentiella användare etc, för varje val (eller gren). Det medför att alla alternativ från rot till löv (som representerar en tjänst) associeras med en sannolikhet. Genom att genomföra sina tester enligt lövens sannolikheter säkerställer man att de fel som finns kvar i systemet har så liten exponering som möjligt för användarna. I bild 1 går det till exempel utläsa att sannolikheten för H: P(H) är 0.4 * 0.4 = 0.16, vilket är mycket högre än sannolikheten för N: P(N) som är 0.1*0.2 = Därmed kan det fastställas att det är viktigare att testa H innan N testas, eftersom fel i H kommer att ha större exponering än fel i N. Att sätta upp användningsprofiler kan vara applicerbart även i andra sammanhang, till exempel för att välja vilka konfigurationer som testerna ska köras på. Eftersom det ofta inte är realistiskt att testa alla konfigurationer är det viktigt att välja de mest sannolika. Sammanfattning Många organisationer har problem med effektiviteten i sin testverksamhet. De resurser som spenderas, spenderas många gånger i onödan, eller med otillfredsställande resultat eftersom det saknas genomtänkta strategier för test. Genom att fokusera på tidiga kravbaserade tester av krav i kombination med riskhantering, skapas förutsättningar för att reducera kostnaderna och därmed öka effektiviteten. Nr 1 mars

6 AV JAMES A. WHITTAKER Vad är test av mjukvara? Och varför är det så svårt? Copyright 2000 IEEE. Publicerad med tillstånd av IEEE. Ursprungligen publicerad i IEEE Software, januari/februari 2000, med namnet What Is Software Testing? And Why Is It So Hard?. Testning av mjukvara kan sägas vara den minst förstådda delen av utvecklingsprocessen. James A.Whittaker ser på problemen i fyra steg och visar varför det är så knepigt att eliminera fel (buggar) och varför testning är en ständig kompromiss. Alla programutvecklare vet hur frustrerande det är när användarna rapporterar programvarufel. När detta händer frågar sig utvecklaren ofrånkomligen: Varför upptäcktes inte detta under test? Oräkneliga timmar lades säkerligen på noggrann testning av hundratals eller tusentals variabler och kodrader, så hur kan ett fel ha undsluppit detta? Svaret kräver i första hand en närmare granskning av testning i utvecklingssammanhang. För det andra kräver det förståelse av den roll som spelas av mjukvarutestare och utvecklare två mycket olika funktioner. Vi antar att de fel användarna rapporterar förekommer i ett program som verkligen har felaktigheter. Svaret kan då bli något av dessa: Användaren körde otestad kod. Det är inte ovanligt att utvecklare till följd av tidsbrist släpper otestad kod kod i vilken användaren kan hitta fel. Ordningen i vilken programsatserna exekverades i verkligt bruk skiljer sig från den som testades. Denna ordning kan vara avgörande för om ett program fungerar eller ej. Användaren exekverade en kombination av otestade indata-värden. Kombinationen av indatavärden som tusentals användare kan exekvera i ett programs interface är helt enkelt för många för att alla ska kunna testas. Testare måste göra svåra val om vilka värden som ska testas och ibland väljer man fel. Användarens operativsystem har aldrig testats. Vi kanske kände till systemet, men hade aldrig tid att testa det. Kanske hade vi inte möjlighet att efterlikna användarens kombination av hårdvara, perifera enheter, operativsystem och applikationer i vårt testlabb. Företag, som till exempel gör mjukvara för nätverk, skapar knappast ett nätverk med tusentals noder i sitt testlabb trots att användare kan, och gör, detta. Med hjälp av en översikt av problemen och processen vid mjukvarutestning undersöker den här artikeln de problem testare står inför. De tekniska bekymmer som lösningarna måste tillgodose identifieras också. Jag undersöker även de existerande grupper av lösningar som används i praktiskt bruk. Testare och testprocessen För att kunna planera och utföra tester måste testarna titta på vad mjukvaran ska utföra, den indata som ges och hur dessa kan kombineras, samt den omgivning i vilken mjukvaran slutligen ska fungera. Denna svåra, tidskrävande process kräver sofistikerat tekniskt kunnande och riktig planering. Testare måste inte bara ha goda utvecklingskunskaper testning innebär ofta en hel del kodning utan även ha kunskaper i formella språk, grafteori och algoritmer. Faktum är att kreativa testare har använt många relaterade områden inom datalogin som hjälp vid testproblem, ofta med imponerande resultat. Även enkla program kan uppvisa hinder för testarna. För att få en klarare syn på några av de svårigheter mjukvarutester innebär ska vi närma oss testningen i fyra faser: 1. Modell av mjukvarans omgivning 2. Val av testscenarier 3. Körning och utvärdering av testscenarier 4. Mätning av hur testerna framskrider Dessa faser skapar en struktur för testarna, i vilken man kan gruppera relaterade problem som måste lösas innan man går vidare till nästa fas. Fas 1: Modell av mjukvarans omgivning Testaren har till uppgift att simulera interagerandet mellan mjukvaran och dess omgivning. Testare måste identifiera och simulera de interface ett mjukvarusystem använder och räkna upp de indata som passerar varje interface. Detta är kanske den mest fundamentala uppgift en testare möter, och det kan vara svårt med tanke på de olika filformaten, kommunikationsprotokollen och tillgängliga tredjepartsinterface. De fyra vanliga interfacen är följande: Mänskligt interface inkluderar alla de vanliga metoder med vilka människan kommunicerar med mjukvaran. Vanligast är GUI, men även äldre varianter som exempelvis kommandorad och menydrivet interface används fortfarande. Indata från perifera enheter att tänka på kan vara musklick, tangentbordsaktiviteter och indata från andra tillbehör. Testarna avgör sedan hur dessa data ska organiseras för att förstå hur de ska utgöra en bra testsvit. Mjukvaruinterface, med samlingsnamnet API, innebär sättet på vilket mjukvaran använder ett operativsystem, databas eller bibliotek. De tjänster dessa applikationer tillhandahåller är utformade som test för indata. Utmaningen för testare är att inte bara kontrollera de förväntade utan även de oväntade tjänsterna. Alla utvecklare förväntar sig till exempel att operativsystemet ska spara filer åt dem. Den funktion man inte tänker på är att operativsystemet meddelar när lagringsmediet är fullt. Även felmeddelanden måste testas. Filsystemsinterface finns alltid när mjukvaran läser eller skriver data till externa filer. En utvecklare måste skriva mängder av felkontrollkod för att veta om filerna innehåller korrekt data och format. Följaktligen måste testare konstruera eller generera filer med innehåll som är både korrekt och felaktigt och filer som innehåller varierad text och format. Kommunikationsinterface ger direkt tillgång till fysiska enheter (såsom drivrutiner, con- 6 Nr 1 mars 2003

7 trollers och andra inbyggda system) och behöver ett kommunikationsprotokoll. För att testa sådan mjukvara måste testare kunna generera både korrekta och felaktiga protokollströmmar. Testare måste sammanställa (och skicka till mjukvaran som testas) många olika kombinationer av kommandon och data i rätt paketformat. Testare måste därefter förstå det sätt på vilket användaren kan agera och som faller utanför den kontroll den testade mjukvaran utför. Konsekvenserna kan bli allvarliga om programmet inte är förberett. Exempel på situationer som testaren måste förbereda är de följande: Genom att använda operativsystemet raderar en användare en fil som en annan användare har öppen. Vad händer nästa gång programmet vill öppna denna fil? En enhet blir omstartad mitt i en pågående kommunikations-session. Kommer mjukvaran att förstå detta och reagera på rätt sätt, eller kommer den att hänga sig? Två programvarusystem konkurrerar om samma tjänst från en API. Kommer API:n att kunna serva båda korrekt? Varje applikations unika miljö kan resultera i ett betydande antal användarageranden som måste testas. Att ta hänsyn till När ett interface uppvisar problem av oändlig storlek och komplexitet står testaren inför två svårigheter: Han måste noggrant välja värden för alla variabla indata och han måste bestämma indatasekvens. När man väljer värden, bestämmer testaren värdena på individuella variabler och förser systemet med intressanta kombinationer när programmet accepterar multipla variabler som indata. Testare använder ofta tekniken med gränsvärdesanalys för att välja enstaka variabelvärden vid eller runt gränserna. Exempelvis är testning av minimum, maximum och nollvärde av ett bekräftat heltal en vanligt accepterad idé. Det gäller även värden som omger vart och ett av dessa områden, till exempel 1 och 1 (vilka ju omger nollgränsen). Värdet mellan gränserna behandlas som samma siffra, om vi använder 16 eller gör ingen skillnad för den mjukvara som testas. En mer komplex situation är att välja värden för multipla variabler som behandlas samtidigt och potentiellt påverkar varandra. Testare måste ta hänsyn till hela vektorprodukten av värdekombinationer. För två heltal räknar man med båda positiva, båda negativa, en positiv och en negativ och så vidare. När man ska bestämma sekvensen för indata har testare problemet med sekvensgeneration. Testare behandlar varje fysiskt indata och abstrakt händelse som symboler i ett formellt språk och definierar en modell av det språket. En sådan modell låter testaren visualisera ett antal möjliga tester, för att se hur varje test passar in i helheten. Den vanligaste modellen är en graf eller ett logikdiagram, men det finns många varianter. Andra populära modeller inkluderar standarduttryck och grammatik, verktyg från språkteori. Mindre vanliga är stokastiska processer och genetiska algoritmer. Modellen är en representation som beskriver hur indata och händelsesymboler kombineras för att ge syntaktiskt korrekta ord och meningar. Dessa meningar är indatasekvenser som kan appliceras på mjukvaran vid testning. Ta till exempel uttrycket Filemenu.Open, vilket ger en dialogruta för filval; filename, vilket representerar valet (kanske genom musklickning) av en existerande fil, samt ClickOpen och ClickCancel,som innebär knapptryckningar. Sekvensen Filemenu. Open filename ClickOpen är korrekt såväl som många andra. Sekvensen ClickCancel Filemenu.Open är inte möjlig därför att cancelknappen inte kan tryckas ner innan Nr 1 mars

8 dialogrutan har anropats. Modellen för ett formellt språk kan göra sådana distinktioner mellan sekvenser. Exempel på textredigering Vi kan representera korrekta användningar av filvalsdialogen i till exempel en textredigerare med standarduttycket: Filemenu.Open filename* (ClickOpen ClickCancel) Där står asterisken för Kleene stängoperatör, vilket indikerar att filename-aktiviteten kan förekomma noll eller fler gånger. Detta uttryck betyder att det först erhållna indatat är Filemenu.Open, följt av noll eller flera val av filnamn (med en kombination av musklick och tangentbord). Sedan trycks på antingen Öppna- eller Stängknapparna. Denna enkla modell utgör alla kombinationer av indata som kan förekomma vare sig de är begripliga eller inte. För att skapa en fullständig modell av mjukvarans miljö för hela textredigeraren, skulle vi tvingas representera sekvenser för användarinterfacet och operativsystemets interface. Vi behöver dessutom en beskrivning av korrekta och korrumperade filer för att fullständigt kunna undersöka filsystemets interaktion. En sådan uppgift skulle kräva en generös användning av dekomposition och abstraktion. Fas 2:Val av testscenarier Många domänmodeller och variabla partitioner representerar en oändlig mängd testscenarier, som alla kostar tid och pengar. Endast en undergrupp kan användas i ett realistiskt schema för mjukvaruutveckling, så hur väljer en smart testare? Är 17 ett bättre heltal än 34? Hur många gånger ska ett filnamn väljas innan man trycker på knappen öppna? Dessa frågor, som har många svar, är föremål för forskning. Testpersonal föredrar dock svar som relaterar till att täcka källkod eller dess indatadomän. Testare strävar efter täckning: täckning av koduttryck (köra varje källkodsrad minst en gång) och täckning av indata (prova varje externt genererad händelse). Detta är de minimikriteria testare använder för att bedöma hur komplett deras arbete är; följaktligen är de tester man väljer de som bäst visar täckningsmålen. Om det räckte med kod och täckning av in-datavärden skulle utsläppta program ha mycket få fel. När det gäller koden så är det inte de enskilda koduttrycken som intresserar testare utan körbara vägar: sekvenser av koduttryck som resulterar i en exekvering av mjukvaran. Dessvärre finns det en oändlig mängd vägar. När det gäller indatadomänen är det inte enskilda indata som intresserar testaren utan indatasekvenser som, sett till helheten, står för scenarier som mjukvaran måste agera på. Det finns en oändlig mängd av dessa också. Testarna går igenom dessa oändliga sätt för att komma fram till bästa möjliga adekvata testdatakriterier, som på ett lämpligt och ekonomiskt sätt ska representera alla de oändliga möjligheterna. Bäst och adekvat är något subjektivt: testare söker vanligen det sätt som upptäcker flest fel. (Hög och låg felfrekvens samt uttydning av dessa tas upp senare). Många användare och professionella kvalitetssäkrare vill gärna att testarna ska utvärdera scenarier som avser typisk användning, alltså det som oftast händer i verkligheten. Sådana tester säkerställer att mjukvaran fungerar i enlighet med specifikationen och att de vanligast förekommande felen har upptäckts. Vi kan till exempel titta på textredigeringsexemplet igen. För att testa verklig användning inriktar vi oss på redigering och formatering, eftersom detta är vad verkliga användare gör mest. För att hitta fel är dock de mer svårkodade funktionerna för figurritning och tabellredigering ett troligare ställe att leta på. Kriterier för exekvering av testvägar Kriterier för riktiga testdata riktar in sig på täckning av exekverbara vägar eller på täckning av indatasekvenser, men sällan på båda. Det vanligaste kriteriet för val av exekverbar väg fokuserar på att täcka upp kontrollstrukturer. Till exempel: Gör ett urval av testfall som exekverar varje koduttryck minst en gång. Gör ett urval av testfall som gör att varje grenstruktur (If, Case, While osv.) utvärderas med varje möjligt värde. Flödeskontroll är dock endast en aspekt av källkoden. Det mjukvaran egentligen gör är att flytta data från ett ställe till ett annat. Adekvata testdatakriterier och dessas täckning beskrivs i dataflow-familjen. Till exempel: Gör ett urval av testfall som initialiserar varje datastruktur och sedan följaktligen används. Slutligen, felsådd, som är mer uppmärksammat av forskare än av praktiker, är intressant. Denna metod innebär att fel avsiktligen inplanteras i källkoden. Sedan utformas testscenarier för att finna dessa fel. Genom att finna de inplanterade felen finner testaren i bästa fall även riktiga fel. Ett kriterium enligt följande är alltså möjligt: Gör ett urval av testfall som visar alla de inplanterade felen. Kriterier för test av indatadomän Kriterierna för att täcka en indatadomäns område omfattar alltifrån en enkel täckning av ett interface till mer komplicerade statistiska mätningar. Gör ett urval av testfall som innehåller varje fysisk indata. Gör ett urval av testfall som gör att varje interfacekontroll (fönster, meny, knapp, osv.) kommer att stimuleras. Kriteriet diskriminering kräver slumpvis val av indatasekvenser, tills dessa statistiskt representerar hela den oändliga indatadomänen. Gör ett urval av testfall som har samma statistiska egenskaper som hela indatadomänen. 8 Nr 1 mars 2003

9 Gör ett urval av vägar som sannolikt kommer att exekveras av den typiske användaren. Sammanfattning Testforskare studerar algoritmer för val av minimala testsviter som möter kriterierna för exekvering av vägar och indatadomäner. De flesta forskare anser att det är klokt att använda flera kriterier när man tar beslut om att släppa en produkt. Experiment som jämför hur adekvata kriterier för testdata är behövs, såväl som nya kriterier. Testare bör vara medvetna om vilka kriterier som är inbyggda i deras metoder, samt förstå de begränsningar dessa kriterier har när man rapporterar resultat. Vi återkommer till adekvata testdata i den fjärde fasen (som handlar om testmätning) eftersom kriterier även fungerar som ett mått på hur fullständigt ett test är. Fas 3: Köra och utvärdera testscenarier Efter att ha identifierat lämpliga test brukar en testare konvertera dessa till exekverbar form, ofta som kod, så att testscenarierna simulerar typiskt agerande av en användare. Då det kräver mycket arbete att manuellt tillämpa testscenarier och fel lätt uppstår, brukar testare försöka automatisera detta så långt som möjligt. I många miljöer kan man använda automatiserade applikationer med hjälp av kod som simulerar användare. Det finns också hjälpfunktioner för detta. Fullständig automatisering kräver att man simulerar varje källa för indata och destinationer för hela operativmiljön. Testare inkluderar ofta datainsamlingskod i den simulerade miljön som så kallade taggar, det vill säga en resultatkontroll. Dessa taggar tas bort när mjukvaran släpps, men när testscenariot körs ger de värdefull information som hjälper testare att identifiera missar och isolera fel. Utvärdering av scenarier, den andra delen av fas 3, är svår att genomföra (och ännu värre att automatisera). Utvärdering innebär jämförelser mellan verkliga utdata, som ett resultat av körda testscenarier, och förväntade utdata såsom dessa dokumenterats i en specifikation. Specifikationen antas vara riktig; avvikelser är misslyckanden. I praktiken är det svårt att göra denna jämförelse. Teoretiskt är det omöjligt att jämföra två godtyckliga, Turing-körbara funktioner (för att se överensstämmelse). För att återgå till exemplet med textredigering: om utdata ska vara markera ett felstavat ord, hur avgör man då om varje felstavning har upptäckts? Denna svårighet är skälet till varför verklig-mot-förväntad-jämförelser vanligen görs av ett mänskligt orakel, en testare som visuellt ser på skärmdata och omsorgsfullt analyserar utdata. Två sätt att utvärdera ditt test När det gäller problemet med att utvärdera tester jobbar forskarna med två vägar: formalism och inbäddad testkod. Formalism innebär huvudsakligen ett hårt jobb med att formalisera sättet på vilket specifikationer skrivs, och hur design och kod härleds från dessa. Både objektorienterad och strukturerad utveckling innehåller mekanismer för såväl formellt uttryckta specifikationer som för att förenkla jämförelser mellan förväntat och verkligt resultat. Industrin har vanligen tagit avstånd från formella metoder. Nr 1 mars

10 Trots detta är en bra specifikation, även en informell sådan, till mycket god hjälp. Utan en specifikation kommer testare troligen endast att finna de mest uppenbara felen. Dessutom betyder frånvaron av en specifikation att massor av tid går förlorad när testare rapporterar ospecificerade funktioner som fel. Det finns huvudsakligen två typer av inbäddad testkod. Den enklaste typen är testkod som exponerar vissa interna dataobjekt eller tillstånd och gör det lättare för ett externt orakel att bedöma korrektheten. När den är införd är en sådan funktion osynlig för användaren. Testare kan se testkodsresultaten med exempelvis en test-api eller en debugger. En mer komplex typ av inbäddad kod är självtestande program. Detta innebär ibland att flera lösningar av problemet kodas och en lösning får kontrollera den andra, eller att inverterade rutiner som återställer operationerna skrivs. När en operation är utförd och sedan återställs, ska mjukvarans status vara samma som före operationen. I denna situation är oraklet inte perfekt, det kan finnas ett fel i båda operationerna, där det ena felet döljer det andra. Regressionstestning Efter att testarna överlämnat framgångsrikt återupprepbara felindikationer till utvecklarna, brukar dessa vanligen ta fram en ny version av mjukvaran (i vilken felet förhoppningsvis är borttaget). Testningen fortsätter med följande versioner till dess att en version anses vara klar att släppa. Frågan är hur mycket omtestning (kallad regressionstestning) av version n som är nödvändig med användning av de tester som gjordes på version n 1? Varje särskild ändring kan (a) rätta endast det problem som rapporterats, (b) misslyckas med att rätta problemet, (c) rätta till problemet men förstöra något som fungerat tidigare, eller (d) misslyckas med att rätta till problemet och förstöra något annat. Med tanke på dessa möjligheter förefaller det välbetänkt att köra om varje test från version n 1 på version n innan något nytt testas, trots att en sådan procedur är kostnadskrävande. Nya mjukvaruversioner har dessutom ofta många nya funktioner förutom rättade fel, så regressionstestning kommer att stjäla tid från testningen av ny kod. För att spara resurser har testarna ett nära samarbete med utvecklarna för att prioritera och minimera regressionstestningen. En annan nackdel med regressiv testning är att denna (tillfälligt) kan förändra avsikten med testdatakriteriernas korrekthet som valts ut i den tidigare testvalsfasen. När regressiva tester görs försöker testare endast att påvisa frånvaron av fel och tvinga applikationen att uppvisa ett specifikt uppförande. Resultatet av detta är att korrektheten i testdatakriterierna, vilket hittills styrt testvalen, nu ignoreras. Istället måste testarna säkerställa att en pålitlig ändring av koden har gjorts. Relaterade problem Det bästa är när utvecklare skriver kod med testningen i åtanke. Om koden är svår att testa och verifiera bör den skrivas om för att bli mer testbar. På liknande sätt bör en testmetod bedömas efter hur mycket stöd den ger för automatisering och orakelproblem. Alldeles för många metoder ger ringa ledning på något av områdena. Ett annat problem för testare vid test och verifiering är koordineringen av debuggeraktiviteter med utvecklarna. Eftersom systemfel identifieras av testarna och diagnostiseras av utvecklarna, uppstår två frågor: om felreproduktion och återexekvering av testscenariot. Felreproduktion är inte så enkelt som det kan verka. Den självklara lösningen är förstås att köra det problematiska testet och observera det felaktiga uppförandet igen. Dock innebär en omkörning av ett test ingen garanti för att exakt samma omständigheter skapas. När man kör om scenarier krävs att vi känner till exakt status för operativsystemet och all tilläggsmjukvara, Exempelvis kräver klientserver-applikationer att man återskapar de förhållanden som omgav både klienten och servern. Dessutom måste vi känna till status för testautomatiken, perifera enheter, samt eventuella applikationer i bakgrunden som körs lokalt eller över ett nätverk och kan påverka den applikation som testas. Det är inte så konstigt att en av de vanligaste kommentarerna som görs i ett testlabb är: Så här uppförde det sig inte förut Fas 4:Att mäta testningens framsteg Anta att jag är testare och en dag frågar min chef: Vad är statusen på din testning? Testare får ofta den frågan men är dåligt rustade att svara. Skälet är att dagens praxis är att räkna saker. Vi räknar hur mycket indata vi använt, den procent av koden vi täckt och det antal gånger vi startat applikationen. Vi räknar hur många gånger vi avslutat applikationen korrekt, antal missar vi funnit och så vidare. Uttydningen av sådan räkning är svår; är det bra eller dåligt när man finner mycket missar? Svaret kan vara varken eller. Ett stort antal fel kan betyda att testningen var noggrann och mycket få fel återstår. Det kan även betyda att mjukvaran helt enkelt har massor av fel och trots att många hittats, så återstår flera. Eftersom det ger liten insikt i testningens framsteg att räkna åtgärder, så förstärker många testare dessa data genom att besvara frågor som utformats för att säkerställa hur kompletta de funktionella och strukturella testerna är. För att kontrollera hur komplett en struktur är kan testare till exempel ställa följande frågor: Har jag testat för vanliga programmeringsfel? Har jag kontrollerat all källkod? Har jag tvingat fram initialisering och användning av alla interndata? Har jag hittat alla planterade fel? För att kontrollera hur komplett en funktion är kan testare ställa följande frågor: 10 Nr 1 mars 2003

11 Har jag tänkt igenom de sätt på vilket mjukvaran kan göra fel och valt tester som visar att den inte gör fel? Har jag använt alla indata? Har jag utforskat mjukvarans alla möjliga tillstånd? Har jag kört alla scenarier jag förväntar mig att en användare ska exekvera? Dessa frågor (huvudsakligen korrektheten i testdatakriterier) är till hjälp för testare, men att bestämma när man ska sluta testa, och släppa ut en produkt, är mer komplext än så. Testare vill ha kvantitativa mätningar av hur många fel som finns kvar i mjukvaran och risken för att dessa ska upptäckas på fältet. Vi kan närma oss det kvantitativa problemet strukturellt och funktionellt. Testbarhet Jeffrey Voas har från en strukturell utgångspunkt föreslagit testbarhet-stabilitet (testability) som ett sätt att bestämma komplexiteten i testningen av en applikation. Tanken att antal programrader är ett mått på hur svår testningen av programmet är, är förlegad. Saken är mycket mer dunkel och det är här testbarheten kommer in. När en produkt har hög testbarhet är den lätt att testa och följaktligen lätt att hitta felen i. Vi kan då övervaka testningen och se att eftersom antalet fel är färre, så är det mindre troligt att det finns många oupptäckta fel. Låg testbarhet kräver många fler tester för att kunna dra samma slutsatser; vi förväntar oss att felen är svårare att finna. Testbarhet är en fängslande idé, men ännu bara i sin linda; inga data om dess förutsägande möjligheter har ännu publicerats. Tillförlitlighetsmodeller Hur länge kommer mjukvaran att fungera innan något fel uppstår? Hur dyrt blir det att underhålla den? Det är definitivt bättre att ta reda på detta medan du fortfarande har mjukvaran i testlabbet. Från en funktionell synpunkt är tillförlitlighetsmodeller (matematiska modeller av testscenarier som försöker förutse framtida felmönster baserat på använda data) väl etablerade. Dessa modeller försöker alltså förutse hur mjukvaran kommer att uppföra sig på fältet baserat på hur den uppförde sig under testningen. För att åstadkomma detta behöver de flesta tillförlitlighetsmodeller en specificerad användningsprofil, en beskrivning av hur användare förväntas ge indata. För att kunna beräkna sannolikheten för ett misslyckande gör dessa modeller antaganden om den underliggande sannolikhetsfördelningen för förekomsten av fel. Såväl forskare som praktiker är skeptiska till att sådana profiler kan sammanställas korrekt. Dessutom har antaganden gjorda av vanliga trovärdighetsmodeller inte blivit teoretiskt eller experimentellt verifierade utom i speciella applikationsdomäner. Trots det har framgångsrika fallstudier visat att modellerna är pålitliga. Mjukvaruföretag står inför stora utmaningar vid testning av sina produkter, och utmaningarna växer varefter mjukvaran blir alltmer komplex. Det första och viktigaste att inse är komplexiteten vid testning och att ta detta på allvar. Mitt råd är: anställ den smartaste personal du kan hitta, hjälp dem att få de verktyg och den utbildning de behöver för att lära sig yrket och lyssna på dem när de berättar om kvaliteten på din mjukvara. Att ignorera dem kan vara det dyraste misstag du någonsin kommer att göra. Testforskare står på samma sätt inför utmaningar. Mjukvaruföretagen är angelägna om att finansiera bra forskningsidéer, men kraven på mer praktiskt och mindre akademiskt arbete är stora. Det är nu dags att knyta akademisk forskning till verkliga industriprodukter. Då blir vi alla vinnare. James A.Whittaker forskar och undervisar i datavetenskap på Florida Institute of Technology. Forskningen är inriktad mot test av mjukvara, datasäkerhet och sårbarhet inom dataområdet. Han är författare till boken How to Break Software och har fått publicerat över 50 vetenskapliga artiklar inom mjukvaruutveckling och datasäkerhet. Nr 1 mars

12 12 Nr 1 mars 2003

13 AV STIG URSING 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. Ä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 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 Nr 1 mars

14 En sådan lista kan kallas en testkatalog, och den är speciellt användbar i matrisform. Kolumnerna i matrisen är de testfall som man använder om och om igen, matrisens rader är testobjekten. En effektiv katalog betingar ett stort värde för organisationen. Giltiga indata betyder alla indata för vilket systemet förväntas ha ett korrekt beteende, ogiltiga betyder då att de avviker från det specificerade värdeområdet. En parameter som representerar temperaturen från en sensor kan exempelvis ha ett värde som är lägre eller högre än vad som är specificerat för sensorn. Felaktiga indata betyder att indata ligger inom giltigt värdeområde men avviker från normalsituationen. Dessa illvilliga fel är besvärligare fall, då det gäller att identifiera orimliga värden eller ovanliga situationer. Ett enstaka högt men giltigt värde från temperatursensorn ska hanteras på ett visst sätt, en kontinuerlig höjd temperatur hanteras på ett annat sätt. De fel man först kommer att tänka på är ofta elektriska eller hårdvarurelaterade. Samtidigt vet vi av erfarenhet att många fel har sin orsak i programvaran, exempelvis beräkningsfel eller fel i villkor. Det är alltså viktigt att man skapar sig en uppfattning av vilken typ av fel man vill detektera, en felmodell. Olika konstruktions- och utvärderingsmetoder resulterar i vissa typer av fel. Från tidigare projekt har vi erfarenheten att en viss typ av fel är allvarliga, risker i den tänkta användningen av systemet medför kanske fokusering på andra typer av fel. Urval Var för sig blir mängden testfall i bild 1 omfattande, med kombinationer blir det ohanterligt. Strategin blir då: 1. Testa på så låg systemnivå som möjligt, det ger möjlighet till parallella aktiviteter samtidigt som kombinatoriken begränsas. 2. Använd alternativa metoder (analyser och granskningar) för att fånga klasser av fel och för att undvika att fel kommer in i implementationen. I många fall är det dock svårt att se att någon annan metod för utvärdering än dynamisk exekvering (test) ger tillräckligt förtroende. En direkt observation av resultatet av ett test, med till exempel fördröjda indata, är svårt att ersätta. Det finns två olika testtekniker att rekommendera för pålagda (injicerade) fel. Den ena fokuserar på potentiella problem, så kallat riskbaserat test, den andra fokuserar på genomförandet, så kallat utforskande test. Riskbaserat test utgår från en riskanalys med syfte att finna allvarliga felyttringar. Man ställer sig repetitivt frågan, Vad kan gå fel här? och söker efter svagheter, hot och konsekvenser. I de fall en FMEA har utförts, är det självklart en viktig ingång till urvalet vid riskbaserat test. FMEA är en analysmetod som utgår från att fel på låg nivå ansätts och eventuella konsekvenser utvärderas. En del tester av felhanteringsmekanismer brukar utgöras av så kallade utforskande test. Testfallen har då inte utfall som kan specificeras i förväg, utan resultatet får utvärderas mot oönskade händelser (feared events). Det innebär ofta att man planerar, konstruerar och kör sina tester i en aktivitet. Man utvecklar alltså testfall baserat på det man lär sig. Detta kan med fördel utföras som parvis testning, när två testare arbetar tillsammans och växelvis delar genomförandet, vilket samtidigt är ett sätt att skapa en kreativ och stimulerande miljö. En faktor som i hög grad påverkar förmågan att utföra test av felhanteringsmekanismer är observerbarhet och styrbarhet. Observerbarhet: möjligheten att läsa signaler som reflekterar systemets tillstånd Styrbarhet: möjligheten att lägga på signaler som ställer systemet i ett visst tillstånd För att skapa förtroende för att omfattningen av test är tillräcklig, mäter vi täckningen och påverkar utvecklingsarbetet för högre testbarhet. Test av egenskaper som säkerhet, tillgänglighet och tillförlitlighet ställer stora krav på förståelse för kundens behov. En förutsättning för att kunna kommunicera och rapportera omfattningen av genomförda tester är att vi mäter med en överenskommen måttstock. En överenskommen testkatalog ger stöd för uttalandet Nu är jag nöjd. Stig Ursing är seniorkonsult inom test och dependability engineering på. 14 Nr 1 mars 2003

15 AV SVEN WENNERSTRÖM Miljölagar driver på testutvecklingen När Lars Wallin arbetade med flygmotorerna i JAS-projektet föddes idén till ett nytt sätt att arbeta med motortester. Idéerna tog han med sig till arbetet med diagnossystem i Saab Automobiles bilmotorer. En av skillnaderna mellan bil- och flygmotorer, berättar Lars, är att bilmotorernas styrsystem är betydligt mer avancerade. Programvaran som finns i alla moderna bilmotorer innehåller inte bara funktioner för motorstyrningen. Ungefär hälften av programvaran svarar för att hela tiden övervaka hur motorn och bilen uppför sig. Diagnosfunktionerna, som blir allt mer omfattande, har drivits fram av striktare miljökrav för bilar. Emissionskraven gäller för hela bilens livslängd och för att kunna uppfylla dem finns ett system med sensorer som hela tiden styr och övervakar motorn. Data från sensorerna jämförs med en modell av hur bilen ska uppföra sig. Om sensorerna läser av värden som tyder på funktionsfel varnas föraren genom att en varningslampa tänds. Det är främst de hårda miljölagarna i Kalifornien som sätter press på biltillverkarna, säger Lars Wallin. Reglerna kräver att alla felaktigheter som riskerar att leda till ökade utsläpp upptäcks och rättas till. Hela bilserier kan tvingas tillbaka till fabriken för åtgärdande och det har hänt att biltillverkare har blivit stämda på miljardbelopp för att de inte uppfyllt lagkraven. Att misslyckas med att uppfylla miljökraven är alltså kostsamt. För en liten biltillverkare som Saab skulle det kunna leda till en ekonomisk katastrof om bilarnas diagnossystem inte fungerar som de ska. Det är alltså i högsta grad affärskritiskt att systemen fungerar som de ska och att vi lyckas verifiera att bilarna uppför sig som det är tänkt i utvecklingsarbetet, säger Lars Wallin. Svårt hitta normalanvändning Att verifiera hur en bil beter sig och skapa fungerande diagnossystem är särskilt krävande. För bilar är det nästan omöjligt att hitta en normalanvändning. Testernas körcykler ska avbilda olika användningsområden för bilarna, allt från ryckig stadstrafik till jämn motorvägstrafik. Men det finns fler faktorer att ta hänsyn till. Bilmodeller som säljs över hela världen utsätts för olika klimat med skiftande temperatur och luftfuktighet. Dessutom inverkar lufttrycket, och därmed på vilken höjd över havet bilen framförs. För att kunna bygga ett bra system måste vi alltså veta hur våra motorer uppför sig i alla möjliga situationer över hela världen, säger Lars Wallin. När bilmodellerna utvecklas testas först alla komponenter var för sig och slutligen testkörs hela bilen för att verifiera att allt fungerar som det är tänkt. Verifieringsarbetet för bilar är mycket intensivt. Bilens hela livscykel ska testas. För att täcka in så mycket som möjligt av det bilmodellen kommer att utsättas för under sin livslängd, körs testbilarna över mil på Nr 1 mars

16 Lars Wallin överför idéer från JAS Gripenprojektet till testverksamheten på Saab Automobile. olika håll i världen under de årslånga verifieringscyklerna. CAN-buss, systembussen för motorstyrning paket. Flight recordern kopplas till bilens Traditionellt genomförs testerna av ingenjörer som åker runt i världen och kör bilarna Upp till 150 kanaler kan läsas in samtidigt. och andra funktionskritiska enheter i bilen. fullproppade med mätinstrument, förklarar De flesta kanaler läses in med ganska låg frekvens, men systemet tillåter att upp till 30 Lars Wallin. Egentligen är det ett ganska ineffektivt sätt att bedriva test på, eftersom ingenjörerna ägnar en stor del av sin tid åt att vissa villkor och när villkoren uppfylls löser triggers läggs in. Varje trigger svarar mot köra bil istället för att analysera testdata. triggern ut och den aktuella kanalen läses in Det Lars Wallin vill åstadkomma och med upp till tio gånger så hög frekvens. genomför på Saab Automobile, är att flytta testingenjörernas arbete från testbanorna runt Förenklad felsökning om i världen in till skrivborden. Istället för Vi använder systemet med flight recordern i att ingenjörerna följer med bilarna till testbanorna, ska testfordonen framföras av chauffö- är i verifieringen, men vi använder också sys- tre faser i vår utveckling. Det tyngsta arbetet rer och alla mätdata spelas in och skickas till temet tidigare i utvecklingen, när vi testar på ingenjörerna för analys. komponentnivå mot motorsimuleringar. Vi använder en flight recorder för att Slutligen använder vi flight recordern i felsökningsarbetet. registrera mätdata från testbilarna. Den stora vinsten med att flytta in mycket av arbetet, är I felsökningen kommer möjligheten att att vi kan köra testerna parallellt på ett sätt använda triggers väl till pass. Ofta har de som var omöjligt när ingenjörerna själva som felsöker en god uppfattning om vad det körde bilarna. Vi kan samtidigt testa bilar i är som går fel. Genom att sätta triggers som flera olika klimat, vilket förkortar verifieringstiden avsevärt. Dessutom siktar vi på att går det att läsa ut mer av den information reagerar på de faktorer som spelar in på felet, kunna halvera antalet testbilar, vilket också som är intressant för felet. Dessutom markeras relevant information i datamaterialet som skulle innebära en stor besparing. Den flight recorder som används heter Frec ska analyseras. 2000, en svart låda stor som ett halvt mjölk- På det här sättet kan vi samla in data från flera bilar samtidigt. Vi kan utrusta bilar som får rulla i verklighetstrogen trafik. Systemet har vid något tillfälle till och med monterats i Saabs egna tjänstebilar. Ett liknande system för att samla in mätdata från bilens sensorer fanns redan när modellen 9-5 utvecklades i mitten av 90-talet. Data hämtades då från buffertarna i motorns styrsystem och behandlades i Microsoft Excel. Ganska snart stod det klart att arbetssättet med att hämta data från motorns egna system inte räckte till. Med Frec 2000 ökade datamängderna avsevärt och all data lagras nu i stället i en gemensam databas och analyseras med matematiska verktyg. Informationen vi samlar in påminner en del om de data som läkemedelsföretagen får in under sin utvärdering av nya preparat. När vi letade efter analysverktyg vände vi oss bland annat till läkemedelsindustrin och fann det statistiska verktyget Spotfire, som är bra på att analysera stora datamängder. Till mer avancerade modelleringsarbeten använder vi också MatLab. Effektiva tester avgör framtiden I framtiden ligger att flytta in mer och mer av testarbetet till skrivborden och att ytterligare förfina modellerna för hur bilen uppför sig. En begränsande faktor är idag att datakraften i bilen är begränsad och inte tillåter de mest avancerade beräkningarna. Istället används filter som bygger på statistiska data för att särskilja ett felaktigt beteende från naturliga avvikelser. Arbetet med att effektivisera testerna är på många sätt avgörande för Saab som liten tillverkare av motorer. Lars Wallin tror att kunderna har speciella förväntningar på motorer från Saab: Våra kunder förväntar sig ett stort kraftuttag ur en relativt liten motor. Som en liten tillverkare av motorer kan vi bara uppfylla det genom att vara effektiva i utvecklingen och testverksamheten. 16 Nr 1 mars 2003

17 AV SVEN WENNERSTRÖM När fel inte får förekomma För patienter vars njurar inte längre fungerar är dialys villkoret för att kunna leva vidare. Blodet renas i en maskin utanför kroppen och förs sedan tillbaka till patienten. Ett av de största företagen som utvecklar och säljer dialysutrustning är Gambro, med delar av sin utveckling och produktion i Lund. Drygt svenska patienter får sitt blod renat genom hemodialys. Det innebär att blodet leds ut ur kroppen, renas i en konstgjord njure dialysfiltret för att sedan föras tillbaka in i patienten igen. Kraven på dialysmaskinen är naturligtvis högt ställda. En maskin som kopplas till patientens blodomlopp får absolut inte skada patienten genom ett felaktigt beteende. Strax norr om Lund, i utkanten av forskarbyn Ideon, ligger Gambro. Jag kommer dit en lerig skånsk vinterdag för att ta reda på mer om hur test och validering går till i ett medicinteknikföretag med extremt högt ställda krav på hur produkterna ska fungera. Utvecklingen och tillverkningen ligger i Monitor Division. Inom Monitor Division finns avdelningen Design Quality, DQ, som ansvarar för verifiering och validering av produkterna. De huvudsakliga uppgifterna för DQ är att granska och godkänna alla nya produkter och förändringar som görs i existerande produkter. I arbetet ingår att granska kravdokumentationen och delta i de genomgångar, reviews, som görs under utvecklingsarbetet. Magnus Grén är chef för avdelningen: Vi säkerställer att alla våra produkter uppfyller de regler som finns för medicinteknisk utrustning. Både det amerikanska regelverket från FDA och det europeiska medicintekniska direktivet har högt ställda krav som vi måste följa. För att uppfylla de olika regelverken utnyttjas bland annat standarder, till exempel från ISO och IEC, som överensstämmer med kraven i regelverken. Standarderna ska vara erkända av respektive regelverk och kan omfatta såväl produktrelaterade krav som Gambros dialysmaskiner kan innebära skillnaden mellan liv och död för patienter med skadad njure. En sådan maskin måste helt enkelt fungera felfritt, vilket ställer stora krav på testarna. Magnus Grén är ansvarig för avdelningen som jobbar med verifiering och validering. processkrav, till exempel för riskhantering och utveckling. V-modell för nyutveckling Nya produkter utvecklas efter den så kallade v-modellen: Med en marknadsspecifikation som utgångspunkt analyseras kraven och överförs till en teknisk specifikation på systemnivå. Dessa krav bryts sedan ned till kravspecifikationer och konstruktionsbeskrivningar för delsystem, moduler och komponenter. DQ kommer in i utvecklingsarbetet redan när kravspecifikationen upprättas på systemnivå, säger Magnus Grén. Vi försöker så tidigt som möjligt granska kraven med avseende på entydighet, testbarhet, spårbarhet och genomförbarhet. Vi bidrar också till bevakningen av vilka standarder som är tillämpbara på produkten och att kraven i standarderna efterlevs under hela utvecklingsarbetet. Efter utförd implementation utförs verifiering, testning och integrationstestning på modul- och delsystemnivå av utvecklingsingenjörerna. DQ fungerar som ett stöd och granskar hur testerna utförs. Vi granskar hur testerna är utformade: vilka krav som ställs, att acceptanskriterierna är entydigt utformade och om testerna verkligen täcker in allt som måste testas, säger Magnus Grén och påpekar att en viktig del i arbetet är regelbundna granskningar, reviews: Jag håller granskning som metod väldigt högt. Hur duktig man än är så ser fler par ögon alltid mer. En annan fördel ur vår synvinkel är att vi via granskningen på moduloch delsystemnivå lär oss hur produkten är uppbyggd. Den kunskapen är viktig när vi ska utföra den slutgiltiga produktvalideringen. För att kontrollera att vissa av standarderna är uppfyllda anlitas externa testhus som komplement till de egna verifieringarna. Magnus Grén anser att det ger testerna Nr 1 mars

18 Gambros AK 200 ULTRA S, framtagen och tillverkad på Gambro i Lund. ytterligare trovärdighet. Att samarbeta med externa parter som är väl kända och erkända för sin verksamhet kan också ge ett mervärde till produkten när den ska marknadsföras. Formellt överlämningsmöte När utvecklingsprocessen har nått så långt att produkten existerar som ett system och tillverkningsprocessen är validerad, inleds produktvalideringen med ett formellt överlämningsmöte mellan utvecklingsavdelningen och DQ. Valideringen är den stora biten för oss på DQ. Det är då vi bland annat testar produkten mot krav baserade på avsedd användning och användarnas behov. På överlämningsmötet går vi igenom en checklista för att kontrollera att alla tester och verifieringar är utförda enligt vår utvecklingsprocess. På så vis försöker vi minimera risken att identifiera fel under produktvalideringen eftersom de problem som vi hittar i den fasen ofta är dyra att åtgärda. Som en del i valideringen säkerställs också att alla tester och verifieringar är utförda enligt Gambros utvecklingsprocess och med godkänt resultat. Valideringen utförs på systemnivå, varför testerna oftast är så kallade black-box-tester; produkten betraktas inte som en uppsättning delsystem, utan testerna är inriktade på hur produkten ska fungera när den används av kunderna. Som en del av valideringen utförs bland annat ett stort antal simulerade behandlingar. Valideringen sker alltid på serietillverkade produkter eller ekvivalenta. Slutligen CE-märks produkterna. Serviceteknikerna involveras Att testa nya produkter är inte hela arbetet för DQ. Varje år inkommer mellan 500 och 600 ändringsmeddelanden på existerande produkter. Det som föranleder förändringar kan vara förslag från produktionsavdelningen, önskemål om nya funktioner från marknadsavdelningen eller klagomål från kunder. Samtliga förändringar i dialysapparaterna ska testas och godkännas. När en förändring ska genomföras är det första steget att genomföra en problemanalys. Ofta är det svårt att utifrån rapporten veta exakt vad i maskinen som ska ändras. Det första steget är alltså att ta reda på vilket problem som ska lösas. Processen som används vid ändringar bygger i stort sett på samma principer som den som används för nyutveckling. Problemställningen leder fram till en System Change Request, CR, det vill säga en kravspecifikation som granskas och godkänns av DQ. Efter implementering testas ändringen för att säkerställa att den uppfyller kraven i CR och att den inte lett till oönskade sidoeffekter på övriga delar av systemet. Dessa tester granskas och godkänns också av DQ. I vissa fall utnyttjas även tekniker från säljbolagen i olika länder för att på ett tidigt stadium testa införda ändringar. På så sätt tas erfarenheter till vara från dem inom Gambro som arbetar närmast slutkunden. Som sista steg utför sedan DQ valideringen. Att serviceteknikerna är involverade under testningen är av stort värde. Dels har de med sin erfarenhet mycket att tillföra och dels kan de bekräfta att vi förstått det aktuella problemet och rättat till det. Effektivare test Arbetet med att testa och validera dialysutrustning måste alltid ske inom ramarna för de strikta regelverken för medicinteknisk utrustning. Men även inom dessa ramar går det att effektivisera testerna. Det är viktigt att DQ inte uppfattas som den sista barriären, säger Magnus Grén och menar att DQ:s roll aldrig får bli polisiär. Det arbetssättet är inte effektivt och kan aldrig accepteras. Det måste finnas en samsyn mellan utvecklingsingenjörerna och kvalitetsingenjörerna om vikten av tillräcklig testning, eller rättare sagt verifiering och validering. Den samsynen tycker jag finns här på Gambro och det ger styrka åt hela processen Istället vill Magnus Grén att DQ ska komma in så tidigt som möjligt i utvecklingsprocessen, för att se till att granska krav, testmetoder och testresultat. Ett sådant arbetssätt säkerställer produktkvaliteten på ett effektivt sätt. Dessutom kostar det betydligt mindre än om vi istället kommer med kommentarer eller identifierar fel i slutet av processen och därmed tvingas göra om mycket av arbetet. Ju närmare vi är deadline, desto svårare är det naturligtvis att vinna gehör för de här tankarna. Samtidigt inser alla att det finns potential att göra utvecklingen snabbare, billigare och med bättre kvalitet om det här perspektivet följs från början. 18 Nr 1 mars 2003

19 AV MAGNUS OHLSSON Kom igång med prediktionsoch evolutionsmodeller Det behöver inte vara svårt att komma igång med prediktions- och evolutionsmodeller. Med ganska enkla medel kan man uppnå användbara resultat. Men det gäller att i förväg tänka igenom vad man vill uppnå. Största delen av dagens mjukvaruprojekt är i huvudsak vidareutveckling av befintlig mjukvara, där man utökar funktionaliteten eller uppdaterar den mot nya standarder. Många projekt utvecklas inkrementellt, vilket också kan ses som en form av vidareutveckling. Skillnaden mot att nyutveckla ligger i att strukturer och beroenden till viss del finns på plats och man måste anpassa sig och bygga efter dessa. Detta resulterar i att man hela tiden får med sig ett arv från de äldre delarna, med allt vad detta innebär. Förutsättningarna för vidareutvecklingen bestäms redan på ett tidigt stadium i projektet. Även om man utvecklar inkrementellt är det lätt att glömma och hålla all väsentlig information i huvudet. Bra dokumentation av systemet och dess arkitektur underlättar därför. Tyvärr är inte dokumentationsnivån den önskvärda i alla projekt. Många organisationer hamnar därför i en situation där man efterhand som man bygger vidare på systemet spenderar mer och mer tid på att rätta fel som uppkommer. Situationen kan även vara den att man släpper nya versioner av mjukvaran efterhand som man rättar problem man har funnit. I slutänden är det oftast bara ett fåtal fel kvar, men dessa är oftast väldigt svåra att handskas med på grund av olika anledningar. Oftast är det bara en delmängd av komponenterna som skapar de största problemen, och man har en känsla för vilka de är. Det är lätt att bli förblindad av dessa och förbise komponenter som inte utmärker sig men som ändå kan vara problematiska. Prediktion och evolution Hur ska man då hantera dessa komponenter och hur kan man på ett tidigt stadium agera för att undvika problem längre fram i utvecklingen? Att arbeta preventivt kan låta självklart, men är inte alltid enkelt om man inte vet var man ska börja. Om man redan har hamnat i en nedåtgående spiral av ständiga rättningar och uppdateringar kan man behöva hjälp. Ett hjälpmedel för att fokusera sina resurser (till exempel granskningar och test) på de mest problematiska komponenterna är prediktionsmodeller. Dessa kan användas i förebyggande syfte för att tidigt peka ut komponenter som är på väg att bli problematiska. Beroende på hur de appliceras, och med vilka förutsättningar, kan de användas i både kortoch långsiktigt syfte. När man arbetar med prediktionsmodeller finns det två avvägningar man måste ta hänsyn till, förhållandet mellan hur lättanvänd och hanterbar den ska vara kontra hur exakt prediktionen ska bli. Man måste även ha en bra uppfattning om vad syftet med modellen är för att den ska bli ändamålsenlig. Datainsamling Grunden för att bygga modeller är tillgången till data från mjukvaran och processen samt om resurserna. Många organisationer ställs ofta inför dilemmat att inte ha en såpass utvecklad process att data samlas in kontinuerligt. Detta behöver inte hindra byggandet och användandet, då man oftast med en relativt enkel insats kan samla in nödvändig information. Det är ett av de ställningstaganden man måste göra när det gäller avvägningen mellan användbarhet och prediktionsprecision. Oftast finns möjlighet att på ett smidigt sätt inhämta data från befintliga verktyg och processer. Man kan till exempel från versionshanteringsverktygen extrahera information om komponenterna som ingår i systemet, hur ofta det har gjorts ändringar i dem och vilka ändringar som har gjorts. Vidare kan man nyttja informationen i tidrapporteringssystemen för att se hur mycket tid som har använts till olika aktiviteter. Ett fel man bör undvika för att ge en rättvisande prediktion är att samla in data från de sena processfaserna. Till exempel bör man inte samla in information om hur mycket tid man har lagt på att testa olika komponenter, för att prediktera hur felintensiva de är. Det är dock rimligt att göra detta om man vill arbeta med evolution eller prediktion för nästa release. Istället bör man fokusera på att använda sig av data från till exempel designfasen. Man måste ha klart för sig vad syftet med modellen är och vilken information som är relevant att samla in. När det gäller prediktions- och evolutionsmodeller finns ett antal måttyper som man bör fokusera på: Storleksmått Till exempel rader kod eller antalet if-satser. Antalet if-satser (och även vissa andra mått) kan ses som ett storleksmått eftersom antalet bidrar till storleken. En annan möjlighet är att använda dem som strukturmått. Strukturmått Cyklomatisk komplexitet, mängden modifierad kod och interface-karakteristika är exempel på strukturmått. Mängden modifierad kod kan ses som ett strukturmått med avseende på att det indikerar mängden strukturella förändringar i koden. Processmått Till exempel frekvensen för vissa aktiviteter i olika utvecklingsfaser, eller tiden att utföra vissa förändringar. Feldata Klassificering av olika fel och antalet fel funna i olika faser är exempel på olika typer av feldata. Alla dessa mått kan dessutom kombineras för att få fram andra intressanta, så kallade indirekta, mått. Det är till exempel möjligt att kombinera antalet funna fel med antalet rader kod för att räkna ut feldensiteten. Detta mått kan i sin tur sedan kombineras med mängden modifierad kod i olika komponenter för att ta reda på hur förändringarna påverkar feldensiteten. En sak som har utelämnats är kvalitativa Nr 1 mars

20 mätningar, det vill säga de subjektiva mät- Felintensitet ningarna eller uppfattningarna. Dessa kan tillföra olika aspekter, klargöra oklarheter och besvara frågor angående vissa omständigheter. Problemet är att det tar en hel del tid att samla in denna information och syftet med våra prediktions- och evolutionsmodeller är inte att skapa denna djupa inblick. * Röd Gul Övre nivå Modellbygge Baserat på insamlad information kan vi bygga modeller för att analysera data, med syfte att förbättra och kontrollera våra processer. En modell bygger på en teori (syftet) som beskriver bakgrunden och det förväntade resultatet. Viktigt att veta är att modeller av sin natur är instabila. När en organisation blir medveten om ett fenomen förändras ofta beteendet, och därmed förutsättningarna för modellen. Därför är det viktigt att kontinuerligt uppdatera sina modeller. Byggstenarna i själva modellen är ett antal statistiska metoder av olika avancerad karaktär, beroende på vad man vill uppnå. Dessa metoder kan i sin tur kombineras på olika sätt, ungefär som man kombinerar olika mått, för att uppnå önskat resultat. Inom de statistiska modellernas ramar finns det även utrymme för justering och anpassning på ett antal punkter. Detta ligger dock utanför ramarna för denna artikel. Modellexempel Vi ska visa hur man kan bygga en modell för prediktion av felintensiva komponenter som sedan kan utökas och användas för att följa evolutionen hos dessa. Vi visar även hur man kan undersöka strukturella förändringar hos komponenterna i det berörda systemet för att få indikationer på vad som orsakar problemen. Prediktion och evolution De två modellerna har sitt upphov i att skapa ett gemensamt språk för kvalitetsfolk, utvecklare och chefer för att kunna fatta gemensamma beslut som alla förstår innebörden av. Modellerna bygger på teorin om att det till * Undre nivå * * * * Grön * * Release Figur 1.Trenden för en komponent över ett antal releaser. största delen är samma komponenter som uppvisar flest fel i varje release. Man kan dela in dem i tre kategorier beroende på hur felintensiva eller degenererade de är: även vara kandidat för re-engineering. Ifall man inte reagerar och hanterar de gula komponenterna finns risk för att de passerar den övre felnivån och klassificeras som röda. Gröna (normal evolution) Dessa representerar normal evolution och en viss fluktuation är normal. Komponenterna är enkla att uppdatera, dvs funktionaliteten kan utökas och fel kan rättas utan att man behöver spendera allt för mycket tid. Dessutom behövs inte systemexperter för att underhålla dessa komponenter. Man ska följa upp komponenterna från release till release för att kunna hitta illavarslande trender och ifall någon komponent överstiger en viss felnivå, (den undre nivån i figur 1), ska man hantera Röda ( mission impossible ) En röd komponent är problematisk och kostsam att underhålla. Röda komponenter har en tendens att ställa till stora problem i slutet av projekten, när det dessutom finns lite tid och pengar kvar att spendera. De ses oftast vara i allt för dåligt skick, dvs mission impossible. För att hantera dessa komponenter behöver vi människor med expertkunskap. Dessa komponenter är inte längre kandidater för re-engineering, de måste göras om. problemet innan den klassificeras som gul. De olika kategorierna finns exemplifierade i Gula (kod-degenerering) När en komponent passerar den undre nivån klassificeras den som gul och behöver speciellt fokus för att framtida problem ska undvikas. Komponenter som klassificerats gula är kandidater för specifikt riktade förbättringsinsatser. Detta kan innebära en mer rigid process, där fokus ligger på till exempel granskningar. Komponenten kan Figur 1. Exemplet visar utvecklingen för en specifik komponent över ett antal releaser. De data vi använder oss av i exemplen kommer från 28 mjukvarukomponenter som är från två releaser. Dessa utgör en del av ett stort realtidssystem inom telekommunikationsområdet. Programspråket är ett företagsinternt språk som är en föregångare till SDL. För komponenterna samlades tio olika mått 20 Nr 1 mars 2003