专栏名称: 51Testing软件测试网
51Testing软件测试网,人气最旺的软件测试技术门户,提供软件测试社区交流,软件测试博客,人才服务,测试沙龙,测试杂志,测试资料下载等全方位信息服务,是国内最专业的软件测试就业培训、企业服务供应商...
目录
相关文章推荐
51好读  ›  专栏  ›  51Testing软件测试网

BUG有哪些分类?一个BUG完整的生命周期又是怎样的?

51Testing软件测试网  · 公众号  · 测试  · 2019-10-28 17:30

正文

点击上方蓝色字体,关注我们



bug的分类


  bug,其实就是软件期望的行为与实际行为的差异。从程序的角度来看,在软件整个生命周期中都会有bug的出现。需求分析过程中,需求理解的不足,导致的理解错位 ,遗漏甚至变化都可能导致bug;设计本身有好坏之分,但是bug本身还是比较隐晦,不是那么明显。编码阶段,也会有理解错误,语言特性,第三方库框架,等等导致的bug. 后期打包,部署,运维也会产生 bug,打包的错误,配置错误,以及环境的错位。自己主要谈谈编码引入的和环境的导致bug。这是最最经常碰到的bug。
  另外也可以从其他方面开分类,比如稳定可重现的bug与不可稳定重现的bug。比如多线程导致的竞争。数据敏感的导致的不能稳定重现的bug。从是否与环境关联,业务逻辑的bug,环境相关的的bug等。

一个BUG的生命周期


  缺陷状态
  对于一个问题,其处理过程是一个周期,周期的不同阶段,其所处的状态也是不一样的。不同状态所对应的处理人也是不一样的。
  打开 :表示问题被提交等待有人处理。
  重新指派 :问题被重新指派给某人处理。
  处理 :问题在处理中,尚未完成。
  固定 :确认此问题存在,但暂时不进行处理。
  回归 :对已经修复的问题进行回归确认。Reopened
  关闭 :问题的最后一个状态。
  提交(打开)缺陷
  在提交一个缺陷的缺陷,首先尽量描述这个缺陷的属性。Bug重现环境,bug类型,bug等级,bug的优先级以及详细的重现步骤,结果与期望等。
  当然,我们在提交一个问题之前首先应该保证,这个缺陷是没有被提过的,以免造成重复缺陷单。
  如果是回归不通过的缺陷,其状态又会变为打开状态。
  分配(转交)缺陷
  这一步不是必须的,跟项目模式有关,有些公司测试部门与开发部门独立,那么测试人员就不确定自己测试的模块是由哪位开发人员负责的,在这种情况下,测试人员统一把问题指派给项目组长或经理,由项目组长(或经理)对问题进行确认后再次分配给相应的开发人员。
  有些测试人员是穿插到不同研发团队中的,所以对不同的开人发员负责的开发模块非常清楚,这个时候就可以将问题直接指派给相应的开发人员。
  也有一种情况,本来此问题应该由A开发人员负责,但由于A开发人员的调离或辞职,些问题为转交给其它人员处理。“分配”强调是上级对下级;“转交”强调的是平级之间。
  确认缺陷
  当开发人员接到一个缺陷时,首先是对其进行分析与重现,如果对其进行分析发现不是缺陷(可能由于测试人员不了解需求)或无法对此问题进行重现,那么就需要将此问题反回给测试人员,并注明原因。如果确认为缺陷则需要对其进行处理。
  推迟处理
  在处理问题之后,还需要进行一次判断,是否需要推迟处理,有些需求已经确认了是问题,由于其可能在极端情况下才会出现,或需要对系统架构进行改动,或其优先级非常低,所以暂时不需要对此问题进行处理(或到下个版本进再进行修复)。
  固定
  对于推迟处理的问题可以暂时进行固定(“固定”为QC中的叫法。)一般固定的问题需要经过项目经理与测试经理协商后才能固定。
  处理缺陷
  开发人员在确认完一个问题需要处理时,那么就对其进行处理工作。(例如,redmine 是支持处理人时时更新问题处理进度的,如 已处理30% ,已处理80% 等,当然,对于短时间内可以修复的问题就没必要时时的去更新处理进度。
  回归缺陷
  回归缺陷对于测试人员来说是非常重要的工作,其有三个入口两个出口。
  确认非缺陷问题:对于提交的一个缺陷,开人员处理为非问题或无法重现,然后直接转交给测试人员回归。测试人员再次确认,如果真如开发人员所说,则将问题关闭。如果非开发人员所说,是由于问题描述模糊或其它原因喂重现问题,则再次注明原因转给开发人员。
  确认修复问题:对开发人员修复的问题再次进行确认,确认能过,则关闭问题。确认不通过,将问题再次打开并转给开发人员。
  确认固定问题:有计划的对固定问题进行确认,有些固定问题随着时间的推移,版本的更新或已经不存在了,对这类问题应该及时关闭。有些固定问题依然存在且变得紧急,对于这类问题应该及时打开交给开发人员处理。
  关闭缺陷
  对于已经修复的缺陷进行关闭,这也是一个缺陷的最后一个状态。
  过程描述
  测试工程师开始执行测试,发现bug则新建bug,这时bug是新建状态。
  测试组负责人把bug修改为打开状态,表明开发人员可以修改该bug了。之所以会有打开这一步有两点目的:第一是测试组负责人对bug进行确认工作,避免提交错误的bug,第二是对bug进行一次筛选操作,告诉开发组本次需要修复哪些bug。(这一步需要测试组的负责人验证所有的bug,有些麻烦,我经历过的项目都是新建完bug后,由提bug的人直接打开,如果确实不应该提,大不了增加一个无效bug,影响不大)
  开发工程师找到状态为打开的bug,不会立即进行修复,也需要判断是否接受该bug,接受则修改bug,修改完成后把bug状态置为已修复。如果不接受则置为拒绝。
  测试工程师找到已修复的bug,在下一版本验证bug,如果确实已经修改正确,则把bug状态置为关闭,该bug生命周期结束。
  拒绝的bug必须由项目组的负责人判断拒绝是否有效,如果无效,则重新打开,进入修复过程。如果确实无效,则添加备注说明信息,该bug生命周期到此结束。(关于拒绝这一步,还可以新增一个无效状态。在项目负责人确认bug无效后,改为此状态,表明开发人员拒绝操作是合理的。只有项目组负责人有置无效的权限。




原文链接:

https://www.cnblogs.com/lxc1997ye/p/11521318.html

本文为51Testing经授权转载,转载文章所包含的文字来源于作者。如因内容或版权等问题,请联系51Testing进行删除。

推荐阅读

点击阅读☞Bug产生前就能预防它的发生?这样的自动化测试我是很想体验一下!

点击阅读☞我是这样搞懂一个神奇的BUG

点击阅读☞一文教你区分前端BUG和后台BUG

点击阅读☞如何高效填写软件缺陷报告

点击阅读☞简单易懂的缺陷分析笔记

“阅读原文”一起来充电吧!
爱我请给我“在看”!
推荐文章
环球旅行  ·  我的天呐,微信居然有隐身功能
7 年前
军武次位面  ·  裤裆保卫战:二战美军性教育
7 年前