bug的处理流程(2)

　　严重

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

　　一般

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

　　轻微

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

　　建议

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

　　缺陷优先级(priority)

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

　　优先级的划分：

　　低——>中——>高——>紧急

　　延迟处理——>正常排队——>优先处理——>紧急处理

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

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

　　严重程度高优先级不一定高：

　　如果某个严重的软件缺陷只在非常极端的条件下产生，则没有必要马上处理。

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

　　严重程度优先级不一定低

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

　　缺陷状态

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

　　打开 ： 表示问题被提交等待有人处理。

　　重新指派 ： 问题被重新指派给某人处理。

　　处理 ： 问题在处理中，尚未完成。

　　固定 ： 确认此问题存在，但暂时不进行处理。

　　回归 ： 对已经修复的问题进行回归确认。Reopened :

　　关闭 ： 问题的最后一个状态。

　　Bug处理流程

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

　　提交(打开)缺陷

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

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

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

　　分配(转交)缺陷

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

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

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

　　确认缺陷

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

　　推迟处理

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

原文转自：http://www.uml.org.cn/Test/201301232.asp