利用bugzilla提交Bug写作指南

为什么你要读这份指南?

简单地说，如果你报告Bug越有效, 工程师完全修复它的可能性就越大这份Bug写作指南是针对新手在书写有效的Bug报告方面进行指导的常规指南，并非每个建议都正好适用于你的软件项目。

如何写一份有用的Bug报告?

有用的Bug报告是用于正确修复Bug的。因此一份有用的Bug报告通常地有两个特征：

可复现：

如果工程师不能发现或最终证明这一Bug存在,工程师或许会将它标记为WORKSFORME(所有要重新产生这个bug的企图是无效的)"或 " INVALID(描述的问题不是一个bug )，并且继续进行下一个Bug的修复工作。任何你能提供的详尽描述将为工程师修复Bug提供帮助。

详细精确：

如果工程师能越早隔离、定位问题，就越可能方便地修复。

让我们举一个例子：你正在测试一个Web阅览器，在访问foo.com网站时崩溃了，因此你想写一个Bug报告:

糟糕的Bug报告：“我的浏览器崩溃了。我正在访问foo.com。我的计算机使用Windows系统。这真是个大问题，你们应该马上修复它。顺便说一下,你们的图标真恶心，如果你们保留那些丑陋的图标，没有人将再使用你们的软件。还有我的祖母的主页看上去外观也不正确，或者，它们全被搞乱了。祝好运。”有用的Bug报告：“每当我访问foo.com时应用程序就崩溃了，我使用的是在Win NT 4.0 (Service Pa ……此处隐藏1342个字……windows NT 4.0)-不发生在11/4/99Red Hat Linux; 特点没支持的) Internet Explorer 5.0 (RTM修造在windows NT4.0)Netscape Communicator 4.5 (RTM基于Mac OS)

其它信息：任何其他调试信息

Win32: if you receive a Dr. Watson error, please note the type of the crash, and the module that the application crashed in. (e.g. access violation in apprunner.exe)

Mac OS: if youre running MacsBug, please provide the results of a how and

an sc.Unix: please provide a minimized stack trace, which can be generated by typing gdb apprunner core into a shell prompt.

Win32: 如果您接受一个 Dr. Watson 错误, 请注意崩溃的型, 和模块, 应用碰撞了in. (即访问违例在apprunner.exe)

Mac OS: 如果你是在运行MacsBug, 请提供怎么和sc 的结果。

Unix: 请提供减到最小的栈检索, 可能由键入的gdb apprunner 核心引起入壳提示。

你已经完成了一篇不错的bug报告！