Insekt

Från Wikipedia, den fria encyklopedin
Hoppa till navigation Hoppa till sökning

Ofta Fel- eller mjukvarufel eller programvaruavvikelse, och Bug ( engelska kallad), termer är från programvarutekniken som systemkomponentprogramvara med avvikelser hänvisas till ett önskat eller önskat måltillstånd för. Dessa kan uppstå om z. B. en viss definition av specifikationen är felaktig eller har implementerats felaktigt, och leder initialt till ett internt felstatus i programmet , vilket i sin tur leder till oväntat beteende eller resultat när programmet körs.

För den mest fullständiga möjliga upptäckten och eliminering av programfel, genomförs vanligtvis projektfasen " mjukvarutest " i programvaruutvecklingsprocesserna , dvs innan den faktiska, "produktiva" användningen av programvara med validering utförs. Fel som uppstår under denna process är vanliga och syftet med testning är att hitta dem, [1] medan fel under drift kan representera kritiska avvikelser / funktionsstörningar, beroende på effekten av felet. I praktiken dyker datorprogram sällan upp utan programfel. Feldätheten är känd som en kvalitetsfunktion för program. Den beskriver antalet fel per 1 000 kodrader ( kilos källkoder ) eller per funktionspunkt .

Så kallade felsökare , med vilka ett program kan köras och kontrolleras steg för steg, är användbara som specialinstrument för att söka efter orsakerna till fel i program. När det gäller särskilt kritisk programvara (t.ex. flygplanskontroll) utförs ibland (komplex) formell verifiering .

Så kallade bug trackers (som Bugzilla eller Mantis ) används för inspelning och dokumentation. Dessa inkluderar felrapporter samt förslag till förbättringar och förfrågningar (så kallade funktionsförfrågningar ) från användare eller allmänna processer. Se även defekthantering .

Processen att eliminera ett programfel kallas i allmänhet buggfixning . Resultatet av förbättringen kallas i tekniska termer för en buggfix, patch eller programvarupatch .

Definitioner

Ett program- eller programvarufel är baserat på den allmänna definitionen av " fel "

"Underlåtenhet att uppfylla ett krav (EN ISO 9000: 2005)".

Specifikt definieras felet sedan som

"Avvikelse av det VERKLIGA (observerade, bestämda, beräknade tillstånd eller processer) från TARGET (definierade, korrekta tillstånd och processer), om det överskrider den fördefinierade toleransgränsen [som också kan vara 0]."

Enligt ISTQB [2] bildas termen 'fel' från följande sammanhang:

  • en felaktig åtgärd (engelska fel)
"Den mänskliga handlingen som leder till ett felstillstånd ([enligt IEEE 610])"
  • ... leder till ett feltillstånd
"Defekt (internt fel) i en komponent eller ett system som kan försämra en nödvändig funktion hos produkten ..."
  • en feleffekt kan (engl. Failure) leda till
"Manifestationen av ett internt fel i körningen [av programmet] som ett felaktigt beteende eller resultat eller som ett systemfel."
Exempel division med noll : Felaktig åtgärd: Noll som ett möjligt ingångsvärde har inte kontrollerats / uteslutits; Felstatus: Programmet är (möjligen obemärkt) felaktigt; Misslyckande: Om du anger ett nullvärde orsakas ett körtidsfel när kommandot körs .

Uttryck som problem, defekt, avvikelse, anomali, brist används också som en synonym för "fel" eller utöver det. Detta innebär att ”felets svårighetsgrad” också kan differentieras konceptuellt, t.ex. B. bryter mot reglerna för programmeringsstil , levererar felaktiga resultat eller avslutar programmet .

"Bug" som en synonym för programfel

Loggbokssida för Mark II Aiken Relay Calculator med den första buggen (1947)

Ordet bug betyder på engelska " Schnabelkerf ; Bug "och i allmänhet" lantlig leddjur "eller" (insektsliknande) ohyra ". [3] I jargongen av amerikanska ingenjörer har betydelsen "funktionsfel" eller "konstruktionsfel" bevisats sedan slutet av 1800 -talet; Denna användning av ordet är baserad på (skämt) tanken att små krypande nötkreatur bråkar med växellådan, linan etc. Det äldsta beviset är två brev från Thomas Edison från 1878 till William Orton , presidenten för telegrafföretaget Western Union , och Tivadar Puskás , uppfinnaren av telefonväxeln , där det står:

