bug缺陷管理流程及等级划分 - CSDN博客
bug缺陷管理流程及等级划分
缺陷等级划分
缺陷等级一般划分为四个等级，致命、严重、一般、提示。
&致命（一级bug）
通常表现为:主流程无法跑通，系统无法运行，崩溃或严重资源不足，应用模块无法启动或异常退出，主要功能模块无法使用。
比如：1.内存泄漏；2.严重的数值计算错误；3.系统容易崩溃；4.功能设计与需求严重不符；5.系统无法登陆；6.循环报错，无法正常退出。
严重（二级bug）
通常表现为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
比如：1.&功能未实现；2.功能存在报错；3.数值轻微的计算错误。
一般（三级bug）
通常表现为：界面、性能缺陷。
比如：1.边界条件下错误；2.容错性不好；3.大数据下容易无响应；4.大数据操作时，没有提供进度条。
提示（四级bug）
通常表现为：易用性及建议性问题
比如：1.界面颜色搭配不好；2.文字排列不整齐；3.出现错别字，但是不影响功能；4.界面格式不规范。
缺陷管理流程说明
　　1、人员填写并提交给开发组长，Bug的状态为New；
　　2、开发组长次日前对bug确认是否有效。有效的bug，状态变化为open，并分配给开发人员；bug无效或者延期修改的，将bug状态变化为Rejected，同时也在comment中注明原因。
　　3、开发人员上班的第一件事情是查看自己有几个bug需要修改。
　　4、开发人员修改bug，修改完成并进行后，将bug的状态变为fixed，在comment中说明修改方法；
　　5、测试人员每天查看自己提交的bug的状态变化，应该成为每个测试人员的例行行为；
　　6、当bug的状态变为fixed时，测试人员打开该bug，开始对该bug进行回归测试；
　　7、如果该bug回归测试通过，则状态变为closed。否则bug的状态变为reopen（必须说明reopen、closed状态变化原因或者操作过程）；
　　8、如果回归测试通过，可是修改的同时又引入新的bug，则重新提交bug，状态为new。如果需要的时候注明相关联的bug号；
　　9、只有当所有的bug状态为closed，才可发布版本。
　　注：每当bug状态改变后，必须给出相应的注释和说明，以便查看bug生命周期的变化情况。
new-open(rejected)-fixed(reopen)-closed
本文已收录于以下专栏：
相关文章推荐
A类：致命，基本功能无法实现
手机无法正常开机/关机。Android开发
正常操作时手机出现程序崩溃、死机、重启或者掉电等。
正常情况下基本功能无法正常工作，...
石的颜色(Colour)等级介绍（戴维尼网站）
钻石颜色分为两大系列，常见的无色系列包括无色、浅黄、浅褐色；彩色系列包括深黄、灰色、粉红等。无色钻石色泽通常以美国宝石学院GIA...
计算机信息系统安全保护等级划分准则
1 范围2 引用标准3 定义4 等级划分准则
编辑本段1 范围
　　(GB )　　本标准规定了...
摘要：相信开发人员一定对初级、中级、高级软件工程师这类词汇很熟悉吧！你们是否对编程进行过等级划分？这个又是如何划分的呢？本文作者把编程复杂性从简到难化成27个等级，你同意这样的划分吗？
通常来说...
read uncommitted
--读未提交，解决了更新丢失，产生脏读
read committed--读已提交，解决脏读，修改中的数据不可读，不可重复读。默认级别
...
他的最新文章
讲师：何宇健
讲师：董岩
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)如何有效的进行bug回归
在软件测试工作中，测试人员最大的目标就是尽可能的提升产品质量，减少bug数量。因而bug长期以来都困扰着广大测试工程师，如何尽可能减少bug数，在测试的各个阶段都有不同的解决方案，下面以我经常犯错的bug回归阶段的bug遗漏问题说起。
回归阶段的bug遗漏通常有几种原因：
1、bug回归人员对回归bug所对应的功能不够熟悉，不能或没有举一反三，没有将所测功能的其他入口点遍历
2、用例不规范，无法建立bug和用例的对应，回归测试不完整
3、用例更新不及时，例如需求变更，随机测试等所发现的bug没有对应的测试用例，回归随机性很大
4、项目进度紧，没有时间进行更细致的回归
5、测试人员对bug如何修复不了解，错误评估测试回归范围
针对上面所遇到的问题，我们主要从两方面思考问题解决方案：方法层面和思想层面
从思想层面：
思想层面的总结最终形成的是一种意识形态上的思考，适合有经验的测试工程师，那么我们可以从如下几个方面去规范我们的思想：
1、加强所负责模块的熟悉程度，及时梳理模块功能逻辑及各种入口。
2、提升对于bug回归在测试过程中重要性的理解。
虽然一个项目下来，我们会发现bug分散于各个模块之中，但是在深入一步看的话，你会发现其实bug也是有一定聚集性的，也就是我们经常看到的某某开发工程师的产品经常出问题，某个功能出问题。在例如项目后期阶段，以点辐射开来找bug的效率应该是大于随机测试找bug的效率的。
3、加强项目中的文档管理，维护和更新。
4、加强项目风险预测和项目时间管理。
这样项目预定的流程才能够被执行，不至于因为时间来不及而影响到测试工程师的执行心态及执行成效。
5、加强与开发工程师的沟通。
方法层面：
测试工程师最重要的还是实践动手能力，反映到问题总结上面，就是需要有一个切实可行的方案出来。
针对于bug回归阶段的bug遗漏问题，我认为可以从如下几个方面
1、测试用例设计阶段，设计并维护一个各个功能入口的说明文档。
其实这个文档的作用很大，一方面对于bug回归阶段的人来说，这是用于提醒的；另外一个方面，在随机测试的时候，随机程度也能有所提高，测试人员能够自己随意组合可能的路径。当然，一样一份文档也能提升文档设计人员，文档阅读人员对于模块的整体认识
2、Bug提交阶段，评估阻塞用例说明。
在项目初期，尤其是版本刚提交的时候，往往会出现功能无法使用或者没有实现的问题，这时候我们提交bug并不仅仅是说明预期没有实现，更重要的是我们如何备忘这件事情，如何保证没有实现的功能在最终版中实现，那么在提交bug的时候，我们需要注明，哪些case被阻塞，该功能没有验证会影响到哪些其他模块和功能的验证等
3、Bug提交阶段，在bug描述中备注回归时的路径说明。
测试工程师提交bug时是在当时的环境下的，也就是说对测试目录，前后操作及路径都非常清楚，对于其他可能的入口或者操作，测试工程师是知道的，因而在提交bug的时候，测试工程师除了提交出现bug的操作步骤之外，如果能补充一下其他可能的路径说明，一方面开发在修复bug的时候可以作为参考，另外一方面测试工程师在bug回归的时候也能够进行更全面高效的回归
4、Bug提交完毕，对非用例内影响因素或路径更新到测试用例或者进行备忘。
测试影响因素包括各个方面，因为测试工程师的经验，知识储备等各方面原因，测试设计往往会有一定的遗漏，这是不可避免的，在测试过程中我们往往会突然想到某个影响因素或者测试路径，这时候我们往往会去执行一下是否有问题，如果有问题，则会有bug提交，如果没有bug呢？往往我们会去继续去执行下一条case去了。实际上这种情况是对测试工程师脑力的一种浪费，不利于测试工程师经验的积累。
我们试想如果我们将这种问题更新进用例，或者至少以某种方式，例如项目便签的方式对这些问题进行记录，当项目完成之后总结阶段，我们将这些问题拿出来，整理，分析，更新文档，更新测试知识库，那么首先我们不用去抓耳挠头想有什么可总结的东西，其次下一次用例设计时我们就可以直接思考到这个因素，而无需执行过程中突然想到了。
5、测试过程中，对需求变更等文档进行有效管理。
测试过程中因为各种原因，例如需求权限，开发实现的成本，bug影响等，会导致产品需求的变更，测试工程师需要及时相应需求变更，更新测试用例并验证信需求，但是往往因为项目进度或其他原因，测试工程师没有这个时间，我们在回归的时候，如何保证这部分需求变更测试通过呢？那么一个测试整理的需求变更文档是必要的，这其中可以记录产品的原始需求变更，以及测试记录的测试要点。当项目总结阶段，再进行统一的维护，这对产品项目而言是很有效和清晰的方法。
6、测试管理中，bug的两阶段回归。
其实这个想法并不成熟，仅仅作为参考。在项目过程中，开发和测试是并行的，也就是说到了一定阶段，新建bug是处于收敛而修复bug是发散的。这时候我们往往会进行bug回归，但是我们经常会发现到了上线的时候，某些bug又出现了，或者因为代码提交的问题，或者因为其他模块修改的问题或者逻辑变更的问题，但是一个问题，线上有bug!其实我一直在想，对于这些bug,我们是否可以在上线前的某段时间进行一次粗略的回归呢？
7、Bug回归时，尽可能与开发沟通bug原因及修改方案。
这个在实际操作时是有困难的，因为哪些bug需要与开发沟通，开发是否有时间等都是影响因素，当然有人会提出由开发在处理bug时提交修改说明，这当然是最好的方式，但是与国内实际环境是不符的，因而我们是尽可能的与开发了解bug原因及修改方案，然后在bug跟踪系统中或者其他什么方式进行一个简明的说明，例如是初始化数据错误这样的原因，那么在后期我们进行bug分析时，就能从一个统计意义上的数据来对测试的测试设计及执行进行一个指导
责任编辑：
声明：本文由入驻搜狐号的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
今日搜狐热点}