一条软件缺陷（或者叫Bug）记录都包含了哪些内容？在传统的BugZilla中，BUG描述应该包括以下的信息：
-
所属模块和BUG产生对应的软件版本
-
开发的接口人员
-
BUG的优先级
-
BUG的严重程度
-
BUG可能属于的模块，如果不能确认，可以用开发人员来判断
-
BUG标题，需要清晰的描述现象
-
BUG描述，需要尽量给出重新Bug的步骤
-
BUG附件中能给出相关的日志和截图。
BUG管理工具的跟踪过程和bug的状态：从一个bug被发现到这个bug被关闭这一段时间，bug可能会有以下状态：new ，open Postpone，Pending Retest，Retest,Pending Reject,Reject,Deferred,closed.
新建（new）-分配-研发修订-测试确认-关闭。
New:（新的）
当某个“bug”被发现的时候（第一次），测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New
Assigned（已指派的）
当一个bug被指认为New之后，将其将给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”
Open（打开的）
一旦开发人员开始处理bug的时候，他（她）就将这个bug的状态设置为“Open”，这表示开发人员正在处理这个“bug”
Fixed（已修复的）
当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组
Pending Reset（待在测试的）
当bug被返还到测试组后，我们将bug的状态设置为“Pending Reset”
Reset(再测试)
测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为“Reset”
Closed（已关闭的）
如果测试人员经过再次测试之后确认bug已经被解决之后，就将bug的状态设置为“Closed”
Reopen（再次打开的）
如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组，并将bug的状态设置为“Reopen”
Pending Reject（拒绝中）
如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是bug时，这种情况下开发人员可以拒绝，并将bug的状态设置为“Pending Reject”
Rejected(被拒绝的)
测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”
Postponed（延期）
有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed”
Deferred（延期的）
有些情况一些特殊的bug显得不那么重要，同时也是可以消除的，这个时候我们可以将bug的状态设置为“Deferred”
原创文章，作者：carmelaweatherly，如若转载，请注明出处：https://blog.ytso.com/196008.html