Frontend Functional Testing

前端功能测试用例生成

工作流程

按以下步骤依次执行。每一步完成后更新 TodoList 进度。

任务进度：
- [ ] 步骤1：收集需求信息
- [ ] 步骤2：探索代码变更
- [ ] 步骤3：评估影响面
- [ ] 步骤4：生成测试用例
- [ ] 步骤5：输出测试报告

---

步骤1：收集需求信息

确认测试范围和目标。向用户获取需求信息：

1. 识别当前项目：从工作目录的 package.json（name 字段）或目录名确定当前项目名称，后续只关注 PRD 中与当前项目相关的需求内容。PRD 中涉及其他前端项目的需求一律忽略。
2. 请用户提供 PRD（使用 AskUserQuestion）：

• PRD 链接或文档路径（必须）

1. 读取 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：评估影响面

建立「改动文件 → 页面 → 模块 → 功能」的映射关系。

分析方法：

1. 从改动文件出发，追踪 import/require 链，找到所有引用该文件的页面
2. 查看路由配置，确定涉及的页面 URL
3. 查看组件树，确定父子组件关系

输出影响面清单：

影响面清单：

直接改动（必须测试）：
- [页面名] > [模块名] > [功能名]：[改动内容摘要]

关联影响（需要回归测试）：
- [页面名] > [模块名] > [功能名]：[为什么需要回归]

回归测试范围判断原则：

• 公共组件/工具函数/hooks 被改动 → 所有使用该模块的功能都要回归
• API 接口改动 → 所有调用该接口的页面都要回归
• 状态管理改动 → 所有依赖该状态的组件都要回归
• 样式/主题改动 → 视觉上可能受影响的页面要回归
• 路由改动 → 涉及跳转的所有路径要回归

---

步骤4：生成测试用例

基于需求 + 代码变更，生成四类测试用例。

用例分类

| 类别 | 说明 | 来源 | | -------------- | ---------------------------- | ----------------- | | 新功能测试 | PRD 中新增的功能点 | 需求文档 + 新代码 | | 改动回归测试 | 已有功能被修改的部分 | 代码 diff | | 关联回归测试 | 代码改动间接影响的功能 | 影响面清单 | | 异常与边界测试 | 极端输入、错误处理、异常操作 | 所有来源 |

用例合并原则

同一页面、同一模块下的多个 UI 元素测试合并为一条用例，不要拆得太细。一条用例可以覆盖同一模块内的多个操作步骤和预期结果。

合并的判断标准：如果多个操作在同一个页面、同一个功能模块内，且操作之间有业务关联性（比如同一个表单的多个字段、同一个列表的多个交互），就合并为一条用例。

拆分的情况：只有当操作属于不同模块、不同页面、或者需要不同的前置条件/不同接口 mock 数据时，才拆分为独立用例。

边界场景检查清单（每个表单/输入都要过一遍）

• 空值：空字符串、null、undefined、空数组、空对象
• 极值：0、负数、极大数（Number.MAXSAFEINTEGER）、极长字符串（1000+字符）
• 特殊字符：alert(1)、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 数据体现了测试所需的业务状态（如列表为空、特定枚举值等）
- [ ] 代码中发现的问题已单独列出
- [ ] 边界场景检查清单已过一遍

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [gaorun](https://github.com/gaorun)
- **Source:** [gaorun/my-labs](https://github.com/gaorun/my-labs)
- **License:** MIT

Install and usage instructions live in the source repository linked above.