一、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处理流程图
提交（打开）缺陷
在提交一个缺陷的缺陷，首先尽量描述这个缺陷的属
性。Bug重现环境，bug类型，bug等级，bug的优先级以及
详细的重现步骤，结果与期望等。
当然，我们在提交一个问题之前首先应该保证，这个
缺陷是没有被提过的，以免造成重复缺陷单。
如果是回归不通过的缺陷，其状态又会变为打开状
态。
分配（转交）缺陷
这一步不是必须的，跟项目模式有关，有些公司测试
部门与开发部门独立，那么测试人员就不确定自己测试的
模块是由哪位开发人员负责的，在这种情况下，测试人员
统一把问题指派给项目组长或经理，由项目组长（或经
理）对问题进行确认后再次分配给相应的开发人员。
有些测试人员是穿插到不同研发团队中的，所以对不
同的开人发员负责的开发模块非常清楚，这个时候就可以
将问题直接指派给相应的开发人员。
也有一种情况，本来此问题应该由A开发人员负责，但
由于A开发人员的调离或辞职，些问题为转交给其它人员处
理。“分配”强调是上级对下级；“转交”强调的是平级之
间。
确认缺陷
当开发人员接到一个缺陷时，首先是对其进行分析与
重现，如果对其进行分析发现不是缺陷（可能由于测试人
员不了解需求）或无法对此问题进行重现，那么就需要将
此问题反回给测试人员，并注明原因。如果确认为缺陷则
需要对其进行处理。
推迟处理
在处理问题之后，还需要进行一次判断，是否需要推
迟处理，有些需求已经确认了是问题，由于其可能在极端
情况下才会出现，或需要对系统架构进行改动，或其优先
级非常低，所以暂时不需要对此问题进行处理（或到下个
版本进再进行修复）。
固定
对于推迟处理的问题可以暂时进行固定（“固定”为QC
中的叫法。）一般固定的问题需要经过项目经理与测试经
理协商后才能固定。
处理缺陷
开发人员在确认完一个问题需要处理时，那么就对其
进行处理工作。（例如，redmine 是支持处理人时时更新
问题处理进度的，如 已处理30% ，已处理80% 等，当
然，对于短时间内可以修复的问题就没必要时时的去更新
处理进度。）
回归缺陷
回归缺陷对于测试人员来说是非常重要的工作，其有
三个入口两个出口。
确认非缺陷问题：对于提交的一个缺陷，开人员处理
为非问题或无法重现，然后直接转交给测试人员回归。测
试人员再次确认，如果真如开发人员所说，则将问题关
闭。如果非开发人员所说，是由于问题描述模糊或其它原
因喂重现问题，则再次注明原因转给开发人员。
确认修复问题：对开发人员修复的问题再次进行确
认，确认能过，则关闭问题。确认不通过，将问题再次打
开并转给开发人员。
确认固定问题：有计划的对固定问题进行确认，有些
固定问题随着时间的推移，版本的更新或已经不存在了，
对这类问题应该及时关闭。有些固定问题依然存在且变得
紧急，对于这类问题应该及时打开交给开发人员处理。
关闭缺陷
对于已经修复的缺陷进行关闭，这也是一个缺陷的最
后一个状态。
网友评论