文本描述
Bug剖析
所有的Bug报告有以下的基本要求：
标题。要简略。
指派。谁来处理这个问题。
重现步骤。问题再次出现的相关步骤。
优先级别。问题的紧迫性与重要性。
严重程度。问题所产生的后果。
解决方案。怎么解决问题。
其他很多方面对修复问题及明白其深层次原因也很有帮助，但以上基本准则简练得多。下面我们来对每条准则逐一展开讨论，消除这些疑惑。
标题及指派
标题应该简明扼要，一句话就详尽说明问题的唯一性，使Bug报告的检索及标识变得简单。“点击取消按钮，屏幕就清空了”是个差劲的标题。“关闭编辑框，清空屏幕”就是个很好的标题。后者简短得多，而且对问题的出处及发生时间提供了具体的信息。
当你要创建一份新的Bug报告时，你必须指定具体人选来解决其中问题。但是，即使你这个团队的每个人都很了解，你也不应该将一个Bug指定给其中某一位，除非你是开发团队的一员。相反，你应该将此任务交给这整个团队。通常的做法是在Bug报告中指定责任方或团队作为默认选择。默认的选择通常是“主导”或“会诊”团队。不会再有更好的了。要相信这些团队，他们会知道问题由谁来解决。
作者注：有些团队希望将所有Bug都指派给团队中的某些个人，这样可保证没有Bug被遗漏。但是，他们还是必须确认将Bug指派给“主导”或“会诊”团队以确保Bug未被遗漏。毕竟，团队外部人员并不知道软件还有其他什么功能。
作为惯例，所有Bug必须指派给能对其进行经常性检查的个人或团队。因为，大多数优先团队会每天开例会，我还是偏好将Bug指定给“主导”或“会诊”团队为默认选择。
重现步骤
没什么比一份Bug报告没有清晰的重现步骤更让人郁闷了。就像你的亲友对你说：“你知道该怎么办！”，没有给你更多解释。这让我很茫然，不知道怎么办。悲催了。
Bug重现步骤应是言简意赅——一言中的。同时要包含软件创建编号（通常是单独列出的），你的工作环境（操作系统版本、所用浏览器及其他相关的细节）以及一些先备条件（像先注册个Xboxcom金牌账号等）。
有时你不能确定Bug是怎么发生的，因为它有时是间歇性的或跟某种特定的状态相关。这种情况下，列出创建编号、运行环境及配置等信息，接着描述下当时的情况，以说明具体的Bug重现步骤无法确定。 作者注：我们有些内部工具，如Watson与Autobug，它们可以自动生成Bug报告。诚然，用这些工具生成Bug重现步骤有其局限性，但是它们通常仍可以提供些堆栈跟踪信息、创建编号、环境及其他相关的信息，且它们对隔离问题有帮助。
在简洁的Bug重现描述后，你必须指出什么是你希望发生的（“期望”），及事实发生了什么（“事实”）。所有的重现步骤包括
==>> 点击下载文档
