6. Bug 生命周期和缺陷管理怎么回答？
Bug 生命周期是软件测试面试高频问题。
很多人只会背：新建、指派、修复、回归、关闭。这个答案太简单，面试官更想听你怎么把缺陷跟踪到闭环。
一、先说标准生命周期
一个常见 Bug 生命周期是：
- New：测试提交缺陷；
- Assigned：指派给开发；
- Open：开发确认并处理；
- Fixed：开发修复完成；
- Retest：测试回归验证；
- Closed：验证通过后关闭；
- Reopen：验证不通过重新打开。
不同公司字段可能不一样，但核心都是发现、确认、修复、验证、关闭。
二、提交 Bug 要写清楚关键信息
一个高质量 Bug 通常包含：
- 标题；
- 所属模块；
- 环境信息；
- 前置条件；
- 复现步骤；
- 实际结果；
- 预期结果；
- 严重程度；
- 优先级；
- 截图或录屏；
- 日志、接口请求、数据库信息。
标题要简洁明确，比如“订单支付成功后订单状态仍显示待支付”。
三、严重程度和优先级要区分
严重程度表示问题对系统的影响。
比如：
- 阻塞：系统崩溃、核心流程不可用；
- 严重：主要功能异常、数据错误；
- 一般：普通功能问题；
- 轻微：文案、样式、易用性问题。
优先级表示修复紧急程度。
有些 Bug 严重但不紧急，有些 Bug 不严重但上线前必须立即修。
四、开发不认 Bug 怎么办
这是面试常见追问。
可以这样处理：
- 先确认需求文档和验收标准；
- 补充复现步骤、截图、日志和数据；
- 和开发一起复现问题；
- 如果是需求不明确，拉产品确认；
- 如果影响上线，升级给测试负责人或项目负责人评估风险。
不要回答“和开发吵”，也不要说“开发说不是 Bug 我就关了”。
五、偶现 Bug 怎么处理
偶现 Bug 不能简单忽略。
处理思路：
- 记录出现时间、账号、环境和操作路径；
- 查看接口请求和响应；
- 查看前端控制台和服务端日志；
- 尝试不同浏览器、网络、数据复现；
- 统计出现频率；
- 提供尽可能多的上下文给开发。
如果偶现问题影响核心链路，要持续跟进。
六、回归测试不是只点原步骤
Bug 修复后，回归要验证：
- 原问题是否解决；
- 相同模块是否受影响；
- 相关功能是否被改坏；
- 数据是否修复；
- 是否引入新问题。
比如修复优惠券计算 Bug 后，不只测这张券，还要测满减券、折扣券、不可叠加券等相关规则。
七、缺陷分析能体现测试价值
成熟测试不只是提 Bug，还会分析 Bug。
可以从这些维度统计：
- 哪些模块 Bug 多；
- 哪类问题占比高；
- 哪个阶段发现问题最多；
- 是否存在需求理解不一致；
- 是否有重复缺陷；
- 是否需要补充评审或自动化。
这能体现测试对质量改进的贡献。
八、面试回答模板
可以这样回答：
Bug 生命周期一般是测试发现并提交缺陷，指派给开发确认和修复，开发修复后测试回归验证，通过后关闭，不通过则重新打开。提交 Bug 时我会写清楚环境、前置条件、复现步骤、实际结果、预期结果、严重程度、优先级，并尽量附上截图、日志、接口请求和数据库信息。如果开发不认 Bug，我会依据需求文档和验收标准沟通，必要时拉产品确认。回归时不仅验证原问题，还会覆盖相关影响范围，避免引入新问题。
这个答案既有流程，也有实际处理经验。
九、下一步建议
建议你准备两个真实 Bug 案例：
- 一个功能 Bug；
- 一个接口或数据一致性 Bug。
每个 Bug 都按“现象、定位、原因、修复、回归”来讲。
配套刷题：
