Insekt

Fejl- eller softwarefejl eller software -anomali ofte også buen ( engelsk kaldet), termer er fra softwareteknologien, hvormed systemkomponenter software, afvigelser henvises til en påkrævet eller ønsket måltilstand for. Disse kan forekomme, hvis z. B. en bestemt definition af specifikationen er forkert eller er blevet implementeret forkert , og fører i første omgang til en intern fejltilstand i programmet , hvilket igen fører til uventet adfærd eller resultat, når programmet udføres.

For den mest fuldstændige opdagelse og eliminering af programfejl, normalt i processerne til softwareudvikling , dvs. H. Inden den egentlige, "produktive" brug af software, skal du gennemgå projektfasen " softwaretest ", hvorunder en validering udføres. Fejl under denne proces er almindelige, og formålet med testen er at finde dem, mens fejl under drift kan repræsentere kritiske anomalier / funktionsfejl, afhængigt af fejlens effekt. I praksis vises computerprogrammer sjældent uden programfejl. En kvalitetsfunktion til programmer kendes blandt andet. den defekt tæthed . Den beskriver antallet af fejl pr. 1.000 kodelinjer ( kilo kildekoder ) eller pr. Funktionspunkt .

Såkaldte debuggere , som et program kan udføres og kontrolleres trin for trin, er nyttige som særlige instrumenter til at søge efter årsagerne til fejl i programmer . I tilfælde af særlig kritisk software (f.eks. Flykontrol) udføres undertiden (kompleks) formel verifikation .

Såkaldte bug trackers (f.eks. Bugzilla eller Mantis ) bruges til registrering og dokumentation . Disse omfatter fejlrapporter samt forslag til forbedringer og anmodninger (såkaldte funktionsanmodninger ) fra brugere eller generelle processer. Se også fejlhåndtering .

Processen med at fjerne en programfejl kaldes i daglig tale fejlrettelse . Resultatet af forbedringen omtales i tekniske termer som en fejlrettelse, patch eller softwarepatch .

Definitioner

En program- eller softwarefejl er baseret på den generelle definition af " fejl "

"Manglende opfyldelse af et krav (EN ISO 9000: 2005)".

Specifikt defineres fejlen derefter som

"Afvigelse af den AKTUELLE (observerede, bestemte, beregnede tilstande eller processer) fra TARGET (definerede, korrekte tilstande og processer), hvis den overskrider den foruddefinerede tolerancegrænse [som også kan være 0]."

Ifølge ISTQB er udtrykket 'fejl' dannet ud fra følgende sammenhænge:

• en defekt handling (engelsk fejl)

"Den menneskelige handling, der fører til en fejltilstand ([ifølge IEEE 610])"

• ... resulterer i en fejltilstand (engelsk defekt)

"Defekt (intern fejltilstand) i en komponent eller et system, der kan forringe en påkrævet funktion af produktet ..."

• en fejleffekt kan (engl. Failure) føre til

"Manifestationen af ​​en intern fejl i udførelsen [af programmet] som en forkert adfærd eller et resultat eller som en fejl i systemet."

Eksempel division med nul : Forkert handling: Nul som en mulig inputværdi blev ikke markeret / ekskluderet; Fejlstatus: Programmet er (muligvis ubemærket) defekt; Fejl: Indtastning af en nullværdi forårsager en runtime -fejl under udførelsen af kommandoen .

Udtryk som problem, defekt, afvigelse, anomali, mangel bruges også som et synonym for "fejl" eller ud over det. Det betyder, at "fejlens sværhedsgrad" også kan differentieres konceptuelt, f.eks. B. overtrædelse af programmeringsstilregler , levering af forkerte resultater eller afslutning af programmet .

"Bug" som synonym for programfejl

Logbogsside i Mark II Aiken Relay Calculator med den første fejl (1947)

Ordet fejl betyder på engelsk " Schnabelkerf ; Bug "og i daglig tale" landdyr "eller" (insektlignende) skadedyr ". I jargonen af amerikanske ingeniører er betydningen "funktionsfejl" eller "konstruktionsfejl" blevet attesteret siden slutningen af ​​det 19. århundrede; Denne brug af ordet er baseret på (spøg) ideen om, at små kravlende kvæg roder med gearkassen, linjen osv. Det ældste bevis er to breve fra Thomas Edison fra 1878 til William Orton , formanden for telegraffirmaet Western Union , og Tivadar Puskás , opfinderen af telefoncentralen , hvori der står:

