test-runner

name	test-runner
description	测试执行工作流。创建测试计划，编写测试脚本，执行测试，生成测试报告。在"/test"、"/测试"、"运行测试"时使用。

测试执行工作流

定位

开发流程第六阶段：单元测试

核心目标：验证功能正确性，确保代码质量

前置条件

• 需求文档已存在：docs/requirements/feature-xxx.md
• 开发计划已存在：docs/dev-plans/feature-xxx.md
• Review 问题已全部修复（如有）
• 代码已准备好进行测试

工作流程

1. 创建测试计划

分析测试范围：

• 从需求文档提取功能点
• 从开发计划提取涉及的模块
• 识别需要测试的边界情况

设计测试用例：

• 正常流程测试
• 边界条件测试
• 异常情况测试
• 性能测试（如需要）

保存测试计划：docs/tests/test-plan.md

2. 编写测试脚本

测试框架选择：

• 根据项目技术栈选择合适的测试框架
• 前端：Jest / Vitest / Cypress
• 后端：Jest / Mocha / pytest

测试代码规范：

• 测试文件命名：xxx.test.ts 或 xxx.spec.ts
• 测试用例命名：清晰描述测试场景
• 遵循 AAA 模式：Arrange → Act → Assert

测试覆盖：

• 单元测试：核心函数/方法
• 集成测试：模块间交互
• E2E 测试：关键用户流程（如需要）

3. 执行测试

运行测试：

npm test
# 或
pytest

收集结果：

• 通过/失败数量
• 覆盖率报告
• 失败用例详情

4. 生成测试报告

分析测试结果：

• 哪些测试通过？
• 哪些测试失败？为什么？
• 覆盖率是否达标？

保存测试报告：docs/tests/test-report.md

5. 标注走查要点

为用户走查提供指引：

• 需要手动测试的场景
• 边界情况和极限情况
• 可能的风险点

交付物格式

测试计划文档

# [Feature 名称] 测试计划

> 创建日期：YYYY-MM-DD
> 需求文档：[feature-xxx.md](../requirements/feature-xxx.md)
> 开发计划：[feature-xxx.md](../dev-plans/feature-xxx.md)

## 测试范围

### 功能测试
| 功能 | 测试点 | 优先级 |
|-----|-------|-------|
| F1: xxx | 正常流程、边界情况 | 高 |
| F2: xxx | 正常流程、异常处理 | 高 |

### 模块测试
| 模块 | 测试点 |
|-----|-------|
| `src/xxx.ts` | 函数 A、函数 B |
| `src/yyy.ts` | 类 C 的方法 |

## 测试用例

### TC1: [测试用例名称]
- **功能**：F1
- **场景**：正常流程
- **前置条件**：[条件]
- **测试步骤**：
  1. 步骤1
  2. 步骤2
- **预期结果**：[结果]
- **优先级**：高

### TC2: [测试用例名称]
- **功能**：F1
- **场景**：边界情况 - 空输入
- **前置条件**：[条件]
- **测试步骤**：
  1. 步骤1
- **预期结果**：[结果]
- **优先级**：中

### TC3: [测试用例名称]
- **功能**：F2
- **场景**：异常处理 - 网络错误
- **前置条件**：[条件]
- **测试步骤**：
  1. 步骤1
- **预期结果**：[结果]
- **优先级**：中

## 测试环境

- 运行环境：[描述]
- 测试数据：[描述]
- 依赖服务：[描述]

## 测试策略

### 自动化测试
- 单元测试：覆盖核心逻辑
- 集成测试：覆盖模块交互

### 手动测试
- UI 交互测试
- 用户体验验证

## 覆盖率目标

- 行覆盖率：> 80%
- 分支覆盖率：> 70%

测试报告文档

# [Feature 名称] 测试报告

> 测试日期：YYYY-MM-DD
> 测试计划：[test-plan.md](./test-plan.md)
> 状态：通过 / 未通过

## 测试概况

| 指标 | 结果 |
|-----|------|
| 总用例数 | 10 |
| 通过 | 8 |
| 失败 | 2 |
| 跳过 | 0 |
| 通过率 | 80% |

## 覆盖率

| 指标 | 结果 | 目标 | 状态 |
|-----|------|------|------|
| 行覆盖率 | 85% | 80% | ✅ |
| 分支覆盖率 | 72% | 70% | ✅ |

## 测试结果详情

### 通过的用例
- ✅ TC1: [用例名称]
- ✅ TC2: [用例名称]
- ...

### 失败的用例

#### ❌ TC3: [用例名称]
- **失败原因**：[描述]
- **错误信息**：

Error: xxx at xxx.ts:42

- **分析**：[原因分析]
- **建议**：[修复建议]

#### ❌ TC4: [用例名称]
- **失败原因**：[描述]
- **错误信息**：[错误]
- **分析**：[原因分析]
- **建议**：[修复建议]

## 问题汇总

| ID | 问题描述 | 严重程度 | 状态 |
|----|---------|---------|------|
| BUG1 | [描述] | 高 | 待修复 |
| BUG2 | [描述] | 中 | 待修复 |

## 走查要点

以下场景建议用户手动验证：

### 必须验证
- [ ] 场景1：[描述]
- [ ] 场景2：[描述]

### 建议验证
- [ ] 边界情况：[描述]
- [ ] 极限情况：[描述]

### 风险提示
- ⚠️ [潜在风险1]
- ⚠️ [潜在风险2]

## 结论

[测试结论和建议]

流转条件

测试通过：

• 所有高优先级用例通过
• 覆盖率达标
• 无严重 bug

→ 进入下一阶段：用户走查

测试未通过：

• 存在失败用例
• 覆盖率未达标
• 发现 bug

→ 返回修复，修复后重新测试

注意事项

1. 测试先行：复杂功能可以先写测试再实现
2. 覆盖边界：边界情况往往是 bug 高发区
3. 保持独立：测试用例之间不应相互依赖
4. 快速反馈：测试应该能快速运行
5. 可重复：测试结果应该稳定可重复