QA/BugReport/da Fejlrapport
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
Glad for, at du nåede hertil. Du skal til at yde et vigtigt bidrag til LibreOffice. En god fejlrapport er meget nyttig for vore udviklere. Herunder finder du vejledning i at gøre denne proces lettere.
Ikke alle fejl kommer til Bugzilla
Alle hunde kan komme i himlen
, men nogle fejlrapporter bør indgives uden for Bugzilla. De omfatter:
| Klasse af fejl | Hvortil fejl skal indsendes |
|---|---|
| LibreOffice Udvidelser | med udvidelses forfatter |
| TDF/LibreOffice Infrastruktur (websteder, mail-lister osv.) | Redmine |
| Bygning af LibreOffice | Developer postliste |
| LibreOffice Enhedstests | Developer postliste |
| Ord mangler i ordbøger | Til ordbogsvedligeholderen eller arkivet |
| Fejl i oversættelser | Det er tilladt at rapportere dem i Bugzilla, men det er mere effektivt at tilføje dem som forslag i Weblate (kræver ikke registrering) |
Før du indsender en fejlrapport
Bekræft, at det faktisk er fejl. Det meste af tiden er en fejl noget, der får softwaren til at opføre sig på en måde, som en fornuftig bruger ikke ville ønske, at den opførte sig på. Det omfatter, at softwaren ikke gør det, du vil have den til at gøre, at den gør noget, du aldrig har bedt den om at gøre eller at den simpelthen bryder ned under normal brug. Bag kulisserne kan en fejl være noget, der får softwaren til at tage meget tid om noget og bruger mange flere ressourcer, end den burde.
Nogle fejl kan faktisk være resultatet af en korrupte brugerprofil. Problemer med OpenGL (i nyere versioner kig efter Skia) og OpenCL er normalt gyldige fejl. Det hjælper meget, hvis du tjekker virkningerne af OpenGL- og OpenCL-indstillingerne, før du skriver din fejlrapport.
Fra et vist punkt er det, der ser ud som fejl, faktisk mere som funktionalitetsønsker, hvor vi ved, hvordan funktionaliteten burde virke i en ideel verden, selv om den ønskede funktionalitet ikke er bygget endnu. Heldigvis behøver du ikke at bekymre dig meget om at skelne mellem fejl og funktionalitetsønsker. Hvis det er noget, der griber ind i normal, gyldig brug af programmet, rapporterer du det som en fejl.
Det hjælper dog meget, hvis du kan finde rundt i LibreOffice, så du har en god fornemmelse af, hvad der er normal, god brug. Du har ikke lyst til at bruge en masse tid på at rapportere, hvad du tror er fejl, mens problemet er, at du endnu ikke ved, hvordan en bestemt funktionalitet skal bruges. Overvej at læse den engelske brugerdokumentation, og brug programmerne meget, så du bliver bekendt med, hvad de almindeligvis gør.
Hvis du kender LibreOffice rimelig godt op og løber ind i noget, der kan være en fejl, men kunne være noget, du ikke forstår, kan du lægge et spørgsmål på LibreOfficebrugerne mail-liste eller Ask LibreOffice.
Men lad os sige, at det du har fundet faktiske ligner en fejl. Det her er, hvad du så skal gøre:
- Skriv noter, så du ikke glemmer noget, der skete omkring den tid, hvor fejlen viste sig. Hvad gjorde du, hvad ventede du, der skulle ske og hvad skete der faktisk? Hvordan vidste du, at der var noget galt? Kan du gentage den dårlige adfærd?
- Tjek for lignende, eksisterende fejlrapporter:
- Gå til Komponenter, og vælg den rette komponent (eller delkomponent).
- Hvis du valgte en komponent: vælg den rette delkomponent eller Udvidet hjælp, hvis du ikke finder delkomponenten på den side.
- Hvis du valgte Udvidet hjælp: vælg den rette delkomponent eller [1] nederst på listen hvis du ikke fandt eller ikke kendte den rette delkomponent.
- Du vil se en liste over fejl i den delkomponent. Nederst på siden vælger du "Rediger søgning". Du kan ændre søgningen der efter dine behov.
- Hvis du finder en fejlrapport, der omhandler dit problem, kan du bidrage til den. Hvis du ikke finder en fejlrapport, der omhandler dit problem, sender du en ny fejlrapport.
- Hvis fejlen kun sker på Ubuntu eller er relateret til udskrivning, går du til #Flere oplysninger.
- Hvis det efter alt dette ikke ser ud, som om der findes en fejlrapport på dette spørgsmål, følger du instruktionerne ved #Indsendelse af en fejl.
Indsendelse af en fejl
Indsend en særskilt fejlrapport for hver fejl, du støder på, også selv om symptomerne fra en brugersynsvinkel ser identiske ud. Forskellige problemer med forskellige rødder, der viste sig i forskellige forskellige LibO-versioner kan være ordnet af forskellige folk, i forskellige versioner og på forskellige tidspunkter. Det er umuligt at spore alt det i en enkelt fejlrapport.
Gå til Bugzilla.
Tilmelding
Hvis du opfordres til at melde dig ind, logger ind du på med din Bugzilla-konto.
Hvis du ikke har en Bugzilla-konto, skal du oprette en ved at klikke på Ny konto.
Komponent
Under Komponent, vælger du komponenten.
Hvis du ikke er sikker på, hvilken komponent, dit problem omfatter, vælger du komponenten LibreOffice. En eller anden vil senere gennemse din fejlrapport og vælge en mere præcis komponent. (Find flere oplysninger om triage, som er at gennemse fejlene for at få de betydningsfulde øverst på listen, ved at kaste et blik på "BugTriage".)
Hvis det er et påtrængende problem (defekte dele, regression osv.) og du er en erfaren bruger, der kender udviklingsteamet, kan du tildele fejlrapporten til en af udviklinger, der er oplistet på siden FindTheExpert
Detaljer
Hvis der en sektion Delkomponent, vælger du delkomponenten.
Hvis du ikke kender den rette delkomponent, går du til Komponenter. På den side klikker du på den rette komponent. Læs beskrivelsen af alle delkomponenter på denne komponents side. Hvis du ikke finder en passende delkomponent, klikker du på Udvidet hjælp og læser beskrivelserne af delkomponenterne på den side.
Vælg den version af programmet, som fejlen viste sig i. For at tjekke, hvilken version af LibreOffice, du bruger, vælger du ▸
Under Operativsystem eller OS vælger du det operativsystem, der er på den computer, du brugte, da du fandt fejlen.
Hvis der er en Hardware sektion, udfylder du den.
Hvis der er en Sværhedsgrad sektion, og du rapporterer en funktionsanmodning, skal du vælge forbedring. Ellers ignorer det, medmindre du er erfaren. Hvis du ønsker at kende definitionerne af emnerne i sektionen Severity, se dette diagram.
Du kan ignorere sektionen seneste kendte virkende version.
Emne
Tjek i tabellen muligvis beslægtede fejl related Bugs og på siden om fejlrapportering og endelig i Duplikat-tabellen for at se, om problemet faktisk ikke er rapporterede tidligere.
I afsnittet Emne (også kendt som resuméet):
- Medtag ikke oplysninger, der allerede er kendt fra felterne.
- Inkluder navnene på underkomponenter fra Components.
- Gør underkomponenterne med store bogstaver.
- Hvis delkomponenten kan forveksles med dele af et ord (for eksempel er UI en del af ordet quit) omslutter du delkomponenten med firkantede klammer.
- Brug højst to delkomponenter.
- Brug delkomponenter præcis, som de vises på listen, men du må gerne indarbejde dem i en sætning i emnelinjen som “WIKIHELP [UI] ikke tilgængelig på alle sprog”.
- Sammenfat problemet rimeligt præcist.
- dårligt eksempel: “Filen er defekt”
- bedre eksempel: “Menupunktet Filer > Gem som ikke tilgængelig (nedtonet)”ac
- Undgå korte former som “doesn’t” eller “isn’t” for lette søgningen efter strenge i Resuméet; brug i stedet den lange form som fx “does not” eller “is not”.
- Hvis problemet, der beskrives i rapporten er, at LibreOffice bryder sammen eller holder med at svare ("hænger"), tilføjer du orden CRASH til resuméet, sådan at disse fejl let kan findes og spores.
Beskrivelse og vedhæftninger
I den Lange Beskrivelse eller sektionen Beskrivelse giver du en længere, faktuel beskrivelse af problemet:
- oplist trin til gentagelse af fejlen;
- brug en nummereret liste; og
- beskriv den nøjagtige metode til at få noget til at ske. I stedet for for eksempel at skrive “Åbn dokument”, skriver du “I et nyt, tomt LibO regnearks-dokument, bruger du menuen Filer > Åbn (LibO-dialog) > filtype “Tekstdokuments” > vælg vedhæftet eksempel-dokument > dobbeltklik”.
Hvis du bruger en forhåndsbygget LibreOffice under Linux, oplister de præcise versioner af LibreOffice-pakker i dit pakkehåndteringssystem. Hvis du bruger Windows, oplister du det præcise filnavn på installatør og hvorfra den blev downloadet.
- Det kan være nyttigt, at du medtager information om installeret og anvendt lokalisering (brugerflade-sprog, dokumentsprog)
- Medtag, om du bruger en 32-bit LibreOffice på et 64-bit (Linux) system.
- Medtage pakke-kilden, hvis det ikke er den officielle LibreOffice-konstruktion.
Beskriv den ønskede adfærd og den aktuelle adfærd.
Du kan medtage en vedhæftning som fx et skærmbillede eller et eksempel-dokument. Den typiske måde at tage et skærmbillede på er at trykke på knappen "Print Screen/PrtScn" på dit tastatur. Afhængigt af dit operativsystem ksn fu være nødt til at åbne et billedredigeringsprogram (som fx Paint under Windows) og udføre - Rediger > Indsæt i det.
- Hvis du opretter skærmbilleder, skifter du sproget til engelsk, inden du tager skærmbilledet. Det kan du gøre på ▸ ▸ ▸ .
- Du kan gøre skærmbillederne mere nyttige ved at tilføje kommentarer og markere relevante områder med LibreOffice Draw.
- Hvis du vil vedhæfte mere end et skærmbillede, bør du samle dem allesammen i et dokument (kopier / indsæt i et LibreOffice Draw-dokument) og indsæt det som en PDF. Tilføj venligst en kort kommentar for at fortælle, hvad du vil vise med det.
- Hvis vedhæfter et eksempel-dokument, der viser den fejl, du rapporterer, bør du venligst gøre dokumentet så lille som muligt. Ved fx Writer-fejl bør dokumentet bare have et enkelt afsnit. For at gøre det let at finde teksten fra dit dokument i fejlsøgningen bruger du en rigtig let genkendelig tekst, som fx AAAAAAAAAA ₂ ZZZZZZZZZZ ved en fejl, der udløses af det tegn.
- Det bør foretrækkes at uploade vedhæftninger hver for sig. Hvis du imidlertid vil vedhæfte mere end et halv dusin dokumenter, opretter du en .zip-fil med alle dokumenterne og vedhæfter .zip-filen.
- Hvis din vedhæftning er for stor til at blive vedhæftet i Bugzilla (større end 1 MB), kan du bruge Experimental upload page.
Status
Det eneste tidspunkt, hvor bør ændre status til NEW er, hvis nogen allerede har bekræftet fejlen på et andet sted (Ask, mail-liste, et forum). I disse tilfælde send et link til diskussionen med bekræftelsen.
Send
Klik på Submit og din rapport bliver tilføjet til Bugzilla-databasen.
Hvis Bugzilla virker skræmmende
Hvis fejlsporingssystemet Bugzilla virker skræmmende eller for svært at forstå, bør du poste dit problem her:
Selvom du poster dit problem på disse kanaler, bør dit mål være at få en god fejlrapport på Bugzilla. Disse kaneler kan hjælpe dig med det. Bemærk, at rapportering af problemer på sociale medier (Facebook, Twitter osv.) i almindelighed ikke er produktivt, da det sjældent fører til en god fejlrapport havner i Bugzilla (se også: 99 måder at ødelægge et open source-projekt på, top 5).
Efter du har indsendt en fejlrapport
Hvis ingen har gennemset din rapport inden for en rimelig tid (24 timer for kritiske fejl, 14 dage for et forbedringsønske), bør du bede en eller anden om at reproducere din fejlrapport på users@global.libreoffice.org mail-listen eller IRC-kanalen #libreoffice IRC://.
Tilføjelse af kommentarer til fejlrapporter
- Undgå at sende "også mig"-kommentarer, som ikke indeholder mere nyttig brugerinformation.
Undtagelsen her er, når du kommenterer på en fejl, der indtil videre har været UNCONFIRMED (ikke-bekræftet). I det tilfælde: skriv venligst gentagelsestrin (eller bekræft dem, den til oprindelige indberetter opgav) og flyt problemet til status NEW (ny). Bemærk, at der ikke er klare gentagelsestrin, kan problemet hurtigt flytte tilbage til NEEDINFO (mangler info), så det er væsentligt er at finde et godt og enkelt gentagelses-scenarie. - Undgå at tilføje kommentarer i retningen "vi har 1000 arbejdspladser her og denne fejl er det eneste, der forhindrer os i at skifte", da det ikke giver nogen information, der er relevant for QA (kvalitetskontrollen) eller for prioriteringen af problemet.
LibreOffice er open source og din hjælp til at løse problemer er mere end velkommen. Du kan:
- Bruge og/eller lære dine egne udviklere at arbejde på LibreOffice. Vi vil med glæde være mentorer for dem: se udviklerens sider.
- Støt enkeltpersoner eller firmaer for at arbejde med bestemte problemer - se listen over certificerede udviklere.
- KontaKt The Document Foundation om at hjælpe dig, hvis du bare har et lille bidrag og du vil samarbejde, koordinere eller slå dine ressourcer sammen med andre i den samme situation for at finansiere bestemte rettelser eller forbedringer.
Gode Rapporter
Minimumskrav
- OS/LibreOffice version;
- nummererede, gentagelige trin;
- enkle vedhæftninger, hvor det er passende; og
- observerede/forventede resultater.
Gode eksempler
- tdf#85004 - Writer: Nedbrud ved klik på ikonet Sæt Påmindelse på værktøjslinjen Navigation
- tdf#87907 - DIALOG: Forhåndsvisning i dialogen Udskrivning opdateres under åbning af Udskrivningsdetaljer
- tdf#74839 - EDITING (redigering): Placeringen af forbindelseslinjer, der er fundet til en gruppe, opdateres ikke under opdatering af gruppens indhold
Eksempler på mindre gode rapporter
Rapporter kan være mindre end ideelle af et antal grunde. Herunder er nogle af de mest almindelige problemer:
Tekst-afsnit
Beskrivelse af fejlrapport i tekst-afsnit er et af de mest almindelige problemer. Udviklere har ikke tid til at læse flere tekstafsnit. Klare, kortfattede, nummererede trin er altid bedre.
En rapport, fem fejl
En rapport bør kun indeholde en enkelt fejl. Gruppering af fejl, eller oplistning af en hel liste af fejl i et enkelt dokument, er aldeles uhensigtsmæssigt. For at finde udviklere til at ordne problemerne, er det bedst at give dem et enkelt problem at fokusere på. De bryder sig ikke at gå i gang med en fejl, der har fler problemer oplistet
Manglende detaljer/trin
Alle fejl fejlrapporter skal i det mindste have:
- dit operativsystem og LibreOffice-version;
- klare, gentagelige trin;
- forventede resultater;
- observerede resultater; og
- en enkelt vedhæftning, når det er passende.
Tilføjelse af overflødig information
Tilføjelse af en masse ekstra detaljer, der ikke er relevante, er det andet almindeligt problem. Eksemplerne omfatter:
- “det er en blokering”;
- en lang liste af grunde til, at det er en blokering;
- “jeg kan ikke bruge LibreOffice på grund af denne fejl”;
- “LibreOffice stinker” (eller enhver variation af det); og
- Jeg begynder at bruge deres konkurrent, hvis I ikke ordner det.
Komplekse vedhæftninger
Vedhæftninger bør være så enkle som muligt. Tag dig tiden til at skære dine eksempler ned til et nøgent minimum. Det hjælper enormt til diagnosticere problemer.
Antagelsen at bidragsydere alting
Antag ikke, at bidragsyderne ved, hvad snakker om. Beskriv dine trin klart, skridt for skridt hele vejen.