| name | test |
| description | 专注测试职能。用于编写/优化测试用例、执行单元测试与集成测试、产出测试报告。严禁修改任何业务代码，仅限操作测试代码。触发词包括"写测试"、"跑测试"、"单元测试"、"集成测试"、"test"、"/test"。 |
Test - 测试技能
根据 plan 文档编写并执行单元测试与集成测试，产出结构化测试报告。该技能的核心目标是验证而非修复。
职能边界
- 绝对禁令：禁止修改任何非测试相关的业务源码。即便发现 bug，也只能在测试报告中记录并建议修复，不得自行调用
/implement 或手动修改源码。
- 操作范围：仅允许修改、新增测试文件、测试目录内容，或项目明确归类为测试资产的文件。
- 输出目标：高质量的测试代码覆盖及详尽的
test.md 测试报告。
核心原则
- 以 Plan 为准：测试用例严格基于
plan.md 中的验收标准与测试规范。
- 验证驱动：所有职能围绕“证明代码是否符合预期”展开。
- 独立报告：测试结果必须固定产出到对应的
test.md 文档中。
- 可调用外部 Skill/工具：需要环境观测、运行验证、引擎执行或自动化操作时可调用相应工具。
工作流程
阶段一：单元测试
-
阅读 Plan 的测试标准
- 阅读对应功能
plan.md 中的"单元测试标准"。
- 提取每个 TODO 的验收标准。
-
编写/优化单元测试
- 仅在测试目录或项目既有测试命名约定下编写代码。
- 覆盖正常路径、边界条件、异常场景。
-
执行单元测试
- 运行项目测试命令或测试入口（如
vitest、npm test、pnpm test、dotnet test、Unity Test Runner）收集结果。
-
失败分析与记录
- 如果测试失败：
a. 分析是测试代码本身的逻辑错误，还是业务代码的 bug。
b. 如果是测试代码写错了，直接在测试文件中修正。
c. 如果是业务代码 bug，停止修改行为，将失败原因、错误日志及重现步骤记录到测试报告中。
阶段二：集成 / 场景验证
-
阅读 Plan 的集成测试标准
- 阅读对应功能
plan.md 中的"集成 / 场景验证标准"。
-
编写并执行集成 / 场景验证
- 根据场景编写独立的测试脚本、测试用例或自动化验证流程。
- 捕获命令输出、退出码、运行结果、日志或截图作为执行证据。
阶段三：产出测试报告
按照下方固定模板撰写，写入对应功能的 test.md。
固定模板
# <功能名称> 测试报告
> 关联 Spec：<spec 文档路径>
> 关联 Plan：<plan 文档路径>
> 测试日期：YYYY-MM-DD
> 测试环境：运行时 / OS / 版本 / 其他相关信息
## 测试总结
| 指标 | 数值 |
| -------------- | ---- |
| 单元测试总数 | N |
| 单元测试通过 | N |
| 单元测试失败 | N |
| 集成测试总数 | N |
| 集成测试通过 | N |
| 集成测试失败 | N |
| 总体通过率 | N% |
## 单元测试详情
### ✅ 通过的测试
| 测试文件 | 测试用例 | 对应 TODO |
| --------------- | -------- | --------- |
| `path/to/test` | 测试描述 | TODO-S1 |
### ❌ 失败的测试
#### [FAIL-1] <测试用例名称>
- **测试文件**：`path/to/test`
- **对应 TODO**：TODO-XX
- **失败原因**：详细描述（明确区分是测试错误还是业务 bug）
- **修复建议**：针对业务 bug 提出修改建议
- **错误日志**：
相关的错误输出
## 集成 / 场景验证详情
### 场景 1：<场景名称>
- **操作步骤**：...
- **期望结果**：...
- **实际结果**：✅ 符合预期 / ❌ 与预期不符
- **证据**：命令输出 / 日志 / 截图路径 / 运行结果
## 未覆盖的测试场景
列出 Plan 中要求但本次未覆盖的测试场景及原因。
## 遗留问题
列出需要人工关注的问题（如环境限制、业务代码存在的风险点等）。
关键约束
- 禁止跨权：严禁调用
/implement 技能或者直接去尝试修复业务逻辑。
- 测试独立性：每个测试用例应独立运行，不依赖其他测试的执行顺序。
- 不修改 spec/plan：测试过程中发现 spec 或 plan 的问题，记录到报告中，不自行修改。
- 证据完整：每个关键测试场景必须有可验证的执行证据。
