bug的生命周期你知道吗？一张图带你看懂它！

最新推荐文章于 2023-03-13 15:16:26 发布

龙洋静

最新推荐文章于 2023-03-13 15:16:26 发布

阅读量1.2k

点赞数 1

分类专栏：测试文章标签： bug

本文链接：https://blog.csdn.net/LYJbao/article/details/128305852

版权

35 篇文章 6 订阅

订阅专栏

1、什么是bug

软件的bug狭义方面可以理解为是指软件程序的漏洞或缺陷，广义方面除找到程序漏洞之外，还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等等。

即测试的介入可以从需求分析开始，跟踪开发流程。

生命周期状态：发现bug——>提交bug——>指派bug——>研发确认bug——>研发去修复bug——>回归验证bug——>是否通过验证——>关闭bug

上图：

a.发现bug

b.提交bug

在提交一个bug时，需要尽量描述这个bug的属性、bug出现的环境、bug类型、bug等级、bug的优先级以及详细的重现步骤、结果和期待等

c.指派bug

这一步不是必须的，跟项目模式有关，有些公司测试部门与开发部门独立，那么测试人员就不确定自己测试的模块是由哪位开发人员负责的，在这种情况下，测试人员统一把问题指派给项目组长或经理，由项目组长（或经理）对问题进行确认后再次分配给相应的开发人员。

有些测试人员是穿插到不同研发团队中的，所以对不同的开人发员负责的开发模块非常清楚，这个时候就可以将问题直接指派给相应的开发人员。

也有一种情况，本来此问题应该由A开发人员负责，但由于A开发人员的调离或辞职，些问题为转交给其它人员处理。“分配”强调是上级对下级；“转交”强调的是平级之间。

d.确认bug

当开发人员接到一个缺陷时，首先是对其进行分析与重现，如果对其进行分析发现不是缺陷（可能由于测试人员不了解需求）或无法对此问题进行重现，那么就需要将此问题反回给测试人员，并注明原因。如果确认为缺陷则需要对其进行处理。

e.修复bug

　　在处理问题之后，还需要进行一次判断，是否需要推迟处理，有些需求已经确认了是问题，由于其可能在极端情况下才会出现，或需要对系统架构进行改动，或其优先级非常低，所以暂时不需要对此问题进行处理（或到下个版本进再进行修复）。

　　对于推迟处理的问题可以暂时进行固定（“固定”为QC中的叫法。）一般固定的问题需要经过项目经理与测试经理协商后才能固定。

　　开发人员在确认完一个问题需要处理时，那么就对其进行处理工作。（例如，redmine 是支持处理人时时更新问题处理进度的，如已处理30% ，已处理80% 等，当然，对于短时间内可以修复的问题就没必要时时的去更新处理进度。）

f.回归验证BUG

回归缺陷对于测试人员来说是非常重要的工作，其有三个入口两个出口。

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