木鸡 SteadyGame Alpha 冲刺测试随笔：从“能跑”到“可回归”

目录

一、测试工作怎么安排

这次 Alpha 冲刺只有七天，测试不能等开发做完再补，只能和开发并行。我们的安排是：

具体做法：

1. 每次合并前自测：前端 npm test、npm run build，后端 mvn test、mvn verify；
2. 每天主干统一跑一次：避免“各分支都绿、合起来红”；
3. 缺陷走 Issue：记录复现步骤、预期/实际、影响范围，修复后补回归用例；
4. 测试也留证据：保留原始输出、JSON 结果、截图和提交记录，不用一句“已测试”代替结果。

测试分工

按《SteadyGame Alpha 七天开发与协作计划》，测试不是某一个人的专职工作：

• 前 6 天各自开发、各自准备可执行样例和自测；
• 第 7 天全员集中测试，每个人都要执行自己模块以外的用例；
• 模块负责人负责修复缺陷和提供复现样例，不负责“自己证明自己通过”；
• 修复后由非修复人重跑失败用例，共用碰撞改动还要回归小球和水果。

二、测试工具选择和运用

我们没有追求“工具越多越好”，而是按“能测什么、测不了什么”来选。

测试分层大致是：

单元测试（Vitest / JUnit）
  → 契约测试（OpenAPI 字段、状态码、错误码）
    → 集成测试（H2 / 真实 MySQL）
      → 端到端（回放 → 预检 → 提交；浏览器 + 摄像头）
        → 手工验收（真机、弱光、遮挡、多人）

三、测试用例文档

用例主要放在三类位置：

