QA/Hlášení chyby

    From The Document Foundation Wiki
    < QA
    This page is a translated version of the page QA/BugReport and the translation is 100% complete.

    TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

    Other languages:

    Jsme rádi, že jste se sem dostali. Můžete významně přispět do LibreOffice. Dobré hlášení o chybě je pro naše vývojáře velmi užitečné. Níže je uvedeno několik pokynů, jak tento proces usnadnit.

    Ne všechny chyby se týkají Bugzilly

    All dogs may go to heaven⁠Wikipedia logo v3.svg, ale některé zprávy o chybách by měly být podány mimo Bugzillu. Tyto zahrnují:

    Druhy chyb Kam nahlásit chybu
    LibreOffice Extensions (rozšíření) Autorovi rozšíření
    Infrastruktura TDF/LibreOffice (webové stránky, e-mailové konference atd.) Redmine
    Kompilace LibreOffice E-mailová konference vývojářů
    Jednotkové testy pro LibreOffice E-mailová konference vývojářů
    Chybějící slova ve slovnících Správce slovníku nebo repozitáře
    Chyby v překladech Jejich nahlášení v Bugzille je povoleno, ale efektivnější je přidat je jako návrhy do Weblate (nevyžaduje registraci).

    Než odešlete chybové hlášení

    Ujistěte se, že skutečně jde o chybu. Bug je většinou něco, co způsobí, že se software chová tak, jak by rozumný uživatel nechtěl, aby se choval. To znamená, že software nedělá to, co chcete, aby dělal, dělá to, co jste od něj nikdy nepožadovali, nebo se prostě při běžném používání zhroutil. Chyba může být také něco, co způsobí, že softwaru trvá provést požadovanou operaci mnohem déle a spotřebuje mnohem více zdrojů, než by měl.

    Některé závady mohou být ve skutečnosti výsledkem poškozeného uživatelského profilu. Problémy s OpenGL (v novějších verzích se podívejte na Skia) a OpenCL jsou obvykle platné chyby. Hodně pomůže, když před napsáním hlášení o chybě zkontrolujete vliv nastavení OpenGL a OpenCL .

    Může se stát, že to, co vypadá jako chyba, je ve skutečnosti spíše požadavek na funkci, přičemž víme, jak by software měl ideálně fungovat, avšak požadovaná funkce ještě nebyla vyhotovena. Naštěstí není třeba se tolik starat o rozlišení mezi chybou a funkčním požadavkem. Pokud je vysledované chování něčím, co narušuje normální a platné používání aplikace, nahlaste to jako chybu.

    Velmi pomohou získané zkušenosti s LibreOffice, díky kterým si vypěstujete cit pro rozpoznání normálního a platného použití. Jistě nechcete trávit mnoho času nahlašováním domnělé chyby, pokud skutečným problémem je, že ještě nevíte, jak určitou funkci používat. Zvažte přečtení uživatelské dokumentace a používejte LibreOffice často, abyste se důvěrněji seznámili s jeho chováním.

    Pokud znáte LibreOffice docela dobře a narazíte na něco, o čem si nejste jistí, zda jde o chybu či chování, kterému nerozumíte, můžete zaslat dotaz do e-mailové konference uživatelů nebo na Ask LibreOffice.

    Pokud vámi nalezené chování vypadá jako chyba, je dobré ji nahlásit. Níže vám ukážeme, jak postupovat:

    1. Pište si poznámky, abyste nezapomněli na něco, co se dělo v době, kdy se chyba objevila. Co jste dělali, co jste očekávali a co se vlastně stalo? Jak jste zjistili, že nastala chyba? Dokážete reprodukovat špatné chování?
    2. Zkontrolujte podobné existující zprávy o chybách (pokud nic nenajdete, klidně nahlašte duplicitní hlášení):
      1. Přejděte na stránku Komponenty a vyberte příslušnou komponentu (nebo dílčí komponentu).
      2. Pokud jste vybrali komponentu: Vyberte příslušnou dílčí komponentu nebo rozšířenou nápovědu, pokud na dané stránce dílčí komponentu nevidíte.
      3. Pokud jste vybrali rozšířenou nápovědu: vyberte příslušnou dílčí komponentu nebo pokud jste příslušnou dílčí komponentu nenašli nebo neznali, vyberte ze seznamu v dolní části [1].
      4. Uvidíte seznam chyb s touto dílčí komponentou. V dolní části stránky vyberte možnost "Upravit vyhledávání". Tam můžete upravit vyhledávání podle svých potřeb.
      5. Pokud najdete hlášení o chybě, které se týká vašeho problému, můžete ho doplnit. Pokud hlášení o chybě, které by se týkalo vašeho problému, nenajdete, podejte novou zprávu o chybě.
    3. Pokud se chyba vyskytne pouze na "Ubuntu" nebo se týká "tisku", přejděte na #Další informace.
    4. Poté, pokud to stále nevypadá, že by pro tuto chybu již existovalo hlášení, postupujte podle pokynů na #Odeslání chyby.

    Odeslání chyby

    Pro každou chybu, na kterou narazíte, podejte samostatnou zprávu o chybě, i když se příznaky z pohledu uživatele zdají stejné. Různé problémy s různým původem, které se objevily v různých verzích LibreOffice, budou možná opravovat různí lidé, pro různé verze a v různých časech. Není možné sledovat vše v jediném bugreportu.

    Přejděte do Bugzilly.

    Přihlášení

    Bugzilla - hlavní stránka

    Pokud jste vyzváni k přihlášení, přihlaste se pomocí účtu v Bugzille.

    Pokud nemáte účet Bugzilla, vytvořte si jej kliknutím na Nový účet.

    Component (komponenta)

    V seznamu Component vyberte komponentu.

    Pokud si nejste jisti, které komponenty se týká váš problém, vyberte komponentu LibreOffice. Někdo později hlášení zkontroluje a vybere přesnější komponentu. (Pro více informací o třídění, pomocí nějž se kontrolují chyby, aby se důležitější dostaly na začátek seznamu, se podívejte na "BugTriage".)

    Pokud se jedná o naléhavý problém (nefunkční části, regrese atd.) a jste zkušený uživatel, který zná vývojový tým, můžete přiřadit hlášení o chybě jednomu z vývojářů uvedených na stránce FindTheExpert.

    Detaily

    Pokud existuje sekce Sub-component, vyberte subkomponentu.

    Pokud neznáte vhodnou subkomponentu, otevřete stránku Components. Na ní klikněte na příslušnou subkomponentu. Přečtěte si popisy všech subkomponent na stránce dané komponenty. Nezobrazuje-li se vhodná dílčí subkomponenta, klikněte na odkaz Extended Help a přečtěte si tam popisy subkomponent.

    Vyberte verzi aplikace, ve které se chyba objevila. Chcete-li zkontrolovat, kterou verzi LibreOffice používáte, vyberte Nápověda ▸ O LibreOffice

    V Operating system nebo OS vyberte operační systém počítače, který jste používali, když jste na chybu narazili.

    Pokud existuje sekce Hardware, vyplňte ji.

    Pokud existuje sekce Severity (závažnost) a vy zadáváte požadavek na vylepšení, vyberte enhancement. Jinak ji ignorujte pokud nemáte dostatek zkušeností. Výběrem Blocker nebude chyba opravena rychleji. Pro zobrazení definic položek v části Severity se podívejte na tento graf.

    Sekci latest known-working version (nejnovější známá funkční verze) můžete ignorovat.

    Summary (Předmět)

    Ověřte možné související chyby v tabulce na stránce hlášení chyb a dále v duplicitních hlášení a zjistěte, zda tento problém opravdu ještě nebyl ohlášen.

    V části Předmět (známé také jako Summary):

    • Nezahrnujte již známé informace z polí.
    • Uveďte názvy subkomponent z přehledu komponent.
      • Pro názvy subkomponent použijte velká písmena.
      • Pokud lze subkomponentu zaměnit s částmi slova (například UI je součástí slova q ui t), dejte název subkomponenty do hranatých závorek.
      • Použijte maximálně dvě subkomponenty.
      • Používejte subkomponenty přesně tak, jak jsou uvedeny v seznamu, ale můžete je integrovat do věty předmětu, jako například „WIKIHELP [UI] not available in all languages“.
    • Shrňte problém co nejpřesněji.
      • Špatný příklad: „File is broken“ (český překlad: „Soubor je poškozen“).
      • Lepší příklad: „Menu File > Save as not available (greyed out)” (český překlad: „Nabídka Soubor> Uložit jako není k dispozici (zašedlá))“.
    • V anglickém jazyce se vyhněte krátkým formám jako „doesn't“ nebo „isn't“. Abyste usnadnili dotazování na řetězce v Summary, použijte místo toho nezkrácenou formu, například „does not“ nebo „is not“.
    • Pokud je problém napsaný ve zprávě v tom, že LibreOffice „havaruje“ nebo přestane reagovat („zablokuje se“), přidejte do souhrnu slovo „CRASH“, aby tyto chyby bylo možné snadno lokalizovat a sledovat.

    Popis a přílohy

    V části Dlouhý popis nebo Popis zadejte delší a věcný popis problému:

    • uveďte seznam kroků k reprodukci chyby;
    • použijte číslovaný seznam;
    • uveďte přesný postup k vyvolání akce. Například namísto věty „Otevřít dokument“ napište „V novém prázdném dokumentu LibO Spreadsheet použijte nabídku Soubor > Otevřít (dialog LibO) > typ souboru „Textové dokumenty“ > vyberte připojený ukázkový dokument > dvakrát klikněte“.

    Pokud používáte předinstalovaný LibreOffice v systému Linux, uveďte přesné verze balíčků LibreOffice v systému správy balíčků. Pokud používáte Windows, uveďte přesný název instalačního souboru a odkud byl stažen.

    • Užitečné může být zahrnutí informací o nainstalované a použité lokalizaci (jazyk uživatelského rozhraní, jazyk dokumentu).
    • Uveďte, zda je v 64bitovém (Linux) systému použit 32bitový LibreOffice.
    • Pokud sestavení LibreOffice není oficiální, uveďte zdroj balíčku.

    Popište očekávané chování a skutečné chování.

    Můžete přidat přílohu, například snímek obrazovky nebo dokument, ve kterém se chyba vyskytla. Typickým způsobem pořízení snímku obrazovky je stisknutí klávesy „Print Screen/PrtScn“. V závislosti na operačním systému budete možná muset otevřít aplikaci pro úpravu obrázků (například Malování ve Windows) a v ní provést Edit - Vložit.

    • Pokud vytváříte snímky obrazovky, před vytvořením snímku přepněte jazyk na angličtinu. Můžete tak učinit v okně Možnosti (Nástroje ▸ Možnosti ▸ Jazyková nastavení ▸ Jazyky).
    • Snímky obrazovky budou užitečnější, pokud přidáte komentáře a označíte příslušné oblasti (například pomocí LibreOffice Draw).
    • Pokud chcete připojit více než jeden snímek obrazovky, měli byste je všechny shromáždit v jednom dokumentu (zkopírovat/vložit do dokumentu LibreOffice Draw) a připojit jako PDF. Ke každému snímku obrazovky přidejte krátký komentář a uveďte, co jím chcete demonstrovat.
    • Pokud připojíte ukázkový dokument, který vykazuje chybu, kterou hlásíte, vytvořte dokument co nejmenší. Například pro chyby ve Writeru by měl dokument v ideálním případě obsahovat pouze jeden odstavec. Chcete-li usnadnit nalezení textu z dokumentu při trasování ladění, použijte nějaký velmi snadno rozpoznatelný text, například AAAAAAAAAA ₂ ZZZZZZZZZZ pro chybu, která je tímžo znakem vyvolána.
    • Je lepší nahrávat přílohy jednotlivě. Pokud však chcete připojit větší počet dokumentů, vytvořte soubor *.zip, obsahující všechny dokumenty, a připojte jej.
    • Pokud je vaše příloha příliš velká na to, aby mohla být v Bugzille připojena (větší než 1 MB), můžete použít Experimental upload page.

    Status

    Stav reportu na NEW byste měli měnit pouze tehdy, pokud již někdo chybu potvrdil někde jinde (fórum Ask, e-mailová konference, nějaké jiné fórum). V těchto případech uveďte odkaz na diskusi, v níž byla chyba nahlášena.

    Submit (Odeslat)

    Pro přidání vašeho hlášení do databáze Bugzilly stiskněte tlačítko Submit (Odeslat).

    Pokud se zdá, že je Bugzilla nesrozumitelná

    Pokud se vám systém sledování chyb Bugzilla zdá být nesrozumitelný nebo příliš těžko pochopitelný, zkuste svůj problém zveřejnit zde:

    I když svůj problém zveřejníte na těchto kanálech, vaším cílem by mělo být dodat dobrý bugreport do Bugzilly. Tyto kanály vám s tím mohou pomoci. Všimněte si, že hlášení problémů na sociálních médiích (Facebook, Twitter atd.) není obecně produktivní, protože zřídka vede k dobrému reportu, který by skončil v Bugzille (viz také: 99 způsobů, jak zničit open-source projekt, top 5).

    Po odeslání chyby

    Pokud nikdo v přiměřené době (24 hodin pro kritickou chybu, 14 dní pro žádost o vylepšení) vaši zprávu neposoudí, zvažte, zda požádat někoho dalšího, aby chybu reprodukoval, na help/mailing-list/users@global.libreoffice.org e-mailové konferenci nebo IRC kanále #libreoffice IRC://.

    Přidávání komentářů k chybám

    • Vyvarujte se zveřejňování komentářů typu „já také“ bez dalších užitečných informací.
      Výjimkou je komentování chyby, která dosud nebyla potvrzena (je ve stavu UNCONFIRMED). V takovém případě uveďte reprodukční kroky (nebo potvrďte kroky poskytnuté původním oznamovatelem) a nastavte hlášení status NEW (NOVÝ). V případě, že kroky k reprodukování chyby nejsou jasné, může se bug rychle vrátit zpět do stavu NEEDINFO, proto je nezbytné poskytnout dobrý a jednoduše reprodukovatelný postup k vyvolání chyby.
    • Vyhněte se přidávání komentářů typu „máme zde 1000 stanic a pouze tato chyba nám brání v migraci“, protože neobsahuje žádné další informace týkající se QA nebo priority problému.

    LibreOffice je open source (s otevřeným zdrojovým kódem) a vaše pomoc při řešení problémů, které jsou relevantní pro vaši konkrétní situaci, je velmi vítána. Můžete:

    • Zaměstnat a/nebo naučit své vlastní vývojáře, aby pracovali na LibreOffice. Velmi rádi je budeme mentorovat: viz vývojářské stránky.
    • Financovat jednotlivce nebo společnosti, aby pracovali na konkrétních problémech - viz seznam certifikovaných vývojářů.
    • Kontaktovat nadaci The Document Foundation, aby vám vypomohla, pokud máte jen malé množství finančních prostředků a chcete spolupracovat, koordinovat nebo sdružovat své zdroje s ostatními ve stejné situaci a financovat konkrétní opravy nebo vylepšení.

    Dobrá hlášení

    Minimální požadavky

    1. Verze OS/LibreOffice;
    2. číslovaný seznam reprodukovatelných kroků;
    3. kde je to vhodné, jednoduché přílohy;
    4. pozorované/očekávané výsledky.

    Příklady dobrých zpráv

    • tdf#85004 - Writer: Crash when clicking the Reminder icon on the Navigation toolbar
    • tdf#87907 - DIALOG: Page preview in print dialog refreshes when opening print details
    • tdf#74839 - EDITING: Position of connectors connected to a group aren't updated when editing group content

    Příklady méně dobrých zpráv

    Zprávy nejsou vždy ideální, a to z několika důvodů. Níže jsou uvedeny některé běžné problémy:

    Odstavce textu

    Popis chybového hlášení v odstavcích textu je jedním z nejčastějších problémů. Vývojáři nemají čas číst odstavce textu. Jasné, stručné a vyjmenované kroky jsou vždy lepší.

    Jedna zpráva, pět chyb

    Jeden bugreport má obsahovat pouze jednu chybu. Seskupování chyb nebo vypisování celých seznamů problémů v jednom dokumentu je naprosto neužitečné. Chcete-li najít vývojáře, kteří se začnou něčím zabývat, je nejlepší dát jim jediný problém, na který se mají zaměřit. Není pravděpodobné, že by začali pracovat na opravě chyby, která obsahuje problémů více.

    Chybějící podrobnosti / kroky

    Všechny zprávy o chybách by měly obsahovat minimálně:

    1. operační systém a verzi LibreOffice;
    2. jasné opakovatelné kroky;
    3. očekávané výsledky;
    4. pozorované výsledky;
    5. případně jednoduchou přílohu.

    Přidávání nadbytečných informací

    Dalším častým problémem je přidání informací, které nejsou relevantní. Například:

    1. „Toto je blokátor“;
    2. dlouhý seznam důvodů, proč se jedná o blokátor;
    3. „Nemohu použít LibreOffice kvůli této chybě“;
    4. „LibreOffice mě štve“ (nebo jakákoli jeho variace);
    5. začnu používat vaši konkurenci, pokud to neopravíte.

    Složité přílohy

    Přílohy by měly být co nejjednodušší. Věnujte čas na očištění příkladů na holé minimum. Velmi to pomáhá při diagnostice problémů.

    Předpoklad, že přispěvatelé vědí všechno

    Nepředpokládejte, že přispěvatelé vědí, o čem mluvíte. Popište jasně své kroky, každý krok postupu.

    Další informace

    Retrieved from "https://wiki.documentfoundation.org/index.php?title=QA/BugReport/cs&oldid=710687"