软件缺陷(bug)的处理流程

　　又属于一篇普及文，希望自己在被各种技术吸引的同时，能时常来整理和总结软件测试最基本的知识。

　　从刚工作时接触的第一个缺陷管理工具禅道，到redmine、JIRA、bugzilla ，再到现在的QC，当然还有其它种的开源的或商业的缺陷管理工具，它们的本质是一样的，就是来管理缺陷的生命周期。

　　其实，你理解任意的一款工具，其它的工具也一定能无师自通。这不谈某款工具，单把它本质的一些东西抽离出来与大家分享。

　　Bug的属性

　　Bug重现环境

　　这个应该是我们重现bug的一个前提，如果没有这个前提，我们可能会无法重现问题，或者跟本就无从下手。

　　操作系统

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

　　浏览器

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

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

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

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

　　对于c/s软件，可能还要考虑与其它常用软的兼容等，例如，是在安装的某款软件后，对本软件的安装和使用造成影响。这些都是重现问题的必须描述的环境。

　　问题类型

　　根据JIRA的管理系统的划分，bug 只是问题的一种，它可以用于跟踪多种不同类型的问题(其实，他只是将bug做为一子类而已)。

　　JIRA系统缺省提供的问题类型(大部分的系统都可以自定义类型的，这样就增加了灵活性。)

　　Bug : 测试过程、维护过程发现影响系统运行的缺陷。(这就是一般测试人员所提交的bug)

　　New Feature : 对系统提出的新功能。(单个的小需求可以，如果大的话，就相当于一个需求，放到这里是不合理的。)

　　Task : 需要完成的一任务。(开发或测试任务指派。)

　　Improvement : 对现有系统功能的改进。(一般产品经理或产品体验师做的事)

　　当然，不同的公司，他们的人员定位与职责是不太相同的，按照上面的分类，JIRA就不是简单的缺陷管理系统了，它涵盖一项目(或产品)所需要处理的任务、需求与缺陷。

　　Bug 类型：

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

　　下面看一些常见的分类：

　　划分方式一：

　　代码错误

　　设计缺陷

　　界面优化

　　配置相关

　　安装部署

　　性能问题

　　标准规范

　　测试代码

　　其它

　　划分方式二：

　　功能类(function)

　　性能类(performance)

　　界面类(UI)

　　易用性类(usability)

　　兼容性类(compatibility)

　　其它(else)

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

　　缺陷等级

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

　　致命

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

　　严重

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

　　一般

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

　　轻微

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

　　建议

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

　　缺陷优先级(priority)

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

　　优先级的划分：

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

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

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

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

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

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

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

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