1。缺陷摘要（摘要）

容易理解，容易理解

长度一般不超过30个单词。

尽可能多告诉我：问题是什么，问题出在哪里

便于他人查找bug，不必重复删除同一个bug。

2。在缺陷的描述（说明）

重复步骤（动作）

详细说明重现问题的关键步骤

省略无关的操作并努力做到这一点：所有的再现步骤都是充分和必要的。

简单易懂的常规步骤，可以在一句话中完成，比如作为管理员登录，进入后台用户管理页面。

一个与环境相关的问题，给出特定的条件，例如某个操作系统、某个浏览器。

实际结果（实际结果）

描述实际的错误结果

可以用截图来表示

不总是复制错误，给出频率或规律

预期结果（预期结果）

可选的，当没有关于规范实现的详细要求时，测试人员使用它来表达他们的观点。

三.截图附件（附件）

难以表达或UI的问题

图像格式以JPG格式使用；Windows绘图工具的默认BMP图片太大，无法使用。

用醒目的颜色标出问题的区域。

你也可以考虑一篇短文。

4。其他

对于多个人同时测试同一个模块，检查在bug之前是否有类似的bug（TD提供了一个简单的查找类似的缺陷函数）

错误严重性（严重性）必须准确

缺陷优先级（优先级）必须准确（具体地参照公司标准文档）

填入模块/函数域，以便将开发管理器分配给相应的开发人员。

该项目中常见的问题包括在公共模块中。

许多相同的问题，例如负责修改的开发人员，可以编写缺陷报告，但是有必要指出问题的多个位置。

对于拒绝的有争议的bug，尽可能与开发人员通信。