菜单
为前端开发生成可执行的功能测试用例。基于PRD需求和代码变更分析影响面， 输出包含操作步骤、测试数据和预期结果的完整测试报告。 当用户说"帮我生成测试用例"、"生成测试报告"、"功能测试"或提到前端测试、 回归测试、测试覆盖时使用。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/gaorun/my-labs --skill frontend-functional-testing命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
基于 SOC 职业分类
| name | frontend-functional-testing |
| description | 为前端开发生成可执行的功能测试用例。基于PRD需求和代码变更分析影响面， 输出包含操作步骤、测试数据和预期结果的完整测试报告。 当用户说"帮我生成测试用例"、"生成测试报告"、"功能测试"或提到前端测试、 回归测试、测试覆盖时使用。 |
按以下步骤依次执行。每一步完成后更新 TodoList 进度。
任务进度：
- [ ] 步骤1：收集需求信息
- [ ] 步骤2：探索代码变更
- [ ] 步骤3：评估影响面
- [ ] 步骤4：生成测试用例
- [ ] 步骤5：输出测试报告
确认测试范围和目标。向用户获取需求信息：
package.json（name 字段）或目录名确定当前项目名称，后续只关注 PRD 中与当前项目相关的需求内容。PRD 中涉及其他前端项目的需求一律忽略。必须明确的信息：
分析代码改动，确定影响范围。
未提交的改动：
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 # 获取改动文件列表
对每个改动的文件，阅读代码，关注：
代码审查：在分析改动时，如果发现以下问题，直接记录到报告中：
建立「改动文件 → 页面 → 模块 → 功能」的映射关系。
分析方法：
输出影响面清单：
影响面清单：
直接改动（必须测试）：
- [页面名] > [模块名] > [功能名]：[改动内容摘要]
关联影响（需要回归测试）：
- [页面名] > [模块名] > [功能名]：[为什么需要回归]
回归测试范围判断原则：
基于需求 + 代码变更，生成四类测试用例。
| 类别 | 说明 | 来源 |
|---|---|---|
| 新功能测试 | PRD 中新增的功能点 | 需求文档 + 新代码 |
| 改动回归测试 | 已有功能被修改的部分 | 代码 diff |
| 关联回归测试 | 代码改动间接影响的功能 | 影响面清单 |
| 异常与边界测试 | 极端输入、错误处理、异常操作 | 所有来源 |
同一页面、同一模块下的多个 UI 元素测试合并为一条用例，不要拆得太细。一条用例可以覆盖同一模块内的多个操作步骤和预期结果。
合并的判断标准：如果多个操作在同一个页面、同一个功能模块内，且操作之间有业务关联性（比如同一个表单的多个字段、同一个列表的多个交互），就合并为一条用例。
拆分的情况：只有当操作属于不同模块、不同页面、或者需要不同的前置条件/不同接口 mock 数据时，才拆分为独立用例。
<script>alert(1)</script>、SQL 注入 ' OR 1=1 --、emoji、中文、日文、阿拉伯文### 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 数据体现了测试所需的业务状态（如列表为空、特定枚举值等）
- [ ] 代码中发现的问题已单独列出
- [ ] 边界场景检查清单已过一遍