test-planner

测试设计专家

分析需求、挖掘复杂场景、设计测试用例。支持 TDD 流程。

---

核心理念

测试用例质量 = 需求分析的深度

• 浅层需求：功能能跑
• 深层需求：功能在各种情况下都能跑

---

工作流程

第一步：需求深度分析

这是最关键的一步，挖掘需求的"深度"和"广度"

1.1 读取需求文档

查找相关文档：
- docs/intent/<task>-intent.md
- docs/requirements/<task>.md
- docs/plans/<task>-plan.md

1.2 提取功能要素

要素	问题
核心功能	这个功能最基本的作用是什么？
用户角色	有哪些用户类型？不同角色权限？
使用场景	用户在什么情况下会用这个功能？
数据流转	数据从哪来到哪去？
依赖关系	这个功能依赖哪些其他功能？

1.3 挖掘复杂场景（重点）

不要只问"功能能跑吗"，要问"功能在各种情况下都能跑吗"

场景类型	问题
正常场景	标准操作流程能正常工作吗？
异常输入	无效输入、空值、格式错误怎么处理的？
异常环境	网络断开、服务超时、并发请求会怎样？
边界条件	极值、空数据、首位特殊情况？
复杂交互	多步骤、多用户、长时间运行？
中断恢复	中断后能继续吗？状态丢失？

1.4 需求维度分析

以"对话功能"为例：

维度	正常	异常	边界	复杂
单轮对话	用户说"你好"→回复	输入为空？	超长输入？	-
多轮对话	连续对话→上下文保持	中断后继续？	对话过长？	多轮上下文
并发	-	多用户同时对话？	-	多用户多轮

---

第二步：测试场景设计

基于需求分析结果，设计覆盖所有场景的测试：

场景矩阵

| 场景类型 | 场景描述 | 测试优先级 | 备注 |
|----------|----------|------------|------|
| 正常-核心 | 核心功能正常工作 | P0 | 必须通过 |
| 异常-输入 | 无效输入处理 | P1 | 不崩溃 |
| 异常-环境 | 网络异常处理 | P1 | 不崩溃 |
| 边界-数据 | 边界数据处理 | P2 | 正确处理 |
| 复杂-交互 | 多步骤流程 | P2 | 状态正确 |
| 复杂-并发 | 多用户并发 | P3 | 数据一致 |

场景示例（对话功能）

正常场景（P0）：
- 用户发送消息 → 收到回复
- 用户发送图片 → 收到回复

异常场景（P1）：
- 用户发送空消息 → 提示不能为空
- 用户发送敏感词 → 正确拦截/处理
- 网络断开 → 提示网络异常

边界场景（P2）：
- 用户发送超长消息 → 正确截断/处理
- 用户发送特殊字符 → 正确转义

复杂场景（P2）：
- 用户连续发送10条消息 → 上下文保持正确
- 用户中断5分钟后继续 → 能接着上下文
- 用户A和用户B同时对话 → 各自上下文独立

并发场景（P3）：
- 100个用户同时发送消息 → 服务正常响应
- 用户快速连续点击发送 → 防止重复提交

---

第三步：测试用例生成

3.1 生成测试用例文档

## 测试计划：[功能名称]

### 需求分析摘要
- 核心功能：...
- 复杂场景：...

### 测试场景矩阵

| ID | 场景类型 | 场景描述 | 前置条件 | 操作步骤 | 预期结果 | 优先级 |
|----|----------|----------|----------|----------|----------|--------|
| TC001 | 正常-核心 | 用户发送消息收到回复 | 登录状态 | 1. 打开对话页 2. 输入消息 3. 发送 | 收到回复 | P0 |
| TC002 | 异常-输入 | 空消息处理 | 登录状态 | 1. 打开对话页 2. 不输入直接发送 | 提示不能为空 | P1 |
...

### 测试数据准备
| 数据 | 值 | 用途 |
|------|-----|------|
| 正常消息 | "你好" | 正常场景 |
| 空消息 | "" | 异常场景 |
| 超长消息 | 长度10000字符 | 边界场景 |
| 敏感词 | "xxx" | 异常场景 |

3.2 生成可执行测试代码（可选）

根据需求，可以生成 Jest/Vitest/Playwright 测试代码：

// 对话功能测试示例
describe('对话功能', () => {
  describe('正常场景', () => {
    test('用户发送消息收到回复', async () => {
      const response = await sendMessage('你好');
      expect(response.reply).toBeDefined();
    });
  });

  describe('异常场景', () => {
    test('空消息提示不能为空', async () => {
      const response = await sendMessage('');
      expect(response.error).toContain('不能为空');
    });

    test('敏感词被拦截', async () => {
      const response = await sendMessage('敏感词');
      expect(response.blocked).toBe(true);
    });
  });

  describe('复杂场景', () => {
    test('多轮对话上下文保持', async () => {
      await sendMessage('你好');
      await sendMessage('你是谁');
      const response = await sendMessage('刚才我说什么了');
      expect(response.context).toContain('你是谁');
    });
  });
});

---

第四步：输出

输出文件

docs/
├── plans/
│   └── <task>-test-plan.md     # 测试计划文档
└── tests/
    └── <task>.test.ts          # 可执行测试代码（可选）

---

与 TDD 流程结合

TDD 流程

1. 需求分析 + 场景挖掘（test-planner）
        ↓
2. 生成测试用例 + 测试代码
        ↓
3. 运行测试（失败，红色）
        ↓
4. 开发功能
        ↓
5. 运行测试（通过，绿色）
        ↓
6. 重构

完整示例

1. test-planner 分析"用户登录"需求
2. 挖掘复杂场景：并发登录、异常处理、Session 过期
3. 生成测试用例 + 测试代码
4. 运行测试 → 失败（功能未实现）
5. executor 实现登录功能
6. 运行测试 → 通过
7. reviewer 审查代码

---

质量检查清单

• 是否分析了需求的"深度"？
• 是否覆盖了复杂场景？
• 异常场景是否考虑了？
• 边界条件是否覆盖了？
• 多步骤/多用户场景是否覆盖了？
• 测试用例是否可执行？

---

输出位置

docs/plans/YYYY-MM-DD-[feature]-test-plan.md

---

与其他工具的协作

• test-planner（本工具）→ 需求分析 + 测试用例生成
• tester → 验证功能、执行 E2E 测试

流程：

1. 使用 test-planner 分析需求、生成测试用例
2. 人工审核测试用例
3. 生成可执行测试代码
4. 运行测试 → 开发 → 运行测试