| 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 高发区
- 保持独立:测试用例之间不应相互依赖
- 快速反馈:测试应该能快速运行
- 可重复:测试结果应该稳定可重复