Enbugg, ävenlus,[1] är en felaktighet idatorprogram som gör att programmet inte beter sig som tänkt. Den kan leda till att programmet ger felaktigt resultat eller att detkraschar. Oftast orsakas buggar av misstag avprogrammerare ikällkoden, men i enstaka fall kankompilatorer översätta källkoden felaktigt.
Ordet har delvis mytiskt ursprung, men anses i allmänhet komma från dessengelska betydelseinsekt ellerkryp. Enligt en myt härledde man på någon av de tidigarerelästyrda datorerna (somBARK) en felaktig funktion i datorn till ennattfjäril som hittades död bland reläerna. Ordet skall emellertid ha använts redan på 1870-talet avThomas Edison för att beskriva fel i en apparatur.[2]
Den första dokumenterade buggen hittades 9 september 1947 i enMark II Aiken Relay Calculator avGrace Hopper.
På svenska, kan man använda bådebugg ochbuggfix i vardagligt tal. I mer formella sammanhang passarprogramfel respektiveprogramkorrigering bäst.[3]
Det kan argumenteras att helt felfria program är enutopi, särskilt med dagens storaprogrampaket, trots attutvecklingsmiljön sedan1970-talet vanligtvis är utrustad medverktyg för avlusning. Detta gäller dock i huvudsak programvara med mänsklig interaktion.
För programvara iinbä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 manutvecklar program är det viktigt atttestakoden på flera olikasystem, 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 avsystemarbetet är omfattande användartester, bland annat genom att släppa enbetaversion. 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.
Ett program kan inte anses färdigutvecklat om det inte gjorts användarsäkert genom attfelhanteringen förutser att någon matar in ogiltiga data i programmet. Modernprogrammeringsteknik medobjektorienterad programmering har avsevärt minskat risken att elementära felhanteringsluckor ska bli kvar i det färdiga programmet.
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 understrä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.
 | Den här artikelnbehöverkällhänvisningar för att kunnaverifieras.(2016-11) Åtgärda genom att lägga till pålitliga källor (gärna som fotnoter). Uppgifter utan källhänvisning kanifrågasättas och tas bort utan att det behöver diskuteras pådiskussionssidan. |
APAR,Authorized Program Analysis Report, är bugrapporter hosIBM.
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) alternativtPMS (Problem Management Software), som utreds. Om problemet kunden beskriver inte kan avhjälpas utan förändringar i koden öppnas enAPAR 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 enPTF, 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 iRETAIN,REmoteTechnicalAssistanceInformationNetwork, enstordatorapplikation som körs internt på IBM. Applikationen körs vanligtvis via grönskärm i3270-emulator även om det under åren utvecklats grafiska gränssnitt för såvälOS/2 somWindows.
