初始化自动化开发工作流技能库
This commit is contained in:
锦麟 王
@@ -0,0 +1,182 @@
|
||||
---
|
||||
name: dev-test
|
||||
description: 开发流程 - 测试阶段，包括代码审核、单模块测试和全流程测试
|
||||
---
|
||||
|
||||
# 测试
|
||||
|
||||
> 开发流程第五阶段：代码审核 + 单模块测试 + 全流程测试。
|
||||
|
||||
## 调用方式
|
||||
|
||||
`/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. 审核报告
|
||||
|
||||
产出审核结果：
|
||||
|
||||
```markdown
|
||||
## 代码审核详情
|
||||
|
||||
### 审核文件列表
|
||||
- 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. 测试结果记录
|
||||
|
||||
```markdown
|
||||
## 模块测试详情
|
||||
|
||||
### 测试框架：Vitest
|
||||
|
||||
| 模块 | 测试文件 | 用例数 | 通过 | 失败 |
|
||||
|------|---------|--------|------|------|
|
||||
| 模块A | xxx.test.ts | 5 | 5 | 0 |
|
||||
```
|
||||
|
||||
### 阶段 C：全流程测试
|
||||
|
||||
#### C1. 设计测试场景
|
||||
|
||||
基于需求文档中的用户故事设计端到端测试场景：
|
||||
- 每个用户故事对应至少一个测试场景
|
||||
- 场景应覆盖完整的用户操作流程
|
||||
|
||||
#### C2. 执行全流程测试
|
||||
|
||||
- 按场景逐步验证
|
||||
- 检查模块间的协作是否正常
|
||||
- 验证完整的数据流转
|
||||
- 检查集成点（API 调用、数据库操作等）
|
||||
|
||||
#### C3. 记录结果
|
||||
|
||||
```markdown
|
||||
## 全流程测试详情
|
||||
|
||||
### 场景 1：用户注册流程
|
||||
- 步骤 1：打开注册页 ✅
|
||||
- 步骤 2：填写表单 ✅
|
||||
- 步骤 3：提交注册 ✅
|
||||
- 步骤 4：验证成功 ✅
|
||||
```
|
||||
|
||||
### 生成测试报告
|
||||
|
||||
汇总所有阶段的测试结果：
|
||||
|
||||
```markdown
|
||||
# 测试报告：<项目名称>
|
||||
|
||||
> 创建日期：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` 技能（框架检测和模板可复用）
|
||||
Reference in New Issue
Block a user