メニュー
为前端开发生成可执行的功能测试用例。基于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コマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
统计代码量——包括代码行数、注释行数、空白行数，按语言/文件维度汇总。支持目录、压缩包、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 代码块但需要渲染成图片文件，也应该触发此技能。
SOC 職業分類に基づく
SKILL.md を表示中
| 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 数据体现了测试所需的业务状态（如列表为空、特定枚举值等）
- [ ] 代码中发现的问题已单独列出
- [ ] 边界场景检查清单已过一遍