Bug管理流程

一、Bug的属性

1、Bug重现环境

操作系统

这个是一般软件运行的一大前提,基本上所有的软件都依赖于操作系统之上的,对于一个软件来说,要想在某个操作系统上运行,必须要对这个操作系统支持,这就需要有真对性的设计与开发。对于不同的操作系统,其可能存在差异(如:win xp 与 win 7)或本质的区别(如 win 7 与 CentOS linux ),所以,操作系统环境是重现问题的一个重要前提。

浏览器

对于B/S系统,或面向大众的互联网产品(网站,邮箱
等),浏览器的兼容性也是必须测试的一个重点,对于现
在的浏览器市场,各式的浏览器都有其用户群,要想使产
品大众化,必须考虑这些产品的兼容性问题。


不同的浏览器之间(IE、 firefox、chrome、opera
等),甚至同一系列不同版本(ie6/ie7/ie8/ie9等)都
可能存在兼容性问题,所以,对于这类应用,浏览器环境
重现bug前提条件之一。

其它(这个“其它”非常重要)

对于不同的系统发现重现问题,都会有其特定的前
提,拿我测试的邮箱来说,必须要描述其是在测试线还是
现网环境,而且还要附带一重现问题的帐号等。

2、Bug 类型

这里缩小范围,单指我们测试人员在测试过程中发现的缺
陷,发现产品缺陷其实就是测试人员工作的主要目的。当
然,你要确定一个问题的类型,也需要对项目(或产品)
有比较深的理解。是代码缺陷还是设计缺陷有时候就不太
容易区分,当然,这个划分,对于开发定位问题影响很
小,但对于问题类型的统计就比较重要了。


下面看一些常见的分类:

划分方式一:
  代码错误
  设计缺陷
  界面优化
  配置相关
  安装部署
  性能问题
  标准规范
  测试代码
  其它

划分方式二:
  功能类(function)
  性能类(performance)
  界面类(UI)
  易用性类(usability)
  兼容性类(compatibility)
  其它(else)

这个分类当然是可以自定义的,具我接触的缺陷管理
都是可以自定义的,既然是对问题的管理,那么你当然可
以拿来做特定环境下的系统来使用,或我就想用这个系统
来指派任务,那么我的自定义类型为前端任务、后端任
务、测试任务、配置部署...

3、缺陷等级

缺陷等级,这个划分也比较灵活,有分三级或四级,
也有分五级的。

致命

一招毙命的缺陷,使你的系统无法运行,有造成数据
泄漏的安全性问题。

严重

可以引起易于纠正的异常情况、可能引起易于修复的
故障或对产品外观难以接受的缺陷。

一般

指不影响产品的运转和运行、不会成为故障起因,但
对产品外观和下道工序影响较大的缺陷

轻微

轻微缺陷是指对产品外观和下道工序可能会有轻微影
响的缺陷

建议

增加用户使用体验的建议性问题。(一般情况下,建
议也为做为缺陷的一种。这个跟系统的类型与需求有关)

4、缺陷优先级(priority)

当问题处理人员在面对许多问题需要处理进,就需要
问题进行优先级排序。我们做事情的安排,操作系统有处

理进程等都在使用着优先级。


优先级的划分:
低——>中——>高——>紧急
延迟处理——>正常排队——>优先处理——>紧急处理


Bug 的严重程度和优先级是含义不同但相互联系密切
的两个概念,它们从不同的侧面描述了软件缺陷对软件质
量和最终用户的影响程序和处理方式。


一般地,严重程序高的软件缺陷具有较高的优先级。
严重程度高说明缺陷对软件造成的危害性大,需要优先处
理,而来严重程序低的缺陷可能只是软件不太尽善尽美,
可以稍后处理。


严重程度高优先级不一定高:
如果某个严重的软件缺陷只在非常极端的条件下产
生,则没有必要马上处理。


如果某一个软件缺陷,需要重新修改软件的整体架
构,可能会产生更多的潜在缺陷,而且软件由于市场的压
力必须尽快发布,此时即使缺陷的严重性很高,是否需要
修正,需要全盘考虑。


