缺陷管理
缺陷管理是把观察到的异常转成可以分析、决定和验证的工作记录，持续跟踪到有明确处置结果。提交一个“有问题”的截图只是起点：还需要知道发生在哪个版本、违反了哪条规则、怎样复现，以及修复后凭什么确认问题消失。
测试开发面试中的缺陷问题，重点在证据和判断。能说清一个缺陷如何被发现、定位和验证，比背一套固定状态名称更有用。
1. 面试核心
先记住这几条，再读正文- 缺陷报告要同时提供环境、前置、步骤、预期、实际和证据，使接手者能够建立同样条件。怀疑的原因应与观察事实分开。卡 · 观察事实与缺陷报告
- 严重程度描述失败影响有多大，优先级描述何时处理、先处理谁。两者相关，但不是同一个字段。卡 · 严重程度与优先级
- 状态流转应保留处置原因、版本和验证证据。“代码已修改”不等于“修复已经验证”。卡 · 状态与验证
- 复测确认原问题得到修复，回归检查变更是否破坏其他行为。两种目标都可能需要，范围由根因和影响决定。卡 · 复测与回归
- 开发不认可缺陷时，回到规则、复现条件与实际影响核对；需求歧义需要澄清，暂缓修复需要明确风险和负责人。卡 · 争议与漏测
- 漏测复盘需要区分没有设计、没有执行、没有断言和环境无法触发，据此选择改进，而不是简单增加用例数量。卡 · 争议与漏测
2. 观察事实与缺陷报告
程序表现异常，不一定已经证明产品代码有缺陷。测试数据错误、环境配置不同或预期理解有误，都可能造成失败。记录应先把差异说清，再分析原因。
下面是一份示例报告，所有标识均为演示值：
| 字段 | 内容 |
|---|---|
| 标题 | 已取消的上传请求重试后生成两条图片记录 |
| 环境 | 测试构建 build-example-17，单文件上传，普通账号，开启断点续传配置 |
| 前置 | 账号下无该文件记录，配额充足，文件内容合法 |
| 步骤 | 发起上传；服务端保存后延迟响应；客户端取消；以同一操作标识重试 |
| 预期 | 根据已确认的重试约定，只保留一条图片记录 |
| 实际 | 列表和服务端查询都返回两条记录，配额扣减两次 |
| 证据 | 操作标识 upload-example-1、两条记录 ID、对应日志和响应 |
| 复现情况 | 在相同受控条件下尝试 5 次，观察到 5 次 |
| 影响与建议 | 可能重复占用配额；严重程度与优先级按实际业务影响确认 |
标题描述触发条件和行为差异，比“上传失败”“后端有 bug”更利于定位。日志里如果只有某个超时，也只能说明该环节观察到超时，不能直接证明根因一定是网络。
证据要保留必要上下文，同时去除真实凭证、用户隐私等与复现无关的信息。复制一整份包含敏感数据的日志并不会自动让报告更完整；请求标识和最小输入通常更容易关联。
3. 严重程度与优先级
严重程度描述缺陷造成的影响，优先级描述处理顺序和紧迫性。等级名称由团队约定，但判断应有可说明的事实。
可以先核对受影响功能是否可用、是否损坏数据、影响范围、触发条件和是否存在可靠绕行方案。然后再结合上线时间、业务承诺、修复依赖与风险安排处理。
| 情况 | 影响判断 | 排序还要考虑什么 |
|---|---|---|
| 核心下单流程对全部用户失败 | 核心能力不可用，影响很大 | 当前是否线上、是否需要立即回退或止损 |
| 特定输入导致记录丢失 | 数据完整性受到破坏 | 是否持续产生损失、是否需暂停入口和修复数据 |
| 活动首页一个显眼文案错误 | 通常不破坏核心功能 | 是否即将公开投放、修改是否明确且低风险 |
| 尚未开放功能的局部错误 | 实际影响受开放范围限制 | 何时启用，是否会通过共用代码影响其他功能 |
不能仅凭“影响用户少”就判定问题轻微，少数用户的数据损坏也可能需要优先止损。反过来，易修改也不是立即处理所有外观问题的充分理由，需要看它占用了什么验证和发布成本。
4. 状态与验证
缺陷流程的核心是让每次决策可追溯，而不是要求所有团队使用相同英文状态。一个可理解的流程可以是：记录异常、分析确认、决定修复或其他处置、完成变更、等待验证、关闭或重新打开。
| 处置 | 应留下什么 |
|---|---|
| 修复 | 根因、变更范围、修复版本和待验证项目 |
| 重复 | 原缺陷链接，保留本次新增触发条件或影响证据 |
| 暂缓 | 当前影响、接受风险的人、后续触发条件或计划 |
| 非缺陷 | 适用规则及为何实际行为符合规则 |
| 无法复现 | 尝试过的环境、步骤与缺少的证据，保留后续调查入口 |
| 验证通过 | 实际验证版本、用例、结果和相关回归范围 |
不能因为开发者提交了代码就直接把缺陷判为验证通过。测试环境可能还没有部署修复版本，或者只修了一条触发路径；先核对部署与配置，再重建原始条件。
偶发问题也需要保留真实结果。连续尝试十次未复现，可以记录“该环境下十次未复现”，但不能改写原先确实出现过的失败证据。
4.1 复测与回归
复测是确认原缺陷已修复，通常重放原触发条件，并核对关键结果。回归测试检查变更是否破坏已有行为，范围来自根因及受影响组件。
如果上传去重修复改了公共请求标识逻辑，复测检查原来的重复记录，回归还应覆盖其他依赖相同标识的正常提交、真正的新请求和失败重试。范围不能只按“改了几行”决定，也不必对任何小修改都无差别运行所有昂贵流程。
适合自动化的最小复现可以留为回归用例。通用回归层次见 测试金字塔。
5. 争议与漏测
开发不认可缺陷时，先区分争议是什么：无法复现、预期不同、影响判断不同，还是知道问题但没有时间处理。不同原因需要不同证据。
无法复现就共同核对版本、配置、数据与时序；预期不同就查契约和需求；规则不清就请对应负责人确认并更新验收条件；只是排序不同，则明确影响、方案与风险接受决定。把所有情况都理解成“不配合”，无法推进实际问题。
线上漏测的复盘可以沿这条证据链检查：
| 缺口 | 需要追查 | 对应改进 |
|---|---|---|
| 没有识别条件 | 需求、风险或历史知识是否缺失 | 补规则分析和设计模型 |
| 用例存在但未执行 | 选择、门禁、跳过与环境阻塞 | 修复执行策略并保留未执行状态 |
| 执行了却未失败 | 断言是否检查真正结果 | 补独立期望和失败验证 |
| 环境无法触发 | 数据量、时序、版本或依赖差异 | 建立有针对性的环境与控制能力 |
| 失败被忽略 | 重试、告警和报告处理 | 保留首次失败，明确处置条件 |
面试里讲自己的缺陷经历时，应按真实贡献说明：观察到了什么、你确认了什么、谁修改了什么、如何验证。原因尚未查清就保留未知，不能把团队后续结论全部写成自己当时已经知道。
6 · 面试题卡片
本页题目与参考回答
6.1 一份有效的缺陷报告应包含哪些内容？
考察重点：复现条件、独立期望与证据完整性。
相关内容：观察事实与缺陷报告。
参考回答
应让别人能够重建条件并判断差异，包括环境版本、前置数据、操作步骤、预期依据、实际结果和关键证据。 再补充复现情况、影响范围与相关记录。
标题直接写触发条件和结果差异；日志、请求标识等用于关联实际执行。观察事实与根因猜测分开，暂时未知的部分不写成确定结论。
6.2 怎样判断缺陷等级，严重程度和优先级是否相同？
考察重点：影响事实、修复紧迫性与排序依据。
相关内容：严重程度与优先级。
参考回答
严重程度判断失败影响，优先级判断处理顺序，二者不能混用。 先看功能受阻、数据损坏、影响范围、触发条件与绕行方案，再结合上线时间和修复风险排序。
等级名称服从团队定义。少量用户的数据丢失仍可能很严重，外观错误也可能因公开活动时间而优先处理，不能只凭一个因素决定。
6.3 一个缺陷从发现到关闭通常经过哪些阶段？
考察重点：分析、处置、修复与验证的责任边界。
相关内容：状态与验证。
参考回答
通常经历记录、分析确认、处置决定、修复、验证和关闭，验证失败可以重新打开。 重复、暂缓和非缺陷等分支都应有理由与关联证据。
状态名称可以不同，但修复提交与验证通过必须区分。关闭时要能说明在哪个部署版本、用什么条件确认了结果。
6.4 原缺陷复测通过后，为什么还可能需要回归测试？
考察重点：原问题修复与变更影响的区别。
相关内容：复测与回归。
参考回答
复测只确认原触发条件下的问题已修复，回归还要检查变更有没有破坏其他既有行为。 公共校验、请求标识等共享逻辑的变化，可能影响没有出现在原缺陷里的调用方。
回归范围根据根因、依赖和风险选择，既不能只重跑原步骤，也不必不加区分地重复所有昂贵流程。
6.5 开发认为不是缺陷或者不愿修改，应怎样处理？
考察重点：争议分类、证据核对与处置决策。
相关内容：争议与漏测。
参考回答
先明确分歧是复现、预期、影响还是处理顺序，再针对性补证据。 共同核对环境与步骤，用需求或契约确认预期；规则不清就找对应负责人澄清。
确认存在问题但暂缓修复时，应记录影响、方案、风险接受决定和后续条件。不能只靠争论状态名称，也不能在没有处置依据时让问题消失。
6.6 测试遗漏了一个线上问题，应怎样复盘并改进？
考察重点：从缺口定位改进措施，避免只增加数量。
相关内容：争议与漏测。
参考回答
先重建触发链路，再确认缺口位于设计、执行、断言、环境还是失败处置。 不同缺口对应不同改进：缺少场景就补分析，已执行却没发现就检查断言，环境差异就补针对性验证。
保留最小复现及必要回归，并确认改进能让同类错误被发现。只增加测试条数、提高通过率或要求“以后更仔细”，无法证明问题得到解决。
7. 参考资料
来源：Coding 101 原文 · 免费阅读，引用请保留出处。内容使用说明