Files
2026-04-27 17:45:20 +08:00

4.4 KiB

name, description
name description
dev-test 开发流程 - 测试阶段,包括代码审核、单模块测试和全流程测试

测试

开发流程第五阶段:代码审核 + 单模块测试 + 全流程测试。

调用方式

/dev-test,也可说"开始测试"。

产出目录

docs/test-reports/

执行流程

启动时选择

展示测试范围选择:

请选择测试范围:

[1] 完整测试流程(代码审核 → 模块测试 → 全流程测试)
[2] 仅代码审核
[3] 仅模块测试
[4] 仅全流程测试

使用多选方式让用户选择。

Checklist

  • 前置检查:读取计划和开发日志
  • 阶段 A:代码审核(如选择)
  • 阶段 B:单模块测试(如选择)
  • 阶段 C:全流程测试(如选择)
  • 生成测试报告

前置检查

  • 读取 docs/plans/docs/dev-logs/
  • 确认开发已全部完成(所有步骤状态为"已完成")
  • 如果未完成,提示用户先运行 /dev-develop 完成剩余步骤
  • 用户可选择跳过(对已完成部分进行测试)

阶段 A:代码审核

A1. 确定审核范围

  • 从开发日志中提取所有修改/新建的文件列表
  • 展示给用户确认

A2. 逐文件审核

对每个文件检查以下维度:

维度 检查内容
安全性 SQL 注入、XSS、命令注入、敏感信息泄露等 OWASP Top 10
性能 N+1 查询、内存泄漏、不必要的同步操作、大数据量处理
代码规范 命名一致性、函数长度、代码重复
设计符合度 对照设计文档,检查实现是否符合设计
边界情况 空值处理、错误路径、并发场景

A3. 审核报告

产出审核结果:

## 代码审核详情

### 审核文件列表
- src/xxx.ts
- src/yyy.ts

### 发现问题

| # | 文件 | 行号 | 严重度 | 描述 | 状态 |
|---|------|------|--------|------|------|
| 1 | xxx.ts | 42 | 高 | SQL 注入风险 | ⏳ 待修复 |

A4. 用户确认修复

  • 展示审核发现的问题
  • 与用户确认哪些需要修复
  • 执行修复
  • 修复后重新验证

阶段 B:单模块测试

B1. 框架检测

自动检测项目使用的测试框架:

  • JavaScript/TypeScript:检查 package.json 中的 jest、vitest、mocha 等
  • Python:检查 pytest、unittest 等
  • 如果没有测试框架,询问用户是否需要安装

B2. 逐模块生成测试

按步骤计划中的模块划分:

  • 为每个模块生成单元测试
  • 测试覆盖:正常路径、边界情况、错误路径
  • 生成测试代码后展示给用户确认

B3. 运行测试

  • 执行生成的测试
  • 展示测试结果
  • 失败的测试进入修复循环:修复 → 重新运行 → 直到通过

B4. 测试结果记录

## 模块测试详情

### 测试框架:Vitest

| 模块 | 测试文件 | 用例数 | 通过 | 失败 |
|------|---------|--------|------|------|
| 模块A | xxx.test.ts | 5 | 5 | 0 |

阶段 C:全流程测试

C1. 设计测试场景

基于需求文档中的用户故事设计端到端测试场景:

  • 每个用户故事对应至少一个测试场景
  • 场景应覆盖完整的用户操作流程

C2. 执行全流程测试

  • 按场景逐步验证
  • 检查模块间的协作是否正常
  • 验证完整的数据流转
  • 检查集成点(API 调用、数据库操作等)

C3. 记录结果

## 全流程测试详情

### 场景 1:用户注册流程
- 步骤 1:打开注册页 ✅
- 步骤 2:填写表单 ✅
- 步骤 3:提交注册 ✅
- 步骤 4:验证成功 ✅

生成测试报告

汇总所有阶段的测试结果:

# 测试报告:<项目名称>

> 创建日期:YYYY-MM-DD
> 对应计划:docs/plans/YYYY-MM-DD-xxx.md
> 状态:已完成

## 审核摘要

| 阶段 | 状态 | 发现问题 | 已修复 |
|------|------|---------|--------|
| 代码审核 | 完成 | N | N |
| 模块测试 | 完成 | N | N |
| 全流程测试 | 完成 | N | N |

保存到 docs/test-reports/YYYY-MM-DD-<项目名>.md,提示下一步可调用 /dev-deliver 生成交付文档。

关键行为

  • 代码审核以设计文档为基准,检查实现是否符合设计
  • 测试失败不跳过,必须修复后重新运行
  • 全流程测试按用户故事场景组织,确保端到端可运行
  • 兼容已有的 automated-testing 技能(框架检测和模板可复用)