som

Edison er ikke en opfinder, men i det mindste et vigtigt vidne for en betydning af ordet, der cirkulerede dengang. Sammenslutningen af ​​udtrykket med computere går muligvis tilbage til computerpioneren Grace Hopper . De spredte historien om, at en møl den 9. september 1945 fejlfejlede et relæ i Mark II Aiken Relay Calculator -computeren . Møllen blev fjernet, sat fast i logbogen og fik følgende note: “ Første faktiske tilfælde af fejl blev fundet. ”(Tysk:” Første gang, at der faktisk blev fundet et ’skadedyr’. ”). Legenden om at finde udtrykket vedvarer, selvom logbogsposten angiver, at udtrykket allerede var i brug før. Hertil kommer, Grace Hopper var forkert om året: Hændelsen faktisk fandt sted den 9. september, blev 1947. Den tilsvarende side af logbogen opbevares på Naval Surface Warfare Centre Computer Museum of den amerikanske flåde i Dahlgren , Virginia indtil begyndelsen af 1990'erne . Denne logbogside med mølen er i øjeblikket på Smithsonian Institute .

Typer af fejl

I software engineering (se også) skelnes der mellem følgende typer fejl i programmer:

• Leksikale fejl er tegnstrenge, der ikke kan tolkes, dvs. udefinerede identifikatorer (variabler, funktioner, bogstaver ...)
• Syntaksfejl er overtrædelser af de anvendte programmeringssprogs grammatiske regler, f.eks. Forkert brug af reserverede symboler (f.eks. Manglende parenteser), typekonflikter, forkert antal parametre.

Leksikalske og syntaksfejl forhindrer normalt kompilering af det defekte program og genkendes derfor på et tidligt tidspunkt. I programmeringssprog, der fortolkes i rækkefølge , afbryder programmet normalt kun på det syntaktisk / leksikalt forkerte punkt.

• Semantiske fejl er fejl, hvor en programmeret instruktion er syntaktisk korrekt, men stadig er forkert med hensyn til indhold, f.eks. Forvirring af kommandokoden, forkert parameterrækkefølge, der ikke kan genkendes syntaktisk.
• Logiske fejl består i en problemløsende tilgang, der er forkert i detaljer, for eksempel på grund afen forkert konklusion , en forkert fortolket specifikation eller simpelthen en forglemmelse eller typografisk fejl. Eksempler: plus i stedet for minus, mindre i stedet for mindre / lige osv. Tolerancen over for sådanne fejl og attributgrammatikken for programmeringssprog, der har tilformål at begrænse dem, f.eks. Tildelingskompatibilitet for datatyper , ermeget forskelligeafhængigt på det anvendte programmeringssprog og kan være svært at forstå sikkerhedshuller og forårsage programnedbrud .
• Designfejl er fejl i det grundlæggende koncept, enten i definitionen af kravene til softwaren eller i udviklingen af ​​softwaredesignet, som programmet er udviklet på. Fejl i definitionen af ​​krav er ofte baseret på manglende kendskab til det fagområde, softwaren er skrevet til, eller på misforståelser mellem brugere og udviklere. Fejl direkte i softwaredesign kan derimod ofte spores tilbage til manglende erfaring fra softwareudviklerens side , ustruktureret programmering eller efterfølgende fejl på grund af fejl i kravspecifikationen . I andre tilfælde er designet vokset med tiden og bliver forvirrende med tiden, hvilket igen kan føre til designfejl, når programmet videreudvikles. Ofte udføres programmering direkte uden et korrekt koncept , hvilket kan føre til designfejl, især hvis softwaren er mere kompleks. For fejl i kravdefinitionen samt i softwaredesignet er omkostnings- eller tidspres ofte et problem. En typisk designfejl er gentagelse af kode , som ikke direkte fører til programfejl, men meget let kan overses under softwarevedligeholdelse , ændring eller udvidelse af programkode og derefter uundgåeligt fører til uønskede effekter.
• Fejl i driftskonceptet. Programmet opfører sig anderledes end hvad enkelte eller mange brugere forventer, selvom det teknisk set er fejlfrit.

