耍起最队｜StudyDay Alpha冲刺测试随笔

本轮Alpha以两条流程作为阶段展示重点：课表→任务→专注→历史，以及AI问答→保存确认→转笔记预览→正式笔记。测试围绕这两条路径展开，兼顾学习/生活任务的区别、本人资源访问、重复操作和失败提示。

本文汇总七天材料，并补充对同一版本代码的实际测试。本次两批后端选跑合计18个顶层用例通过；前端选跑55项通过。 团队交付说明中的接口回归和人工演示记录另列，避免重复统计。

目录

一、测试工作安排

1. 测试如何跟随开发推进

围绕课程指定的《构建之法》第2章和第13章，本轮将测试分成开发者自测、模块联调和阶段回归。开发时先验证输入、状态和返回值，模块接入后检查接口约定，收尾时再按用户流程核对页面与数据结果。

下表依据七天开发随笔、阶段标签、仓库测试源文件和最终交付材料归纳。Day表示材料中的相对阶段，补测结果不倒填为当日已执行。

2. 测试协作分工

以下沿用原岗位说明测试协作职责。个人实际提交以Git/MR和工作项为依据，公共测试结果不拆成每人的独立提交。

问题处理按“记录版本与步骤→定位接口或状态→修改→重跑对应自动用例→回看主流程”推进。对可重复出现的协议和状态问题，优先保留自动用例，方便后续改动时继续检查。

3. 范围与环境

本次自动化复核使用Windows、Go 1.26.10和Node.js 24，对上述main版本执行既有测试。Go业务依赖主要由Mock隔离；前端测试使用纯逻辑、模拟状态或本机HTTP夹具。HTTP夹具会经过实际HTTP请求，但服务端由测试代码提供。

团队演示材料采用本地Docker Compose和Chrome 390×844视口。该环境及截图属于成员的阶段运行资料，本次助手未重新启动Compose或调用真实模型。华为云、多物理设备、真实库并发和长时间运行尚未纳入本次补测结论。

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

仓库还提供演示前检查脚本demo-preflight.sh，用于检查服务、供应商配置日志及演示账号/数据准备情况。它用于演示准备，不单独作为全部功能通过的依据。

本次没有新增测试框架，也没有将Python脚本当作Go业务测试的替代。Python只用于组织执行、解析日志和整理用例文档。

三、测试用例文档

1. 用例设计与结果口径

用例记录包括编号、前置条件或输入、操作、预期结果、实际结果及源码位置。我们主要检查：

• 类别与权限： 学习/生活任务、本人/他人课程或笔记、合法/非法输入。
• 状态变化： 待办→专注运行→结束；回答处理中→保存确认→允许转笔记。
• 边界与重复： 默认/超范围专注时长、正常结束时间、重复结束、同来源重复确认。
• 失败恢复： 模型失败、保存失败、读取失败与未确认操作恢复。

下方“通过”只针对已经执行的对应测试及其断言。后端顶层用例内可以包含多个场景，统计时仍按一个顶层用例计算；未运行覆盖率工具，不提供覆盖率百分比。

2. 后端选定用例与实测结果

U01—U12来自本次整理前已完成的同版本补测；U13—U18为编写本篇时针对规则与异常覆盖补跑。两批测试名互不重复，合计18个顶层用例通过，0失败。多数Service测试替换了数据库或模型依赖，属于逻辑/契约验证。

其中，U13验证了生活任务带课程时应被拒绝；U10与U14/U15覆盖专注的开始、运行和结束规则；U17区分生成失败与保存失败；U18检查预览整理失败后仍保留原文。

SSE Handler断言摘录：

assert.Equal(t, http.StatusOK, w.Code)
assert.Contains(t, w.Header().Get("Content-Type"), "text/event-stream")

body := w.Body.String()
assert.Contains(t, body, "event: accepted")
assert.Contains(t, body, "event: delta")
assert.Contains(t, body, "event: saved")

代码来自backend/internal/handler/contract_test.go，省略请求和Mock夹具。同一顶层用例还验证失败事件与3001。Service测试进一步检查事件顺序。当前实现是在完整模型回答保存后发出delta和saved，本次没有把它描述为上游逐token流式输出。

3. 前端自动化测试

本次选跑12个测试文件，共55项通过，0失败、0跳过。

一个重要用例是：文字已经完整出现，仍需要等待保存确认后才允许转笔记。 以下是frontend/tests/state.test.js中已执行用例的核心逻辑：

const message = {
  role: 'ASSISTANT', generationStatus: 'SUCCESS', content: '完整回答'
}
assert.equal(canConvert(message), false)
applyEvent(message, 'accepted')
applyEvent(message, 'delta', { text: '更多文字' })
assert.equal(canConvert(message), false)
applyEvent(message, 'saved', { content: '最终回答' })
assert.equal(canConvert(message), true)

这类检查能直接对应产品规则，避免只凭页面出现文本就显示“已保存”。前端HTTP夹具还验证读取失败后的重试，以及恢复已有专注后继续结束的状态处理。

