6.3 Bug包含的内容

了解完缺陷管理平台，如果测试的时候发现Bug就可以提交上去了。但是提交一个Bug需要包含哪些内容呢？（以下以禅道为例）

（1）填写所属产品

（2）填写所属项目

（3）选择所属的模块（前提是创建了相对应的模块）

（4）选择影响版本（默认选择Trunk）

（5）当前指派人（指派给解决问题的开发人员或者开发负责人）

（6）Bug的标题（唯一性，便于查找，编写参考：Bug的操作+Bug的结果）

（7）重现步骤包括三个方面：操作步骤、结果、预期结果。（附上测试数据、Bug截图、日志截图）

（8）Bug类型/严重程度（类型10大种，选择对应的Bug类型即可；严重等级1, 2,3,4）

（9）兼容性PC端，考虑在某个操作系统下的某个浏览器

（10）附件，Bug的重现上传对应的文件（如文件测试数据、日志文件）

以上Bug提交内容中，有两点在此说明一下，以提高测试报告Bug结果分析中Bug统计的正确性。

①Bug的类型

要确定一个Bug的类型，需要对项目（或产品）有比较深的理解。这个划分对于开发定位问题影响很小，但对于问题类型的统计就比较重要了。常见的Bug类型划分（禅道系统为例，可自定义）如下。

代码错误、设计缺陷、界面优化、性能问题、配置相关、安装部署、安全相关、标准规范、测试脚本等。

其他划分：功能类、界面类、性能类、易用性类、兼容性类、其他。

② Bug的等级

Bug等级，这个划分有分三级或四级，也有分五级的。如果是等级越高，那么可能被修复的等级也会高一些，然后有些公司还会根据你提的Bug数量和Bug等级来考察你的绩效。很多情况下，我们提交Bug大致的等级差不多即可，没有严格区分。

判断Bug的等级（严重程度），一般可以参照下面的判断条件。

致命错误：

▪ 常规操作引起的系统崩溃、死机、死循环。

▪ 造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露。

▪ 涉及金钱计算部分。

严重错误：

▪ 重要功能不能实现。

▪ 错误的波及面广，影响到其他重要功能正常实现。

▪ 非常规操作导致的程序崩溃、死机、死循环。

▪ 外观难以接受的缺陷。

▪ 密码明文显示（关注界面和数据库）。

一般错误：

不影响产品的运行，不会成为故障起因，但对产品外观和下道工序影响较大的缺陷。

▪ 次要功能不能正常实现。

▪ 操作界面错误（包括数据窗口内列名定义、含义不一致）。

▪ 查询错误，数据错误显示。

▪ 简单的输入限制未放在前端进行控制（格式限制）。

▪ 删除操作未给出提示。

细微错误：

程序在一些显示上不美观，不符合用户习惯，或者有一些文字的错误。

▪ 界面不规范。

▪ 辅助说明描述不清楚。

▪ 提示窗口文字未采用行业术语。

▪ 界面存在文字错误。

▪ 改进建议：可以提高产品质量的建议，包括新需求和对需求的改进。