目录

历阶 Helix 是一个智能学习计划平台：用户输入学习目标，系统经"检索 → 分析 → 生成 → 排期"四段流水线生成可执行的计划草案，确认后进入日常打卡与 FSRS 复习调度，并通过阶梯式层级体系、层级测试与 AI 助手追踪学习成长。

一、测试工作安排

项目前期的测试主要依靠人工逐页点选界面，也为此付出过代价：一处接口返回结构的修改，导致多个页面同时出现异常，只能将主流程重新完整走查一遍后才敢提交。这正是"回归测试"在书中被专门论述的原因——困难不在于发现缺陷本身，而在于每次改动之后"确认没有影响其他功能"的成本过高，且这一成本会随功能增多持续上涨。

七日冲刺（10 月 23 日至 29 日）里，每天的测试焦点如下：

这一安排对应《构建之法》第 13 章：首尾两次冒烟先确认系统能够运行、联调前再确认主链路跑通；前几天的用例在后续反复执行，相当于小步回归，将回归成本分摊到每一天。

分工上，计划明确"测试任务融入当日开发"，测试由一名同学全程负责。自动化以接口层为切入点：冲刺期间用例执行以手工为主，接口层在冲刺后半程用 Apifox 整理成一份可重复执行的测试清单，收尾的全链路冒烟由清单实测与页面走查共同完成；单元测试已在冲刺期间用 Vitest 落地。

二、测试工具的选择和运用

项目选定如下工具——其中 Vitest 与 Apifox 是直接的测试工具，其余为配套的质量保障工具。

三、测试用例文档

冲刺期间的用例设计沉淀为三份测试用例文档，与三个测试层一一对应：功能测试用例文档档覆盖页面功能与交互，接口测试用例文档覆盖后端接口，单元测试用例文档覆盖纯逻辑模块。

功能测试用例文档：每条用例按"前置条件、测试步骤、预期结果、实测结果、结论"五要素编写，不通过项与五份测试问题报告的登记一一对应——如抽屉与层级测试弹窗叠开、今日看板详情弹窗五个按钮无响应、甘特图过去日期无法改期；文档只保留用例与结论，现场截图与根因分析索引至对应报告，修复后按原步骤逐条回归。

接口测试用例文档：用例按"权限控制 → 认证流程 → 业务功能 → AI 接口"分层组织，组间依赖会话状态、按执行顺序排列——A 组专测未登录，B 组建立会话，其后各组复用登录态；输入设计采用等价类划分与场景法，每条用例除校验状态码外，同步核对统一响应契约（成功 {"data":...}，失败 {"error":{"code":...,"message":...}}）。幂等重发（同一 Idempotency-Key 连发两次返回同一 id、第二次多出 cached: true）、登录前后 401 与 200 的对照、删除计划后复查列表等用例共同构成业务结果证据链。

单元测试用例文档：测试对象限定为不碰数据库、不发网络请求、不依赖当前时间的纯逻辑单元——组件交互归浏览器测试，数据库链路归接口集成测试，AI 接口因团队共用密钥计费仅做参数校验。文档同时记录了两条过程要点：一条会话篡改用例的初版因构造方式失误而首跑失败，属用例自身缺陷而非被测代码缺陷，说明测试代码同样需要检验；依赖真实日期的模块不纳入单测、会话有效期以假时钟模拟过期，体现时间依赖的处理原则。

四、AI 技术员在自动化测试中的作用

下面将整个冲刺里 AI 在测试端的用法集中说明。我们为 AI 设定的定位十分明确：**它是初稿生成器和分析器，不是决策者。**具体有三个用途。

用途一：生成测试用例初稿。 将一个功能的需求描述交给 AI，由其先行列出一版用例清单，我再逐条评审：删除冗余项，补充其未能覆盖的边界。AI 在枚举"机械性边界"上十分擅长——Day 3 的模型降级用例中，超时、配额耗尽、网络中断这些异常分支它列举得迅速且全面；但它对业务语义存在盲区，"层级未点亮时测试入口不应存在"这类隐含业务规则它完全无法想到，恰好对应我们实际遇到的问题。因此我的结论是：AI 生成的用例适合作为底稿，异常分支交由它枚举，业务前置条件必须由了解需求的人补充——这也是 测试设计方法的一次人机分工：机械枚举交给 AI，业务判断留给人。三份测试用例文档的骨架，都是在 AI 初稿基础上评审修订而成，效率远高于从零编写。