D5历史截图中92项通过对应成员提供的0.5.1测试记录；本篇55项对应0.5.2的选跑范围，两者分开保留。

4. 功能与集成检查清单

下表记录用户路径、现有结果及待补验证。团队报告和截图能够支持阶段展示，但没有逐项原始记录的部分继续写清边界。

这份清单的前置条件、具体操作和源码/材料位置另附在“功能与集成检查清单.csv”中。未完成的真实环境检查保留为下一阶段任务，不混入18项Go和55项前端的通过数。

阶段运行材料示例：

图1：专注提前结束：显示29秒及任务需手动完成

图2：AI问答：界面显示回答已确认保存

图3：正式笔记：接口数据、内容版本1及来源摘录

三张图均来自docs/alpha/assets/的Alpha综合演示归档。它们展示界面结果，不单独证明真实供应商、刷新前后持久化、事务或并发验收。

5. 问题发现与修复核对

以下编号是本文整理编号，非平台Issue编号。旧版问题依据前五天记录及源码对照，新版状态依据D6/D7提交和补测结果；未另造“修复前测试失败”的日志。

6. 结果汇总与复现

regression.sh本身没有发起真实模型调用；重复笔记检查通过SQL准备成功回答来源，AI失败项固定跳过。这些范围随结果一起保留。

本次六项补测可在仓库backend目录复现：

go test -mod=readonly '-gcflags=all=-l -N' -p=2 -parallel=1 \
  -count=1 -timeout=90s -json \
  -run '^(TestCreateTask|TestStartFocus|TestActiveFocus|TestCreateNote|TestSendMessage|TestPreviewFallsBackToRawContent)$' \
  ./internal/service/task ./internal/service/focus \
  ./internal/service/note ./internal/service/chat

保留gcflags用于mockey运行。上述换行写法适用于Bash；PowerShell可将命令写成一行。完整的18项Go与55项前端选跑命令见随附“选定测试复现命令.md”，原始JSON/TAP日志在“测试日志”目录。

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

本轮AI测试助理参与代码对照、选定用例执行和结果整理。下面区分本次实际辅助工作与可继续复用的提问方式，不把建议生成的场景写成已经执行。

AI生成用例后，仍要对照需求确认预期。例如“专注结束后自动完成任务”不符合本轮流程；“收到完整回答就开放转笔记”也缺少保存确认条件。这些判断需要由团队依据业务规则把关。

本轮没有编造节省时间或效率提升百分比。AI的帮助体现在快速定位源码、整理边界和复用执行流程；通过与否由实际输出及人工核对决定。真实模型、数据库并发和云部署仍需要相应环境中的测试。

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

1. 测试体会

接口约定应成为可执行的检查。 问答的JSON/SSE差异、创建接口的multipart字段，都会影响整条流程。把请求格式、返回字段和事件顺序写进测试后，后续修改更容易发现不一致。

预期结果需要先说清业务规则。 学习任务是否必须选课程、生活任务能否带课程、专注结束是否同时完成任务、笔记何时正式创建，都决定断言如何写。讨论用例的过程也能帮助团队核对需求理解。

状态恢复值得单独测试。 正常点击成功只是其中一种情况。读取失败、已有运行记录、结束响应丢失和保存失败，都需要明确用户看到什么、接下来能够做什么。

测试报告需要说明证据范围。 Mock适合快速验证规则，本机HTTP夹具适合验证客户端协议；数据库事务、模型供应商和云端入口则需要真实环境记录。写清范围，后续成员才能知道哪些结果可复用、哪些还要补测。

2. 本轮做得较好的方面

• 测试材料能够对应七天开发主题，涵盖课表、任务、专注、问答和笔记的核心规则。
• D6将实际对接问题落实到Handler契约测试，保留了可重复运行的检查。
• 通过可控时间和依赖替换测试专注及AI异常分支，避免反复等待计时或消耗模型额度。
• 同版本选跑结果、团队原报告和综合演示素材分开归档，便于追溯。
• 关键运行图能够说明29秒提前结算、回答保存确认，以及带来源的正式笔记。

3. 当前不足

本次补测仍以选定单元/契约用例和前端逻辑为主。真实MySQL事务与并发、完整浏览器自动操作、真实供应商失败及华为云验收尚缺完整证据。390px视口记录也不能覆盖多浏览器和多物理设备。

另外，部分过程材料只有汇总结果，缺少逐条请求、环境和执行时间；历史截图与最新代码没有完整构建哈希对应。下一阶段需要在记录时同步固定这些信息。当前未执行覆盖率、负载、长稳或完整安全测试，不据本轮通过数推断这些指标。

4. 下一阶段改进

Alpha阶段已完成核心流程交付，本篇确认的是对应材料及上述范围的测试结果。后续将优先补充真实环境中的异常与一致性验证，再随功能扩展维护回归用例。

参考与材料入口：

• 本次作业要求。
• 测试随笔目录结构参考：仅参考栏目组织。
• 《构建之法》第2章、第13章。
• StudyDay仓库：测试源文件、七天阶段材料与docs/alpha/交付文档。