| name | testing |
| description | 测试阶段,验证功能符合需求,确保交付质量 |
测试
依赖规范
#[[file:../rules/review-base.md]]
#[[file:../rules/git-workflow.md]]
#[[file:../rules/project-structure.md]]
目的
验证功能符合需求,确保交付质量。
输入
- 模块代码:各模块代码
- 需求清单:需求清单,作为测试用例依据
测试类型
| # | 类型 | 说明 |
|---|
| 1 | 单元测试 | 每个模块的核心逻辑,覆盖正常路径和异常路径 |
| 2 | 集成测试 | 覆盖核心业务流程 |
| 3 | E2E 测试 | 覆盖关键用户场景 |
| 4 | 回归测试 | 每个 bug 修复后补充对应用例 |
| 5 | 性能测试 | 核心流程无明显性能问题(加载时间、渲染卡顿等) |
| 6 | 安全测试 | 输入校验、权限控制、敏感数据不暴露 |
步骤
每个步骤先输出标题,再输出结果
-
询问用户:在开始任何测试工作之前,先向用户发送以下确认消息:
是否需要编写测试?如需要,请选择测试类型(可多选):
- 单元测试
- 集成测试
- E2E 测试
- 回归测试
- 性能测试
- 安全测试
- 不需要测试,跳过本阶段
- 等待用户明确回复后,仅针对用户选择的测试类型执行后续步骤
- 如果用户选择 0 或明确表示不需要测试,跳过本阶段
-
逐类型循环(仅针对用户确认的测试类型):
- 创建分支:根据测试类型决定是否创建独立分支(单元测试可在功能分支上编写,集成/E2E 等建议独立分支)
- 编写用例:按需求清单编写测试用例
- 删除过时:删除已失效的测试用例
- 执行 review:完成后执行 review,遵守
review-base
- 合并分支:review 通过后 merge 到主分支
-
写入文档:所有测试完成后写入测试报告(路径遵守 project-structure 文档存放规范)
-
执行 review:遵守 review-base,通过后才进入下一步
-
提交:review 通过后按 git-workflow 提交
输出
Review 检查清单
- 类型覆盖:用户选择的每种测试类型均已完成
- 业务覆盖:核心业务流程均有测试覆盖
- 边界覆盖:边界条件和异常场景有测试用例
- 用例质量:描述清晰,可作为功能文档使用
阶段结束
下一阶段:deployment
#[[file:../rules/stage-gate.md]]