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