Bug处理流程

Bug 处理流程

Bug 处理流程包含了从测试人员提交 Bug 到最终解决问题的一系列步骤。这个过程可以在特定的缺陷管理工具上进行。

在整个 Bug 处理流程中，其实涉及到了多个角色。下面就来看看不同的角色对 Bug 的职责是什么。

Bug 处理流程其实也可以叫做 Bug 的生命周期。

测试人员在提交一个缺陷的缺陷，首先尽量描述这个缺陷的属性。Bug 重现环境，Bug 类型，Bug 等级，Bug 的优先级以及详细的重现步骤，结果与期望等。当然，在提交一个问题之前首先应该保证，这个缺陷是没有被提过的，以免造成重复缺陷单。

这一步可以由项目经理或者是测试人员进行，具体人选与项目模式有关。

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

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

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

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

开发人员在确认完一个问题需要处理时，那么就对其进行处理工作。

回归缺陷对于测试人员来说是非常重要的工作，有下面几种情况。

确认非缺陷问题：对于提交的一个缺陷，开人员处理为非问题或无法重现，然后直接转交给测试人员回归。测试人员再次确认，如果真如开发人员所说，则将问题关闭。如果非开发人员所说，是由于问题描述模糊或其它原因喂重现问题，则再次注明原因转给开发人员。

确认修复问题：对开发人员修复的问题再次进行确认，确认能过，则关闭问题。确认不通过，将问题再次打开并转给开发人员。

确认遗留问题：有计划的对固定问题进行确认，有些遗留问题随着时间的推移，版本的更新或已经不存在了，对这类问题应该及时关闭。有些遗留问题依然存在且变得紧急，对于这类问题应该及时打开交给开发人员处理。

对于已经修复的缺陷测试人员进行关闭。

对于一个 Bug 来说，最终的处理方式可能都有哪些？这个处理意见其实就是我们 bug 在提交之后去确定我们的 Bug 到底要怎么处理。

当测试人员发现一个 Bug，需要填写一份“缺陷报告”也就是 Bug 报告来记录这个 Bug，并通过这个 Bug 报告告知开发人员所发生的问题。

好的 Bug 报告可以提高研发修改缺陷的速度、提高测试部门的信用度、增强测试和研发部门的协作。

Bug 报告写的越好，在实际中为了修改这个 Bug 花费的时间相对来说就会越少，测试人员的信誉度和产品的贡献度也会很好的提升。

在没有 Bug 管理平台的时候，一般都会在设计好的 Bug 报告表单中填写这些信息。下面是一个 Bug 报告的示例。

但是通过表单管理还是非常的不方便，所以现在都会在管理平台中去进行 Bug 管理，这样既方便填写，也方便和其他人员进行沟通，更能很方便的跟踪 Bug 的状态。

总结一下，Bug 报告中需要包含的要素有以下几方面：