文章目录一. 简介二. 角色与职责分工三. Bug 处理流程1. 提交缺陷2. 指派缺陷3. 确认缺陷4. 推迟处理5. 处理缺陷6. 回归缺陷7. 关闭缺陷四. Bug 处理意见五. Bug 报告1. Bug 报告模版2. Bug 报告要素一. 简介Bug 处理流程包含了从测试人员提交 Bug 到最终解决问题的一系列步骤。这个过程可以在特定的缺陷管理工具上进行二. 角色与职责分工在整个 Bug 处理流程中其实涉及到了多个角色。下面就来看看不同的角色对 Bug 的职责是什么。三. Bug 处理流程Bug 处理流程也可以叫做 Bug 的生命周期。1. 提交缺陷测试人员在提交缺陷时应尽可能详尽地描述其属性包括 Bug 的重现环境、Bug 类型、Bug 等级、Bug 优先级以及详细的复现步骤、实际结果与预期结果等。此外提交前务必确认该缺陷尚未被记录以免造成重复提交。2. 指派缺陷缺陷指派可由项目经理或测试人员执行具体人选视项目模式而定测试与开发部门独立有些公司测试部门与开发部门独立那么测试人员就不确定自己测试的模块是由哪位开发人员负责的在这种情况下测试人员统一把问题指派给项目组长或经理由项目组长或经理对问题进行确认后再次分配给相应的开发人员。测试人员嵌入研发团队有些测试人员是穿插到不同研发团队中的所以对不同的开人发员负责的开发模块非常清楚这个时候就可以将问题直接指派给相应的开发人员。3. 确认缺陷缺陷确认环节通常由开发人员、项目经理或产品人员负责。在接到缺陷报告后首要任务是进行分析与复现。若经分析发现该问题并非缺陷例如因测试人员对需求理解有误或无法复现则需将问题驳回给测试人员并附上详细原因说明。若确认问题属实则进入后续处理流程。4. 推迟处理缺陷确认属实后还需进一步评估是否需要推迟处理。对于部分已确认为缺陷的问题若其仅在极端场景下触发、修复涉及系统架构调整或优先级较低可暂不处理留待后续版本统一修复。5. 处理缺陷开发人员在确认完一个问题需要处理时那么就对其进行处理工作。6. 回归缺陷缺陷回归是测试人员的重要职责主要包括以下三种情况确认非缺陷问题开发人员将缺陷标记为非问题或无法复现后转交测试人员回归验证。测试人员需再次确认——若确实不属于缺陷则关闭该问题若因问题描述模糊或其他原因导致开发人员未能复现则补充说明后重新转回开发人员处理。确认修复问题对开发人员已修复的缺陷进行回归验证。验证通过则关闭缺陷验证未通过则重新打开并转回开发人员继续处理。确认遗留问题对已标记为遗留的缺陷进行定期复查。部分遗留问题可能随版本迭代已经自然消失了对这类问题应该及时关闭若遗留问题依然存在且优先级升高则重新打开并指派给开发人员处理。7. 关闭缺陷对于已经修复的缺陷测试人员进行关闭。四. Bug 处理意见对于一个 Bug 来说最终的处理方式可能都有哪些这个处理意见其实就是我们 bug 在提交之后去确定我们的 Bug 到底要怎么处理。可修改 (Fixable)可修改。表示 Bug 可以被修复或更正。重复 (Duplicated)重复。表示该 Bug 已经被其他测试人员找出来了或者开发任务原因是相同的。推迟处理 (Postponed)延后。由于时间、进度、重要程度或者技术/需求等方面的原因认为不能解决、须延期解决、或者本版不做留待到后续版本解决的 Bug。设计问题 (By Design)因设计结构问题无法修改。不可复现 (Can’t Reproduce)不可复现。不是问题 (Not Error)不是问题。不修改 (Won’t Fix)这个 Bug 是一个错误但还没有重要到非要更正不可的地步可以忽略不计。五. Bug 报告当测试人员发现缺陷后需填写一份缺陷报告Bug 报告来记录问题并以此向开发人员清晰传达缺陷详情。一份高质量的缺陷报告不仅能有效提升开发人员修复缺陷的效率还能增强测试部门的专业信誉促进测试与研发之间的协作。Bug 报告描述得越准确、越详尽开发人员定位和修复问题所耗费的时间就越少测试人员的信誉度与对产品的贡献度也将随之提升。1. Bug 报告模版在没有 Bug 管理平台的时候一般都会在设计好的 Bug 报告表单中填写这些信息。下面是一个 Bug 报告的示例。但是通过表单管理还是非常的不方便所以现在都会在管理平台(jira)中去进行 Bug 管理这样既方便填写也方便和其他人员进行沟通更能很方便的跟踪 Bug 的状态。2. Bug 报告要素Bug 报告中需要包含的要素有以下几方面Bug 编号所属产品发现的版本所属的模块提交人错误类型复现概率严重级别优先级标题言简意赅说明是什么 bug内容描述测试环境 - 前提条件 - 复现步骤 - 预期结果 - 实际结果附件截图、出错的 log 日志、测试用的数据