一个bug的生命周期 ------做者 虫师

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

通常地，严重程序高的软件缺陷具备较高的优先级。严重程度高说明缺陷对软件形成的危害性大，须要优先处理，而来严重程序低的缺陷可能只是软件不太尽善尽美，能够稍后处理。

• 严重程度高优先级不必定高：

若是某个严重的软件缺陷只在很是极端的条件下产生，则没有必要立刻处理。

若是某一个软件缺陷，须要从新修改软件的总体架构，可能会产生更多的潜在缺陷，并且软件因为市场的压力必须尽快发布，此时即便缺陷的严重性很高，是否须要修正，须要全盘考虑。

• 严重程度优先级不必定低

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

缺陷状态

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

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

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

• 处理 ： 问题在处理中，还没有完成。

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

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

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

 

一个bug的生命周期

---

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

提交（打开）缺陷

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

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

若是是回归不经过的缺陷，其状态又会变为打开状态。

分配（转交）缺陷

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

有些测试人员是穿插到不一样研发团队中的，因此对不一样的开人发员负责的开发模块很是清楚，这个时候就能够将问题直接指派给相应的开发人员。

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

确认缺陷

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

推迟处理

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

固定

对于推迟处理的问题能够暂时进行固定（“固定”为QC中的叫法。）通常固定的问题须要通过项目经理与测试经理协商后才能固定。

处理缺陷

开发人员在确认完一个问题须要处理时，那么就对其进行处理工做。（例如，redmine 是支持处理人时时更新问题处理进度的，如 已处理30% ，已处理80% 等，固然，对于短期内能够修复的问题就不必时时的去更新处理进度。）

回归缺陷

回归缺陷对于测试人员来讲是很是重要的工做，其有三个入口两个出口。

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

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

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

关闭缺陷

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

最后，“状态”和“指派人”的对应关系若是更加细化，对项目而言是有益的：

已关闭--->指派给修复这个bug的开发工程师。 无需解决，不是bug--->指派给提交这个bug的测试人员。 无需解决，迭代待解决--->指派给项目的产品经理。