需求→测试点提取 (Requirement-to-Testpoints)

When to Use This Skill（何时使用）

触发此 Skill 的典型场景：

• 用户要求"提取/写/生成测试点、测试用例、测试场景、测试清单、QA计划"
• 用户提供 PRD、功能规格书、用户故事并要求测试覆盖分析
• 用户表达了以下痛点信号：
• "需求文档太多/太长，提测试点提不完"——效率问题（痛点一）
• "不知道从哪开始，怕漏场景"——经验依赖问题（痛点二）
• "性能/安全/兼容性文档没怎么写，要测哪些"——非功能遗漏问题（痛点三）

⚠️ 如果用户仅提供一句话需求（如"做一个用户管理模块"），应先追问获取更多细节再执行本 Skill。

What This Skill Does（技能功能）

此 Skill 将需求文档（PRD、用户故事、功能规格书、设计文档）转换为结构化、带优先级的测试要点清单。应用系统化的五维度提取框架，能够覆盖人工最容易遗漏的测试场景——特别是边界条件、异常路径和非功能需求。

输出是一个约 80% 覆盖的初稿。使用者应结合业务上下文和团队经验进行二次审核。但基于结构化的 80 分初稿开始，远比从空白页面开始高效。

实测数据参考（以 100 页电商订单模块 PRD 为例）：
| 对比维度 | 时间 | 测试点数 | 备注 |
|---------|------|---------|------|
| 资深测试工程师手动 | 2.5 天 | ~147 个 | 经验丰富但仍有时长限制 |
| 中级测试工程师手动 | 3 天 | ~112 个 | 边界/异常/非功能遗漏明显 |
| 本 Skill 提取 | ~10 分钟 | 200+ 个 | 系统化覆盖，边界/异常/非功能显著提升 |

核心发现：Skill 多出的测试点主要集中在边界条件、异常场景和非功能需求三个维度——这正是人工最容易遗漏的维度。

Core Principles（核心原则）

为什么系统性提取很重要

测试人员处理信息是串行的——阅读 100 页 PRD 时，读到第 80 页时第 10 页的细节早已模糊。本 Skill 对每个部分都应用相同的五维度框架处理，不会疲倦，并且会主动推导非功能测试点（例如，看到"支持文件上传"会自动触发大文件性能检查、文件类型安全、并发上传、上传中断恢复等测试点）。

本 Skill 不是什么

• 它不产生最终、可直接执行的测试套件。业务上下文、历史缺陷和团队特定的领域知识必须由人工审核者补充。
• 它不执行测试。它生成测试点（测试什么），而非测试脚本（如何测试）。

Workflow（工作流程）

必须按顺序执行以下 4 个步骤。不要跳过任何步骤。

Step 1: Requirement Parsing & Module Decomposition（需求解析与模块拆分）

阅读需求文档，构建结构化理解。

1. 识别所有功能模块和子模块，建立分层模块树。
2. 提取显式的业务规则。关注 if/then 条件、验证规则、状态转换、授权规则。这些通常隐藏在段落文本中，而非单独列出。
3. 标记接口依赖。API 调用、外部服务集成、数据库交互、消息队列。
4. 建立功能点清单。列出文档描述的每个功能/特性，粒度要足够细，使每个点都能映射到可测试的行为。

为什么这是第一步： 测试点的质量完全取决于对需求结构的理解程度。仓促完成这一步会导致 Step 2-4 遗漏场景。

操作： 使用 Read 工具阅读文档。如果有多个文档（PRD + API 规范 + UI 设计稿），全部阅读并进行交叉引用。

Step 2: Five-Dimension Test Point Extraction（五维度测试点提取）

对 Step 1 中识别的每个功能模块，在五个维度上提取测试点。完成当前模块的所有五个维度后，再移动到下一个模块。

Dimension 1: Functional Test Points（功能测试点）

覆盖"功能按预期工作"的场景。本维度主要应用场景法和等价类划分：

