bug（二）

Bertha 。 2022-05-30 01:44 155阅读 0赞

从一个bug被发现到这个bug被关闭这一段时间，bug可能会有以下状态：new ，open Postpone，Pending Retest，Retest,Pending Reject,Reject,Deferred,closed.(请注意这里有很多种状态，我们需要根据不同情况来决定怎样或者是否需要跟开发人员沟通)  
　　下面就对这几种状态进行以下解释：  
　　 **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

**bug追踪的过程：**

**提交——确认——分配——修复——验证——关闭**

**提交bug的内容：**

**1、编号**

**2、概述**

**3、发现人**

**4、发现时间**

**5、修复时间**

**6、所属版本**

**7、所属模块**

**8、缺陷状态**

**9、缺陷严重度**

**10、修复优先级**

**11、下一步处理人**

**12、详细描述**

**描述使用bugzilla缺陷管理工具对软件缺陷(BUG)跟踪的管理的流程**

1) 测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或直接通知开发者。

2) 经验证无误后，修改状态为VERIFIED.待整个产品发布后，修改为CLOSED.

3) 还有问题，REOPENED，状态重新变为“New”，并发邮件通知。

4) 项目组长根据具体情况，重新reassigned分配给bug所属的开发者。

5) 若是，进行处理，resolved并给出解决方法。(可创建补丁附件及补充说明)

6) 开发者收到Email信息后，判断是否为自己的修改范围。

7) 若不是，重新reassigned分配给项目组长或应该分配的开发者。

8) 测试人员查询开发者已修改的bug，进行重新测试。

**如何解决不能重现的问题？**

问题场景：  
有一些比较严重的BUG随机发生，难以查找规律的，测试工程师提交上去后，有可能会出现以下三个情形：  
1．开发人员试图重现，重现不出，Reject回来；  
2．开发人员找不到规律，所以不去解决，问题一直处于Open状态；  
3．开发人员因为问题难以解决，所以直接Resolved回来，觉得反正是偶发的，先改成解决状态再说。  
对开发人员、项目经理和测试工程师来说，正确的处理方法应该是怎样的?  
解决方案：  
1 缺陷的描述：  
（1）重现频率：在提交Bug时，记录重现的频率（是、否、随机）  
（2）现象：测试人员尽可能描述发生的情况并有截图。  
（3）软件的版本：确认发现BUG程序版本和重现的代码是一致的，可通过tag(Clearcase应该叫Label)或者Revision号来标注。  
（4）数据：发生错误时的各种变量、内存、存储器等存储的数据内容。  
（5）环境：软件出错时的软硬件环境。  
对缺陷的描述应该尽可能的详细。  
2 缺陷的重现：  
（1）重现的人员： 缺陷的重现工作，最好由测试人员去完成，一方面，测试人员的文字描述其实很难包括所有的现象信息，让开发人员重现的难度很大，另一方面，测试人员的重现更有说服力和更快捷。  
（2）重现的次数：每个难重现的缺陷，由发现该缺陷的测试人员连续重复测试300次，如果还不能重现，将缺陷状态改为closed；  
(3)延长测试时间，努力找到规律。如果市场紧急，由公司级领导特批，相当于高层领导评估风险，就可以先发布软件，但测试和整改继续，留待问题解决后下一版本软件升级；  
(4) 若确实无法重现，转交项目经理做延迟处理，继续跟踪，若保留一个月都无法重现的，可先关闭，以后重现时再Reopen；  
3 不可重现的缺陷的处理方法：  
（1）人工代码走查：无法重现的代码找对系统最熟悉的开发人员重新Review代码，最好是多人一起查。查代码还找不出来，就要检查操作系统、应用服务器及其环境是否有问题，是否有兼容性问题。  
（2）工具静态检查：采用静态检查工具（如pclint,splint等工具）检查代码，消除所有的error与warning。记住：可能出现问题的地方一定出现问题！  
（3）换人重新开发相关模块：  
4 缺陷的记录：  
（1）开发人员Resolve缺陷的时候要写Revision号，写bug的原因。通过Revision号可以追溯到究竟改了什么内容。写bug原因对开发人员也是一种提高，知其然，也知其所以然。  
（2）根据紧急程度，放入每日/每周跟踪列表，每次开例会时跟踪问题的解决状态。