如何写一份良好的缺陷（Bug）报告
jopen 12年前
<p> 英文原文：<a href="/misc/goto?guid=4958347731409707995">How to Write a Good Bug Report</a></p> <p> 没错，任何软件都存在 bug，哪怕是我们自己也存在缺陷，因为程序员也是普通人，人是会犯错误的。当有人在使用软件时遇到 bug，你需要使用邮件形成一份缺陷 bug，发送给开发人员。开发者可以依据该报告定位问题，复现问题，修复问题。</p> <p> 但是很多时候，开发人员很难理解提交上的缺陷报告，因为发送人并不了解我们需要的是什么，那如何与开发人员沟通以及如何写出一份缺陷报告，在这篇文章，我将教你如何写出一份清晰的缺陷报告能使开发者理解、复现、修复问题，<a href="/misc/goto?guid=4958347732216099378" rel="nofollow" target="_blank">这里</a>下载缺陷报告模板。</p> <p style="text-align:center;"><a title="bug_report-250x250" rel="lightbox[22209]"><img title="bug_report-250x250" alt="如何写一份良好的缺陷（Bug）报告" src="https://simg.open-open.com/show/3a20158bc43ab502336f3201a0becae2.gif" width="250" height="250" /></a></p> <p> <strong>为什么要发送缺陷报告</strong></p> <p> 缺陷报告可以用很多方式来帮助我们的开发者。</p> <ul> <li>他们能告知我们没有意识到的问题</li> <li>他们能发现我们可能还没想到的新特性</li> <li>他们能帮助我们感受到客户是如何使用我们的软件，以至于我们可以做的更好</li> </ul> <p> 没有这些缺陷报告，我们就不知道出错的地方，我们需要它就像你唱歌跳舞时需要有软件的支持一样。</p> <p> <strong>什么时候发送缺陷报告</strong></p> <ul> <li>简单来说就是越快越好，详细来说就是：</li> <li>当你看到一个错误消息时就发送错误报告</li> <li>当屏幕是空白或者数据缺失就发送报告</li> <li>当程序没有出现预期的结果时发送报告</li> <li>当程序崩溃、死机、没有响应或者响应很慢时发送报告</li> <li>当程序返回错误结果时发送报告</li> <li>当你得不到想需要的结果时发送报告</li> <li>如果你不清楚怎样做时发送报告</li> <li>如果你不喜欢软件做的方式，或者软件老打搅你时，发送错报告</li> <li>如果你想在系统中实现一个变通方案时发送报告</li> </ul> <p> <strong>缺陷报告需要有哪些内容</strong></p> <p> 缺陷报告应该包含很多信息，你提供的信息越多效果越好，对于开发者，就像我，提供一个纯文本文件模板给你填充然后邮件发给我，当然也有表格形式的，但是最期待你自己杜撰一份然后发给我。下面是一些必须包括的部分以及如何写好每部分：</p> <p> <strong>标题</strong>：创建一个简短的标题，让问题看起来更清晰。“应用崩溃”是一个很恼人的标题因为它没有足够的信息包括 在这份报告里面。取而代之的是标题应该包含错误消息和消息码，或者是结果的名称以及失败时你正在做的事情。例如：Error 402:访问拒绝当点击“发送邮件”这个例子就提供了缺陷系统的上下文信息。</p> <p> 差：“程序崩溃”，“报错”，“Bug”</p> <p> 好：“从’Kifu’中打印时 5C79 错误”，“’Kifu honors’报表为空”</p> <p> <strong>产品</strong>：用名称标识产品，告知你使用的是哪个版本。绝大部分软件都包含有版本信息。web 应用的版本信息通常在页脚。</p> <p> 差：“你的应用”</p> <p> 好：”Kifu v1.01″</p> <p> <strong>平台</strong>：告诉我们软件运行在什么平台。尤其是操作系统的名字及版本和游览器名称版本。特别是 web 应用，这些信息对我们很重要。</p> <p> 差：“Windows”</p> <p> 好：“Windows 7,IE9”</p> <p> 是否能重现：有些恼火的 Bug 是间歇性的出现，我们想预先知道，如果我们正在处理一个灵异事件或者正逢 Bug 出现时。</p> <p> 差：留空白</p> <p> 好：“每次”，“偶然”，“不重现”</p> <p> <strong>描述</strong>：这部分是很多人拿不定的地方，不知道怎么描述问题，在描述中做到包括下面的内容：</p> <p> 总结：用简洁的语言概括出 Bug 出现时你正在做的事情。从上下文开始，在操作应用的哪个部分。聚焦在你做的时候软件做了什么？</p> <p> 差：“系统不能用了”</p> <p> 好：在“honor report”页面单击“打印按钮”，但是报表是空的。</p> <p><strong> 发生了什么</strong>：一步一步描述你做的事情当 bug 出现时，为什么你认为是错误的。事无巨细，打印出菜单的名称，页面标题，点击时的按钮或者链接的名称。做相同的操作是不是出现一样的错误。</p> <p> 差：“空白报表”</p> <p> 好：“点击 ‘File/Save as…’，’Save‘对话空弹出，然后点击‘OK’按钮，但是文件没有保存”</p> <p><strong> 错误时什么</strong>：如果错误消息出现时，拷贝粘贴整个信息，这样更有利于我们跟踪错误。</p> <p> 差：“有个错误，点击它始终读不出”</p> <p> 好：“Error 403：访问拒绝”</p> <p><strong> 复现的步骤</strong>：如果你可以让 bug 重现，那太好了，这能提供很大的帮助。一步步描述如何重现次 bug。</p> <p> 差：“打印没法使用”</p> <p> 好：“从‘Honors Report’页面，点击‘打印按钮’”</p> <p><strong> 预期结果</strong>：描述你预期发生的结果当 bug 发生时，这部分特别有用如果程序没有按照你期待的结果发生时，因为它很诡异。</p> <p> 差：“我期待能正常工作”</p> <p> 好：“我期待能看到‘Honors Reports’的 PDF 文件”</p> <p> 真实结果：当 bug 发生时是怎么发生的，什么错误，为什么有错，或者如果错误抛出，抛出什么错。</p> <p> 差：“没法用”</p> <p> 好：“我收到是空的 PDF 文件，或者’403错误，访问拒绝’”</p> <ul> <li><strong>附件</strong>：如果你知道怎么截屏，做吧，附上一个简短的错误，截屏可以是错误之前或者发生错误之后，我们的开发者能够看到究竟发生了什么。如果应用有崩溃的日志，同样附上它。</li> <li><strong>联系方式</strong>：附上你的名字和 email，我们可以让你提交的报告及时的得到答复，在我们不理解问题的描述时还能够询问你，如果你忘记附联系方式了，我们也就没法联系到你，也没法修复 bug。</li> </ul> <p> 原文：<a href="/misc/goto?guid=4958347731409707995" rel="nofollow" target="_blank">Noverse</a> 编译：<a href="/misc/goto?guid=4958185140659301754" target="_blank">伯乐</a>在线 –<a href="/misc/goto?guid=4958347734480579477" target="_blank">刘志军</a></p>