”[...] Jag hittade en” bugg ”i min apparat, men den fanns inte i telefonen. Det var av släktet 'callbellum'. ”

"[...] Jag hittade en" bugg "i min uppsättning, men inte i själva telefonen. Den var av släktet" callbellum "."

- Thomas Edisons i ett brev till William Orton, daterat den 3 mars 1878 [4]

som

”Det första steget [i alla mina uppfinningar] är en intuition, och kommer med en burst, då uppstår svårigheter - det här ger sig och [det är] då” Bugs ” - som sådana små fel och svårigheter kallas - visar sig själva [...]. "

”Det första steget [i alla mina uppfinningar] är en intuitiv tanke som kommer i ett utbrott, men då uppstår svårigheter - saken slutar fungera, och sedan [det är] att” buggar ” - som så små misstag och svårigheter kallas - visa sig [...]. "

- Thomas Edison i ett brev till Tivadar Puskás, daterat den 18 november 1878

Edison är inte en uppfinnare, men åtminstone ett viktigt vittne för en betydelse av ordet som cirkulerade då. Termens koppling till datorer går möjligen tillbaka till datorpionjären Grace Hopper . De sprider historien om att den 9 september 1945, en mal gjorde ett fel i ett relä i Mark II Aiken Relay Calculator -datorn. Mölen togs bort, fastnade i loggboken och försågs med följande anteckning: ” Första faktiska fallet med fel som hittades. ”(Tyska:” Första gången som en ”ohyra” faktiskt hittades. ”). Legenden om att hitta termen kvarstår, även om loggboksposten indikerar att termen redan var i bruk tidigare. Dessutom hade Grace Hopper fel om året: Händelsen inträffade faktiskt den 9 september 1947. Motsvarande sida i loggboken förvarades på Naval Surface Warfare Center Computer Museum i US Navy i Dahlgren , Virginia fram till början av 1990 -talet. Denna loggbokssida med mal finns för närvarande vid Smithsonian Institute . [5]

Typer av buggar

Inom programvaruteknik (se även [6] ) görs åtskillnad mellan följande typer av fel i program:

  • Lexikalfel är teckensträngar som inte kan tolkas, dvs odefinierade identifierare (variabler, funktioner, bokstäver ...)
  • Syntaxfel är kränkningar av de grammatiska reglerna för programmeringsspråket som används , till exempel felaktig användning av reserverade symboler (t.ex. saknade parenteser), typkonflikter, felaktigt antal parametrar.

Lexikal- och syntaxfel förhindrar vanligtvis sammanställningen av det felaktiga programmet och känns därför igen i ett tidigt skede. I programmeringsspråk som tolkas sekventiellt avslutas programmet vanligtvis bara vid den syntaktiskt / lexiskt felaktiga punkten.

  • Semantiska fel är fel där en programmerad instruktion är syntaktiskt korrekt, men fortfarande felaktig när det gäller innehåll, till exempel förvirring av kommandokoden, felaktig parameterordning som inte kan identifieras syntaktiskt.
  • Logiska fel består av ett problemlösande tillvägagångssätt som är felaktigt i detalj, till exempel på grund av en felaktig slutsats , en felaktigt tolkad specifikation eller helt enkelt ett försummelse eller typfel. Exempel: plus istället för minus, mindre istället för mindre / lika etc. Toleransen mot sådana fel och attributgrammatiken för programmeringsspråk som är avsedda att begränsa dem, till exempel tilldelningskompatibilitet för datatyper , är mycket olika beroende på programmeringsspråket som används och kan vara svårt att förstå säkerhetsluckor och orsaka programkrascher .
  • Designfel är fel i grundkonceptet, antingen i definitionen av kraven för programvaran eller i utvecklingen av programvarudesignen på grundval av vilken programmet utvecklas. Fel i definitionen av krav bygger ofta på bristande kunskap om det ämnesområde som programvaran är skriven för eller på missförstånd mellan användare och utvecklare. Fel direkt i mjukvarudesign kan å andra sidan ofta spåras tillbaka till bristande erfarenhet från programutvecklarens sida , ostrukturerad programmering eller efterföljande fel orsakade av fel i kravspecifikationen . I andra fall har designen vuxit med tiden och blir förvirrande med tiden, vilket i sin tur kan leda till designfel när programmet vidareutvecklas. Ofta utförs programmeringen direkt utan ett korrekt koncept , vilket kan leda till designfel, särskilt om programvaran är mer komplex. För fel i kravdefinitionen såväl som i programvarudesignen är kostnads- eller tidspress ofta ett problem. Ett typiskt designfel är kodrepetition , som inte leder direkt till programfel, men som mycket lätt kan förbises under programvaruunderhåll , modifiering eller expansion av programkod och sedan oundvikligen leder till oönskade effekter.
  • Fel i driftskonceptet. Programmet beter sig annorlunda än vad individen eller många användare förväntar sig, även om det tekniskt sett fungerar felfritt.