严重程度优先级不一定低:
如果是软件名称或公司名称的拼写错误,虽然说其属
于界面错误,严重程度不高,但其关系到软件和公司的市
场开解,必须尽快修正。

5、缺陷状态

对于一个问题,其处理过程是一个周期,周期的不同
阶段,其所处的状态也是不一样的。不同状态所对应的处
理人也是不一样的。


**打开 : **表示问题被提交等待有人处理。
重新指派 : 问题被重新指派给某人处理。
处理 : 问题在处理中,尚未完成。
固定 : 确认此问题存在,但暂时不进行处理。
回归 : 对已经修复的问题进行回归确认。Reopened :
关闭 : 问题的最后一个状态。

二、Bug处理流程

下面通过一个比较完整的bug的处理流程图,更深刻的
理解bug的状态以一个bug的生命周期。


Bug管理流程_第1张图片
Bug处理流程图

提交(打开)缺陷

在提交一个缺陷的缺陷,首先尽量描述这个缺陷的属
性。Bug重现环境,bug类型,bug等级,bug的优先级以及
详细的重现步骤,结果与期望等。


当然,我们在提交一个问题之前首先应该保证,这个
缺陷是没有被提过的,以免造成重复缺陷单。


如果是回归不通过的缺陷,其状态又会变为打开状
态。

分配(转交)缺陷

这一步不是必须的,跟项目模式有关,有些公司测试
部门与开发部门独立,那么测试人员就不确定自己测试的
模块是由哪位开发人员负责的,在这种情况下,测试人员
统一把问题指派给项目组长或经理,由项目组长(或经
理)对问题进行确认后再次分配给相应的开发人员。


有些测试人员是穿插到不同研发团队中的,所以对不
同的开人发员负责的开发模块非常清楚,这个时候就可以
将问题直接指派给相应的开发人员。


也有一种情况,本来此问题应该由A开发人员负责,但
由于A开发人员的调离或辞职,些问题为转交给其它人员处
理。“分配”强调是上级对下级;“转交”强调的是平级之
间。

确认缺陷

当开发人员接到一个缺陷时,首先是对其进行分析与
重现,如果对其进行分析发现不是缺陷(可能由于测试人
员不了解需求)或无法对此问题进行重现,那么就需要将
此问题反回给测试人员,并注明原因。如果确认为缺陷则
需要对其进行处理。

推迟处理

在处理问题之后,还需要进行一次判断,是否需要推
迟处理,有些需求已经确认了是问题,由于其可能在极端
情况下才会出现,或需要对系统架构进行改动,或其优先
级非常低,所以暂时不需要对此问题进行处理(或到下个
版本进再进行修复)。

固定

对于推迟处理的问题可以暂时进行固定(“固定”为QC
中的叫法。)一般固定的问题需要经过项目经理与测试经
理协商后才能固定。

处理缺陷

开发人员在确认完一个问题需要处理时,那么就对其
进行处理工作。(例如,redmine 是支持处理人时时更新
问题处理进度的,如 已处理30% ,已处理80% 等,当
然,对于短时间内可以修复的问题就没必要时时的去更新
处理进度。)

回归缺陷

回归缺陷对于测试人员来说是非常重要的工作,其有
三个入口两个出口。

确认非缺陷问题:对于提交的一个缺陷,开人员处理
为非问题或无法重现,然后直接转交给测试人员回归。测
试人员再次确认,如果真如开发人员所说,则将问题关
闭。如果非开发人员所说,是由于问题描述模糊或其它原
因喂重现问题,则再次注明原因转给开发人员。


确认修复问题:对开发人员修复的问题再次进行确
认,确认能过,则关闭问题。确认不通过,将问题再次打
开并转给开发人员。


确认固定问题:有计划的对固定问题进行确认,有些
固定问题随着时间的推移,版本的更新或已经不存在了,
对这类问题应该及时关闭。有些固定问题依然存在且变得
紧急,对于这类问题应该及时打开交给开发人员处理。

关闭缺陷

对于已经修复的缺陷进行关闭,这也是一个缺陷的最
后一个状态。

你可能感兴趣的:(Bug管理流程)