对BUG的分析与理解

Posted lxc1997ye

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了对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% 等,当然,对于短时间内可以修复的问题就没必要时时的去更新处理进度。)

回归缺陷

回归缺陷对于测试人员来说是非常重要的工作,其有三个入口两个出口。
  确认非缺陷问题:对于提交的一个缺陷,开人员处理为非问题或无法重现,然后直接转交给测试人员回归。测试人员再次确认,如果真如开发人员所说,则将问题关闭。如果非开发人员所说,是由于问题描述模糊或其它原因喂重现问题,则再次注明原因转给开发人员。
  确认修复问题:对开发人员修复的问题再次进行确认,确认能过,则关闭问题。确认不通过,将问题再次打开并转给开发人员。
  确认固定问题:有计划的对固定问题进行确认,有些固定问题随着时间的推移,版本的更新或已经不存在了,对这类问题应该及时关闭。有些固定问题依然存在且变得紧急,对于这类问题应该及时打开交给开发人员处理。

关闭缺陷

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

过程描述

  1. 测试工程师开始执行测试,发现bug则新建bug,这时bug是新建状态。
  2. 测试组负责人把bug修改为打开状态,表明开发人员可以修改该bug了。之所以会有打开这一步有两点目的:第一是测试组负责人对bug进行确认工作,避免提交错误的bug,第二是对bug进行一次筛选操作,告诉开发组本次需要修复哪些bug。(这一步需要测试组的负责人验证所有的bug,有些麻烦,我经历过的项目都是新建完bug后,由提bug的人直接打开,如果确实不应该提,大不了增加一个无效bug,影响不大)
  3. 开发工程师找到状态为打开的bug,不会立即进行修复,也需要判断是否接受该bug,接受则修改bug,修改完成后把bug状态置为已修复。如果不接受则置为拒绝。
  4. 测试工程师找到已修复的bug,在下一版本验证bug,如果确实已经修改正确,则把bug状态置为关闭,该bug生命周期结束。
  5. 拒绝的bug必须由项目组的负责人判断拒绝是否有效,如果无效,则重新打开,进入修复过程。如果确实无效,则添加备注说明信息,该bug生命周期到此结束。(关于拒绝这一步,还可以新增一个无效状态。在项目负责人确认bug无效后,改为此状态,表明开发人员拒绝操作是合理的。只有项目组负责人有置无效的权限。)

以上是关于对BUG的分析与理解的主要内容,如果未能解决你的问题,请参考以下文章

深入理解python虚拟机:调试器实现原理与源码分析

从编程角度理解什么是蜜罐

对于软件开发中开发人员与测试人员关系的理解

oracle 游标分析与理解(基础)

ThreadLocal的理解与应用场景分析

对动态规划算法的理解及相关题目分析