Andra feltermer

  • Körtidsfel : Även om de fel som nämns ovan betyder ett program som faktiskt är felaktigt, som antingen inte kan köras eller ger felaktiga resultat, kan ett "korrekt" program också leda till fel när det körs. Körtidsfel är alla typer av fel som uppstår när programmet bearbetas. Beroende på situationen kan orsaken till exempel vara en olämplig programmiljö (t.ex. en felaktig version av operativsystemet , felaktiga parametrar när programmet anropas (även som en underrutin ), felaktiga inmatningsdata, etc.)
Runtime -fel kan dyka upp på många olika sätt. Programmet visar ofta oönskat beteende, i extrema fall avbryts genomförandet av programmet ("krasch"), eller programmet går in i ett tillstånd där det inte längre accepterar användarinmatning ("frys", "häng").
Effekt exempel på ett programfel
Om, i programmeringsspråk utan automatisk sophämtning (t.ex. C eller C ++ ), minnet inte längre frigörs efter användning, kommer programmet att använda mer och mer minne i längden. Denna situation kallas en minnesläcka . Liknande problem kan emellertid också uppstå i programmeringsspråk med automatisk sophämtning (t.ex. Java eller C # ) om till exempel objekt ackumuleras på ett okontrollerat sätt på grund av programmeringlåg nivå . Ännu mer kritiskt är minnesområden som av misstag släpptes av programmeraren , som ofta fortfarande refereras av hängande pekare , eftersom detta kan leda till helt okontrollerat beteende hos programvaran. Vissa körtidsmiljöer tillåter därför i allmänhet inte sådana programmerbara minnesreleaser. Det finns också buggar i interaktion med andra program.
  • Fel i kompilatorn, körtidsmiljön eller andra bibliotek. Sådana fel är vanligtvis särskilt svåra att förstå eftersom programmets beteende i sådana fall inte motsvarar dess semantik. Särskilt kompilatorn och runtime -miljön förväntas vara särskilt tillförlitlig.
  • En regressionsfel ( regression betyder "bakåtsteg") är ett fel som bara visas i en senare programversion. Dessa är ofta oupptäckta biverkningar av buggfixar eller programändringar någon annanstans.
  • Fel till följd av fysiska driftförhållanden. En mängd olika händelser som elektromagnetiska fält, strålning, temperaturfluktuationer, vibrationer etc. kan också leda till fel i system som annars är korrekt konfigurerade och drivs inom specifikationerna. Fel av denna typ är mycket osannolika, är mycket svåra att upptäcka och kan få ödesdigra konsekvenser i realtidstillämpningar. Av statistiska skäl kan de dock inte uteslutas. Det berömda "fallet av lite" i minnet eller på hårddisken på grund av de beskrivna influenserna är till exempel ett sådant fel. Som effekterna av ett sådant fel (t.ex. systemkrasch eller oförmåga att starta eftersom en systemfil har skadats) från vilka andra programfel vanligtvis är mycket svåra att skilja, misstänker man ofta en annan orsak, särskilt eftersom ett sådant fel ofta inte är reproducerbart.
  • Programfel kontra programvarufel: I den mån dessa två termer inte förstås som synonymer kan en bredare definition också gälla för 'programvarufel' - i enlighet med skillnaden i betydelse mellan datorprogram och programvara : Enligt detta kan fel eller brister i dokumentationen skulle också vara programvarufel, oavsett om de ledde till felaktiga program. Felaktiga data (denna term tilldelas också programvaran beroende på definitionen) bör knappast betraktas som ett programfel, utan snarare, om alls, som ett mjukvarufel.

I vissa projekt används inte termen bugg, utan snarare till exempel metabugs, där en bugg är ett element i en uppgiftslista. I vissa projekt används termen "frågor" istället, eftersom denna term inte är begränsad till buggar.

Specifika exempel på fel med en viss mediepåverkan finns i listan över programfelexempel .

Ekonomisk mening

Programvarufel är mycket mer än bara irriterande åtföljande omständigheter för mjukvaruutvecklare; de ​​orsakar betydande kostnader ur affärsmässig och ekonomisk synvinkel . IX -studien 1/2006 [7] visade z. B. följande värden fastställda för Tyskland:

  • De årliga förlusterna på grund av mjukvarufel i medelstora och stora företag uppgår till cirka 84,4 miljarder euro
  • Cirka 14,4 miljarder euro årligen (35,9% av IT -budgeten) används för att eliminera programfel ;
  • Produktivitetsförlusterna på grund av datorfel på grund av defekt programvara uppgår till cirka 70 miljarder euro

Samma studie undersöker också utvecklingen av mjukvarukvalitet för perioden 2002 till 2004 - med resultatet:

  • andelen misslyckade projekt steg från 15% till 18%
  • andelen framgångsrika projekt sjönk från 34% till 29%
  • hastigheten på projekt med kostnadsöverskridanden ökade från 43% till 56%
  • andelen projekt som missade tidsfrister steg från 82% till 84%
  • hastigheten på projekt med lämplig funktionalitet sjönk från 67% till 64%

En rapport från Supreme Audit Office for New Projects (1985) vid den amerikanska federala administrationen visar ett särskilt stort antal misslyckanden, [8] enligt vilket

  • 27% av den programvara som betalades för levererades aldrig,
  • 52% har aldrig fungerat,
  • 18% användes endast efter omfattande renovering.
  • Endast 3% av den beställda mjukvaran uppfyllde de överenskomna avtalsvillkoren.

Standish Group International noterade: [9] I genomsnitt överstiger projekten

  • de ursprungligen planerade projektkostnaderna med 89%
  • de schemalagda utnämningarna med 222%.

Ewusi-Menach identifierade följande faktorer som orsaker till projektavslut på grund av dålig mjukvarukvalitet: [8]

  • Syftet är oklart
  • Felaktig projektgruppsyrkning
  • Otillräcklig kvalitetssäkring
  • Brist på tekniskt kunnande
  • Otillräcklig hänsyn till utgångsläget
  • Brist på användarmedverkan

Undvikande och korrigering av programfel

I allmänhet gäller följande: [10] Ju tidigare felet uppstår i utvecklingsprocessen och ju senare det upptäcks, desto mer tidskrävande är det att rätta till felet.

Under planeringen

Det viktigaste är en bra och ändamålsenlig planering av utvecklingsprocessen. Det finns redan ett antal procedurmodeller från vilka en lämplig kan väljas.

I analysfasen

Ett problem är att riktigheten av ett program bara kan bevisas mot en lämpligt formaliserad specifikation. Att skapa en sådan specifikation kan dock vara lika komplicerat och felaktigt som att programmera själva programmet.

Utvecklingen av allt mer abstrakta programmeringsparadigm och programmeringsstilar som funktionell programmering , objektorienterad programmering , design efter kontrakt och aspektorienterad programmering tjänar bland annat till att undvika fel och förenkla felsökning. En lämplig teknik bör väljas bland tillgängliga tekniker för problemet. En viktig punkt här är att erfarna programmerare måste vara tillgängliga för respektive paradigm, annars uppstår ofta motsatt effekt.

Det är också mycket användbart att låta utvecklingsverktygen hantera så många felundvikande uppgifter som möjligt pålitligt och automatiskt. B. underlättas med hjälp av strukturerad programmering . Å ena sidan gäller detta kontroller som synlighetsregler och typsäkerhet , samt undvikande av cirkulära referenser som kan antas av kompilatorn innan program översätts, men också kontroller som bara kan utföras vid körning , t.ex. indexkontroller för datafält eller typkontroller för objekt för objektorienterad programmering.

I designfasen

Programvaruexperter är överens om att nästan alla icke-triviala program innehåller buggar. Tekniker har därför utvecklats för att hantera fel inom program på ett tolerant sätt. Dessa tekniker inkluderar defensiv programmering , undantagshantering , redundans och övervakning av program (t.ex. med hjälp av en vakthundstimer ) samt plausibilitetskontroll av programmet under utveckling och data under programkörningen.

Vid programmering

Dessutom erbjuds ett antal avancerade applikationer som analyserar antingen källkoden eller den binära koden och försöker hitta fel som ofta görs automatiskt. Denna kategori innehåller program för exekveringsövervakning, som vanligtvis pålitligt upptäcker felaktiga minnesåtkomstar och minnesläckor . Exempel är det fritt tillgängliga verktyget Valgrind och det kommersiella Purify . En annan kategori testprogram inkluderar applikationer som statiskt analyserar källkod eller binär kod, till exempel att hitta och rapportera icke stängda resurser och andra problem. Dessa inkluderar FindBugs , Lint och Splint .

Vid testning

Det är perfekt att testet utvecklas före själva programmet. Detta säkerställer att ett test inte skrivs som matchar det program som redan har skrivits. Detta kan göras under analys- eller designfasen genom att identifiera testfall baserat på specifikationen . Fastställandet av testfall i detta tidiga skede av mjukvaruutveckling gör också att programmets krav kan kontrolleras med avseende på testbarhet och fullständighet. De testfall som fastställs på grundval av specifikationen är grunden för godkännandeproven - som kontinuerligt förädlas över hela utvecklingsprocessen och z. B. kan förberedas för testautomatisering .

Vissa mjukvaruleverantörer genomför ibland testfaser offentligt och utfärdar betaversioner så att de oväntat olika användningsvillkoren för olika användare kan testas och kommenteras av dem.

Operativ

Om ett fel uppstår under drift måste ett försök göras att hålla dess effekter så låga som möjligt och att begränsa dess verksamhetsfält genom att skapa "skyddande väggar" eller "skyddsåtgärder". Detta kräver å ena sidan förmågan att upptäcka fel och å andra sidan att kunna reagera adekvat på ett fel.

Ett exempel på feldetektering under körning av ett datorprogram är påståenden , med hjälp av vilka villkor som efterfrågas som alltid uppfylls enligt programdesignen. Andra mekanismer är undantagshantering som fälla och undantag.

Genom att implementera bevisförande kod kan programvaran garantera och säkerställa dess tillförlitlighet i viss utsträckning under körning.

Felfrihet

Fullständig frihet från fel för programvara som överskrider en viss komplexitetsgräns är praktiskt taget varken uppnåelig eller verifierbar. Med ökande komplexitet minskar översikten, särskilt om flera personer är involverade i programmeringen. Även dyr eller omfattande testad programvara innehåller programmeringsfel. När det gäller användbara program talar man då om robusthet snarare än att vara fri från fel. Programvara anses vara robust när fel endast uppstår mycket sällan och sedan bara orsakar mindre olägenheter och inte orsakar stora skador eller förluster.

I speciella fall är det möjligt att bevisa att ett program är felfritt (med avseende på de angivna kraven). Särskilt inom områden där användning av programvara är förknippad med höga finansiella, ekonomiska eller mänskliga risker, t.ex. B. i programvara som används för militära eller medicinska ändamål eller inom flygindustrin används också en metod som kallas "(formell) verifiering ", där programvarans korrekthet bevisas matematiskt. Men på grund av den enorma ansträngning som är inblandad har denna metod strikta gränser och är därför praktiskt taget omöjlig att genomföra med komplexa program (se även förutsägbarhet ). Men det finns nu verktyg som, enligt egen information, kan tillhandahålla detta bevis snabbt och pålitligt, åtminstone för delområden ( körtidsfel ).

Förutom matematisk verifiering finns det också en praktisk form av verifiering, som beskrivs av kvalitetshanteringsstandarden ISO 9000 . Med det anges ett fel formellt endast om ett krav inte uppfylls. Omvänt kan ett arbetsresultat (och därmed även programvara ) beskrivas som 'felfritt' om det bevisligen uppfyller alla krav. Uppfyllandet av ett krav bestäms av tester . Om alla tester som definierats för ett krav ger de förväntade resultaten, har kravet uppfyllts. Om detta gäller tester av alla krav (förutsatt korrekt och fullständig testning) dras slutsatsen att det inte finns några fel med avseende på kraven. Om kraven som testerna bygger på är felaktiga eller ofullständiga fungerar programvaran fortfarande inte "som önskat".

Klassificering av defekter

Fel som uppstår behandlas i allmänhet systematiskt vid felhantering . Enligt IEEE-standarden 1044 (klassificering av programvaruavvikelser) går varje fel genom en så kallad klassificeringsprocess, som består av de fyra stegen för igenkänning, analys (utredning), bearbetning (åtgärd) och slutsats (disposition). [11] I vart och ett av dessa steg utförs administrativa aktiviteter som registrerar, klassificerar och identifierar effekter. [12]

Kriterier enligt vilka fel kan klassificeras inkluderar (med exempel):

  • Typ av fel: Enligt [6] görs åtskillnad mellan: lexikaliska fel (okänd referens), syntaktiska fel (glömt semikolon), semantiska fel (felaktig deklaration ), körtidsfel (felaktigt formaterade indata) och logiska fel ( plus istället för minus, loop -fel, ...)
  • orsaken till felet: oprecis specifikation, roterade siffror, fel formel, okontrollerade (felaktiga) inmatningsdata ...
  • den tidpunkt då felet inträffade ('felaktig åtgärd'): Redan när du anger programmet, när du skriver koden, när du kodar, ...
  • Tidpunkten då felet uppstår ('feleffekt'): En grundläggande skillnad uppstår om felet uppstår under programutveckling, till exempel under testning (här är ett normalt fall [1] ) eller i produktiv drift (där det är ofta representerar ett kritiskt fel).
  • upptäcktstiden: ju längre "felet uppehållstid", desto mer tidskrävande i. A. Korrigeringsåtgärden fortsätter.
  • felets effekt (er): visningsfel, felaktiga resultat, programavslutning, externa effekter ...
  • Ansträngning och varaktighet för felsökning: minimal ... mycket hög; omedelbart ... mycket lång varaktighet;
  • Bearbetningsstatus: inträffade, undersöktes, korrigeringsordning i processen, omprovning möjlig, ..., klar

Med hjälp av mätvärden bör "resultaten [och fynden om fel] också vara en anledning att söka efter orsakerna bakom problemen". [1] "Felklassificeringar utgör grunden för standardiserade förfaranden för felhantering och stöder också kontinuerlig kvalitetsförbättring när det gäller kvalitetshantering ." [13] Ytterligare information för varje fel som en detaljerad beskrivning av felet, berörda program, berörda personer, etc. åtföljer åtgärderna för att åtgärda felen och dokumentera dem. Mer information finns i BITKOM -guiden. [13]

För att förenkla saker är programfel i felhanteringsprocessen ofta bara uppdelade i kategorier / klasser som A, B, C ... eller 1, 2, 3 ... etc. beroende på felets svårighetsgrad, vilket också inkluderar effekten av felet och den ansträngning som krävs för att rätta till det. För exempel, se BITKOM -riktlinjer, [13] särskilt i bilagan.

Konsekvenser av programfel

Konsekvenserna av programfel kan variera mycket och manifestera sig på många olika sätt. Om fel upptäcks under utvecklingsprocessen, är konsekvenserna av felet också begränsade till revidering av programvaran (kodkorrigeringar, konceptrevidering, dokumentation ...) - beroende på situationen med större eller mindre effekt på projektbudgeten och projektets längd. Å andra sidan har fel som bara känns igen i produktiv drift ofta en mer kritisk effekt, till exempel kan de orsaka processstörningar eller produktionsstopp, skada bilden, orsaka förlust av kunder och marknader, utlösa återkravsförpliktelser eller till och med äventyra företagets existens. I värsta fall kan fel i tekniska applikationer leda till katastrofer.

Specifika exempel på programfel och deras konsekvenser finns i listan över programfelexempel .

Reproducerbarhet av programfel

Vissa programfel är extremt svåra eller omöjliga att reproducera på ett tillförlitligt sätt. Om en tidigare misslyckad process upprepas under uppenbarligen oförändrade förhållanden finns det en sannolikhet att dessa fel inte kommer att uttryckas igen. Es gibt zwei mögliche Gründe für dieses Verhalten: Zum einen kann es zu Verzögerungen zwischen der Fehleraktivierung und dem letztlich auftretenden Problem beispielsweise einem Programmabsturz kommen, welche die tatsächliche Ursache verschleiern und deren Identifikation erschweren. Zum anderen können andere Elemente des Softwaresystems (Hardware, Betriebssystem, andere Programme) das Verhalten der Fehler in dem betrachteten Programm beeinflussen. Ein Beispiel hierfür sind Fehler, die in nebenläufigen Umgebungen mit mangelnder Synchronisation (genauer: Sequentialisierung ) auftreten. Wegen der hieraus folgenden Wettlaufsituationen (Race Conditions) können die Prozesse in einer Reihenfolge abgearbeitet werden, welche zu einem Laufzeitfehler führt. Bei einer Wiederholung der gleichen Aktion ist es möglich, dass die Reihenfolge der Prozesse unterschiedlich ist und kein Problem auftritt.

Weiterführende Themen

Literatur

  • William E. Perry: Software Testen. Mitp-Verlag, Bonn 2002, ISBN 3-8266-0887-9 .
  • Elfriede Dustin, Jeff Rashka, John Paul: Software automatisch testen. Verfahren, Handhabung und Leistung. Springer, Berlin ua 2001, ISBN 3-540-67639-2 .
  • Cem Kaner, Jack Falk, Hung Quoc Nguyen: Testing Computer Software. 2nd edition. John Wiley & Sons, New York NY ua 1999, ISBN 0-471-35846-0 .

Weblinks

Wiktionary: Programmfehler – Bedeutungserklärungen, Wortherkunft, Synonyme, Übersetzungen

Einzelnachweise

  1. a b c M. Pol, T. Koomen, A. Spillner: Management und Optimierung des Testprozesses. dpunkt.Verlag, Heidelberg 2002, ISBN 3-89864-156-2 .
  2. Spillner et al. Praxiswissen Softwaretest - Testmanagement Leseprobe Kap. 1.1 Basiswissen / Fehlerbegriff ( Memento vom 17. Dezember 2010 im Internet Archive ) (PDF) dpunkt.de
  3. Merriam-Webster Unabridged Dictionary (iOS-App, 2016): bug: a) an insect or other creeping or crawling invertebrate … b) any of certain insects commonly considered especially obnoxious … c) an insect of the order Hemiptera , especially: a member of the suborder Heteroptera
  4. The Papers of Thomas A. Edison, vol. 4, ed. Paul B. Israel, Baltimore and London, 1993. Online [1]
  5. Fred R. Shapiro: Etymology of the Computer Bug: History and Folklore . In: American Speech 62:4, 1987, S. 376–378.
  6. a b informatik.uni-oldenburg.de
  7. iX-Magazin , Studie Software-Testmanagement , war früher im IX Kiosk erwerbbar ( Memento vom 9. Januar 2013 im Internet Archive )
  8. a b Wallmüller: Software-Qualitätsmanagement in der Praxis, beck-shop.de (PDF; 612 kB), Hanser, München 2001, ISBN 978-3-446-21367-8 .
  9. Junginger: Wertorientierte Steuerung von Risiken im Informationsmanagement . 2005, ISBN 3-8244-8225-8 .
  10. Georg Edwin Thaller Softwaretest, Verifikation und Validation 2002, ISBN 978-3-88229-198-8 .
  11. my.safaribooksonline.com
  12. IEEE Standard Classification for Software Anomalies. (PDF) IEEE Standards Board, 1993, S. 32 , abgerufen am 22. November 2014 (White Paper; Dokument hinter Paywall).
  13. a b c Fehlerklassifikation für Software. BITKOM, Dezember 2007, archiviert vom Original am 16. April 2019 ; abgerufen am 11. April 2021 .