5.3 管理缺陷并回归：记录问题、修复问题、确认不再出错¶
发现问题不是失败，找不到、说不清、复现不了的问题才危险¶
修复一个问题，不等于系统已经更可靠
5.2 执行测试后，你可能发现页面提示不清、接口越权、重复提交、状态错误、数据库数据不一致或部署配置遗漏等问题。不要只在聊天记录里说“有 bug”，也不要边测试边随手改几行代码。
一个合格的缺陷管理过程应当形成闭环：发现现象 → 记录并复现 → 判断影响与优先级 → 定位原因 → 最小化修复 → Git 提交 → 重跑原用例 → 检查关联功能 → 更新记录。
本节学习目标
将测试中发现的问题整理为可追踪缺陷，优先修复阻断启动、核心流程、数据正确性和权限安全的问题；完成原用例回归与关联场景回归，形成缺陷清单、修复记录和回归测试结果。
🎯 本节完成后，你要交付¶
| 成果 | 要求 |
|---|---|
| 缺陷清单 | 每个问题都有编号、现象、复现步骤、影响、优先级和状态 |
| 缺陷修复记录 | 能够说明根因、修改位置、修复方式与对应 Git 提交 |
| 原用例回归结果 | 修复后重新执行导致问题的原始测试用例 |
| 关联场景回归结果 | 检查修复是否破坏登录、权限、状态、数据或相邻功能 |
| 未解决问题说明 | 对暂不修复的问题写明影响、原因、临时处理和后续计划 |
| 更新后的测试执行记录 | 失败项已更新为“已修复并通过”或保留真实状态 |
不允许用“已知问题”掩盖 P0 缺陷
项目不能启动、不能登录、核心流程无法完成、数据被错误修改或普通用户能越权操作，属于阻断或严重问题，必须修复后才能进入部署与交付。
一、什么是缺陷：不只是“程序报错”¶
缺陷是系统实际行为与需求、设计、接口约定或合理预期不一致的地方。它可能表现为错误提示，也可能“看起来成功”但数据已经错了。
常见缺陷类型¶
| 类型 | 典型现象 | 示例 |
|---|---|---|
| 启动与环境 | 项目无法启动、找不到配置、数据库无法连接 | README 说明的命令无法运行 |
| 功能缺失 | 需求中的功能没有实现或入口不可用 | 管理员无法编辑已发布活动 |
| 业务规则 | 系统没有按规则拒绝非法操作 | 名额已满仍可报名 |
| 数据正确性 | 数据重复、丢失、关联错误、统计不准 | 重复报名导致名额扣减两次 |
| 权限安全 | 未登录或无权限用户能够访问、修改数据 | 普通用户直接调用管理员删除接口成功 |
| 状态流程 | 状态跳转错误、跳过步骤、重复处理 | 已完成报修可以再次确认 |
| 接口协议 | 状态码、字段、参数或错误信息与约定不一致 | 参数错误仍返回成功 code |
| 页面体验 | 页面崩溃、提示不清、入口找不到、刷新丢失状态 | 空列表显示白屏而非空状态 |
| 部署配置 | 本机能运行，按 README 或 Docker 无法运行 | 环境变量缺失导致容器连不上数据库 |
先区分现象和根因
“点击报名没反应”是现象；根因可能是前端没有发送请求、接口地址错误、后端校验失败、数据库异常或权限拦截。缺陷记录先写清可观察现象，定位后再补充根因。
二、第一步：把测试失败写成可复现缺陷¶
一句“有 bug”不能帮助自己、同学或 AI 助手定位问题。缺陷记录必须让未参与测试的人也能复现。
1. 缺陷最小记录字段¶
| 字段 | 说明 |
|---|---|
| 缺陷编号 | 例如 BUG-001，全程保持不变 |
| 标题 | 用“条件 + 实际问题”描述，例如“已报名用户重复报名仍成功” |
| 来源用例 | 来自哪条测试用例，例如 TC-WORKFLOW-01-05 |
| 发现版本 | 分支、标签或提交编号 |
| 环境 | 浏览器、数据库、部署方式、账号等关键信息 |
| 前置条件 | 复现问题前必须具备的数据和状态 |
| 复现步骤 | 别人可以逐步照做的操作 |
| 预期结果 | 根据需求或规则，本应发生什么 |
| 实际结果 | 系统实际上发生什么 |
| 证据 | 截图、接口响应、日志、数据库查询结果 |
| 严重程度与优先级 | 影响有多大、修复是否紧急 |
| 状态 | 新建、处理中、待回归、已关闭、暂缓 |
2. 不合格与合格记录对比¶
不合格：
合格：
3. 不要把多个问题塞进一条缺陷¶
以下写法不利于修复：
应拆分为独立缺陷：
这样每个问题可以独立分配优先级、提交修复和回归验证。
三、第二步：评估严重程度和修复优先级¶
“看起来不舒服”和“会破坏核心数据”不能放在同一个优先级。先修高风险问题，避免在低价值优化上耗尽时间。
1. 缺陷严重程度¶
| 等级 | 定义 | 示例 | 交付前要求 |
|---|---|---|---|
| 阻断 | 系统无法启动、无法测试或核心流程完全无法继续 | 数据库初始化失败、所有用户不能登录 | 必须修复 |
| 严重 | 数据错误、权限绕过、核心流程错误或关键角色无法操作 | 普通用户可删除记录、重复扣库存 | 必须修复 |
| 一般 | 非核心功能错误，有替代方式但影响使用 | 查询条件无效、列表刷新不及时 | 尽量修复；未修复需说明 |
| 建议 | 文案、样式、低频体验问题 | 提示语不够清楚、按钮间距不一致 | 可列入优化清单 |
2. 与 P0/P1/P2 的关系¶
| 优先级 | 常见对应缺陷 | 处理原则 |
|---|---|---|
| P0 | 阻断、严重的启动、登录、核心流程、数据与权限问题 | 立即修复；回归通过前不能交付 |
| P1 | 重要功能失败、常见异常、重要页面体验 | 优先修复；无法修复需写明限制 |
| P2 | 非核心体验、低频边界、后续优化 | 记录即可，可在交付后继续改进 |
3. 一个简单的判断顺序¶
发现问题后依次问：
权限问题默认按严重处理
即使页面隐藏了按钮，只要普通用户可以直接通过接口、修改 URL 或篡改对象 ID 完成越权操作，就可能泄露或破坏数据，应按 P0 或至少严重问题处理。
四、第三步：定位问题，但不要盲目大改¶
定位的目标是找出最小根因和影响范围，不是借修一个 bug 顺便重写整个模块。
1. 从证据开始定位¶
| 证据 | 可以帮助判断什么 |
|---|---|
| 页面截图 | 用户看到什么、入口和提示是否正确 |
| 浏览器 Network | 请求是否发出、URL/参数/请求体是否正确、状态码和响应是什么 |
| 浏览器 Console | JavaScript 是否报错、前端数据处理是否异常 |
| 后端日志 | 哪个接口、服务、SQL 或异常发生问题 |
| 接口测试响应 | 不依赖页面时后端行为是否仍然错误 |
| 数据库查询 | 操作前后是否产生、修改或删除了正确数据 |
| Git diff / 日志 | 问题可能由哪次改动引入 |
2. 沿请求链路排查¶
对“点击按钮后结果不正确”的问题，可按以下顺序检查：
不要一看到页面异常就先修改 CSS，也不要一看到接口失败就先改数据库。先确认问题在哪一层出现。
3. 使用 AI 协助定位时的正确上下文¶
可以给 AI：
不要只说：
先确认方案，再让 AI 修改
AI 可能给出能临时通过当前用例的修复，但破坏其他流程。先理解它准备改哪些文件、为什么改、会影响什么，再执行修改。
五、第四步：最小化修复并保留 Git 证据¶
1. 一个缺陷一次只做一件事¶
推荐的修复节奏：
避免：
2. 修复前后对照记录¶
| 项目 | 内容 |
|---|---|
| 缺陷编号 | BUG-003 |
| 根因 | 服务层未判断当前用户是否已有该活动报名记录 |
| 修改文件 | RegistrationService.java、RegistrationMapper.xml |
| 修改方式 | 新增“用户 + 活动”唯一查询；重复时抛出业务异常 |
| 数据库调整 | 增加唯一约束（如适用） |
| 影响范围 | 报名创建接口、管理员报名统计、重复报名测试 |
| 原用例回归 | TC-WORKFLOW-01-05：通过 |
| 关联回归 | 首次报名、名额已满、管理员查询：通过 |
3. 提交信息应说明修复目的¶
提交前检查：
确认没有把数据库密码、构建产物、调试截图、无关格式化或未完成代码混入修复提交。
六、第五步：执行两层回归测试¶
修复完成后，至少完成两层验证：原用例回归与关联场景回归。
1. 原用例回归：确认问题本身已解决¶
原用例就是发现缺陷的那条测试用例。例如 BUG-003 来自 TC-WORKFLOW-01-05，修复后必须用同一账号、同一前置数据和同一步骤重新执行。
| 缺陷编号 | 原测试用例 | 修复前结果 | 修复后结果 | 状态 |
|---|---|---|---|---|
| BUG-003 | TC-WORKFLOW-01-05 重复报名 | 第二次成功 | 第二次被拒绝，数据不变 | 通过 |
如果修改后原用例仍失败，不要标记“待回归通过”，应继续保持“处理中”。
2. 关联场景回归：确认没有引入新问题¶
修复重复报名时，不能只验证“第二次被拒绝”，还应确认：
| 关联场景 | 为什么要测 | 预期 |
|---|---|---|
| 首次报名 | 新增校验不能误伤正常流程 | 正常报名成功 |
| 不同用户报名同一活动 | 校验范围应是“同一用户 + 同一活动” | 不同用户可正常报名 |
| 名额已满报名 | 规则之间不能互相覆盖 | 拒绝且原因正确 |
| 管理员查看名单 | 新增约束不能影响列表查询 | 数据仍正确显示 |
| 取消报名后再次报名 | 若业务允许，需要验证状态恢复规则 | 按需求允许或拒绝 |
3. 常见修改的关联回归范围¶
| 修改点 | 至少回归什么 |
|---|---|
| 登录、Token、Session | 登录成功、错误登录、退出、未登录访问、不同角色登录 |
| Filter / 拦截器 / 权限 | 正常用户访问、未登录访问、管理员访问、普通用户越权、静态资源访问 |
| 数据库表或 SQL | 新增、查询、修改、删除、历史数据读取、初始化脚本 |
| 状态转换规则 | 正常状态流转、非法跳转、重复操作、多角色后续操作 |
| 前端请求封装 | 列表、详情、表单提交、错误提示、登录过期跳转 |
| 公共工具或全局异常处理 | 至少两个不同模块的正常响应和错误响应 |
回归不是再测一遍全部系统
回归的范围由修改影响决定。小修复先测原用例和直接关联功能；改了公共认证、数据库脚本或全局组件时，回归范围必须扩大。
七、第六步：关闭、暂缓或重新打开缺陷¶
1. 缺陷状态建议¶
也可以使用：
但每种非“已关闭”的状态都必须说明理由。
| 状态 | 含义 | 使用条件 |
|---|---|---|
| 新建 | 已发现但尚未确认或处理 | 刚由测试发现 |
| 已确认 | 已复现，确认是系统问题 | 复现步骤和证据完整 |
| 处理中 | 正在分析或修改代码 | 有明确负责人或处理计划 |
| 待回归 | 代码已修复，尚未重新执行测试 | 有对应修复提交 |
| 已关闭 | 原用例与关联回归均通过 | 证据完整 |
| 暂缓 | 当前版本不处理 | P2 或已知限制，有后续计划 |
| 无法复现 | 按步骤无法再次出现 | 必须记录环境与尝试过程 |
2. 什么情况下不能关闭¶
下列情况都不能把缺陷标为“已关闭”：
- 只修改了代码，没有运行原测试用例；
- 页面看起来正常，但接口或数据库没有验证；
- 原问题消失，但关联功能出现新问题；
- 只在开发环境成功，部署环境没有验证；
- 找不到修复提交、测试证据或实际结果；
- 用手工改数据库绕过了问题。
3. 暂缓问题怎样说明¶
例如一个 P2 的体验问题可以暂缓：
P0 和严重权限、数据问题不能用“时间不够”直接暂缓。
八、维护缺陷清单与回归记录¶
建议在项目中创建：
缺陷清单模板¶
回归测试记录模板¶
九、用 AI 协助缺陷管理的边界¶
AI 可以帮助：
- 根据缺陷记录检查是否缺少复现步骤、预期结果或证据；
- 分析日志、堆栈、接口响应和相关代码；
- 给出可能的根因和最小修改建议；
- 根据改动范围列出建议回归测试点；
- 帮助整理缺陷清单和提交信息初稿。
AI 不能替代：
- 实际复现问题；
- 确认数据库是否被错误修改；
- 判断修复后的页面和接口是否真实通过；
- 虚构“已回归通过”的结果；
- 在没有理解影响范围时大规模重构代码。
推荐提示词¶
十、提交前自查¶
- 每个失败测试项已转化为独立缺陷记录；
- 缺陷记录包含版本、环境、前置条件、复现步骤、预期和实际结果；
- 已区分阻断、严重、一般和建议问题；
- P0 问题已优先处理，没有被随意暂缓；
- 修复前已确认根因或至少缩小影响范围；
- 每次修复尽量对应一个明确问题与一个 Git 提交；
- 修复后已重新执行原测试用例；
- 已根据改动范围执行关联回归；
- 只有原用例和关联回归通过后才关闭缺陷；
- 未修复问题已记录影响、原因、临时处理和后续计划；
- 没有用手工改数据库、临时改代码或虚构结果掩盖问题。
本节小结¶
缺陷管理的目标不是让清单看起来没有问题，而是让问题可追踪、修复可证明、质量可持续改进：
记录可复现问题 → 按影响排序 → 定位最小根因 → 小范围修复 → Git 留痕 → 原用例回归 → 关联场景回归 → 如实关闭或暂缓。
完成本节后，项目应解决影响启动、核心流程、数据和权限的关键缺陷。下一节将整理部署所需的配置、数据、环境变量和启动清单，为从开发环境走向可交付环境做准备。