메뉴
为前端开发生成可执行的功能测试用例。基于PRD需求和代码变更分析影响面， 输出包含操作步骤、测试数据和预期结果的完整测试报告。 当用户说"帮我生成测试用例"、"生成测试报告"、"功能测试"或提到前端测试、 回归测试、测试覆盖时使用。
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
SOC 직업 분류 기준
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/gaorun/my-labs --skill frontend-functional-testing명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SKILL.md 표시 중
统计代码量——包括代码行数、注释行数、空白行数，按语言/文件维度汇总。支持目录、压缩包、Git 仓库、两个版本差异对比。当用户说"统计代码量"、"代码行数"、"loc"、"cloc"、"看下代码规模"、"这个项目多大"、"代码行数统计"时触发。
从前端代码中定位后端接口的使用情况、分析页面与接口的关联、生成面向不同角色的接口分析报告。当用户问到某个接口在哪些地方有调用、入参/出参如何被使用、页面调了哪些接口、字段与接口的对应关系、接口调用链路、页面接口发现报告时触发。也适合在开发前做方案对齐时使用，输入 PRD 或变更需求后自动分析影响范围。还能分析整个前端项目的架构和接口全景。使用场景包括：接口反向溯源、页面接口发现、全项目接口摸底、前后端方案对齐、PRD 变更影响分析。适合后端、测试、产品同学了解前端接口使用全貌。
mermaid-cli (mmdc) 使用指南：将 Mermaid 定义文件(.mmd)转换为 SVG/PNG/PDF，支持 CI/CD 自动化、 Markdown 内嵌图表渲染、自定义主题和 CSS、批量转换。当用户提到渲染 Mermaid 图表、 把 .mmd 转成图片、自动化生成图表、在 CI 中构建 Mermaid 图、Markdown 里嵌入渲染后的图表、 自定义 Mermaid 图表样式/主题/字体、mmdc 报错或 Chromium 配置问题时触发。如果用户写出了 ```mermaid 代码块但需要渲染成图片文件，也应该触发此技能。
| 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 数据体现了测试所需的业务状态（如列表为空、特定枚举值等）
- [ ] 代码中发现的问题已单独列出
- [ ] 边界场景检查清单已过一遍