Bugg (dator)

En bugg, även lus,^[1] är en felaktighet i datorprogram som gör att programmet inte beter sig som tänkt. Den kan leda till att programmet ger felaktigt resultat eller att det kraschar. Oftast orsakas buggar av misstag av programmerare i källkoden, men i enstaka fall kan kompilatorer översätta källkoden felaktigt.

Ordets ursprung

Ordet har delvis mytiskt ursprung, men anses i allmänhet komma från dess engelska betydelse insekt eller kryp. Enligt en myt härledde man på någon av de tidigare relästyrda datorerna (som BARK) en felaktig funktion i datorn till en nattfjäril som hittades död bland reläerna. Ordet skall emellertid ha använts redan på 1870-talet av Thomas Edison för att beskriva fel i en apparatur.^[2]

Den första dokumenterade buggen hittades 9 september 1947 i en Mark II Aiken Relay Calculator av Grace Hopper.

På svenska, kan man använda både bugg och buggfix i vardagligt tal. I mer formella sammanhang passar programfel respektive programkorrigering bäst.^[3]

Avlusning

Det kan argumenteras att helt felfria program är en utopi, särskilt med dagens stora programpaket, trots att utvecklingsmiljön sedan 1970-talet vanligtvis är utrustad med verktyg för avlusning. Detta gäller dock i huvudsak programvara med mänsklig interaktion.

För programvara i inbäddade system är felfri kod möjligt och naturligtvis önskvärt. Där är det möjligt genom att definiera felfri som att programvaran helt uppfyller ställda krav inom avsedda (tänkta?) gränser. Det vill säga att så länge programvarans omgivning beter sig som förväntat kommer också programvaran att göra det. Notera att detta i sin tur innebär att återanvändning av sådan "felfri" kod inte på något sätt innebär att den är felfri i sin nya användning eftersom gränserna där kan vara annorlunda. (Se [1] på engelska Wikipedia) Överlag är bara tillräckligt enkla program i världen helt felfria, exempelvis standardprogrammet "Hello, World!".

I samband med att man utvecklar program är det viktigt att testa koden på flera olika system, så att man sedan vet vilka system programmet fungerar på. När en applikation vidareutvecklas är det också normalt att man testar den på nytt, dels för att kontrollera att nya funktioner fungerar som den skall samt att några gamla funktioner inte försvunnit.

Ett viktigt steg i den senare delen av systemarbetet är omfattande användartester, bland annat genom att släppa en betaversion. Det innebär att man låter villiga användare testa en tidig version av programmet. De kan sedan rapportera in buggar och svårigheter med att använda programmet. Användarna kan till exempel få genomföra olika testfall där olika programfunktioner testas och rapportera hur väl testfallen utfaller. Eventuella fel rapporteras till programmeraren. De fel som hittas kan indelas i olika allvarlighetsgrader efter hur stort felet är, till exempel om det är ett hindrande fel eller bara ett stavfel. På så sätt kan man till exempel välja att driftsätta en applikation där alla hindrande fel är borta och låta alla skönhetsfel och stavfel rättas i en kommande release.

Felhantering

Ett program kan inte anses färdigutvecklat om det inte gjorts användarsäkert genom att felhanteringen förutser att någon matar in ogiltiga data i programmet. Modern programmeringsteknik med objektorienterad programmering har avsevärt minskat risken att elementära felhanteringsluckor ska bli kvar i det färdiga programmet.

Omfattning

Som tumregel kan man säga att dåligt testad programvara kan ha betydligt mer än 10 fel per 1 000 rader kod, medan programvara som togs fram under stränga kvalitetskontrollmekanismer, med kodgranskningar, enhetstester, integrationstester, automatiska regressionstester samt olika funktionella tester och systemtester m.m. kan uppnå feldensiteter på någon tiondels fel per 1 000 rader kod. Normalbegåvade programmerare som tror sig testat "allt" hamnar i bästa fall på ungefär 1-10 fel på 1 000 kodrader.

APAR

Den här artikeln behöver källhänvisningar för att kunna verifieras. (2016-11) Åtgärda genom att lägga till pålitliga källor (gärna som fotnoter). Uppgifter utan källhänvisning kan ifrågasättas och tas bort utan att det behöver diskuteras på diskussionssidan.

APAR, Authorized Program Analysis Report, är bugrapporter hos IBM.

När ett problem i en mjukvara rapporteras in till IBM försöker supporten återskapa problemet och ge en beskrivning på hur man gör för att återskapa och eventuellt avhjälpa problemet. Supporten öppnar ett ärende, PMR (Problem Management Record) alternativt PMS (Problem Management Software), som utreds. Om problemet kunden beskriver inte kan avhjälpas utan förändringar i koden öppnas en APAR som beskriver problemet ingående för programmerarna.

En APAR kan stängas på olika sätt, ett vanligt exempel är att problemet helt enkelt fixas och att en PTF, Program Temporary Fix, skickas till kunden för att avhjälpa problemet^[4]. Problemet kan också stängas med slutsatsen att det är en begränsning eller att det fungerar enligt specifikationen (WAD, Working As Designed) och det kan också resultera i att problemet inte avhjälps i den nuvarande versionen av programmet utan flyttas till nästa version, en så kallad Feature Request.

Alla PMR, APAR och PTF:er har identifierande nummer så man kan följa dem genom processen.

Allt ovanstående sköts i RETAIN, REmote Technical Assistance Information Network, en stordatorapplikation som körs internt på IBM. Applikationen körs vanligtvis via grönskärm i 3270-emulator även om det under åren utvecklats grafiska gränssnitt för såväl OS/2 som Windows.

Se även

• 404 error
• Antimönster
• Blåskärm
• Bugzilla
• Datasäkerhet
• Linus lag
• Millenniebuggen
• Slumpfel
• Systemkrasch
• Säkerhetshål
• År 2038-problemet
• Återkommande buggar

Referenser