• Happy path 验证（正常路径）：端到端的主要成功流程
• 输入字段校验：类型检查、长度限制、格式要求、必填 vs 可选字段
• 状态转换：每个状态变更（创建→审核→生效→作废），包括触发条件和副作用
• 角色/权限差异：不同用户角色在每一步能做什么/不能做什么
• UI 行为：元素可见性、加载状态、空状态、错误消息展示
• 数据流：数据的来源、转换和最终存储位置——包括中间状态

关键洞察： Happy path 是最容易提取且最不容易被遗漏的。将注意力集中在 Happy path 偏离时发生的情况——那才是缺口所在。

Dimension 2: Business Rule Validation（业务规则验证）

将业务逻辑转换为可测试的条件。本维度主要应用判定表法和因果图法：

• 识别需求中的每个 if/then 或 when/then 语句
• 将每个规则转换为测试条件：Given [上下文], when [操作], then [预期结果]
• 检查规则组合——当两条规则同时适用时会发生什么？
• 检查规则冲突——是否有任何规则相互矛盾？
• 公式/计算规则：识别所有数字计算、折扣逻辑、评分算法，用代表性数值进行测试

示例：
> 需求："订单满 200 元免运费，VIP 会员额外享受 5% 折扣。"
>
> 测试点：
> - 订单 200 元整 → 免运费？（边界）
> - 订单 199.99 元 → 不免运费（边界）
> - VIP + 订单 ≥ 200 元 → 两条规则同时适用？叠加还是覆盖？
> - VIP + 订单 < 200 元 → 仅 VIP 折扣？
> - 非 VIP + 订单 ≥ 200 元 → 仅免运费？

Dimension 3: Boundary Conditions（边界条件——人工遗漏率最高的维度）

这是人工提取遗漏率最高的维度。对每个有边界的输入/输出，使用边界值分析法和等价类划分进行系统提取：

分类框架：

为什么在这里花时间： 经验数据显示边界条件占生产缺陷的约 40%。对每个输入字段进行系统化的边界检查，可以在这些缺陷到达生产环境之前捕获大部分。

Dimension 4: Exception Scenarios（异常场景）

考虑出错时会发生什么。本维度主要应用错误猜测法和故障注入法。对每个功能路径至少生成一个异常测试点。

分类框架：

关键洞察： 对维度一中的每个功能路径，问自己"这一步可能出什么问题？"，并至少创建一个异常测试点。一个有 5 个步骤的 Happy path 应至少产生 5 个异常测试点。

Dimension 5: Non-functional Requirements（非功能需求——主动推导）

从功能描述中主动推导——不要依赖需求文档明确提及。本维度应用专项测试方法论（性能/安全/兼容性测试方法论）。

主动推导规则表：

标准覆盖项（始终检查）：
- 性能：响应时间预期、负载下的吞吐量、并发用户容量、大数据量处理（分页、批量操作）
- 安全性：SQL 注入、XSS、CSRF、IDOR（用户 A 能否访问用户 B 的数据？）、速率限制、认证/授权绕过、敏感数据暴露（日志/URL/响应中的 PII）、文件上传安全（类型/大小/恶意软件）
- 兼容性：浏览器支持（Chrome/Firefox/Safari/Edge — 当前版本及 N-1 版本）、移动端响应式、屏幕阅读器可访问性、不同操作系统版本
- 可用性/可访问性：错误消息清晰度、键盘导航、屏幕阅读器支持（ARIA 标签）、色彩对比度、焦点管理
- 可靠性：崩溃后数据持久化、恢复机制、重试逻辑、重启后数据一致性

主动推导示例：
> 需求："用户可以上传头像图片"
>
> 推导的非功能测试点：
> - 性能：10MB 图片上传时间，50 用户同时上传的并发表现
> - 安全性：.exe/.php 伪装成图片的上传、通过文件名进行 XSS 攻击、文件名中的路径遍历
> - 兼容性：移动端浏览器上传、不同图片格式（JPEG/PNG/WebP/HEIC）
> - 可用性：格式不支持时的错误提示、上传进度指示器

Step 3: Deduplication & Priority Sorting（去重与优先级排序）

1. 合并语义重复的测试点。两个用不同数据测试相同行为的测试点是重复的——保留一个，合并数据集。
2. 按风险分配优先级：
   - 高 (P0)：核心路径验证、安全漏洞、数据完整性、收入关键流程。故障=生产事故。
   - 中 (P1)：次要功能、边界条件、大多数异常场景。故障=明显但不严重。
   - 低 (P2)：边缘情况、界面微小问题、不常见的平台组合、锦上添花的场景。
