如何报告 LibreOffice 中的 Bug

From The Document Foundation Wiki
< QA‎ | BugReport
Jump to: navigation, search

很高兴能在这儿遇到您。看来,您将要为 LibreOffice 作出非常重要的贡献。高质量的 bug 报告对于开发者非常重要。接下来,您将学到整个 bug 提交过程中的一些有用的指导。

不是所有的 bug 都应当在 Bugzilla 中报告

曾经有部电影名字叫 All dogs may go to heaven⁠Wikipedia logo v3.svg, 意思是所有的狗死后都会进天堂。但是,并不是所有的 bug 都应该在 TDF 的缺陷跟踪系统 Bugzilla 报告。有一些 bug 需要报告到其他地方从而被解决,这包括:

Bug 类别 需要在哪里报告
LibreOffice 扩展 报告给该扩展的作者
TDF/LibreOffice 基础设施相关问题(网站,邮件列表等) 报告到 Redmine
与编译 LibreOffice 有关的缺陷 Development/Mailing List
LibreOffice 单元测试 Development/Mailing List

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

先确认,您发现的问题 确实 是个 bug.

如果您确信所发现的问题确实是个 bug, 那么下一步您需要: 1. 做简单的笔记,从而您能够记得 bug 出现时您正在进行什么操作,发生了什么错误情况,正确情况应该是怎么样的?您是怎么知道发生了错误,而不是正确的结果?您能否可靠地重现该 bug?

2. 检查 已有的 bug 报告,看看您遇到的问题别人是否已经上报了

  1. Bugzilla 高级搜索页面:Summary 框输入合适的关键词, Product 选择 LibreOffice,Component 选择 bug 所在部件。其他字段可以留空,也可以根据情况输入,以缩小查询范围。然后点击 Search 按钮进行搜索。进行之前您需要有 bugzilla 的账户并已登录。
  2. 查看搜索结果条目,判断是否有已经报告过的相同或类似的报告。
  3. 如果找到了相同的已经报告过的bug, 您不用再提交新的bug了,直接将自己加入到已报告的bug的cc抄送列表里即可 (Add me to CC list),以便该bug有任何进展时您能随时收到邮件通知。这是因为,QA 团队的人手有限,重复报告 bug 会让有限的精力浪费在没有必要的事情上。

3. 如果没有已报告的bug, 那么进行下一步。

提交 bug

当您发现一个问题,确认是个bug, 在 bugzilla 上也没有找到相同的报告,那么您需要提交新的 bug 报告。请务必确保为每个单独的问题提交单独的报告;在您不确认这是两个问题还是一个问题的情况下,推荐的做法是提交两个不同的 bug 报告。

要提交新的 bug 报告,请进入 TDF官方缺陷跟踪系统,并参考以下步骤:

登录,新建 bug 报告

用您的 TDF Bugzilla 账号登陆,然后点击左上方的 New 链接,以打开新建 bug 报告页面。

选择产品

点击 LibreOffice.

输入 bug 详情

首先,请阅读上方小字部分的说明,尤其是红色加粗的文字,其大意是您提交给 bug 跟踪系统的信息将会被所有人看到,并且无法删除,因此如果您要附加示例文档的话,请务必首先去除保密信息。这一点很重要,否则涉及商业秘密泄露的问题后果会很严重。

