How to file a bug report/zh-cn

文档摘要:

目的: 以易懂的方式描述汇报错误的步骤.

目标群体: 对于错误汇报不熟悉的 Linux 用户

假设： 用户运行的是 Fedora Linux，有互联网连接，并且掌握一般的计算机软件使用.

相关文档： Bugs and feature requests

Note: This page is intended to be more beginner friendly than Bugs and feature requests, and includes less technical information. Hopefully, this page won't scare away a new user as the other might.

主要撰写者: danielsmw

= 如何提交一个bug=

这个页面描述了向Fedora开发者们提交软件Bug的流程. bug的定义是："在程序设计中的术语，是指在软件运行中因为程序本身有错误而造成的功能不正常、死机、数据丢失、非正常中断等现象. " (维基百科). 当前文档针对Fedora使用的Red Hat's Bugzilla system. 但用户也很可能可以找到对其他Bug反馈系统（Bugzilla implementations）上Bug的提交有帮助的信息.

Bug报告是Fedora改进软件质量的重要组成部分. 没有用户反馈，许多问题将无法解决，因此学习使用Bugzilla反馈工具是一个重要的用户技能. 注意：不是所有您在Fedora中使用的东西都是Fedora项目和包维护者的责任范围. 例如，如果您正在使用ForbiddenItems，那么您不应该就这个问题向Fedora开发者提交Bug. 如果您安装了非Fedora包管理器中的源，您同样也不应该向Fedora提交相关的bug报告.

Fedora是一个操作系统，而且并不是您计算机上的每一个程序都由Fedora项目拥有且负有责任. 请在填写bug报告前检查ForbiddenItems清单. 任何在该清单上的程序或工具的问题都无法由Fedora项目组解决.

= 为什么我们提交Bug =

作为最终用户，遇到妨碍您工作/娱乐的bug往往是令人沮丧的经历. 大部分时候，忽略bug并仅仅找一条能完成工作的不同的方法是一条有效的用户经验. 但从长远眼光看，不去报告bug意味着您遇到的问题将永远得不到解决. 不同于许多人在大的软件公司报告bug的经验，开源软件用户会发现软件开发者会对bug报告进行回复并通过电子手段与您联系.

这对您意味着什么呢？这意味着通过报告bug，您可以确切的知道，您的体验被开发者关注. 您提交的bug可能不会被立即修复，但维护您使用的软件的程序员将会了解您报告中提到的问题，并在未来修复您提交的问题.

= 创建Bugzilla账户 = Bugzilla是一个开源的bug跟踪工具，它用于管理用户提交的问题、缺陷和功能障碍. Bugzilla一般可以用web界面访问-也就是说，您通过您的WEB浏览器访问，因而您不需要下载任何新的软件. 要在Bugzilla上提交一个Bug，您需要首先创建一个用户账户. 注意：如果您没有在三天内单击Email中的确认链接，您将需要从头开始您的申请.
 * 1) 打开您的浏览器，并访问 bugzilla账户创建页面.
 * 2) 用您经常使用的Email地址请求一个账户
 * 3) 检查您的电子邮箱，知道您收到一封账户创建确认邮件
 * 4) 单击该邮件中的地址，填写并提交浏览器导航到的表单.

当您创建了一个账户后，您就可以用您的email地址和密码登录到Bugzilla了.

= 收集您要提交的信息 = 在您提交一个bug之前，请您尽可能多的收集希望我们知道的信息. 在您收集信息的时候，请确保至少让我们知道：
 * 这个bug已经被报告过了吗？
 * 您想抱怨的软件名称和版本
 * 当bug发生时您正在做什么？您准备去做什么？出现了什么问题？（如果有错误代码，请您一定告诉我们错误代码）
 * 您使用的操作系统（以及版本）以及
 * 您计算机的[指令集架构].

另外，只有在极为少数的情况下，开发者只需要弄明白上面这些问题就可以解决您报告的问题. 请您考虑报告bug时附上其他的信息，例如：问题产生时您正在运行的其他程序，任何可能与您运行的程序交互的外设（如打印机，扫描仪，相机等），与其他软件同时出现问题（其他程序在您运行的软件出现问题的同时也出现了问题），以及出现错误的日期与时间. 开发者知道的越多，就有越多的帮助他们定位故障原因的线索.

避免重复的bug报告
有时，您能找到的最重要的信息是您发现的bug是否已经被其他用户报告过. 当同样地报告在bugzilla上报告过多次时，开发者的效率会降低，因为他们需要重复的阅读同样地bug报告. 在Bugzilla系统中，请使用搜索功能来查找任何您要报告的bug的信息.



当您登录到Bugzilla后，查看您的常用任务(Most Common Actions)面板(界面左侧)，并单击“查找已有Bug(Search Existing Bugs)”(请参见“提交Bug报告”项下的图). 当令找到搜索表单后，您能使用不同的选项和不同的关键字来搜索符合您问题的bug. 高级搜索页提供了更多的灵活性，但它非常复杂. 您看到的简单的表单应当能够胜任大多数的验证bug报告存在性的任务. 在产品(product)中选择(Fedora)——除非您确信其他的选项更为合理.

确认一个bug是否已经被提交的步骤很容易被忽略. 如果这使您产生困扰，提交一个bug报告永远比仅仅是忽略它要好. 但是，开发者会被海量的重复bug报告淹没，所以在提交您的bug报告前，考虑搜索一下现有的bug库.

