Bug描述规范_草稿

Bug描述规范-草稿

准确、简洁、完整、规范的描述Bug，有利于分析错误产生的原因，定位错误以及修改。

1.      Bug标题

一个好的Bug，要写好Bug标题；

a)       bug描述包括三要素：位置、操作、现象；

位置：首先应说明操作进行的位置，通常是系统中的某一模块。另外是具体的出错位置，可能是某一字段、某一页面。

操作：详细的、有次序的、每一步的操作步骤，包括输入的数据 

现象：具体的错误描述，包括界面显示、错误信息。

b)      bug描述要求：清晰明确且简明扼要

然而，描述清楚的同时，我们又比较容易遇到另一个问题，就是冗长，开发者看到一堆文字就头大了。不愿意花时间去仔细读（自己回头再看也容易晕）所以我们写bug描述一定要清晰明确且简明扼要；

c) 每条Bug只能包括一个错误；

每条错误报告只包括一个错误，可以使错误修正者迅速定位一个错误，集中精力每次只修正一个错误。校验者每次只校验一个错误是否已经正确修正。

d)       避免重复

提交Bug时，按照功能模块去提交，提交前确定之前没有提过；如果之前提过，直接激活即可；也可通过“搜索”功能进行查找之前是否提过，避免提交重复Bug.

2.      重现步骤

一个好的BUG，还要写好重现步骤；

a)       步骤：写好重现步骤

b)       结果：说清楚什么地方出错，添加必要截图

c)        期望:期望应当是什么结果

3.      附件

根据缺陷或错误类型，选择截图、录屏文件，附加必要的特殊文档、个人建议和注解；

4.      历史记录

开发人员填写“原因、解释”内容。

5.      基本信息

Bug基本信息包括所属产品、所属模块、Bug类型、严重程度、优先级、Bug状态、激活次数、是否确认、当前指派、操作系统、浏览器、关键词。

所属产品：选择Bug所属产品；

所属模块：选择Bug所属模块；

Bug类型：代码错误、界面优化、设计缺陷、配置相关、安装部署、安全相关、性能问题、标准规范、测试脚本、数据类、建议类、其他；

严重程度：致命（1）、2严重（2）、一般（3）、较小（4）；

优先级：立即解决（1）、高优先级（2）、正常排队（3）、低优先级（4）；

Bug状态：激活、已解决、已关闭；

激活次数：此Bug被重新激活；

是否确认：开发人员是否确定是Bug；

当前指派：指派给谁；

操作系统：当前操作系统 ；

浏览器：当前浏览器；

关键词：

6.      Bug的一生

由谁创建：

影响版本：选择影响版本号；

由谁解决：解决Bug人员；

解决版本：解决Bug版本；

解决方案：选择解决的方案是设计如此、重复Bug、外部原因、已解决、无法重现、延期处理、不予解决、转为需求；

由谁关闭：最后修改是谁？

7.      项目/需求/任务

填写BUG单时，要写清楚所属项目名称；比如：是IDPRE2.5？还是IDPRE3.0？

8.      其它相关

抄送给：一Bug可同时抄送给其他人；

相关Bug:标注相关Bug号；

相关用例：标注相关用例号；

转需求：将Bug转需求

转任务：将Bug转任务