af Simon Tatham, professionel og fri software programm�r
[ English | Português | 简体中文 | Česky | Dansk | Deutsch | Español | Fran�ais | Magyar | Italiano | Nederlands | Polski | Русский | 繁體中文 ]
Enhver som har skrevet software til offentlig brug har sikkert modtaget mindst en d�rlig fejlrapport. Rapporter der ikke siger noget ("Det virker ikke!"); rapporter der ikke giver mening; rapporter der ikke giver nok information; rapporter der giver forkert information. Fejlrapporter der viser sig at v�re brugerfejl; rapporter om fejl der viser sig at v�re et andet programs fejl; rapporter om problemer der viser sig at v�re netv�rksfejl.
Der er en grund til at teknisk support anses for at v�re en forf�rdelig branche at v�re i, og den grund er d�rlige fejlrapporter. Men ikke alle fejlrapporter er ubehagelige: Jeg vedligeholder fri software, n�r jeg ikke tjener til f�den, og nogle gange modtager jeg vidunderligt klare, hj�lpsomme, informative fejlrapporter.
I dette essay vil jeg pr�ve klart at formulere hvad der skal til i en god fejlrapport. Ideelt set ville jeg �nske at alle i verden l�ste dette essay f�r de rapporterer fejl til nogen som helst. Jeg ville i hvert fald �nske at alle som rapporterer fejl til mig havde l�st det.
I en n�ddeskal er m�let for en fejlrapport at g�re programm�rerne i stand til at se programmet fejle foran sig. Du kan enten vise det personligt, eller give omhyggelige og detaljerede instruktioner i hvordan man f�r fejlen frem. Hvis de kan f� fejlen frem selv, vil de pr�ve at samle yderligere information indtil de kender �rsagen. Hvis de ikke kan f� fejlen til at ske selv, bliver de n�d til at bede dig om at samle denne yderligere information for dem.
Pr�v at g�re det meget klart i en fejlrapport, hvad der er egentlige fakta ("Jeg sad ved computeren og dette er hvad der skete") og hvad der er dine egne teorier ("Jeg tror problemet m�ske er dette"). Udelad teorierne hvis du vil, men udelad aldrig fakta.
N�r du rapporterer en fejl s� g�r du det fordi du gerne vil have fejlen rettet. Der er ingen id� i at svine programm�rerne til eller v�re overlagt uhj�lpsom; det kan v�re at det er deres fejl og dit problem, og det kan v�re du m�ske har ret til at v�re sur p� dem, men fejlen bliver rettet hurtigere hvis du hj�lper ved at give dem al den information de har brug for. Husk ogs� at hvis programmet er frit s� har forfatterne ofte gjort det frit ud af venlighed og hvis folk er ubeh�vlede over for dem kan det v�re det holder op med at v�re venlige.
G� ud fra at programm�rerne ikke er helt uintelligente: hvis programmet virkelig slet ikke virkede, s� ville de sandsynligvis have opdaget det. Da de ikke har det, s� virker det for dem. Det vil sige, enten g�r du noget andet end de g�r eller ogs� er dit milj� anderledes end deres. De har brug for information; at give denne information er form�let med en fejlrapport. Mere information er altid bedre end mindre.
Mange programmer, specielt frie, offentligg�r en liste over kendte fejl. Hvis du kan finde en liste over kendte fejl er det v�rd at l�se den for at se om den fejl du lige har fundet allerede er kendt eller ej. Hvis den allerede er kendt, s� er det sandsynligvis ikke n�dvendigt at rapportere den igen, men hvis du mener du har mere information end der allerede st�r i fejllisten s� har du m�ske lyst til at kontakte programm�rerne alligevel. De kan m�ske rette fejlen nemmere hvis du giver dem information de ikke havde i forvejen.
Dette essay er fuld af retningslinier. Ingen af dem er ufravigelige regler. Hver programm�r har sin foretrukne m�de at modtage fejlrapporter p�. Hvis programmet har sine egne fejlrapporteringsprocedurer: l�s dem. Hvis retningslinierne modsiger hvad dette essay siger s� f�lg programmets!
Hvis du ikke rapporterer en fejl, men bare sp�rger om hj�lp til at bruge programmet, s� b�r du angive hvor du har kigget efter l�sninger til dit problem. ("Jeg kiggede i kapitel 4 afsnit 5.2, men kunne ikke finde noget om dette er muligt eller ej.") N�r du g�r dette viser du programm�rerne hvor du forventede at finde svaret, s� de kan g�re dokumentationen nemmere at bruge.
En af de allerbedste m�der du kan rapportere en fejl er ved at vise programm�ren hvordan den opst�r. Stil dem foran din computer, start deres program og demonstr�r det der g�r galt. Lad dem f�lge med mens du starter maskinen, mens du starter programmet, i hvordan du bruger programmet og i hvad programmet g�r n�r du bruger det.
De kender programmet som deres egen bukselomme. De v�d hvilke dele de stoler p� og de v�d hvilke dele der sandsynligvis er problemer med. P� det tidspunkt hvor programmet g�r noget indlysende forkert har de m�ske allerede tidligere opdaget noget sm�t der er forkert, som kan give dem en ledetr�d. De kan se alt computeren g�r undervejs, og selv sortere de ligegyldige informationer fra.
Det kan v�re det ikke er nok. Det kan v�re de beslutter at de har brug for mere information og beder dig om at vise det samme en gang til. Det kan v�re de beder dig om at forklare hvad de skal g�re, s� de selv kan genskabe fejlen s� mange gange de har lyst til. Det kan v�re de pr�ver sm� variationer af fremgangsm�den for at se om problemet kun sker i nogle n�rt besl�gtede tilf�lde. Hvis du er uheldig er det m�ske n�dvendigt at de s�tter sig ned i nogle timer med forskellige udviklingsv�rkt�jer for virkelig at fejls�ge. Under alle omst�ndigheder er det vigtigste at programm�rerne ser maskinen n�r fejlen sker. N�r de kan se problemet ske, kan de som oftest tage det som udgangspunkt n�r de skal rette fejlen.
Vi lever i internettets �ra. Den internationale kommunikations �ra. I denne �ra kan jeg sende mit program til en Rusland med et tryk p� en knap og han kan sende mig kommentarer om det lige s� nemt. Men hvis han har et problem med mit program, s� kan han ikke f� mig til at st� foran hans computer mens fejlen sker. "Vis mig hvordan" er godt n�r det er muligt, men det er det ofte ikke.
Hvis du skal rapportere en fejl til programm�rer som ikke kan v�re til stede personligt s� er m�let med �velsen at g�re det muligt for dem at genskabe problemet. Du �nsker at programm�rerne k�rer deres egne udgaver af programmet, g�r det samme ting som du g�r og f�r det til at lave fejl p� samme m�de. N�r de kan se problemet ske foran sig, s� kan de g�re noget ved det.
Alts�: fort�l dem pr�cis hvad du gjorde. Hvis det er et program med grafisk brugergr�nseflade, fort�l hvilke knapper du klikker p� i hvilken r�kkef�lge. Hvis det er et kommandolinieprogram vis dem pr�cis den kommando du skrev, bogstaveligt talt. N�r det er muligt b�r du altid stille en eksakt afskrift af interaktionen med programmet til r�dighed, der viser hvilke kommandoer du skrev og hvad computeren svarede.
Giv programm�ren alle de oplysninger du kan komme p�. Hvis programmet l�ser en fil, s� vil det sandsynligvis v�re en god id� at sende en kopi af filen. Hvis programmet taler med en anden computer over et netv�rk kan du nok ikke sende en kopi af den computer, men du kan i hvert fald sige hvilken type computer det er og (hvis du kan) oplyse hvilke programmer der k�rer p� den.
Hvis du giver programm�rerne en lang liste af inddata og handlinger og de starter programmet p� deres egne maskiner og alt virker hos dem, s� har du ikke givet dem nok information. M�ske opst�r fejlen ikke p� alle computere; dit system og deres er m�ske forskellige p� en eller anden m�de. M�ske har du misforst�et hvad det er meningen programmet skal g�re og I kigger i virkeligheden p� det samme, men du tror det er forkert og de ved det er korrekt.
Alts�: beskriv hvad der skete. Fort�l dem pr�cist hvad du s�. Fort�l dem hvorfor du mener det du s� er forkert; eller endnu bedre: fort�l dem pr�cis hvad du forventede at se. Hvis du siger "og s� kom fejlen", s� har du udeladt vigtig information.
Hvis du s� fejlmeddelelser s� fort�l programm�rerne om dem, omhyggeligt og pr�cist. De er vigtige! P� dette tidspunkt er programm�rerne ikke i gang med at l�se problemet: de er alene ved at finde det. De skal vide hvad der er g�et galt, og fejlmeddelelserne er computerens bedste fors�g p� at fort�lle hvad det er. Skriv fejlmeddelelserne ned hvis du ikke har nogen anden nemmere m�de at huske dem p�. Det er ikke v�rd at fort�lle at der kom en fejlmeddelelse hvis du ikke kan fort�lle hvad fejlmeddelelsen var.
Specielt, hvis fejlmeddelelsen indeholder tal fort�l programm�ren hvad tallene var. Selv hvis du ikke kan se nogen mening i dem betyder det ikke at der ikke er nogen mening. Tal kan indeholde alle mulige oplysninger som programm�rerne kan bruge og sandsynligvis giver de essentielle ledetr�de. Tal i fejlbeskeder er der oftest fordi computeren er for forvirret til at give en fejlmeddelelse i ord, men den pr�ver s� godt den kan at give vigtig information.
P� dette tidspunkt er programm�rerne i gang med detektivarbejde. De ved ikke hvad der er sket og de kan ikke komme t�t nok p� til at se fejlen opst� selv, s� de s�ger efter ledetr�de som m�ske kan vise hvad det er. Fejlmeddelelser, uforst�elighed tal, ja endda uforklarlige tidsm�ssige forsinkelser er alle lige s� vigtige som fingeraftryk p� et gerningssted. Registrer dem!
Hvis du bruger Unix har programmet m�ske lavet et core dump. Core dumps er en god kilde til ledetr�de, s� slet dem ikke. P� den anden side kan de fleste programm�rer ikke lide at modtage store filer per e-mail uden varsel, s� sp�rg f�r du sender et core dump til nogen. Bem�rk ogs� at et core dump indeholder oplysninger om hele programmets tilstand: alle "hemmeligheder" der er involveret (m�ske var programmet ved at h�ndtere en personlig besked eller ved at h�ndtere fortrolige data) kan m�ske v�re indeholdt i core dumpet.
Der er mange ting du kan g�re n�r en fejl viser sig. Mange af dem g�r problemet v�rre. En af mine venner i skolen kom til at slette alle sine Word-dokumenter ved et uheld. F�r hun ringede efter eksperthj�lp pr�vede hun f�rst at geninstallere Word, hvorefter hun pr�vede at k�re Defrag. Hverken det ene eller det andet hjalp hende med at f� filerne tilbage og tilsammen �ndrede de hendes disk s� meget at intet Undelete program i verden kunne have f�et noget tilbage. Hvis hun bare havde ladet v�re med at g�re noget havde der m�ske v�ret en chance.
S�danne brugere er som et desmerdyr der er fanget i et hj�rne: med ryggen mod muren og sikker d�d i udsigt angriber den som en bers�rk, fordi at g�re noget m� v�re bedre end intet at g�re. Det er ikke en s�rlig fornuftig fremgangsm�de for den type problemer computere pr�senterer.
I stedet for at opf�re dig som et desmerdyr, opf�r dig som en antilope. N�r en antilope konfronteres med noget uventet eller uhyggeligt, s� st�r den helt stille. Den st�r stille og pr�ver p� ikke at tiltr�kke sig opm�rksomhed mens den t�nker sig om og pr�ver at finde ud af hvad det mest fornuftige er at g�re. (Hvis antiloper havde en teknisk support telefonlinie, s� ville den ringe dertil i denne situation). N�r den s� har fundet ud af hvad det sikreste er at g�re, s� g�r den det.
N�r noget g�r galt s� hold med det samme op med at g�re noget som helst. R�r ikke ved knapperne overhovedet. Kig p� sk�rmen og l�g m�rke til alt der er unormalt, husk det eller skriv det ned. Derefter kan du forsigtigt tykke "OK" eller "Fortryd", hvad der nu virker sikrest. Pr�v at opbygge en refleks der siger - hvis computeren g�r noget un�dvendigt, s� stop op.
Hvis det lykkes dig at komme ud af problemet, hvadenten det sker ved at lukke programmet ned eller genstarte computeren, s� er det en god id� at pr�ve p� at f� det til at opst� igen. Programm�rer kan bedst lide problemer man kan genskabe mere end en gang. Glade programm�rer retter fejl hurtigere og mere effektivt.
Det er ikke kun ikke-programm�rer som laver d�rlige fejlrapporter. Nogle af de v�rste fejlrapporter jeg har set er fra programm�rer, og det endda gode programm�rer.
Jeg arbejdede med en programm�r engang, som blev ved med at finde fejl i sin egen kode og pr�vede at rette dem. En gang i mellem fandt han en fejl han ikke kunne l�se og bad mig komme over og hj�lpe. "Hvad er der galt?" spurgte jeg. Han svarede med at fort�lle sin �jeblikkelige mening om hvad der burde rettes.
Det virkede fint n�r hans �jeblikkelige opfattelse var korrekt. Det bet�d at han allerede havde gjort halvdelen af arbejdet og vi kunne afslutte det sammen. Det var effektivt og brugbart.
Men ofte tog han fejl. Vi arbejdede et stykke tid p� at pr�ve at gennemskue hvorfor en eller anden specifik del af programmet producerede forkert data og til sidst opdagede vi at det slet ikke gjorde det, at vi havde brugt en halv time p� at fink�mme et stykke helt fin kode og at problemet l� et andet sted.
Jeg er sikker p� at han ikke ville g�re det samme med en l�ge. "Doktor, jeg har brug for en recept p� Hydroyoyodyne." Folk ved ikke hvad de skal sige hos l�gen: man beskriver symptomerne, ubehaget, hvor det g�r ondt, udslet og feber og s� lader man l�gen udarbejde diagnosen og hvad der skal g�res ved det. Hvis man ikke g�r det kategoriserer l�gen �n som hypokonder eller sm�sk�r, med god ret.
Det er det samme med programm�rer. Det kan nogle gange v�re en hj�lp at du kommer med din egen diagnose, men forklar altid hvad symptomerne er. Din egen diagnose er en valgfri ekstraoplysning og ikke et alternativ til at oplyse om symptomerne. P� samme m�de er det at sende en kode�ndring en brugbar tilf�jelse til en fejlrapport, men det er ikke en brugbar erstatning for samme.
Hvis en programm�r beder dig om yderligere information skal du ikke bare opfinde noget! Der var en som rapporterede en fejl til mig engang og jeg bad ham om at pr�ve en kommando jeg vidste ikke ville virke. Grunden til at jeg bad ham om at pr�ve den var at jeg var interesseret i at vide hvilken af to fejlmeddelelser kommandoen ville give. At vide hvilken af dem der kom tilbage ville give en vigtig ledetr�d. Men han pr�vede den ikke - han skrev bare tilbage og sagde "Nej, det virkede heller ikke". Det tog mig et stykke tid at overtale ham til virkelig at pr�ve.
Det er fint at bruge sin intelligens til at hj�lpe programm�rerne. Selv hvis dine deduktioner er forkerte b�r programm�rerne v�re glade for at du i det mindste pr�vede p� at g�re deres liv nemmere. Men rapporter ogs� symptomerne, ellers g�r du deres liv meget mere besv�rligt i stedet.
Sig "periodisk fejl" til en hvilken som helst gruppe programm�rer og se dem blegne. De nemme problemer er dem hvor fejlen kommer n�r man udf�rer en simpel r�kke af handlinger. Programm�rerne kan gentage disse handlinger under t�t observation og se hvad der sker i detaljer. Mange problemer er ikke af den type: der er programmer som fejler en enkelt gang om ugen, ved h�jvande, og som aldrig fejler n�r du viser dem for en programm�r, men altid lige f�r deadline.
De fleste periodiske fejl er ikke rigtigt periodiske. De fleste af dem han en eller anden slags logik et eller andet sted. Nogle sker m�ske kun n�r maskinen l�ber t�r for hukommelse, nogle sker m�ske n�r et andet program pr�ver at modificere en vigtig fil p� det forkerte tidspunkt og nogle sker m�ske kun i den f�rste halvdel af hver time! (Jeg har faktisk v�ret ude for s�dan en).
N�r du kan genskabe en fejl, men programm�rerne ikke kan, s� kan det meget vel v�re fordi deres computere er forskellig fra din og denne forskel udl�ser problemer. Jeg havde et program engang vis vindue kr�llede sammen som en lille kugle i �verste venstre hj�rne af sk�rmen, hvor det s� sad og klynkede. Men det gjorde det kun p� 800x600 sk�rme; det virkede fint p� min 1024x768 sk�rm.
Programm�rerne vil have alt du kan finde ud af om problemet at vide. Pr�v det for eksempel p� en anden maskine. Pr�v det to eller tre gange og se hvor ofte det sker. Hvis fejlen opst�r mens du laver rigtigt arbejde og ikke n�r du pr�ver at demonstrere den, kan det v�re lang k�retid eller store filer der f�r fejlen til at optr�de. Pr�v at huske s� mange detaljer du kan om hvad du var ved at g�re, da fejlen opstod, og hvis du ser nogen m�nstre, n�vn dem. Alt hvad du kan levere kan v�re til hj�lp. Selv hvis det kun er sandsynligheder (som "det plejer at g� ned oftere n�r Emacs k�rer"), det giver m�ske ikke direkte spor til hvad �rsagen er, men det kan m�ske hj�lpe programm�rerne til at genskabe fejlen.
Vigtigst af alt: Programm�rerne vil �nske at v�re sikker p� om det er en �gte periodisk fejl eller en maskin-specifik ting. De vil �nske at kende en masse detaljer om din computer, s� de kan finde ud af hvordan din maskine adskiller sig fra deres. Hvilke detaljer der er relevante vil afh�nge af hvad det er for et program, men en ting du helt sikkert skal have parat er versionsnumre. Versionsnummeret for programmet selv, versionsnummeret for operativsystemet og evt. for andre programmer involveret i problemet.
At formulere sig klart er essentielt i en fejlrapport. Hvis programm�ren ikke kan forst� hvad du mente kunne du lige s� godt ikke have sagt noget.
Jeg modtager fejlrapporter fra hele verden. Mange af dem er fra folk der ikke har engelsk som modersm�l og en masse af dem undskylder for deres d�rlige engelsk. For det meste er fejlrapporterne med undskyldninger for d�rligt engelsk faktisk meget tydelige og brugbare. Alle de mest uklare rapporter kommer fra folk med engelsk som modersm�l som g�r ud fra at jeg vil forst� dem selvom de ikke g�r nogen som helst indsats for at v�re tydelige og pr�cise.
Bem�rk: Jeg har aldrig set et desmerdyr eller en antilope i virkeligheden. Min zoologi kan meget vel v�re upr�cis.
$Id: bugs-da.html 8168 2008-09-08 18:03:28Z simon $
Copyright � 1999 Simon Tatham.
Dette dokument er
OpenContent.
Du m� kopiere og bruge denne tekst efter vilk�rene i
OpenContent
licensen.
Send venligst kommentar og kritik af denne artikel til
anakin@pobox.com.
Hvis du er kommet til denne side via et link fra et specifikt
program, s� send ikke fejlrapporter for programmet til ovenst�ende
adresse. G� i stedet tilbage til den side du kom fra og find der ud af
hvortil fejlrapporter skal sendes.
Overs�ttelsen til dansk af Adam Sj�gren.