用途二：消化新依赖并准备测试方案。 冲刺期间接入 py-fsrs、Tavily 这类此前未使用过的依赖时，由 AI 讲解它们的工作方式与测试思路（如何 mock 检索响应、如何构造 FSRS 的输入数据），为单元测试的落地做技术准备，远快于从零查阅文档。前提不变：AI 给出的任何方案，我都必须理解其原理才写入清单或文档——测试基础设施若不为自己所理解，后续维护将极为困难。

用途三：分析报错和定位根因。 冲刺中多条问题的代码层分析，均按"AI 先给分析方向、我逐条验证"的方式完成。典型如弹窗不可点击问题，由 AI 协助将三处 CSS 层级与渲染顺序的代码串联，才确认了"三类因素叠加"的根因；接口实测中非法 id 触发 500 的排查遵循同一方式——由 AI 先给出"路径参数未校验、数据库 uuid 语法错误被全局兜底"的分析方向，我逐行读路由代码核实后才写入问题报告。每一条的最终结论都由我本人打开代码核实。AI 将排查时间从"翻阅文档半小时"压缩至几分钟，但最终把关始终在人。

当然也要明确其局限。一是业务语义盲区，隐含前置条件需要人工补充；二是成本约束——我们的大模型接口按量计费，测试自动化不能以真实调用反复压测，Day 3 的降级用例全部基于 Mock 而非真实请求，Day 7 的接口清单直接将 AI 正常链路排除在接口层实测之外；三是 AI 生成的任何代码都必须经过人工评审与 ESLint 门禁才能进入仓库。AI 提升的是效率，测试的准确性仍然取决于用例设计的质量，取决于人。

五、测试体会与项目测试评述

体会方面，最大的变化是测试观的转变。此前认为测试是流水线的最后一道工序，现在确信最好的测试是让缺陷在成本最低的阶段被发现：一个 Hooks 用法问题，ESLint 在提交前即时拦截；拖延至验收阶段才发现，返工的就是一整条功能链路。Day 1 的环境与契约冒烟完成后，全组对质量明显更有信心——测试前置的体感比任何理论都更有说服力。其次，对单元测试价值的认识由"负担"转向"保障"：编写用例是当期投入，回报在之后的每一次改动中——冲刺收尾落地的 33 条 Vitest 用例已能一键回归，这一判断开始得到检验。最后是"用例即文档"：Day 2 编写用例时小组争论的表面是预期结果，实际是需求本身，许多理解偏差在编写用例的过程中即已消解；而"预期结果要随代码改动同步更新"也让我认识到，用例是活文档，维护成本必须提前纳入计划。

对项目测试工作的评述，先说做得好的方面：测试真正融入了冲刺的每日节奏而非堆积于末尾；七天里数轮页面走查加一轮接口实测，每天产出测试问题报告、累计登记 22 条问题，每一条都附有复现步骤、证据截图与根因分析移交开发，执行、回填、问题清单、反馈开发形成闭环；工具选型贴合技术栈，静态检查这道零成本防线每日都在发挥作用；契约先行使前后端并行开发有共同规格可依，接口清单按会话状态分组、按费用写明取舍，测试范围经过设计而非随意执行。不足也很明显：单元测试起步于冲刺收尾，覆盖限于五个纯函数模块，UI 组件测试几乎空白，交互细节仍依赖人工；依赖外部服务的模块（大模型、检索、记忆服务）自动化程度为全项目最低，多数只能依靠 Mock 与降级用例覆盖；测试仅在本地执行，尚未接入持续集成；路径参数格式校验这类低危健壮性问题仍登记在待修复清单中。下一步的改进方向：将 npm run lint、npx tsc --noEmit 纳入每日自查，固化为两道门；扩充 Vitest 用例至配额降级、排期冲突等尚未覆盖的纯函数，并搭建 Playwright 冒烟链路接入 GitHub Actions，使每次 push 自动执行回归；为外部依赖建设统一的 Mock 通道，将检索降级、账号隔离等用例纳入自动化；路径参数校验这类修复成本极低的问题排入迭代，修复后按问题报告中写明的回归顺序验证。

回头看，《构建之法》第 2 章和第 13 章阐述的道理并不深奥，但只有真正在冲刺中被回归测试考验过、被前置条件阻碍过、被 ESLint 拦截过，那些概念才会转化为自己的经验。七天冲刺里，测试从"最后一道工序"变为"每天的节拍"，操作手册、三份测试用例文档与七份问题报告都沉淀为文档——这是我此次 α 冲刺最大的收获，也为 β 冲刺奠定了可直接复用的基础。