Summary:用英文输入该问题的简短描述。描述应当能够反映问题的详细情况,避免模棱两可,避免只说有问题而不说到底有什么问题;尽量包含能反映问题本质的关键词,这样会方便别人搜索时能找到这个问题;对于程序崩溃的问题,Summary 中一定要有 crash 或者 hang 两个词之一,这样才能被更快修复。比如,如果您遇到的问题是在打开打印对话框中的“选项”标签页时程序崩溃,那么您应该写 "Crash if I open the Print dialog and click the 'Options' tab", 而不是 "LibreOffice crashed"。又如,如果您想要提交新功能的建议,那么标题中应当直接描述希望有的功能,而不是只说 "new features" (tdf#114863.

Description:用英文详细扩展一下 Summary 中的内容,说明你是如何发现问题的,发现了什么问题。

Component: 选择出现问题的部件。

Hardware:选择您发现该问题时所使用的计算机体系架构,比如是32位(X86)还是64位(X86-64)。

Operating System:选择出现问题时您所用的操作系统。这里需要注意,如果您只是在 Windows 下遇到问题,而根本没有在其他系统比如 Linux 下测试过是否有问题,那么只选 Windows 即可,千万不要选 All, 那样只会让问题变复杂。

Version: 选择出现该问题对应的最老的软件版本。比如,您能重现该问题是在 5.4.4.2 版本中,那么选择 5.4.4.2;如果您能在 5.4.4.2 上重现,同时您也试了一下之前发布的 5.3.1.2 版本也能重现,那么此处应该选择 5.3.1.2. 这个字段永远显示的是最早出现问题的版本,它将用于查找到底是哪个时间哪个代码提交导致该问题的出现,从而更快修复。记住,在您确认别人提交的bug时,不要将该字段改为更新的版本。

Reproducibility:您能否100%重现该bug,还是有时候能重现,有时候又工作正常。

Severity:问题的严重性。一般情况下,都应该是 Normal. 但是对于基本功能严重不正常的bug,你可以提升严重性等级。

Steps to Reproduce:提供重现步骤,即其他人应该怎么操作,才能99.9%重现这个问题。这里一定要用 1,2,3 的数字编号形式列出步骤,而且对步骤的描述一定要足够精确、简洁。这样能方便别人跟着您给出的步骤进行快速测试。

Actual Results:当前的错误结果。这个很重要,因为某个错误在您的机器和软件版本上显示为1,在别人的机器上可能显示为2。

Expected Result: 期望的结果,即正确的情况下应该出现什么结果。千万不要假定其他人知道一切,即便是很简单的问题,您也一定要说到位,因为如果让别人去猜测,那么100个人对同一个问题会有100种不同的理解。

Additional Information: 提供额外的信息。在这里,您必须复制粘贴“帮助 > 关于 LibreOffice”界面中的信息到这个框里,这些信息包含了重要的信息,以利于判断问题。另外,您必须指出您使用的操作系统类型即版本,比如如果您使用Linux系统,那么指出是 Fedora 27 还是Ubuntu 16.04 LTS,是 Gnome 桌面还是 KDE 桌面。如果是 Windows,那么是 Win10 还是 Win7 或者已经不受支持的 WinXP。您可以包含其他您认为必要的信息。

Did you try resetting your UserProfile:您是否尝试过重置过 LibreOffice 的用户配置文件夹。很多情况下,如果出现问题,将用户配置文件夹重置可能问题会消失。对于 LibreOffice 5.3 及更新的版本,您可以通过菜单项“帮助 > 以安全模式重新启动“来测试安全模式下(模拟的全新用户配置)是否存在相同的问题。对于之前的旧版本,你需要手动重命名用于配置文件夹。Windows XP 下,该文件夹位于 "C:\Documents and Settings\<user name>\Application Data“里;在 Win10下,该文件夹可能位于"C:\Users\<user name>\AppData\Roaming"中。

Is OpenGL enabled: 您是否开启了 OpenGL. 默认情况下,如果可能那么 LibreOffice会开启 OpenGL 进行硬件加速。但是,对于某些有bug的显卡,该选项会存在兼容性问题,比如出现界面图标错位、画屏、闪烁等情况。您可以在“工具 > 选项 > LibreOffice > 视图”中查看是否已开启“为所有渲染启用OpenGL"选项。

Submit Bug Report: 检查上列信息已完整无误,然后单击这个按钮以提交 Bug.

Add an Attachment:如果您需要添加附件,比如一个截图或者一个示例文档,那么需要在点击上述的 Submit Bug Report 按钮创建了bug之后,再点击 Add an Attachment 链接添加。很多时候,说一大堆的话,还不如添加一个截图说的清楚,尤其是当您英文“不咋滴”的时候。

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

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

提交了 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聊天频道里,或者您的个人博客上,或者社交媒体上,都没有问题。

好的 bug 报告

好的bug报告更容易在最短的时间内被修复。其至少需要包含以下信息:

  1. 操作系统及 LibreOffice 的版本号;
  2. 以数字列表形式列出的清晰的重现步骤;
  3. 尽可能简单的 示例文档,用于定位问题;
  4. 包含有期望的结果。

以下是一些好的 bug 报告的范例:

  • 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 报告

  • 大段的文字描述,说了半天没有说出重点,令人头晕眼花。
  • 一个报告里包含5个不同的问题。这5个问题可能的确是相关的,但是从代码的角度来说它们可能属于不同的问题,需要不同的patch去修复。此时,您应该将这5个问题拆分为5个小问题,这样会使问题变得简单,更容易被分别修复。
  • 缺少细节和重新步骤。有些人报告bug,只说有问题,不正常,或者不能工作,而丝毫不说到底哪里有问题,哪里不正常,什么地方不能正常工作,也不说按照什么步骤操作才能发现所说的问题。
  • 夹杂/添加不相关的信息。这样的不相关的信息只会让bug报告变得臃肿,让别人失去兴趣。例如:有些人会描述说”这是个非常严重的bug“,然后列出一系列的理由指出它为什么是个非常严重的bug,或者说由于这个bug我无法使用LibreOffice了,或者得出结论说”LibreOffice真垃圾“,或者”在这个bug没有修复之前我将使用其他Office软件“,等等。
  • 上传复杂的附件。上传的示例文档一定要尽可能简单,这样才能更快定位问题。
  • 假定其他人知道一切。

更多信息