| name | frontend-functional-testing |
| description | 为前端开发生成可执行的功能测试用例。基于PRD需求和代码变更分析影响面， 输出包含操作步骤、测试数据和预期结果的完整测试报告。 当用户说"帮我生成测试用例"、"生成测试报告"、"功能测试"或提到前端测试、 回归测试、测试覆盖时使用。 |
前端功能测试用例生成
工作流程
按以下步骤依次执行。每一步完成后更新 TodoList 进度。
任务进度：
- [ ] 步骤1：收集需求信息
- [ ] 步骤2：探索代码变更
- [ ] 步骤3：评估影响面
- [ ] 步骤4：生成测试用例
- [ ] 步骤5：输出测试报告
步骤1：收集需求信息
确认测试范围和目标。向用户获取需求信息：
- 识别当前项目：从工作目录的
package.json（name 字段）或目录名确定当前项目名称，后续只关注 PRD 中与当前项目相关的需求内容。PRD 中涉及其他前端项目的需求一律忽略。
- 请用户提供 PRD（使用 AskUserQuestion）：
- 读取 PRD 内容：根据用户提供的链接或路径读取文档，筛选出与当前项目相关的功能点和验收标准
必须明确的信息：
- 功能点清单（每个功能点的正常流程和异常流程）
- 验收标准（什么样的结果是正确的）
- 涉及的页面路由和组件
步骤2：探索代码变更
分析代码改动，确定影响范围。
未提交的改动：
git status
git diff
git diff --cached
当前分支相对主分支的改动（自动判断主分支是 main 还是 master）：
git branch --show-current
git log main..HEAD --oneline 2>/dev/null || git log master..HEAD --oneline
git diff main...HEAD --stat 2>/dev/null || git diff master...HEAD --stat
深入分析改动文件：
git diff main --name-only
对每个改动的文件，阅读代码，关注：
- 新增/修改/删除的函数、组件、路由、状态管理
- API 接口变更（新增调用、参数变化、返回值变化）
- 表单字段增删改、校验规则变化
- 条件分支变化（新增 if/else、switch case）
- UI 交互变化（弹窗、跳转、动画、Loading 状态）
- 第三方依赖变化
代码审查：在分析改动时，如果发现以下问题，直接记录到报告中：
- 语法错误（拼写、括号不匹配、未定义变量等）
- 逻辑错误（条件判断反了、边界未处理、类型不匹配等）
- 明显遗漏（需求要求了但代码没实现的功能点）
步骤3：评估影响面
建立「改动文件 → 页面 → 模块 → 功能」的映射关系。
分析方法：
- 从改动文件出发，追踪 import/require 链，找到所有引用该文件的页面
- 查看路由配置，确定涉及的页面 URL
- 查看组件树，确定父子组件关系
输出影响面清单：
影响面清单：
直接改动（必须测试）：
- [页面名] > [模块名] > [功能名]：[改动内容摘要]
关联影响（需要回归测试）：
- [页面名] > [模块名] > [功能名]：[为什么需要回归]
回归测试范围判断原则：
- 公共组件/工具函数/hooks 被改动 → 所有使用该模块的功能都要回归
- API 接口改动 → 所有调用该接口的页面都要回归
- 状态管理改动 → 所有依赖该状态的组件都要回归
- 样式/主题改动 → 视觉上可能受影响的页面要回归
- 路由改动 → 涉及跳转的所有路径要回归
步骤4：生成测试用例
基于需求 + 代码变更，生成四类测试用例。
用例分类
| 类别 | 说明 | 来源 |
|---|
| 新功能测试 | PRD 中新增的功能点 | 需求文档 + 新代码 |
| 改动回归测试 | 已有功能被修改的部分 | 代码 diff |
| 关联回归测试 | 代码改动间接影响的功能 | 影响面清单 |
| 异常与边界测试 | 极端输入、错误处理、异常操作 | 所有来源 |
用例合并原则
同一页面、同一模块下的多个 UI 元素测试合并为一条用例，不要拆得太细。一条用例可以覆盖同一模块内的多个操作步骤和预期结果。
合并的判断标准：如果多个操作在同一个页面、同一个功能模块内，且操作之间有业务关联性（比如同一个表单的多个字段、同一个列表的多个交互），就合并为一条用例。
拆分的情况：只有当操作属于不同模块、不同页面、或者需要不同的前置条件/不同接口 mock 数据时，才拆分为独立用例。
边界场景检查清单（每个表单/输入都要过一遍）
- 空值：空字符串、null、undefined、空数组、空对象
- 极值：0、负数、极大数（Number.MAX_SAFE_INTEGER）、极长字符串（1000+字符）
- 特殊字符：
<script>alert(1)</script>、SQL 注入 ' OR 1=1 --、emoji、中文、日文、阿拉伯文
- 格式错误：错误邮箱、错误手机号、错误日期（2月30日）、错误 URL
- 重复操作：连续快速点击提交按钮、重复提交相同数据、快速切换页面
- 并发场景：同时打开多个标签页操作同一数据
- 网络异常：弱网（3G）、断网、请求超时、接口返回 500/403/404
- 权限边界：无权限访问、过期 token、多设备同时登录
- 浏览器兼容：刷新页面后状态保持、浏览器前进/后退按钮
单条用例格式（严格遵循此格式）
### TC-[序号]: [用例标题]
- 页面：[页面名称] - [路由路径]
- 前置条件：[需要满足的条件，如"已登录管理员账号"]
- 操作步骤：
1. 打开页面 [具体URL或路径]
2. 在「[字段名]」输入框中填入 `[具体值]`
3. 点击「[按钮名称]」按钮
4. [后续操作...]
- 预期结果：
- [操作1的预期]
- [操作2的预期]
- 优先级：P0 | P1 | P2
**Mock 数据**（本用例依赖的接口响应）：
> 场景：[描述当前测试的业务状态，如"用户列表中有一条已禁用的账号"]
```json
// GET /api/user/list - [场景描述]
{
"code": 0,
"message": "success",
"data": {
"list": [
{
"userId": 1,
"username": "testuser001",
"status": "disabled" // ★ 关键字段：此字段决定该用户显示为"已禁用"状态，影响操作按钮是否展示"启用"
}
],
"total": 1,
"page": 1,
"pageSize": 20
}
}
**Mock 数据格式要求**：
- Mock 数据直接写在对应用例内部，不单独列章节
- 每条 mock 数据是完整的接口 response，结构和字段类型与真实接口一致，可直接复制使用
- 用注释 `// ★ 关键字段：` 标注哪些字段在影响当前测试的功能表现，说明该字段如何影响页面行为
- mock 数据的 `data` 部分要体现测试所需的业务状态（如列表为空、数据超长、特定枚举值等），而不是只填占位数据
#### 优先级定义
- **P0**：核心流程，阻塞上线，必须通过
- **P1**：重要功能，影响用户体验
- **P2**：边缘场景，影响较小但有风险
---
### 步骤5：输出测试报告
按照 [report-template.md](report-template.md) 的模板格式输出报告。
Mock 数据已内嵌在每条测试用例中（见步骤4的用例格式），不需要单独列出 Mock 数据章节。
---
## 质量检查
报告输出前，逐项核对：
- [ ] 只关注了当前项目相关的 PRD 需求（已过滤其他项目的内容）
- [ ] 所有 PRD 功能点都有对应用例（逐条对照需求）
- [ ] 所有代码改动的页面都包含在测试范围中
- [ ] 关联影响的功能有回归用例
- [ ] 同一页面同一模块的测试用例已合并，没有拆得太细
- [ ] 每条用例的操作步骤可直接执行（不需要猜测"怎么操作"）
- [ ] 预期结果具体可验证（不是"正常显示"而是"显示文案'提交成功'"）
- [ ] 每条用例内嵌了所需的 mock 数据，且用 `★ 关键字段` 标注了影响功能的字段
- [ ] mock 数据体现了测试所需的业务状态（如列表为空、特定枚举值等）
- [ ] 代码中发现的问题已单独列出
- [ ] 边界场景检查清单已过一遍
