Citering af Ilene Burnstein fra bogen Praktisk softwaretest (anbefales), der adskiller sig fra definitionen i” IEEE-standarder Collection for Software Engineering “(1994) og” IEEE Standard Glossary of Software Engineering Terminology “(standard 610.12, 1990):

Fejl

En fejl er en fejl, misforståelse eller misforståelse hos en softwareudvikler

I kategorien udvikler inkluderer vi softwareingeniører, programmører, analytikere og testere. For eksempel kan en udvikler misforstå en designnotation, eller en programmør kan skrive et variabelnavn forkert.

Fejl (mangler)

En fejl (defekt) indføres i softwaren som følge af en fejl. Det er en anomali i softwaren, der kan få den til at opføre sig forkert og ikke i henhold til dens specifikationer.

Fejl eller mangler kaldes undertiden “bugs”. Brug af sidstnævnte begreb trivialiserer virkningen af fejl på softwarekvaliteten. Brug af udtrykket “defekt” er også forbundet med softwareartifakter såsom krav og designdokumenter. Fejl, der forekommer i disse artefakter, er også forårsaget af fejl og opdages normalt i gennemgangsprocessen.

Fejl

En fejl er manglende evne til et softwaresystem eller en komponent til at udføre sine krævede funktioner inden for specificerede ydelseskrav.

Under udførelsen af en softwarekomponent eller et system skal en tester, eller brugeren bemærker, at den ikke producerer de forventede resultater. I nogle tilfælde indikerer en bestemt type forkert opførsel, at en bestemt type fejl er til stede. Vi kan sige, at typen af dårlig opførsel er et symptom på fejlen.En erfaren udvikler / tester vil have en videnbase om fejl / symptomer / fejlsager (fejlmodeller som beskrevet i kapitel 3) gemt i hukommelsen. Forkert opførsel kan omfatte at producere forkerte værdier for outputvariabler, et forkert svar fra en enheds side eller et forkert billede på en skærm. Under udviklingen observeres fejl ofte af testere, og fejl lokaliseres og repareres af udviklere.

Du kan læse hele kapitlet i Google Bøger, her .

Der er nogle forskellige udtryk relateret til softwarefejl. Uddrag fra et kursus, jeg tog:

• Fejl : Menneskelig handling eller undladelse der resulterer i en fejl.

• Fejl : Fejl er en software defekt (forkert trin, proces eller datadefinition), der forårsager en fejl.

• Fejl : Samme som fejl.

• Fejl : manglende evne til en software til at udføre de krævede funktioner inden for specificerede ydelseskrav.

Ifølge dette er der ingen forskel mellem en fejl og en fejl. Nogle mennesker hævder dog, at bug er en fejl, der findes, før de frigiver softwaren, mens defekten er en, som kunden finder.

Jeg kunne ikke modstå at sende det berømte “første faktiske tilfælde af fejl, der blev fundet. “.

Kommentarer

• Endelig nogen, der har læst: testingstandards.co.uk/bs_7925-1_online.htm
• At ‘ s ikke hvor jeg fik det fra, men de kan have en fælles kilde (eller denne kan være kilden).
• Ja, for mange, mange år siden brugte jeg et stykke tid på at rette en fejl. Jeg havde en irriterende flimmer i en celle på skærmen, og det gav ingen mening. Den fløj til sidst. (Dette var i æraen med hvid tekst på en sort skærm, det pågældende sted var langt nok til højre for altid at være sort, mens Jeg redigerede, så jeg bemærkede det kun, da programmet lagde noget hvidt bag det.)

Åh gud.

Tilbage i gamle dage – defekt betjening af en computer var forårsaget af alle mulige ting – herunder rotter, der tygger ledningerne og rigtige bugs (væsener), der kommer ind i værkerne.

udtryk BUG har siddet fast som et udtryk, der betyder, at noget ikke fungerer som forventet.

