质控/缺陷报告

    From The Document Foundation Wiki
    < QA
    This page is a translated version of the page QA/BugReport and the translation is 91% complete.
    Outdated translations are marked like this.

    文档基金会 LibreOffice官网 Document Liberation 项目 社区博客 Weblate翻译 Nextcloud Redmine Ask LibreOffice 问答 捐助

    Other languages:

    很高兴您能来到这里。看来您将要为 LibreOffice 做出非常重要的贡献。优质的 bug 报告对于开发者很重要。在这里，您将找到一些有用的指南，遵循这些指南将会使得 Bug 报告和处理的流程变得容易。

    并非所有的 bug 都是在 Bugzilla 上报告

    所有的狗都上天堂⁠Wikipedia logo v3.svg, 但并不是所有的 bug 报告都应该归属于 Bugzilla. 有些 bug 需要在其它地方报告，这包括：

    Bug 类别 在哪里报告
    LibreOffice 扩展程序 报告给扩展程序开发者
    TDF/LibreOffice 基础设施（网站、邮件列表等） Redmine
    构建（编译）LibreOffice 开发者邮件列表
    LibreOffice 单元测试 开发者邮件列表
    Words missing from dictionaries To the dictionary maintainer or repository
    Mistakes in translations Reporting them in Bugzilla is allowed, but it is more efficient to add them as suggestions in Weblate (does not require registration)

    在提交 bug 之前，您必须知道

    确认您想要报告的问题确实属于软件缺陷。很多时候，软件缺陷（Bug）是指软件所呈现出来的行为不是一个合理的用户想要看到的行为，这包括软件没有按照您期望的方式工作，没有按照您指示它的方式工作，或者是在正常使用过程中崩溃。再或者，软件可能需要花费过多的时间、耗费过多的系统资源完成本该在很短时间内、耗费很少资源就能完成的工作。

    其中的一些故障可能是由于损坏的用户配置文件导致的，或者是由于 OpenGL (在较新的版本中可能是Skia) 或 OpenCL 问题导致的，这些通常情况下都是有效的 bug。报告 bug 之前进行 OpenGL 和 OpenCL 设置方面的检测和排除，通常是很有用的。

    在某些情况下，一些问题看起来更像是“功能改进建议”，在这种情况下我们知道软件应该工作地更完美，尽管该项功能目前还没有在软件中实现。然而，您大可不必纠结某个问题到底是属于功能改进建议还是软件缺陷。如果某项行为干扰了您正常合理地使用软件，那么您完全可以将其报告为 bug.

    您应该花一些时间尽量去熟悉 LibreOffice 的基本使用方法，从而对什么是“正常、合理”地使用软件有一个正确的判断。您肯定也不希望花太多时间去将某个行为报告为bug、但实际上这个行为可能只是因为您不知道如何使用某项功能。您可以阅读用户文档，并频繁使用软件，从而熟悉软件中的一些基本的使用方法。

    如果您对 LibreOffice 很熟悉，在这种情况下仍然遇到了某个看上去像 bug 的情况，但是不确定到底是不是 bug，那么您可以在 LibreOffice 用户邮件列表或者LibreOffice 中文社区论坛上发帖求助。

    如果您确信所发现的问题确实是个 bug, 那么下一步您需要：

    1. 做简单的笔记，从而您能够记得 bug 出现时您正在进行什么操作，发生了什么错误情况，正确情况应该是怎么样的？您是怎么知道发生了错误，而不是正确的结果？您能否可靠地重现该 bug?
    2. 如果可能，请尝试检查类似的、已有的 bug 报告，看看您遇到的问题别人是否已经上报了（但你需要避免在这一步花费太多时间，提交一个重复的bug报告总比放弃要好）：
      1. 到 Components, 选择合适的部件（或子部件）。
      2. 如果您选择了部件：紧接着选择合适的子部件。如果在该页面上没有找到子部件，请选择扩展帮助。
      3. 如果您选择了“扩展帮助”：选择合适的子部件；如果您找不到或者不知道合适的子部件，请参考该列表底部的[1].
      4. 此时您会看到该子部件下的 bug 清单。在页面底部，选择 Edit Search。在该界面您可以根据需要编辑搜索条件。
      5. 如果在该清单中能找到您关注的问题，那么把自己添加到这个 bug 的 cc 抄送列表中，并为为这个 bug 报告提供线索。如果在这个清单中没有找到您关注的问题，那么您可以新建一个 bug 报告。
    3. 如果该 bug 只在 Ubuntu 操作系统上能重现，或者与 打印有关，请参考#更多信息章节。
    4. 经过所有这些，如果看起来没有关于这个问题的 bug 报告，那么请遵#提交 bug 章节的相关说明。

    提交 bug

    请务必为每一个单独的缺陷行为提交一个单独的 bug 报告，尽管从用户的角度来看这几项行为看起来是同一个问题。不同的 LibreOffice 版本中出现的不同问题，可能是由不同的原因导致的，这些问题需要由不同的人在不同的版本中在不同的时间去各自修复。在同一个 bug 报告中追踪这些不同的问题是不可能的。

    转到 Bugzilla.

    登录

    Bugzilla - Main page

    在弹出登陆界面时，使用您的 Bugzilla 账户进行登陆。

    If you don't have a Bugzilla account, create one by clicking New Account.

    选择产品

    在 Component 字段，选择合适的部件。

    如果您不确定应该选择哪个部件，那么就选择 LibreOffice 这个部件。审阅这个 bug 报告的志愿者之后会帮您修改为最合适的部件。（更多信息，请参考 “Bug 整理”页面，“Bug 整理”是指对已经报告的 bug 进行审阅诊断，从而使得将重要的 bug 在列表中能够排列在前面的过程。）

    如果这个问题比较紧急（例如某些部件无法正常工作，属于一个倒退问题，等等），并且您使用 LibreOffice 的经验比较丰富，而且认识开发者团队，那么您可以将这个 bug 指定（assign）给 FindTheExpert 页面中列出的某个开发者。

    输入 bug 详情

    如果存在 Sub-component，请选择合适的子部件。

    如果您不知道合适的子部件，请转到 Components 页面。在该页面的目录部分单击合适的子部件，从而转到相应的描述。仔细阅读相应的描述，从而确定您要报告的问题应该属于哪个子部件。如果找不到合适的子部件，请点击页面上的扩展帮助，并阅读打开的页面上的提示。

    选择能重现该 bug 的软件版本。要查看您的 LibreOffice 软件版本，请到 帮助 ▸ 关于 LibreOffice

    在 Operating system（操作系统） 或 OS 字段，选择该 bug 出现时您使用的操作系统。

    如果出现 Hardware（硬件） 字段，请填写该字段。

    如果有 Severity（严重性） 字段，您可以忽略它，除非您是很有 bug 报告经验的用户。将严重性设置为 Blocker 级别并不会让这个 bug 修复变得更快。要了解该字段下每个选项的含义，请参考 这张图。

    您可以忽略 latest known-working version 字段（如果有这个字段的话）。

    标题

    在 bug 报告页面出现的 possibly related Bugs（可能相关的 bug） 表格中，检查您要报告的 bug 是否与其中某个相同。另外也请在重复的 bug 排行榜中检查您要报告的 bug 是否与其中的某个重复。

    在 Subject（标题） 字段（也叫“Summary 概述”字段）中：

    • 请不要在该字段包含 bug 报告的字段中本身已经包含了的信息。
    • 请在该字段包含 Components 页面中列出的合适的子部件名称，以方便 bug 整理和修复。
      • 子部件的名称请使用全部大写，比如 FILEOPEN（而不是FileOpen或Fileopen）
      • 如果某个子部件容易与某个单词的一部分混淆（比如，UI 属于单词 quit 的一部分），您可以将子部件的名称用方括号[]扩住。
      • 最多使用两个子部件。
      • 只使用列表中列出的子部件名称。但是，您可以将该子部件的名称“集成”到一个句子里，比如："WIKIHELP [UI] not available in all languages".
    • 在该字段，您应该非常精简而且准确地概括一下您要报告的问题（其实学好语文真的很重要）。
      • 不太好的例子："File is broken (文件损坏了)"
      • 好一些的例子："Menu File > Save as not available (greyed out)" (文件 > 另存为 菜单不可用（显示为灰色）)
    • 尽量避免简写形式（比如 "doesn't" 或者 "isn't"）。为了便于其他人搜索，您应当使用完整单词进行表达（比如 "does not" 或者 "is not"）.
    • 如果报告的问题类似于 LibreOffice 崩溃 (crashes) 或者停止响应 ("hangs"), 那么请在该字段中包含 CRASH关键词，从而使得这类 bug 能够被尽快定位从而修复。

    描述及附件

    在 Description（描述） 字段，提供一段相对完整的、事实性的描述，以说明该问题（请务必使用英文进行描述，英文实在太滥的话，在谷歌翻译中用标准中文句子敲进去然后把翻译的英文复制过来，远比用中文在 bugzilla 上报告要强，至少别人能看懂个十有八九）：

    • 列出这项 bug 能够重现的步骤；
    • 在重现步骤中，务必使用阿拉伯数字 1,2,3 对每个步骤编号；
    • 准确描述要让某项事情发生时需要进行的操作。例如，不要写 "Open document （打开文档）"，把它写成 "In new empty LibO Spreadsheet document, use menu File > Open (LibO dialog) > file type "Text documents" > select attached sample document > double click" (在空白 LibO 电子表格 文档中，使用“文档 > 打开（LibO 对话框）> 文档类型 "文本文档" > 选择附件中的示例文档 > 双击")。

    如果您是在 Linux 下使用 LibreOffice 的某个预发布版本，那么请列出您的操作系统的包管理器中该 LibreOffice 版本的准确版本号和包名。如果您使用的是 Windows, 请列出完整的安装包文件名，并指出您从何处下载的该安装包。

    • 给出已安装的和正在使用的语言包（界面语言、文档语言），这些信息会很有用。
    • 指出您是否在 64 位 (Linux) 操作系统上使用 32 位软件版本。
    • 如果不是由 LibreOffice 官方编译的版本，请指明软件包的来源。

    写明您期望的行为和结果，以及当前观察到的行为和结果。

    您可以包含附件，例如屏幕截图、示例文档等。

    • 如果提供截图，请先将 LibreOffice 的界面语言切换成英文再截图（工具 ▸ 选项 ▸ 语言设置 ▸ 语言）
    • 您可以使用 LibreOffice Draw，把截图复制进去然后添加文字注释以及图形标记，这样更容易让别人理解。
    • 如果想要提供多个截图，您可以将这些截图复制粘贴到同一个 LibreOffice Draw 绘图文档中，导出为一个 PDF 文档然后添加到 bug 报告中。在每个截图中，添加一段文字注释，以说明每个截图分别是什么，用这张图想要说明什么问题。
    • 如果您要为 bug 报告添加一个示例文档，请尽可能将该示例文档制作成“最小的”。例如，对于文本文档，这个示例文档如果只有一段文字就能让 bug 重现那就最好了。为了使得在 bug 调试过程中更容易找到您文档中的文字，您可以在示例文档中使用一些容易识别的文字，比如 AAAAAAAAAA ₂ ZZZZZZZZZZ（假设这项 bug 是由这些文字引起的）。
    • 附件最好一个一个添加。但是，如果您想要添加几十个附件，那么请提供一个.zip压缩包。
    • 如果附件太大无法添加到 Bugzilla上（大于 1 MB），您可以尝试使用实验性上传页面。

    状态

    通常您不需要修改 status（状态）字段。您唯一需要将该字段标记为 NEW 的情形是，该 bug 已经在别的地方被别人确认过能重现了（比如在 Ask 上，LibreOffice 中文社区论坛上等）。在这种情况下，请提供论坛中有关这个 bug 的链接。

    提交

    点击 Submit（提交）, 此时您的 bug 报告将被成功提交到 Bugzilla 数据库中。

    如果您感觉在 Bugzilla 上提交 bug 太困难

    提交 bug 的首选途径是 TDF 的官方 Bugzilla。但是，如果您实在不想在那里提交，那么：

    尽管您通过这些渠道报告了问题，但是您的最终目的应当是在 bugzilla 上提交一个有效的 bug 报告，而这些渠道可以帮助您梳理思路并提交优秀的报告。需要注意的是，在社交媒体上 (Facebook, Twitter，微博，朋友圈) 中报告问题通常情况下没有任何用处，而且一般不会带来任何的 bugzilla上有效的 bug 报告。（另请见：毁灭一个开源项目的 99 种方法：前 5 种）。

    提交了 bug 之后

    如果您提交的bug在过了很久之后仍然无人问津（例如，对于严重的 bug 在过了24小时之后，或者对于功能改进建议提交了14天之后），那么请考虑主动联系其他人让其尝试重现您报告的bug，比如通过 users@global.libreoffice.org 邮件列表，或者 IRC 频道 #libreoffice connect via webchat，或者LibreOffice 中文社区

    在 bug 中添加评论

    • 避免使用 "me too" 这样的没有任何意义的评论。任何评论在提交之前都要确保其能提供更加有价值的信息，否则就等于给大家制造麻烦，因为一个bug报告里的杂乱信息太多时，开发者可能根本就没有耐心看下去了。但是，例外情况是，对于尚处于UNCONFIRMED状态的bug，您可以提交评论说明您也能重现该bug，并指出您的重现步骤、软件版本、操作系统等额外信息，然后将bug标记为NEW.
    • 避免发布例如“我们公司有 1000 台电脑想要安装 LibreOffice，唯有这个 bug 导致我们没法迁移”这样的评论，这样的评论对于 bug 修复本身没有任何意义，只能使得 bug 报告更加杂乱，没有头绪。您可以在社区论坛里发布这样的抱怨，或者IRC聊天频道里，或者您的个人博客上，或者社交媒体上，都没有问题。

    LibreOffice 是开放源代码的软件，我们很希望能在解决特定问题方面获得您的帮助。您可以：

    • 雇佣或者教您自己的开发者为 LibreOffice 工作。我们会很乐意指导他们，见：开发者页面。
    • 资助个人或企业以解决特定的问题。见：经认证的开发者。
    • 如果您有一笔小额资金，想要拿这笔资金与其他人的资助一起为解决某个特定的问题而捐赠，那么请联系文档基金会。

    优秀的 bug 报告

    最低要求

    1. 操作系统/LibreOffice 版本信息；
    2. 编号的重现步骤；
    3. 最好有 简单的 示例文件；以及
    4. 当前的行为和结果 / 期望的行为和结果。

    优秀报告样本

    • 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

    不太好的报告示例

    Bug 报告会因为许多问题而不尽人意。以下是一些常见的毛病：

    大段的文字叙述

    Bug 报告中最常见的问题是：大段的文字描述，说了半天没有说出重点，令人头晕眼花。开发者根本没有时间去阅读很长的文字。简洁明了、带有编号步骤的描述会更好一些。

    一个报告，5 个问题

    比如，有些人会在一个报告里描述 5 个不同的问题。这 5 个问题可能的确是相关的，但是从代码的角度来说它们可能属于不同的问题，需要不同的 patch 去修复。此时，您应该将这这个 bug 报告拆分为 5 个小问题，分开报告，这样会使问题变得简单，更容易被分别修复。

    缺少细节和重现步骤

    有些人报告bug，只说有问题，不正常，或者不能工作，而丝毫不说到底哪里有问题，哪里不正常，什么地方不能正常工作，也不说按照什么步骤操作才能发现所说的问题。

    所有的 bug 报告 至少 应当包含以下信息：

    1. 您的操作系统和 LibreOffice 版本；
    2. 清晰的重现步骤；
    3. 期望的行为或结果；
    4. 当前观察到的行为或结果；
    5. 一个简单的示例文档，从该文档中能重现该 bug.

    添加无关的信息

    常见的另外一个问题是，向 bug 报告中添加过多的额外细节，但这些细节与该 bug 无任何关联。比如：

    1. "this is a blocker"（这是个blocker）;
    2. 列出了一大堆的理由说明这为什么是个 blocker;
    3. “由于这个 bug，我无法使用 LibreOffice”;
    4. “LibreOffice 烂透了”（或者其他的类似语言）；
    5. “你们不赶紧把这个问题修复的话，我就要用你们竞争对手的软件了。”

    过于复杂的附件

    上传的示例文档一定要尽可能简单，这样才能更快定位问题。请尝试将您提供的测试文档做成“最小化”的，这将对修复问题提供巨大的帮助。

    假定参与贡献的人知道一切

    千万不要假定查看这个问题的贡献者们肯定知道您在说什么。请务必通过清晰的步骤明确描述问题。

    更多信息

    Retrieved from "https://wiki.documentfoundation.org/index.php?title=QA/BugReport/zh-cn&oldid=685932"