寻找共有信息
您的bug报告几乎永远需要包括上述信息，经常性的，您需要提交附加信息. 确定如何取得bug数据是非常重要的. 这可能包括打开一个终端. 要在Gnome中打开一个终端，请单击Applications->System Tools->Terminal
 * 软件版本: 对于图形化程序，版本号经常会在"帮助"菜单中出现. 对于一个命令行工具，程序的man手册应当会告诉您用何种参数能使得程序报告它的版本号(经常是在命令后加上 ). 要查看man手册，请输入：  ， 是您正在检查的程序.
 * 操作系统: 有很多方式来确定您的操作系统（和版本）, 在终端中使用  是确定的一种方式.
 * 指令集架构: 有许多种方式用于确定您的计算机的指令集架构，其中的两种是在终端中使用  或  命令.

要运行上面的命令，如： ，只需要打开一个终端窗口，键入完整的命令并按下[ Enter ].

重现错误
很多时候，您发送给开发者的信息是不够的. 要理解“引擎盖下”发生的事情，可以说，开发者需要在自己的机器上重现您报告的错误. 因此，准备好给开发者逐步的指导，以告知他应当如何重现这个错误. 如果您认为这个错误仅仅是与这个程序相关，那么一个不错的开始点是从程序开始运行说起.

逐个描述您单击了什么东西的过程可能是不必要的，重要的是，您应当概述如何使您报告的错误出现. 例如：命令程序打印文档可能有不同方法，或许有一个快捷键；一个菜单项；一个快捷按钮……您需要告诉开发者哪个方法产生了错误.

= 提交Bug报告=

当您成功登陆Bugzilla系统并且收集到了必要的数据之后，您可以开始提交bug报告了. 再次提醒：请确认您要提交的报告还没有被其他人提交.

当您在https://bugzilla.redhat.com登陆后，您应当可以看到常用任务侧边栏，单击"Enter a new bug report".

当您开始填写bug报告后，您会被提示选择您要报告bug的项目. 如果您遇到的bug是关于Fedora Linux的，那么在这里您应当选择"Fedora"，下一步将呈现您选择的项目的问题分类. 如果您发现了软件bug，您应当仅仅单击"Fedora". 每个项目都有一个短标题来帮助您选择. 例如：如果您发现了文档的错误，您应当单击"Fedora Documentation"

如果由于一些原因，您确实不清楚应当如何分类您的bug，请不要放弃，您可以将它提交到任何分类下面，如果有必要，开发者将会搞定分类问题的.

当您选择了您的bug分类后，您将需要填写实际的bug报告. 有两种方式来完成这一步：您可以使用标准表单或向导表单. 标准表单没有向导表单那么多的信息，但如果您知道每一步应当填写什么的话，它比向导表单要容易使用. 推荐新用户使用向导表单.

无论您使用哪种方法，请确认您整理了所有的您之前收集的信息，并开始填写表单.

向导表单
向导表单对提交bug需要填写的内容提供了单步指引. 默认情况下，您看到的是标准表单. 要切换到向导表单，单击标准表单第二段中的"Guided"链接("You may also use the Guided bug entry page for a easier step by step method.").向导表单包括三个步骤.

第一步，决定您要提交的bug是否已经被报告. 第一步帮助您搜索已经记录的bug来确保您要提交的bug还没有在Bugzilla上注册.

第二步， 您需要输入要提交的Bug的详细信息，按照如下顺序输入：


 * Component : 选择给您造成麻烦的软件. 根据您要提交的bug，这可能是一个应用程序，一份文档，或Fedora的其他组件.
 * Hardware Platform : 请在这儿填入我们先前确定的硬件架构. 如果处于一些原因，您无法确定您的平台，您可以选择i386；但是——请确认您已经尽了最大努力去确认您的硬件架构.
 * URL : 这是一个可选项目，不需要处理——除非它呈现给您.
 * Summary : 输入一个能描述问题的简短的句子. 如：“用.tiff文件格式保存文件导致程序退出"
 * Details : 这是您的问题的更长的描述. 越精确越好. 确保给予一个合理的，完整的问题描述；仅仅写上"打印按钮坏掉了"并没有精确的描述问题——而且很可能无助于解决问题.
 * Reproducibility : 这是一个非常重要的区段，按照您给出的步骤是每次都能导致问题产生？或者这个问题只在星期二产生？它只发生了一次吗？
 * Steps to Reproduce : 我们之前讨论过，请在这一步填上重现这个bug的步骤. 如果这个问题您无法重现，在Reproducibility中写上，并尽您的最大努力回忆问题产生时您的操作.
 * Actual Results : 当bug产生时，产生了什么问题？有错误代码吗？有错误提示框吗？您从哪知道不对的？
 * Expected Results : 您期待发生什么？（当它正确运行时）
 * Additional Information : 任何您认为开发者需要知道的内容. 或许是终端输出的一条错误信息. 或者当bug发生时您连接的相机.
 * Severity : 当您报告问题的严重程度的时候，请保持冷静，尝试客观的描述问题. 试着记住：尽管错误打搅了您，但他可能并不是一个大问题. 每个严重级别都有一个标题来帮助您确定.
 * Security :如果您确定您发现了一个安全漏洞，请您在这一栏记上. 这很可能（经常）是一个严重的问题

最后，请单击提交（submit),并定期检查您的email，任何对于问题的更新或开发者对问题的回应都会通过电子邮件发送给您.

= 进一步阅读=
 * Bugs and feature requests - A more advanced guide to filing bugs
 * Bugzilla Etiquette - A guide to being polite using Bugzilla.
 * Filing Bugs Effectively - A commentary on writing effective bug descriptions.