3. 标记核心路径测试点——这些是冒烟测试所需的最小子集。在输出中应清晰标识。

Step 4: Output Structured Checklist（输出结构化清单）

使用 Write 工具保存测试点清单。使用以下格式：

# 测试要点清单: [模块/功能名称]

## 概述
- 需求文档: [文件路径]
- 功能模块数: [N]
- 测试点总数: [N]
- P0/P1/P2 分布: [N/N/N]
- 提取时间: [日期]

## 测试要点

| # | 模块 | 维度 | 测试点描述 | 预期结果 | 优先级 | 前置条件 | 核心路径 |
|---|------|------|-----------|---------|--------|---------|---------|
| 1 | 登录 | 功能测试 | 手机号+验证码登录成功 | 跳转首页，返回 token | P0 | 已注册用户 | ✅ |
| 2 | 登录 | 边界条件 | 手机号 11 位输入 12 位数字 | 截断或提示格式错误 | P1 | - | |
| 3 | 登录 | 异常场景 | 验证码错误 5 次后锁定 | 提示"已锁定，请 N 分钟后重试" | P0 | 错误 5 次 | |

## 按维度汇总

### 功能测试点 (N 个)
[按模块分组列出]

### 业务规则验证 (N 个)
[按模块分组列出]

### 边界条件 (N 个)
[按模块分组列出]

### 异常场景 (N 个)
[按模块分组列出]

### 非功能需求 (N 个)
[按模块分组列出]

## 风险提醒
- [任何未覆盖的跨模块依赖]
- [任何测试环境/数据设置要求]
- [任何需要澄清的需求歧义点]

Important Guidelines（重要指南）

输入质量决定输出质量

• 需求文档越结构化和完整，提取质量越高。
• 如果需求只有一个句子（"构建一个用户管理模块"），先追问更多细节再继续。
• 如果文档是图片/PDF 格式，先阅读，然后应用此 Skill。

始终用中文输出

清单、维度名称、模块名称和描述均使用中文（与目标测试团队的工作语言一致）。技术术语（API、SQL 注入等）可以保留英文。

80 分原则

此 Skill 产出约 80% 覆盖的初稿。始终告知使用者：
- 你识别出的需求文档缺口（模糊区域、缺失细节）
- 哪些领域知识可以改进输出（例如金融：对账规则；电商：库存并发；社交：隐私合规）
- 建议他们先审核 P0 项，然后 P1，最后 P2

Caveats & Limitations（避坑指南）

⚠️ 坑一：Skill 输出不是最终版
把它当作"80 分的初稿"，不是"100 分的终版"。业务上下文、团队历史踩坑经验，这些 Skill 无法自动获取。必须经过人工审核、删减和调整后再使用。

⚠️ 坑二：需求质量决定输出质量
如果需求文档本身就含糊不清、前后矛盾，Skill 提取的测试点也会不准确。在使用本 Skill 前，建议先进行需求评审。

⚠️ 坑三：不要盲目照单全收
Skill 输出的测试点可能包含一些在当前项目上下文中不适用的情况。人工审核时删除不相关的场景，补充业务特有的测试点，调整优先级。

⚠️ 坑四：领域特定知识仍需补充
本 Skill 不具备特定行业的专业知识（如金融交易的对账规则、医疗系统的合规要求）。建议团队维护自己的"领域测试点补充清单"，与本 Skill 配合使用。

Continuous Improvement（持续改进）

每次使用后，如果使用者指出缺口：

• 是维度覆盖缺失？ → 加强该维度的检查清单
• 是对业务逻辑的误解？ → 记录模式，供未来提取参考
• 是 Skill 无法知道的领域特定场景？ → 建议使用者将其添加为团队特定的补充
• 是边界值遗漏？ → 检查该字段类型的边界值分类是否完整

Examples（示例）

输入

"用户注册功能，需要手机号、验证码、密码，密码要求 8-16 位包含字母和数字"

输出片段