Andre fejlbetingelser

• Kørselsfejl : Selvom ovennævnte fejl betyder et virkelig defekt program, der enten ikke kan udføres eller leverer forkerte resultater, kan et "korrekt" program også føre til fejl, når det udføres. Kørselsfejl er alle typer fejl, der opstår, mens programmet behandles. Afhængigt af situationen kan årsagen f.eks. Være et uegnet programmiljø (f.eks. En forkertversion af operativsystemet , forkerte parametre ved opkald til programmet (også som en underprogram ), forkerte inputdata osv.)

Kørselsfejl kan dukke op på forskellige måder. Programmet viser ofte uønsket adfærd, i ekstreme tilfælde afbrydes udførelsen af ​​programmet ("nedbrud"), eller programmet går i en tilstand, hvor det ikke længere accepterer brugerinput ("frys", "hæng").

Afspil mediefil

Effekteksempel på en programfejl

Hvis der i programmeringssprog uden automatisk affaldssamling (f.eks. C eller C ++ ) ikke frigives hukommelse efter brug, vil programmet optage mere og mere hukommelse i det lange løb. Denne situation kaldes en hukommelseslækage . Imidlertid kan lignende problemer også opstå i programmeringssprog med automatisk skraldesamling (f.eks. Java eller C # ), hvis f.eks. Objekter akkumuleres ukontrolleret på grund af programmering på lavt niveau . Endnu mere kritisk er hukommelsesområder , der ved et uheld frigives af programmereren , som ofte stadig refereres til ved at hænge pointer , da dette kan føre til helt ukontrolleret opførsel af softwaren. Nogle runtime -miljøer tillader derfor generelt ikke sådanne programmerbare hukommelsesudgivelser. Der er også fejl i interaktion med andre programmer.

• Fejl i kompilatoren, runtime -miljøet eller andre biblioteker. Sådanne fejl er normalt særligt vanskelige at forstå, fordi programmets adfærd i sådanne tilfælde ikke svarer til dets semantik. Især kompilatoren og runtime -miljøet forventes derfor at være særligt pålidelige.
• En regressionsfejl ( regression betyder "baglæns trin") er en fejl, der kun vises i en senere programversion. Disse er ofte uopdagede bivirkninger af fejlrettelser eller programændringer andre steder.
• Fejl som følge af fysiske driftsforhold. En lang række hændelser såsom elektromagnetiske felter, stråling, temperatursvingninger, vibrationer osv. Kan også føre til fejl i systemer, der ellers er korrekt konfigureret og betjent inden for specifikationerne. Fejl af denne type er meget usandsynlige, er meget vanskelige at opdage og kan have fatale konsekvenser i realtidsapplikationer. Af statistiske årsager kan de imidlertid ikke udelukkes. Det berømte "lidt fald" i hukommelsen eller på harddisken på grund af de beskrevne påvirkninger er f.eks. En sådan fejl. Som virkningerne af en sådan fejl (f.eks. Systemnedbrud eller manglende evne til at starte, fordi en systemfil har er blevet beskadiget), hvorfra andre programfejl normalt er meget vanskelige at skelne mellem, mistænker man ofte en anden årsag, især da en sådan fejl ofte ikke er reproducerbar.
• Programfejl kontra softwarefejl: I det omfang disse to udtryk ikke forstås som synonymer, kan en bredere definition også gælde for 'softwarefejl' - i overensstemmelse med betydningsforskellen mellem computerprogram og software : I henhold til dette kan fejl eller mangler i dokumentationen ville der også være softwarefejl, uanset om de førte til defekte programmer. Forkerte data (dette udtryk tildeles også softwaren afhængigt af definitionen) bør næppe betragtes som en programfejl, men snarere, hvis overhovedet, som en softwarefejl.

I nogle projekter bruges udtrykket fejl ikke, men derimod for eksempel metabugs, hvor en fejl er et element i en opgaveliste. I nogle projekter bruges udtrykket "spørgsmål" i stedet, da dette udtryk ikke er begrænset til fejl.

Specifikke eksempler på fejl med en bestemt mediepåvirkning findes på listen over programfejleksempler .

Økonomisk betydning

Softwarefejl er langt mere end bare irriterende ledsagende omstændigheder for softwareudviklere; de ​​medfører betydelige omkostninger ud fra et forretningsmæssigt og økonomisk synspunkt . IX -undersøgelsen 1/2006 viste z. B. følgende værdier bestemt for Tyskland:

• De årlige tab på grund af softwarefejl i mellemstore og store virksomheder udgør omkring 84,4 milliarder euro
• Cirka 14,4 milliarder euro årligt (35,9% af it -budgettet) bruges til at fjerne programfejl ;
• Produktivitetstabet på grund af computerfejl på grund af defekt software udgør omkring 70 milliarder euro

Det samme studie undersøger også udviklingen af softwarekvalitet i perioden fra 2002 til 2004 - med resultatet:

• antallet af fejlslagne projekter steg fra 15% til 18%
• satsen for vellykkede projekter faldt fra 34% til 29%
• satsen for projekter med omkostningsoverskridelser steg fra 43% til 56%
• satsen for projekter, der gik glip af deadlines, steg fra 82% til 84%
• satsen for projekter med passende funktionalitet faldt fra 67% til 64%

En rapport fra Supreme Court of Auditors for New Projects (1985) ved den amerikanske føderale administration viser et særligt stort antal fejl, hvorefter

• 27% af den betalte software blev aldrig leveret,
• 52% har aldrig arbejdet,
• 18% blev kun brugt efter omfattende renovering.
• Kun 3% af den bestilte software opfyldte de aftalte kontraktbetingelser.

Standish Group International udtalte: I gennemsnit overstiger projekter

• de oprindeligt planlagte projektomkostninger med 89%
• de planlagte aftaler med 222%.

Ewusi-Menach identificerede følgende faktorer som årsager til aflysning af projekter på grund af dårlig softwarekvalitet:

• Formålet er uklart
• Forkert projektteambeskæftigelse
• Utilstrækkelig kvalitetssikring
• Manglende teknisk knowhow
• Utilstrækkelig overvejelse af den oprindelige situation
• Manglende brugerinddragelse

Undgåelse og korrektion af programfejl

Generelt, jo tidligere i udviklingsprocessen fejlen opstår, og jo senere den opdages, jo mere tidskrævende vil det være at rette fejlen.

Under planlægningen

Det vigtigste er god og passende planlægning af udviklingsprocessen. Der findes allerede en række proceduremodeller , hvorfra en passende kan vælges.

I analysefasen

Et problem er, at rigtigheden af ​​et program kun kan bevises mod en passende formaliseret specifikation. Imidlertid kan oprettelse af en sådan specifikation være lige så kompliceret og tilbøjelig til fejl som programmering af selve programmet.

Udviklingen af ​​stadig mere abstrakte programmeringsparadigmer og programmeringsstile som funktionel programmering , objektorienteret programmering , design efter kontrakt og aspektorienteret programmering tjener blandt andet til at undgå fejl og forenkle fejlfinding. En passende teknik bør vælges blandt de tilgængelige teknikker til problemet. Et vigtigt punkt her er, at erfarne programmører skal være tilgængelige for det respektive paradigme, ellers opstår den modsatte effekt ofte.

Det er også meget nyttigt at lade udviklingsværktøjerne håndtere så mange fejlundgåelsesopgaver som muligt pålideligt og automatisk. B. lettes ved hjælp af struktureret programmering . På den ene side drejer det sig om kontroller såsom synlighedsregler og typesikkerhed samt undgåelse af cirkulære referencer, der kan vedtages af kompilatoren, før programmer oversættes , men også kontroller, der kun kan udføres ved runtime , som f.eks. indekskontrol for datafelter eller typecheck for objekter med objektorienteret programmering.

I designfasen

Softwareeksperter er enige om, at stort set alle ikke-trivielle programmer indeholder fejl. Der er derfor udviklet teknikker til at håndtere fejl inden for programmer på en tolerant måde. Disse teknikker inkluderer defensiv programmering , håndtering af undtagelser , redundans og overvågning af programmer (f.eks. Ved hjælp af vagthundstimere ) samt plausibilitetskontrol af programmet under udvikling og dataene under programkørslen.

Ved programmering

Derudover tilbydes en række avancerede applikationer, der analyserer enten kildekoden eller den binære kode og forsøger at finde fejl, der ofte foretages på en automatisk måde. Denne kategori indeholder programmer til eksekveringsovervågning, som normalt pålideligt registrerer forkerte hukommelsesadgange og hukommelseslækager . Eksempler er det frit tilgængelige værktøj Valgrind og det kommercielle Purify . En anden kategori af testprogrammer omfatter applikationer, der statisk analyserer kilde- eller binærkode, såsom at finde og rapportere ikke lukkede ressourcer og andre problemer. Disse omfatter FindBugs , Lint og Splint .

Ved test

Det giver perfekt mening, at testen skal udvikles inden selve programmet. Dette sikrer, at der ikke skrives en test, der matcher det program, der allerede er skrevet . Dette kan gøres i analyse- eller designfasen ved at bestemme testcases baseret på specifikationen . Fastlæggelsen af ​​testcases på dette tidlige stadie af softwareudvikling gør det også muligt at kontrollere programmets krav til testbarhed og fuldstændighed. De testcases, der er bestemt på baggrund af specifikationen, er grundlaget for accepttestene - som løbende forfines over hele udviklingsprocessen og z. B. kan forberedes til testautomatisering .

Nogle softwareudbydere gennemfører undertiden testfaser offentligt og udsteder betaversioner, så de uforudsigeligt forskellige brugsbetingelser for forskellige brugere kan testes og kommenteres af dem.

Operationel

Hvis der opstår en fejl under drift, skal der gøres et forsøg på at holde dens virkninger så lave som muligt og inddæmme dets aktivitetsfelt ved at oprette "beskyttelsesvægge" eller "beskyttelsesforanstaltninger". Dette kræver på den ene side evnen til at opdage fejl og på den anden side at kunne reagere tilstrækkeligt på en fejl.

Et eksempel på fejlregistrering under et computerprograms løbetid er påstande , ved hjælp af hvilke forespørgsler der altid er opfyldt i henhold til programdesignet. Andre mekanismer er undtagelseshåndtering såsom fælde og undtagelse.

Ved at implementere bevisbærende kode kan softwaren i et vist omfang garantere og sikre dens pålidelighed under runtime.

Fejlfrihed

Fuldstændig frihed for fejl for software, der overstiger en vis kompleksitetsgrænse, er praktisk talt hverken opnåelig eller verificerbar. Med stigende kompleksitet falder overblikket, især hvis flere personer er involveret i programmeringen. Selv dyr eller omfattende testet software indeholder programmeringsfejl. I tilfælde af brugbare programmer taler man så om robusthed frem for at være fri for fejl . Software anses for at være robust, hvis fejl kun forekommer meget sjældent og derefter kun forårsager mindre gener og ikke forårsager større skade eller tab.

I særlige tilfælde er det muligt at bevise, at et program er fejlfrit (med hensyn til de angivne krav). Især på områder, hvor brugen af ​​software er forbundet med store økonomiske, økonomiske eller menneskelige risici, som f.eks For eksempel i software, der bruges til militære eller medicinske formål eller i luftfartsindustrien, bruges også en metode kaldet "(formel) verifikation ", hvor softwarens korrekthed er matematisk bevist. På grund af den enorme indsats, der er involveret, har denne metode imidlertid strenge grænser og er derfor praktisk talt umulig at udføre med komplekse programmer (se også forudsigelighed ). Der er imidlertid nu værktøjer, der ifølge deres egne oplysninger kan levere dette bevis hurtigt og pålideligt, i det mindste for delområder ( runtime fejl ).

Udover matematisk verifikation findes der også en praktisk verifikationsform, som er beskrevet af kvalitetsstyringsstandarden ISO 9000 . Med den etableres en fejl formelt kun, hvis et krav ikke er opfyldt. Omvendt kan et arbejdsresultat (og dermed også software ) beskrives som 'fejlfrit', hvis det beviseligt opfylder alle krav. Opfyldelsen af ​​et krav bestemmes ved test . Hvis alle de test, der er defineret for et krav, bringer de forventede resultater, er kravet opfyldt. Hvis dette gælder for test af alle krav (forudsat korrekt og fuldstændig testning), konkluderes det, at der ikke er fejl med hensyn til kravene. Hvis de krav, som testene er baseret på, er defekte eller ufuldstændige, fungerer softwaren stadig ikke "som ønsket".

Klassificering af fejl

Fejl, der opstår, behandles generelt systematisk i fejlhåndtering . Ifølge IEEE-standarden 1044 (klassificering af software-anomalier) går hver fejl igennem en såkaldt klassificeringsproces, der består af de fire trin i genkendelse, analyse (undersøgelse), behandling (handling) og konklusion (disposition). I hvert af disse trin udføres de administrative aktiviteter, der registrerer, klassificerer og identificerer virkninger.

Kriterier, efter hvilke fejl kan klassificeres, omfatter: (med eksempler):

• Fejltypen: Der skelnes mellem: leksikale fejl (ukendt reference), syntaktiske fejl (glemt semikolon), semantiske fejl (forkert deklaration ), runtime -fejl (forkert formaterede inputdata) og logiske fejl (plus i stedet for minus, loop fejl , ...)
• årsagen til fejlen: upræcis specifikation, roterede tal, forkert formel, ukontrollerede (forkerte) inputdata ...
• det tidspunkt, hvor fejlen opstod ('forkert handling'): Allerede i programspecifikationen, i kodeudkastet, i kodningen, ...
• Det tidspunkt, hvor fejlen opstår ('fejleffekt'): En grundlæggende forskel skyldes, om fejlen opstår under programudvikling, for eksempel under test (her er dette et normalt tilfælde) eller i produktiv drift (hvor den ofte repræsenterer en kritisk fejl).
• opdagelsestidspunktet: jo længere "fejlopholdstiden" er, jo mere tidskrævende i. A. Den korrigerende handling fortsætter.
• fejlens virkning (er): visningsfejl, forkerte resultater, programafslutning, eksterne effekter ...
• Indsats og varighed af fejlfinding: minimal ... meget høj; straks ... meget lang varighed;
• Behandlingsstatus: forekommet, undersøgt, korrektion i proces, gentest mulig, ..., udført

Ved hjælp af metrics "bør resultaterne [og fund om fejl] også være en grund til at søge årsagerne bag problemerne". "Fejlklassifikationer danner grundlaget for standardiserede procedurer for fejlhåndtering og understøtter også kontinuerlig kvalitetsforbedring i betydningen kvalitetsstyring ." Yderligere oplysninger om hver fejl, f.eks. En detaljeret fejlbeskrivelse, berørte programmer, involverede personer osv. Ledsager foranstaltninger til fjerne fejlene og dokumentere dem. For mere information, se BITKOM -guiden.

For enkelthedens skyld er programfejl i fejlhåndteringsprocessen ofte kun opdelt i kategorier / klasser som A, B, C ... eller 1, 2, 3 ... osv. Alt efter fejlens sværhedsgrad, som også omfatter virkningen af ​​fejlen og den krævede indsats for at rette den op. For eksempler, se BITKOM -retningslinjerne, især i tillægget.

Konsekvenser af programfejl

Konsekvenserne af programfejl kan variere meget og vise sig på mange forskellige måder. Hvis der opdages fejl under udviklingsprocessen, er konsekvenserne af fejlen også begrænset til revisionen af ​​softwaren (kodekorrektioner, konceptrevision, dokumentation ...) - afhængigt af situationen med større eller mindre effekt på projektbudgettet og projektets varighed. På den anden side har fejl, der kun genkendes i produktiv drift, ofte en mere kritisk effekt, for eksempel kan de forårsage procesforstyrrelser eller produktionsstop, beskadige billedet, forårsage tab af kunder og markeder, udløse regresforpligtelser eller endog bringe fare virksomhedens eksistens. I værste fald kan fejl i tekniske applikationer føre til katastrofer.

Specifikke eksempler på programfejl og deres konsekvenser findes på listen over programfejleksempler .

Reproducerbarhed af programfejl

Nogle programfejl er ekstremt vanskelige eller umulige at gengive pålideligt. Hvis en tidligere mislykket proces gentages under tilsyneladende uændrede forhold, er der en sandsynlighed for, at disse fejl ikke kommer til udtryk igen. Der er to mulige årsager til denne adfærd: På den ene side kan der være forsinkelser mellem aktiveringen af ​​fejlen og det problem, der i sidste ende opstår, for eksempel et programnedbrud, som tilslører den faktiske årsag og gør det svært at identificere. På den anden side kan andre elementer i softwaresystemet (hardware, operativsystem, andre programmer) påvirke opførslen af ​​fejlene i det pågældende program. Et eksempel på dette er fejl, der opstår i samtidige miljøer med utilstrækkelig synkronisering (mere præcist: sekventering ). På grund af de resulterende løb betingelser kan processerne behandles i en sekvens, der fører til en runtime fejl. Hvis den samme handling gentages, er det muligt, at rækkefølgen af ​​processerne er anderledes, og at der ikke opstår et problem.

Yderligere emner

• For princippet om levering af "umoden" software, se bananprincip # Bananware .
• Software, der (ofte tilbydes gratis) f.eks. B. har mangler i sikkerhed, klarhed eller brugbar funktionalitet; se crapware

litteratur

• William E. Perry: Softwaretest. Mitp-Verlag, Bonn 2002, ISBN 3-8266-0887-9 .
• Elfriede Dustin, Jeff Rashka, John Paul: Test af software automatisk. Fremgangsmåde, håndtering og ydeevne. Springer, Berlin et al. 2001, ISBN 3-540-67639-2 .
• Cem Kaner, Jack Falk, Hung Quoc Nguyen: Test af computersoftware. 2. udgave. John Wiley & Sons, New York NY et al. 1999, ISBN 0-471-35846-0 .

Weblinks

Wiktionary: fejl  - forklaringer på betydninger, ordets oprindelse, synonymer, oversættelser

• De 25 farligste programmeringsfejl (engelsk)
• SQS: De mest spektakulære softwarefejl i 2012. I: Computerwoche. 17. januar 2013, adgang til 20. januar 2013 . 

Individuelle beviser

1. ↑ ^{a b c} M. Pol, T. Koomen, A. Spillner: Styring og optimering af testprocessen. dpunkt.Verlag, Heidelberg 2002, ISBN 3-89864-156-2 .
2. ↑ SPILLNER et al. Praktisk viden softwaretest - testledelse læsning af prøve kap. 1.1 Grundlæggende viden / definition af fejl ( Memento fra 17. december 2010 i internetarkivet ) (PDF) dpunkt.de
3. ^ Merriam-Webster Unabridged Dictionary (iOS-App, 2016): fejl: a) et insekt eller andre krybende eller kravlende hvirvelløse dyr ... b) nogle af visse insekter, der almindeligvis betragtes som særligt modbydelige ... c) et insekt af ordenen Hemiptera , især: a medlem af underordenen Heteroptera ...
4. ↑ The Papers of Thomas A. Edison, bind. 4, red. Paul B. Israel, Baltimore og London, 1993. Online [1]
5. ^ Fred R. Shapiro: Etymology of the Computer Bug: History and Folklore . I: American Speech 62: 4, 1987, s. 376-378.
6. ↑ ^{a b} informatik.uni-oldenburg.de
7. ^ IX-Magazin , Study Software Test Management , var tidligere tilgængelig i IX-kiosken ( Memento fra 9. januar 2013 i internetarkivet )
8. ↑ ^{a b} Wallmüller: Software Quality Management in Practice, beck-shop.de (PDF; 612 kB), Hanser, München 2001, ISBN 978-3-446-21367-8 .
9. ↑ Junginger: Værdi-orienteret kontrol med risici i informationsstyring . 2005, ISBN 3-8244-8225-8 .
10. ^ Georg Edwin Thaller softwaretest, verifikation og validering 2002, ISBN 978-3-88229-198-8 .
11. ↑ my.safaribooksonline.com
12. ↑ IEEE Standardklassificering for software -anomalier. (PDF) IEEE Standards Board, 1993, s. 32 , tilgås den 22. november 2014 (hvidbog; dokument bag Paywall). 
13. ↑ ^{a b c} Defektklassificering for software. BITKOM, december 2007, arkiveret fra originalen den 16. april 2019 ; adgang til den 11. april 2021 .