· 清晰地列出所需的前置条件。
· 描述一般性的步骤，例如，某一步骤需要用户新建一个文件并给它命名，那就不要写“新建一个名为Mike’s File的文件”，而最好写成“新建一个测试文件TestFile”。
· 步骤应尽量详细，例如，我们要描述通过MS WORD保存一个文档，那么有两种方式，一是说得细点儿，即“从[文件]菜单里单击[保存]，……”，另一种就是说得简单点，即“保存文档”，但请记住，并非所有人都知道如何从MS WORD保存文档，或者说所有人都会使用同样的方式保存文档，所以描述的时候最好还是采用第一种方式。
· 写完之后自己用新的测试数据或者在新的系统上按照步骤亲自执行一遍，或许能够发现Bug单里有一些是遗漏的或多余的步骤。
测试数据
开发人员重现Bug时可能不会访问测试环境，有些Bug可能只能用一定的测试数据才能重现，所以尽量把测试数据附在Bug单上。
屏幕截图
屏幕截图是Bug单里非常重要的组成部分，有时一张图能胜过千言万语，但也不能养成习惯不管有用没用的图都往上贴，或者是只贴图而缺少文字描述。附图能够使开发人员结合你的描述快速地重现Bug是最理想的：
· 所附图片的尺寸和占用空间不要太大，尽量用jpg或gif格式，而不要用bmp格式。
· 在图中出问题的地方标注一下，更利于开发人员快速定位。
严重级/优先级
· 设置Bug的严重级之前，应该全面地分析Bug的影响，如果我们认为这个Bug的优先级很高，那么应该在Bug单里说明优先级高的原因。
· 如果Bug是由于程序版本恢复到上一版而产生的，那么不管它的严重级如何，它的优先级应该置成“高”。
日志
如果可以的话一定要把程序报错的日志附上，这会让开发人员比较容易进行分析和调试。很多不能重现的Bug都是因为缺少日志，开发人员就会返回去找测试人员要日志信息。如果日志文件不大的话，比如十几行，那么可以直接把日志信息粘到Bug单里，如果日志很大的话，那么最好单独粘到一个文件里，如txt格式的，然后当作Bug单的附件就可以了。
这就是我的经验所得，大家可以对照看看，或者试试，会有帮助的
文章来源于领测软件测试网 https://www.ltesting.net/
