对BUG的分析与理解

Posted 2020-11-13 lxc1997ye

对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无效后，改为此状态，表明开发人员拒绝操作是合理的。只有项目组负责人有置无效的权限。）