调试、测试与发布检查
调试是用证据缩小原因范围，测试是把重要行为固定成可重复检查。先复现，再一次验证一个假设。
- 为一个真实故障写复现记录、根因说明、最小修复和防回归测试。
- 复现、缩小范围、假设和验证
- 演练调试、测试与发布检查后，应当为一个真实故障写复现记录、根因说明、最小修复和防回归测试，并保留权限响应、测试报告、证书状态、告警和恢复记录作为可重复检查的依据。
- 完成 7.2「Web 安全与秘密管理」
FOUNDATION
必须理解
调试是用证据缩小问题范围，测试是把已知行为变成可重复检查。AI 可以提出假设和生成测试，但真实输出、失败复现与验收责任仍在人。
本课依次讲清复现、缩小范围、假设和验证、单元、集成、端到端测试的不同价值和正常路径、边界、失败和回归，最后通过“添加回归测试，确认修复前失败、修复后通过”检查学习结果。
医生不会只听“我不舒服”就开药，而会询问症状、测量指标、排除假设。测试像固定体检项目，调试像针对异常进一步检查。
新增任务失败时，先复现并检查表单状态、Network 请求、服务端日志和数据库记录；修复后添加校验测试，防止相同问题回来。
复现、缩小范围、假设和验证
最小复现就是把无关东西都拿掉，只留下稳定触发错误的步骤、输入和环境。错误原文、堆栈、请求和日志比“还是不行”有用得多。
基础概念
调试是用证据从大量可能原因中逐步缩小范围。稳定复现描述触发条件，假设提出可被推翻的原因，实验每次只改变一个关键变量。
进一步理解
先写预期、实际、步骤、输入、环境和错误原文，再找到最小仍能触发问题的案例。最早的异常通常比最后的连锁报错更接近根因。
假设必须附带预测：如果原因是 X，检查 Y 应出现 Z。结果不符就放弃假设，而不是继续堆补丁。
新增任务失败时固定同一标题，查看表单事件、Network、服务端日志与数据库记录，确定请求究竟在哪一步停止。
看到报错位置不等于找到根因；错误可能在更早的数据输入产生，只在这里第一次被使用。
这一小节记住：先复现和收证据，再用单变量实验排除假设。
单元、集成、端到端测试的不同价值
单元测试盯一个小函数，集成测试看几个部分能不能配合，端到端测试则像真实用户一样走完整流程。它们覆盖不同，也有不同成本。
基础概念
单元测试检查小函数，集成测试检查多个部分协作，端到端测试从用户入口走完整系统。它们覆盖范围、速度和定位能力不同。
进一步理解
单元测试快且容易指出规则错误；集成测试能发现数据库、接口或组件连接问题；端到端测试最接近真实行为，但运行慢且受环境影响。
测试组合应按风险选择，不是端到端越多越好。核心规则用单元测试，关键边界用集成测试，少数主流程用端到端测试。
标题长度规则用单元测试，创建接口与测试数据库用集成测试，用户登录后新增任务用端到端测试。
测试层级描述检查边界，不等于文件夹名称。若所谓单元测试连接真实网络，它实际承担了更大的集成范围。
这一小节记住：让不同层级测试各自守住最适合的风险。
正常路径、边界、失败和回归
一个问题修好后，加回归测试能防止它悄悄回来。发布前还要检查构建、类型、依赖、环境变量、迁移，并在真实环境做一遍冒烟测试。
基础概念
正常路径验证理想输入，边界测试临界值，失败测试验证可恢复错误，回归测试把曾发生的问题固定成以后重复执行的检查。
进一步理解
修复前先让测试稳定失败，证明它确实捕获问题；修复后通过，证明行为改变；旧测试同时通过，降低副作用风险。
发布检查还包括构建、类型、配置、迁移、依赖和真实环境冒烟测试。测试通过不能替代对生产配置与数据的验证。
80 字符标题成功、81 字符返回字段错误；修复 Unicode 计数 Bug 后保留该输入作为回归用例。
回归测试不是复制所有手工步骤，而是保存能够准确触发旧错误的最小行为，并让它在以后每次相关变更中自动重跑。
这一小节记住：每个真实 Bug 都应留下能阻止它悄悄回来的验证。
AI COLLABORATION
AI 如何参与
在调试、测试与发布检查这一课，AI 负责根据真实材料解释复现、缩小范围、假设和验证并指出遗漏，学习者负责控制范围、执行修改和核对权限响应、测试报告、证书状态、告警和恢复记录。
推荐协作顺序
- 1
先把稳定复现步骤和四层证据发给 AI。
- 2
要求它只列三个可证伪假设，每个配一个区分实验。
- 3
找到根因后再让它补回归测试，不允许直接大改组件。
这是复现步骤、期望结果、实际结果、第一条错误和相关代码。请先列三个可证伪假设，每次只给一个检查动作。定位后提出最小修复，并建议一个能在修复前失败、修复后通过的测试。
基于证据的假设树，每次实验只改变一个变量；找到原因后补一项自动测试；调试、测试与发布检查的人工验收必须回到真实页面、请求、终端、测试或数据结果，不能用 AI 的文字说明代替。
人工检查清单
- 确认 AI 区分症状与根因，测试真的会在旧代码失败、修复后通过。
- 要求 AI 的根因结论引用复现步骤、日志或失败测试，并明确哪些仍是假设。
- 修复前确认用例失败，修复后重跑相关测试与完整发布检查，保存回归证据。
COMMON TRAPS
常见误区
下面三类问题会让任务看似完成，却经不起刷新、错误输入或真实环境检查。先看现象，再找原因和修正方法。
凭感觉同时改多处
- 你会看到
- 问题好了却不知道哪项有效
- 为什么发生
- 多个变量一起改变后，即使问题消失，也无法知道哪项修改起作用。
- 怎样纠正
- 一次只验证一个假设
只测试正常路径
- 你会看到
- 空值、重复点击和网络失败仍会出错
- 为什么发生
- 真实输入会包含空值、重复操作和网络故障，成功用例覆盖不到这些分支。
- 怎样纠正
- 为重要边界补失败用例
测试实现细节
- 你会看到
- 重构未改行为却大量失败
- 为什么发生
- 内部结构可以在行为不变时重构，绑定细节会制造没有用户影响的失败。
- 怎样纠正
- 围绕公开输入输出断言
HANDS-ON
动手任务
为一个真实故障写复现记录、根因说明、最小修复和防回归测试。
- 完成 7.2「Web 安全与秘密管理」
跟着做
- 01
选择一个可重复的小故障并写复现步骤。
- 02
收集页面、Network、服务端和数据库四层证据。
- 03
列出三个可证伪假设并安排最小实验。
- 04
定位根因并做最小修复。
- 05
添加回归测试，确认修复前失败、修复后通过。
为一个真实故障写复现记录、根因说明、最小修复和防回归测试。
为创建任务、刷新后确认存在、删除任务这条流程建立端到端冒烟测试说明。
离开本课前，自问四件事
- 稳定复现、假设和验证实验分别应该包含什么？
- 单元、集成与端到端测试各适合保护哪类行为？
- 一个 Bug 修复为何应先看到测试失败再看到它通过？
- 构建与测试成功后，上线前还需要检查哪些真实环境条件？
确认完成后，会同步更新学习中心的课程学习进度。