القائمة
为前端开发生成可执行的功能测试用例。基于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.
استنادا إلى تصنيف 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 数据体现了测试所需的业务状态（如列表为空、特定枚举值等）
- [ ] 代码中发现的问题已单独列出
- [ ] 边界场景检查清单已过一遍