Bug描述单

经常听说不知道BUG怎么写才好，经常听说描述的bug经常会被开发看不懂，等等一系列关于bug的问题，以下是我在测试工作经验中的一些积累，我们公司用mantis来管理工具，以mantis的模版为原型进行bug单描述整理，应该一通百通：

1.      Id（BUG编号）：一般自动生成

2.      测试环境：机型、系统版本、分辨率、浏览器

3.      提交信息：BUG提交人，Bug接收人、接收部门，提交日期

4.      严重程度：系统崩溃、严重问题、次要问题、一般问题、文字错误问题、易用性问题、建议

5.      优先级：特急、加急、急、一般

6.      出现频率：经常出现、偶然出现、有时出现

7.      Bug之项目属性：项目名称，项目版本，所属模块

8.      BUG描述：摘要描述：简述BUG情况

   步骤：Bug生产过程，以最短步骤去描述

   错误表现：当前产生问题的表现

   期望结果：描述期望修改为的结果

   可以写上表明与用例的关联（那条用力引起的BUG）

   附件：包含错误截图、错误log文件、错误视频等一切可以描述BUG的附加文件。

            修改建议：如果精通代码可以把需要修改的代码片断附上

Bug描述常见问题：

1.      测试环境未写完整，开发修改时会出现复现不成功，测试回归时无法精准定位

2.      Bug描述不清晰，导致可阅读性降低

3.      缺少期望结果（或结果不清晰）：导致增加多次沟通成本

4.      Bug步骤冗余：最短路线描述bug增加快速定位