TD的BUG描述规则

~U]jj0BUG描述规则：

1、summary：主要指明BUG发生的地点，什么条件下发生什么现象。

2、description：

1）  版式：51Testing软件测试网'NP%G,D{wU

步骤：1、XXX…… 2、XXX…… 3、XXX…… （描述重现BUG的具体步骤，包括页面入口，权限用户，输入数据，若有需要，还可以提供环境参数等，如浏览器，操作系统）

问题：XXX……（描述缺陷所在，出现了什么错误，与预期结果有什么差别）51Testing软件测试网Z!{4u2?2o

建议：XXX……（建议性BUG，可以省略“问题”部分）51Testing软件测试网:gS`(N}

2）  一个Bug不会包含多个问题，尽量单一化，便于跟踪处理及统计51Testing软件测试网
DDc#U8h2QH

;chp4s~/A%d-c8]cR03）  对于很难描述清楚的Bug需截屏作为附件上传，并在描述中写明参照附件。

[ Tg,x5\{3vG~d04）  尽量减少重现的步骤以达到用最少的步骤来重现问题；51Testing软件测试网7n@ih9k*r9NRO

$y;D)S`,zJ)Tu05）  不要使用完全的大写形式，那样会让人感觉象控诉。不要使用感叹和其他体现个人感情色彩的词语或符号。51Testing软件测试网.nC5R0Z b!v

6）  不要使用含糊的词语（例如，好像，似乎）来描述发现的现象。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。

&{ a+VmKv4hcR1l:[p07）  在BUG提交前，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤。

@w6L2K~08）  如有必要可以把产生结果的SQL语句放上去。51Testing软件测试网;u$c
J'`#u Z

m8y^3^nq[09）  如果是概率性的BUG，尽量重现BUG，找到BUG产生的条件，如果找不出BUG产生的原因必须写明BUG发生的概率大约是多少。51Testing软件测试网6nr#S6@?BU)m

lRw2D9RG010）BUG如果在特定条件下产生的，必须写明BUG产生的条件和操作步聚。51Testing软件测试网 O|/cxs1`XD;H

Comments：

1）开发人员在修改BUG后，尽量描述什么原因引起的，修改了什么，怎么处理这个BUG的。

2）验证BUG后，描述验证的情况，若未修复，说明出现了什么问题。 修改后引起其他问题，建议另建一个BUG。

b8\3]!P"Kp-E*Q;o\2M2Eg03）使用comments按钮，TD会自动生成时间和操作人。51Testing软件测试网D(f6xYj&o
P~{+l#z