对BUG的分析与理解

发表于:2019-10-28 11:21

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:Nigo    来源:博客园

#
Bug
#
bug
分享:
  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无效后,改为此状态,表明开发人员拒绝操作是合理的。只有项目组负责人有置无效的权限。)

      本文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号