• src/**/*.spec.ts：前端单元/组件用例；
• server/src/test/java/**：后端 service、controller、repository 用例；
• docs/acceptance/*.md、docs/baduanjin/*.md：验收清单与真机记录；
• contracts/SteadyGame.openapi.json：接口契约，测试直接读取比对。

举几组实际用例：

1. 八段锦阶段机

2. 回放与提交

3. 数据与接口

4. 页面与输入

四、实际测试结果

Day7 当前工作树（feat/integration-linchen-day7）的测试结果：

当前自动化统计：

前端 377/377
后端 73/73
构建通过

这些数字只代表自动化用例和构建，不代表真实摄像头、真实 MySQL 全链路、非空导出和部署已经通过；这几项在验收边界里单独说明。

测试证据

【插图 01：Day7 测试结果汇总】

测试结果汇总页：前端 377/377、后端 73/73、构建通过。

【插图 02：本机运行的玩法首页】

玩法首页：本机 Vite 站点，三种玩法入口正常显示。

【插图 03：准备页面（摄像头未授权）】

准备页：摄像头未授权时“开始训练”保持禁用。这张图证明页面状态，不证明识别成功。

【插图 04：训练页预览】

训练页：路由和预览区已打开，但未开始真实训练。截图只能证明页面可展示，不能证明摄像头识别通过。

【插图 05：统计与报告页面回归】

统计页错误态、统计页样例数据、报告页空态。

【插图 06：报告与榜单页面回归】

报告页错误态、榜单页错误态、榜单页样例数据。

【插图 07：历史与导出页面回归】

历史页空态、导出页阻塞态、导出页演示状态。

以上 9 张图用于证明页面四态和样例展示，不是真实接口、真实训练或导出成功的凭据；原图在 测试随笔-图片/页面回归状态/。

冲刺中还遇到过这些真实问题：

1. MySQL 启动失败：secure-file-priv 指向的 Uploads 目录不存在，服务只报“无法启动”，日志才有真实原因；
2. MediaPipe 模型加载失败：public/models、public/mediapipe/wasm 未执行 npm run setup:pose，手机端 404；
3. 摄像头出流但姿态启动失败：<video> 还没出第一帧就启动推理，判 video_unavailable；
4. 结束训练报 outcome 不一致：提前结束时玩法按实际进度返回 aborted，协调器请求的是 completed；
5. 同意接口 501：后端 CameraConsentGateway 只有接口没有实现；
6. 提交接口 501：BaduanjinService 曾是占位实现。

这些问题说明：“接口存在”“测试绿了”“页面能点”都不等于链路可用。

五、测试体会

1. 自动化测“确定性”，手工测“真实世界”

阶段机、计分、提交重试这类纯逻辑，用固定输入跑几百个用例很划算；但摄像头权限、弱光、遮挡、多人、手机浏览器兼容，自动化很难覆盖。两者不是替代关系。

2. 固定输入比“多点几次”可靠

八段锦的回放脚本把 7.2s 的动作、每段时长、尝试次数都固定下来。改规则后，时间线一变就能看出来；没有固定输入时，测试绿了也说不清是修对了还是换了个错法。

3. 断言要测行为，不要测实现细节

断言要测行为，不要测实现细节：错误场景应该断言状态码、错误类型或页面状态，不要依赖可变的提示文案。

4. 环境也是测试的一部分

Java 24 下 JaCoCo 0.8.12 插桩报 Unsupported class file major version 68；jsdom 没有真实 Canvas；模型文件被 Git 忽略；MySQL 目录权限不对就起不来。这些都不是业务 bug，但会让测试结果不可信，必须在测试记录里写清楚。

5. 不要把测试数量当质量

377 项通过听起来很多，但其中大量是纯函数用例；真正决定体验的摄像头、保存、导出、真机链路，仍然要靠集成和手工验收。测试报告应该同时写“通过了什么”和“没覆盖什么”。

六、项目测试评述

做得好的

• 有明确分层：单元、契约、集成、端到端、手工；
• 真实 MySQL 和真实 HTTP 冒烟，不是只用 mock；
• 八段锦用固定脚本回放，问题可复现；
• 提交重试区分 409/429/5xx，覆盖了真实网络异常；
• 每天保留测试原始输出、截图和 Issue 证据。

还不够的

1. 没有 CI 门禁：测试靠人工在合并前跑，容易出现“分支绿、主干红”；
2. 没有浏览器自动化：Playwright/Cypress 缺失，页面四态和移动端仍靠手工；
3. 真机验收不足：摄像头、弱光、多人、不同手机浏览器没有形成完整矩阵；
4. 覆盖率没有门槛：JaCoCo 有报告，但没有“低于多少不能合”；
5. 测试与实现会漂移：契约变更后，旧用例没有同步更新。

建议

• 在 CodeArts 或本地脚本里加一条“合并前必跑”流水线；
• 给核心模块设覆盖率下限，但不追求 100%；
• 用 Playwright 覆盖登录、准备、结算、历史四条主路径；
• 把真机验收表变成发布清单，未执行项不能标“通过”；
• 每次契约变更必须同步更新契约测试和用例文档。

七、AI 技术员在测试中的作用

这次冲刺中，AI 技术员主要做了四类事：

AI 确实提高了写用例和造数据的效率，但也带来两个风险：

1. AI 会写出“看起来对”的测试：比如只断言函数被调用，不检查参数和结果；或者把实现细节写进断言；
2. AI 容易过度 mock：mock 掉数据库、摄像头、网络后，测试全绿但真实链路仍然失败。

我们的做法是：AI 生成的用例必须能在真实工程里跑，必须有明确的输入/预期；涉及真实设备、数据库、摄像头的结论，必须由人执行并留证据。没有执行的验证，不写成“已通过”。

八、结语

Alpha 冲刺的测试工作，最大的收获不是“写了多少用例”，而是学会了区分三种状态：

代码写了 ≠ 功能可用
测试绿了 ≠ 真实链路通过
页面能点 ≠ 用户可以完成

测试的价值，是让团队在合并前就知道“哪里会坏、为什么坏、坏了怎么复现”。自动化能守住确定性，手工验收才能守住真实体验；AI 可以加速前者，但不能替代后者。