BUG skal betragtes som et jargongudtryk, der betyder en defekt.

En defekt er en teknisk korrekt term, der betyder at tingen ikke gør som den skal.

Når det er muligt, bruger DEFECT i stedet for BUG faktisk en konnotation, som vi anerkender vores fejl (vores mangler, vores manglende forståelse af brugernes krav eller tingene vi overses i implementeringen) i stedet for at klæde den ud som den mere trivielle lydende “bug”.

Brug DEFEKT.

Prøv ikke at bruge udtrykket BUG. Det er fjollet, irrelevant, historisk og bagatelliserende.

Kommentarer

• Hvorfor vil du fjerne et velkendt teknisk udtryk fra brugen? Jeg ‘ undskyld … ja, BUG er historisk – men hvis du mener, at programmører betragter fejl (generelt set i modsætning til specifikke) som trivielle bare fordi de ‘ kaldes bugs eller udtrykket som irrelevant på grund af dets oprindelse, så jeg ‘ er bange for, at jeg bliver til en grumpy middelalder er helt berettiget. Åh og som @Dan påpeger, er fejl fejl, men defekter er ikke ‘ t nødvendigvis fejl, hvilket yderligere antyder, at udtrykket har værdi.
• @Murph, a ” bug ” er en eufemisme for en programmeringsfejl. Ubevidst lokker dette til en slags gremlin, som udvikleren ikke har kontrol over. Dette er ikke korrekt – det er en fejl og at erkende dette er et skridt mod mere professionel adfærd. (Imho selvfølgelig :-))
• Erm, helt klart er jeg uenig (-: Jeg ved præcis, hvem der er ansvarlig for fejlene – kodning og logiske fejl – som jeg har i min kode. (I ‘ Jeg er også i stand til at identificere fejl i andre mennesker ‘ s kode.) Alle de programmerere, jeg kender, er klare over, hvad udtrykket betyder – at de ( en programmerer) og ikke en form for gremlin lavede en fejl.
• Når du beskæftiger dig med dine kunder, kan du kalde disse ting bugs eller defekter. Bugs er jargon. Defekter er en anerkendelse uden for jargonen, at det er ikke som det burde være. ” Defekter ” er et udtryk, der er og tilskynder til klar kommunikation – også uden for programmeringsbrødrigheden som indeni.(Jeg er også uenig i, at der er forskel på en fejl og en fejl.)
• Fejl er det rette udtryk. Hvor mange programmer frigives med fejl i dem, og det accepterer vi alle? Men hvor mange programmer frigives med mangler? Vi vil ikke ‘ t acceptere det, fordi udtrykket indebærer en større sværhedsgrad, og vi ved, at det ‘ er vores egen skyld for fejlen, snarere end en fejl, hvor vi kan bebrejde vejret eller tidspunktet på dagen.

Fra IEEE-standarden Ordliste over Software Engineering Terminology, som er citeret i Software Engineering Body of Knowledge KA til softwaretest og softwarekvalitet:

bug. Se: fejl; fejl.

fejl. (1) Forskellen mellem en beregnet, observeret eller målt værdi eller tilstand og den sande, specificerede eller teoretisk korrekte værdi eller tilstand. For eksempel en forskel på 30 meter mellem et beregnet resultat og det korrekte resultat. (2) Et forkert trin, proces eller datadefinition. For eksempel en forkert instruktion i et computerprogram. (3) Et forkert resultat. For eksempel et beregnet resultat på 12, når det korrekte resultat er 10. (4) En menneskelig handling, der giver et forkert resultat. For eksempel en forkert handling fra en programmørs eller operatørs side. Bemærk: Selvom alle fire definitioner er almindeligt anvendte, tildeler en sondring definition 1 til ordet “fejl”, definition 2 til ordet “fejl”, definition 3 til ordet “fiasko” og definition 4 til ordet “fejl”. Se a2so: dynamisk fejl; fatal fejl; oprindelig fejl semantisk fejl syntaktisk fejl statisk fejl forbigående fejl.

fejl. Et systems eller komponents manglende evne til at udføre de krævede funktioner inden for specificerede ydelseskrav. Bemærk: Fejltolerancedisciplinen skelner mellem en menneskelig handling (en fejl), dens manifestation (en hardware- eller softwarefejl), resultatet af fejlen (en fejl) og det beløb, hvormed resultatet er forkert (fejlen). Se også: nedbrud; afhængig fiasko undtagelse; fejl tilstand; fejlrate; hård fiasko begyndende fiasko uafhængig fiasko tilfældig fiasko blød svigt fast fejl.

fejl. (1) En defekt i en hardwareenhed eller komponent; for eksempel en kortslutning eller ødelagt ledning. (2) Et forkert trin, proces eller datadefinition i et computerprogram. Bemærk: Denne definition bruges primært af fejltolerancedisciplinen. Ved almindelig brug bruges udtrykkene “fejl” og “fejl” til at udtrykke denne betydning. Se også: datafølsom fejl; programfølsom fejl; ækvivalente fejl fejlmaskering; intermitterende fejl.

Jeg synes, at definitionen af fiasko er den mest relevante. Alt begynder med en fejl, hvad enten det er i kravene, designet, implementeringen eller testsagen / proceduren. Hvis denne fejl manifesteres i software, bliver det en fejl. En fejl skyldes eksistensen af en eller flere fejl i software.

Jeg er dog ikke interesseret i den formelle definition af fejl. Jeg foretrækker meget definitionen, som dukeofgaming giver i hans svar , men den i dette svar er IEEE-standarddefinitionen af fejl.

Dan McGraths svar spikrede det rigtigt.

• En fejl er resultatet af en kodningsfejl
• En defekt er en afvigelse fra kravene

Måske ville et eksempel gøre det klarere.

Eksempel: Klient ønskede, at webformularen kunne gemme og lukke vinduet.

Scenarie nr. 1: Webformular har en gem-knap og en anden luk-knap. Resultat: Defekt, fordi klienten ønskede, at 1-knappen skulle gemme og lukke vinduet. Udvikleren misforstod og oprettede separat. Fordi begge knapper udførte deres krav, er det ikke en fejl, men en fejl, fordi den ikke opfyldte kundens krav.

Scenarie nr. 2: Webformular har en gem & luk-knap, men gemmer kun, men lukkes ikke. Resultat: Insekt. Fordi knappen ikke fungerer som krævet / forventet. Udvikler ved, at det antages at producere det resultat, men i sidste ende gjorde det ikke. (Måske kodningsfejl)

Ikke sikker på, om dette gør det klarere.

p / s: fra en udvikler standpunkt (jeg var engang), både mangler og bugs er lige så vigtige. Vi løser det stadig.

Vi stødte endda på underlige uregelmæssigheder, som vi kategoriserede under bugs, og vi forsøger løbende at finde ud af, hvad er årsagen, og hvordan man løser det. At betegne det bugs gør det ikke trivielt i forhold til mangler.

Kommentarer

• Hvad kalder vi defekte krav?
• @ gnasher729 hvis du med fejlbehæftede krav mente, at programmørerne misforstod kravene, så ville jeg tro, at det ‘ er en defekt. Men hvis du mente fejlbehæftede krav, da brugeren, der leverer de forkerte krav, der resulterer i det endelige arbejde, ikke løser det oprindelige problem, så er det ud over fejl og mangler, da dette er et problem med kravindsamlingssessionen snarere end med udviklingen.

Her er en, jeg gjorde tidligere for min arbejdsgiver Q-LEAP baseret på ISTQB-ordforrådet, og jeg tjekkede også IEEE-ordforrådet. God fornøjelse.

Fejl og fejl? Det samme, selvom man kan have uendelig diskussion om dette. Vi har virkelig andre ting at bekymre os om, livet er allerede kompliceret nok osv.

Et eksempel på hvordan udtrykket bruges i naturen fra “Hvordan Google tester software” s. 113. Åbn en artikel af “IEEE-software”, og den bruges på samme måde. Man møder faktisk sjældent ordet “defekt” i det virkelige liv.

Bugs liv

Bugs og bugrapporter er den artefakt, som hver tester forstår. At finde bugs, triaging bugs, fix bugs og regressing bugs er hjerteslag og workflow for softwarekvalitet. Dette er den del af test, der er den mest konventionelle hos Google, men der er stadig et par interessante afvigelser fra normen. I dette afsnit ignorerer vi de fejl, der arkiveres for at spore arbejdsgenstande og bruger udtrykket til at identificere faktisk brudt kode. Som sådan repræsenterer fejl ofte time-til-time og den daglige arbejdsgang for ingeniørteam.

En fejl er født. Fejl findes og arkiveres af alle hos Google. Produkt Ledere arkiverer fejl, når de finder problemer i de tidlige bygninger, der adskiller sig fra deres specifikationer / tanker. Udviklere arkiverer fejl, når de indser, at de ved et uheld kontrollerede et problem eller fandt et problem et andet sted i kodebasen eller under dogfooding af Google-produkter. Der kommer også fejl fra marken, fra crowd-sourced testere, test af ekstern leverandør og arkiveres af Community Managers, der overvåger de produktspecifikke Google Groups. Mange interne versioner af apps har også hurtige et-klik-måder til filfejl, som f.eks. Google maps. Og nogle gange opretter softwareprogrammer bugs via en API.

Forskellen er, at udtrykket “bug” lyder magisk. Som om et program tilfældigt kan have fejl i det, efter at du er færdig med at programmere. Hvis det har tilfældige fejl, betyder det, at du ikke overholdt specifikationerne, og dit program er i fejl.

En defekt betyder en fejl, hvor programmet ikke overholder specifikationerne. Dette er mere alvorligt og siger grundlæggende, enhver fejl er et stort problem med programmet, og det betyder, at programmet er ikke egnet til at blive frigivet.

Forskellen er i holdningen hos programmørerne, der bruger udtrykkene. Der er millioner af programmer, der frigives med bugs, og folk har det godt, fordi de accepterer af en eller anden grund at en fejl er magisk og tilfældig, og at hvert program indeholder mindst en fejl. Imidlertid kan en programmør, der bruger udtrykket “defekt” blive ubehageligt med at frigive et program med en defekt, fordi udtrykket indebærer en større sværhedsgrad.

Implikationerne ved at foretrække et udtryk frem for det andet påvirker os dagligt.

Uden for specifik fejl / opgave / billet / defekt / problem / uanset sporingssystemtilstand har disse ord ikke nogen nøjagtig betydning, og det er derfor meningsløst at diskutere forskellen mellem dem. Når du afregner din arbejdsgang, skal du afregne terminologien og give beskrivelser.

I mit nuværende miljø er en “defekt” ethvert element i Jira. Det ser ud til, at Jira selv bruger udtrykket “problem”. Vi har muligvis arvet det fra et tidligere system.”Fejl” er en type problem, når noget ikke fungerer som forventet og beskrevet i dokumentationen. “Funktionsanmodning”, når noget fungerer som forventet, men impvovement er ønsket (det kan være indlysende og vigtigt, men hvis den aktuelle adfærd beskrives, er det stadig en funktionsanmodning). Der er flere typer, men disse 2 bruges af folk uden for udviklingsteamet til at spørge noget fra det.

Hvis du vælger navne til problemtyper, lyder “bug” og “defect” svarende til mig. Forskellen mellem dem er stilistisk. Da engelsk ikke er mit modersmål, kan jeg ikke rigtig se meget af det og er ikke sikker på, om det jeg ser er korrekt.