程序员是否经常让你在Bug单上再提供一些更多的信息？当Bug单提交后，你是否经常会再花很多时间来研究如何重现这个Bug？你是否经常听到开发人员说Bug在开发环境下无法重现？问题在于Bug单的质量不高，我们应该花更多的时间在研究如何测试系统上，而不是花更多的时间在Bug单上，本文就如何写出高质量的Bug单提出了一些建议。
为什么要写Bug单
当我们发现Bug后，需要通知开发人员，Bug单是一种沟通的介质，它的主要目的是让开发人员能够亲眼看到这个Bug是什么，如果不提供足够详细的说明来帮助开发人员重现Bug，那么他们就没法确定问题的根源。Bug单是一种用来说明期望结果和实际结果之间的差异以及描述bug如何重现的文档。
发现Bug后应该做什么
· 最好是一发现并确认了bug就立即填写Bug单，而不要等到当天测试结束再和其他bug一起填，因为那时就有可能遗漏一些要点，甚至是遗漏某个bug。
· 花点时间分析一下造成Bug的根本原因是什么，你可能会因此发现更多的Bug，最好能把你的任何有用的证据都写到Bug单上。
· Bug单提交之前自己再读一遍，可能会有错别字或者什么写错的地方需要重写。
下面将谈到填写Bug单时应注意的几个地方：
摘要（概述）
Bug单的“摘要”部分是一个Bug单带给读者的最初印象，它在浏览大量Bug时起着非常重要的作用，每个Bug单都应该有一个能够突出重点的“摘要”，就好像做广告一样。好的摘要应该控制在50~60个字符以内（一个汉字算两个字符），而且不要夹杂任何主观色彩的文字。
措辞
· 要据实反应情况，不要夸大或缩小Bug的影响。
· 有时候会发现一些令人不可思议的低级Bug，但还是要尽量使用较为委婉的词语来表述，免得伤害开发人员的自尊心。
· 描述越简单直接越好，我们不是在写论文或散文，所以不要把Bug单搞得那么复杂难懂。
· 要考虑到目标读者，他们可能是开发人员、测试人员、管理人员或者其他人，甚至是客户，所以要让目标读者都能看得懂Bug描述。
重现的步骤
· 每一步以及所有步骤组合起来应该是符合逻辑的。
· 清晰地列出所需的前置条件。
· 描述一般性的步骤，例如，某一步骤需要用户新建一个文件并给它命名，那就不要写“新建一个名为Mike’s File的文件”，而最好写成“新建一个测试文件TestFile”。
· 步骤应尽量详细，例如，我们要描述通过MS WORD保存一个文档，那么有两种方式，一是说得细点儿，即“从[文件]菜单里单击[保存]，……”，另一种就是说得简单点，即“保存文档”，但请记住，并非所有人都知道如何从MS WORD保存文档，或者说所有人都会使用同样的方式保存文档，所以描述的时候最好还是采用第一种方式。
· 写完之后自己用新的测试数据或者在新的系统上按照步骤亲自执行一遍，或许能够发现Bug单里有一些是遗漏的或多余的步骤。
