Stats
Actions
Tags
How this skill is triggered — by the user, by Claude, or both
Slash command
/unipus-qa-plugin:unipus-qa-test-designThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
统一入口，支持从 PRD 到测试用例的完整测试设计流水线，也可单独生成任意一环文档。
统一入口，支持从 PRD 到测试用例的完整测试设计流水线，也可单独生成任意一环文档。
| 模式 | 触发条件 | 输入 | 输出 |
|---|---|---|---|
| 0：全流程 | 同时提供需求文档 + 设计稿链接 | PRD 文档 + Figma/MasterGo 链接 | 依次输出 A→B→C→D 全部文档 |
| A：需求拆分 | "需求拆分"、"提取功能需求"、"分析PRD" | PRD 文档（.docx/.md/.pdf） | docs/{产品名称}-功能需求拆分.md |
| B：测试计划 | "生成测试计划"、"测试计划" | 功能需求拆分.md（必需）+ 架构设计文档（可选） | docs/{产品名称}_测试计划.md |
| C：测试点 | "提取测试点"、"生成测试点"、"测试点分析" | 需求拆分文档 | docs/testcases/{需求名称}-{模块名称}测试点.md |
| D：测试用例 | "生成测试用例"、"测试用例"、"用例设计" | 测试点文档（或需求文档） | docs/testcases/{需求名称}-测试用例-{序号}.md |
| E：合并测试用例 | "合并测试用例"、"汇总用例"、"合并用例"、"生成完整用例" | docs/testcases/{需求名称}-测试用例-*.md | docs/testcases/{需求名称}-测试用例.md |
完整流水线：PRD → [A]需求拆分 → [B]测试计划 → [C]测试点 → [D]测试用例 → [E]合并测试用例
优先判断全流程触发：
否则按触发词判断单独模式：
若无法判断，询问用户：「请问您要：(A) 提取功能需求、(B) 生成测试计划、(C) 提取测试点、(D) 生成测试用例，还是 (E) 合并所有模块测试用例？」
用户同时提供需求文档和设计稿时，按顺序自动执行 A→B→C→D，无需用户在每步确认，完成后汇报全部输出文件列表。
Step 1 → 读取设计稿（Figma/MasterGo），按「设计稿描述规范」生成文字描述，保存至 docs/{产品名称}_设计稿描述.md
Step 2 → 执行模式 A：生成功能需求拆分文档
Step 3 → 执行模式 B：基于需求拆分文档生成测试计划
Step 4 → 执行模式 C：基于需求拆分文档生成各模块测试点
Step 5 → 执行模式 D：结合设计稿描述文档生成测试用例（含端到端用例）
✅ 全流程已完成，共生成以下文档：
- docs/{产品名称}_设计稿描述.md
- docs/{产品名称}-功能需求拆分.md
- docs/{产品名称}_测试计划.md
- docs/testcases/{需求名称}-{模块名称}测试点.md（共 N 个）
- docs/testcases/{需求名称}-测试用例-01.md ... 测试用例-{N}-端到端流程.md
触发时机： 模式 0 Step 1、模式 D D-Step 0 读取设计稿时，均按本规范生成文字描述文档。
输出路径： docs/{产品名称}_设计稿描述.md
Figma 设计稿：
get_figma_data 读取文件顶层结构，获取 Canvas 名称和所有顶层 Frame（页面）列表MasterGo 设计稿：
mcp__getDsl 读取文件顶层结构，获取所有页面 Frame 列表参考格式：docs/LMS口语练习_设计稿描述.md
# {产品名称} - 设计稿文字描述
> 来源：{设计稿链接}
> 生成日期：{YYYY-MM-DD}
---
## 整体结构
设计稿名称：**{名称}**，包含 {N} 个 Canvas/页面，简要说明覆盖的用户流程。
---
## 页面 N：{页面名称}
**{区域名称}**（描述该区域整体特征）：
- {元素1}：{内容/功能描述}
- {元素2}：{内容/功能描述}
**{子区域名称}**（描述特征）：
- {元素}：{描述}
---
## 设计规范摘要
- 主色调：{颜色描述}（仅此处可标注色值）
- 等级/状态颜色体系：{描述}
- 字体：{字体名}，字重范围
- 卡片圆角：{值}，{阴影描述}
- 整体风格：{简要描述}
必须描述的内容：
描述层级规则：
**粗体** 标注区域名称（导航栏、卡片、弹窗、操作栏）- 列表逐项描述- 列表卡片 N - 前缀区分状态标注规则：
（高亮可点击）、（禁用状态）、（全宽）（红色圆点）、（带阴影）、（渐变背景）禁止在页面描述中出现的内容（仅设计规范摘要章节允许）：
docs/{产品名称}_设计稿描述.md将 PRD 中非结构化的产品描述，转化为原子级、可验证、可追溯的功能需求条目，供测试人员直接使用。
功能模块1、功能模块2...每个功能模块提取：
| 要素 | 内容要求 |
|---|---|
| 功能概述 | 1-2句概括核心能力和业务价值，用户视角，不含技术实现 |
| 用户故事 | 格式：作为[角色]，我希望能够[操作]，[目的]，每模块3-5条 |
| 功能需求（FR） | 原子级需求，全局连续编号 FR-001、FR-002…，按子功能分组 |
| 验收标准（AC） | 全局连续编号 AC-001…，包含可量化指标 |
所有功能模块完成后，单独提取附录，使用 NFR- 编号，分五类：性能指标、质量指标、兼容性要求、安全性要求、可用性要求。
粒度标准：一条 FR = 一个可独立测试的功能点
# [产品名称] - 功能需求拆分文档
> 编号范围：FR-001 ~ FR-XXX | AC-001 ~ AC-XXX | NFR-001 ~ NFR-XXX
## 目录
- [功能模块1: XXX](#功能模块1-xxx)
---
## 功能模块N: [模块名称]
### 1. 功能概述
### 2. 用户故事
### 3. 功能需求
#### 3.1 [子功能名称]
- FR-XXX: [功能需求描述]
### 4. 验收标准
- AC-XXX: [含可量化指标的验收标准]
---
## 附录：非功能需求
- NFR-XXX: [要求描述]
## 文档变更记录
docs/{产品名称}-功能需求拆分.md| 输入文档 | 必要性 | 用途 |
|---|---|---|
| 功能需求拆分文档 | 必需 | 提取测试范围、功能模块、FR/AC/NFR条目 |
| 系统架构设计文档 | 推荐 | 提取技术架构、接口清单、第三方依赖、业务流程 |
从功能需求拆分文档中提取：
从架构设计文档中提取（如有）：
按以下 11 章节顺序生成，详细规则见 references/testplan-chapter-rules.md，输出模板见 references/testplan-output-template.md。
输出文档结构：
1. 项目概述（背景、功能概述、测试目标）
2. 测试范围（In Scope / Out of Scope）
3. 测试策略（测试类型、测试方法、测试优先级）
4. 测试环境（硬件、软件、测试数据、网络）
5. 测试用例设计（各模块用例概要、设计原则、数据设计）
6. 测试执行计划（阶段划分、详细时间安排甘特图）
7. 测试资源（人员配置、技能要求、工具和设备）
8. 风险评估（技术风险、项目风险、应对措施）
9. 准入/准出标准
10. 测试交付物
11. 测试注意事项
关键生成规则摘要：
docs/{产品名称}_测试计划.md逐条读取需求，若无ID，按以下格式生成：
REQ_[模块代码]_[类型代码]_[序号]
类型代码：FUNC(功能) / PERF(性能) / SEC(安全) / UI(界面) / DATA(数据) / INTG(集成)
按业务逻辑将需求拆分为独立功能点，遵循层级结构：
模块 → 功能点 → 验证类型 → 具体测试点
在每个功能点下，按四类验证类型生成测试点：
| 验证类型 | 关注点 | 典型场景 |
|---|---|---|
| 功能验证点 | 核心业务逻辑 | CRUD操作、业务动作、状态变更 |
| 边界验证点 | 边界条件 | 输入长度上下限、权限边界、数据量限制 |
| 异常验证点 | 异常处理 | 错误输入、网络异常、权限不足 |
| 集成验证点 | 模块协作 | 跨模块数据传递、外部接口调用 |
详细提取规则见 references/testpoint-extraction-rules.md
输出格式：
- TP_[模块]_[序号]: [测试点名称]
- 验证要点: [具体验证内容]
- 优先级: 高/中/低
- 关联需求: REQ_XXX_XXX_XXX
- 派生测试用例: [预计数量]个
文档末尾必须包含：测试点统计、需求追溯矩阵、需求覆盖率统计。
完整模板见 references/testpoint-templates.md
docs/testcases/{需求名称}-{功能模块名称}测试点.md若在全流程模式（模式0）中已生成 {产品名称}_设计稿描述.md，直接读取该文件，跳过此步。
单独触发时必须询问用户：
"是否有 Figma/MasterGo 设计稿链接？如果有，请提供链接，我会按「设计稿描述规范」读取并生成文字描述文档，再结合描述生成更准确的测试用例。"
如果用户提供了设计稿链接：
docs/{产品名称}_设计稿描述.md如果用户没有设计稿： 直接进入 D-Step 1。
测试点文档层级：功能模块 → 功能点 → 验证类型 → 具体测试点（含验证要点）
| 测试点类型 | 用例设计策略 |
|---|---|
| 功能验证点 | 正向用例——验证功能正常工作 |
| 边界验证点 | 边界用例——设计多组边界值数据（最小值、最大值、临界值、超界值） |
| 异常验证点 | 异常用例——覆盖各种错误处理场景 |
| 集成验证点 | 组合用例——验证跨模块交互 |
| 端到端验证 | 流程用例——覆盖完整业务路径的跨模块串联场景（见 D-Step 5） |
⚠️ 全局禁止规则：测试用例全文（含前置条件、测试步骤、预期结果）禁止包含任何 UI 样式描述，包括但不限于：颜色值（#xxx、rgb）、字号（14px、16px）、字重（bold）、间距（margin、padding）、圆角（border-radius）、阴影、CSS 属性名。只描述功能行为和内容，不描述视觉实现细节。
按严格的六级 Markdown 层级输出，兼容 XMind 导入：
H1 # 文档标题
H2 ## 功能模块
H3 ### 功能测试点
H4 #### 验证点
H5 ##### [需求ID] 用例场景描述[优先级]
H6 ###### 前置条件（有前置依赖时必须写）
H6 ###### 测试步骤
H6 ###### 预期结果
详细格式规范见 references/testcase-format-spec.md，转换示例见 references/testcase-examples.md
H5 标题格式：
##### [需求ID] 用例场景描述[优先级]
[FR-064,AC-032][P0]/[P1]/[P2]优先级分级：
在完成各功能模块的测试用例后，额外生成一份端到端（E2E）流程测试用例文档，覆盖跨模块的完整业务流程。
输出路径： docs/testcases/{需求名称}-测试用例-{最后序号+1}-端到端流程.md
端到端用例设计策略：
| 场景类型 | 优先级 |
|---|---|
| 正常完整流程（所有模块串联主路径） | P0 |
| 混合操作流程（穿插跳过、重试等分支） | P0 |
| 中断恢复流程（中途退出后恢复完成） | P0 |
| 多轮累计流程（连续多次，验证数据累计） | P0 |
| 权限角色流程（不同角色完整访问路径） | P0 |
| 网络异常恢复流程 | P1 |
| 设备异常恢复流程 | P1 |
| 与现有系统集成流程 | P1 |
{产品名称}_设计稿描述.mddocs/testcases/{需求名称}-测试用例-{序号}.md将 docs/testcases/ 下的所有分模块测试用例文件合并为一份完整文档，便于统一查阅、导出或上传。
docs/testcases/ 目录，匹配文件名规则：{需求名称}-测试用例-{序号}*.md
{需求名称}-测试用例.md，即合并结果文件本身）.md 文件（如 .xmind）---输出文件头部格式：
# {需求名称} - 完整测试用例
> 合并自 {N} 个模块文件，共 {M} 条测试用例
> 生成日期：{YYYY-MM-DD}
> 文件列表：
> - {文件1}
> - {文件2}
> - ...
---
合并规则：
--- 分隔线输出路径： docs/testcases/{需求名称}-测试用例.md
⚠️ 若同名文件已存在，直接覆盖（合并结果文件每次重新生成）
--- 分隔线docs/testcases/{需求名称}-测试用例.mdnpx claudepluginhub glepooek/unipus-plugins-official --plugin unipus-qa-pluginScans the codebase for `ponytail:` comments and compiles a debt ledger of deliberate shortcuts and deferrals, flagging entries with no upgrade path.