【软测】Bug基础知识

1、bug的生命周期：

BUG 生命周期中的各个状态   从一个bug被发现到这个bug被关闭这一段时间，bug可能会有以下状态：

new ，open Postpone，Pending Retest，Retest,Pending Reject,Reject,Deferred,closed.(请注意这里有很多种状态，我们需要根据不同情况来决定怎样或者是否需要跟开发人员沟通) 

下面就对这几种状态进行以下解释：

（1）New（新的）

 当某个“bug”被发现的时候（第一次），测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New 

（2）Assigned（已指派的） 

当一个bug被指认为New之后，将其将给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”

（4）Open（打开的）

 一旦开发人员开始处理bug的时候，他（她）就将这个bug的状态设置为“Open”，这表示开发人员正在处理这个“bug”

 （5）Fixed（已修复的）

当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组

（6）Pending Reset（待在测试的）

 当bug被返还到测试组后，我们将bug的状态设置为“Pending Reset”

 （7）Reset(再测试) 

测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为“Reset”

 （8）Closed（已关闭的）

 如果测试人员经过再次测试之后确认bug 已经被解决之后，就将bug的状态设置为“Closed”

（9）Reopen（再次打开的）

如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组，并将bug的状态设置为“Reopen”

（10）Pending Reject（拒绝中）

如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是bug时，这种情况下开发人员可以拒绝，并将bug的状态设置为“Pending Reject”

（11）Rejected(被拒绝的) 

测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，发组负责人就将这个bug的状态设置为“Rejected”

（12）Postponed（延期）

有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed“

（13）Deferred（延期的）

有些情况一些特殊的bug显得不那么重要，同时也是可以消除的，这个时候我们可以将bug的状态设置为“Deferred”。

2、如何定义bug的优先级：

在测试过程中往往需要定义bug的优先级，否则开发人员可能会逐条来处理bug

最高级-- 阻止对后续功能的测试，通常适用于一下情况：（阻止对后续功能的测试）

1. 软件不能运行

2. 界面/功能 Crash 导致一系列测试部能运行

3. 出错的 Case 为冒烟测试的 Case 

次最高级- 在当前发布版本中必须修复（功能性没有完成用户的需求）

1. Bug 的出现导致软件没有完成用户的需求

一般-- 在时间许可的范围内修复（极端条件或特殊情况下出现）

1. 只有在极端条件下才会重现的 Bug

2. 在特定配置情况下不会出现的 Bug

低 -- 不影响当前发布，可以推迟到下一个发布中修复（用户界面等不稳定非功能性bug)

1. 不能稳定重现的 Bug

2. 因为电脑上装有其他干扰软件产生的 Bug

3. 非功能性 Bug, 如日志，错误回复等