test

name	test
description	专注测试职能。用于编写/优化测试用例、执行单元测试与集成测试、产出测试报告。严禁修改任何业务代码，仅限操作测试代码。触发词包括"写测试"、"跑测试"、"单元测试"、"集成测试"、"test"、"/test"。

Test - 测试技能

根据 plan 文档编写并执行单元测试与集成测试，产出结构化测试报告。该技能的核心目标是验证而非修复。

职能边界

1. 绝对禁令：禁止修改任何非测试相关的业务源码。即便发现 bug，也只能在测试报告中记录并建议修复，不得自行调用 /implement 或手动修改源码。
2. 操作范围：仅允许修改、新增测试文件、测试目录内容，或项目明确归类为测试资产的文件。
3. 输出目标：高质量的测试代码覆盖及详尽的 test.md 测试报告。

核心原则

1. 以 Plan 为准：测试用例严格基于 plan.md 中的验收标准与测试规范。
2. 验证驱动：所有职能围绕“证明代码是否符合预期”展开。
3. 独立报告：测试结果必须固定产出到对应的 test.md 文档中。
4. 可调用外部 Skill/工具：需要环境观测、运行验证、引擎执行或自动化操作时可调用相应工具。

工作流程

阶段一：单元测试

1. 阅读 Plan 的测试标准

   • 阅读对应功能 plan.md 中的"单元测试标准"。
   • 提取每个 TODO 的验收标准。

2. 编写/优化单元测试

   • 仅在测试目录或项目既有测试命名约定下编写代码。
   • 覆盖正常路径、边界条件、异常场景。

3. 执行单元测试

   • 运行项目测试命令或测试入口（如 vitest、npm test、pnpm test、dotnet test、Unity Test Runner）收集结果。

4. 失败分析与记录

   • 如果测试失败： a. 分析是测试代码本身的逻辑错误，还是业务代码的 bug。 b. 如果是测试代码写错了，直接在测试文件中修正。 c. 如果是业务代码 bug，停止修改行为，将失败原因、错误日志及重现步骤记录到测试报告中。

阶段二：集成 / 场景验证

1. 阅读 Plan 的集成测试标准

   • 阅读对应功能 plan.md 中的"集成 / 场景验证标准"。

2. 编写并执行集成 / 场景验证

   • 根据场景编写独立的测试脚本、测试用例或自动化验证流程。
   • 捕获命令输出、退出码、运行结果、日志或截图作为执行证据。

阶段三：产出测试报告

按照下方固定模板撰写，写入对应功能的 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 的问题，记录到报告中，不自行修改。
• 证据完整：每个关键测试场景必须有可验证的执行证据。