Req Deconstruction
将模糊的需求描述系统化拆分为输入、操作、状态、输出、规则五个可测试维度，同时挖掘显性需求之外的那些"没写出来但必须满足"的隐性需求和衍生需求。当用户的需求描述只有一两句话、或者看起来功能很简单但你可能遗漏了什么的时候，一定要用此技能做深度解构。适用于任何测试任务的第二步骤——无论需求文档有多详细，解构之后总能发现盲区。
SKILL.md
⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills
⚠️ 安全警告：本技能的示例可能涉及订单号、支付金额、截图、身份证、手机号等敏感数据。 实际使用时请勿粘贴真实生产数据、客户信息或财务凭证；测试前应脱敏/掩码处理。 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。
需求解构
核心原则
专家看需求文档，看到的不只是文字，而是背后的测试模型。
层的区别是"来源"：显性来自文档，隐性来自追问，衍生来自推导。 无论文档写得多详细，解构之后总能发现盲区——层不清楚，就分不清哪些是"要求的"、 哪些是"我猜的"，下游全部会带错。
1. 三层次速查
| 层次 | 定义 | 挖掘方法 | 数量占比 | 必做动作 |
|---|---|---|---|---|
| 显性 | 文档明确写出的 | 逐条编号提取 | 40-50% | 每条判"可测试吗" |
| 隐性 | 文档没写但隐含的 | 五问法追问 | 30-35% | 每条标 [推断]/[假设] |
| 衍生 | 关联推导出的 | 角色/场景/边界/关联/数据流 | 15-25% | 无依据标 [待确认] |
五问法（挖隐性的核心）：
对每个「应该」问"如果不呢？" · 对每个「正常」问"异常呢？" · 对每个「确定」问"假设呢？" · 对每个「存在」问"不存在呢？" · 对每个「并发」问"同时操作呢？"
2. 五维速查
| 维度 | 问什么 | 最容易漏的子项 |
|---|---|---|
| 输入 | 用户输入什么？ | 精度（0.001 元这类合法但出错的值） |
| 操作 | 用户能做什么？ | 禁止操作（"已支付不能取消"文档通常不写） |
| 状态 | 系统有哪些状态？ | 非法状态转换怎么处理 |
| 输出 | 系统返回什么？ | 错误信息可执行性、多个输出间的一致性 |
| 规则 | 业务规则是什么？ | 规则冲突时的优先级（文档通常不写） |
五维必须完整使用，不可选择性跳过。最常见的失效是"只做输入/操作，忽略状态/输出/规则"—— 因为前三者想得到，后三者想不起来。
3. 需求数量要求
关键指标：以显性需求数为基准，总需求 = 显性 + 隐性 + 衍生。
| 复杂度 | 倍数 | 示例（显性 5 条） | 隐性与显性比例 | 复杂度判断 |
|---|---|---|---|---|
| 简单项目 | ×2 | 总需求 10 条 | 1:1 | 单模块、低风险、无并发 |
| 中等项目 | ×3 | 总需求 15 条 | 2:1 | 多模块、中风险、少量并发 |
| 复杂项目 | ×4 | 总需求 20 条 | 3:1 | 跨模块、高风险、高并发 |
4. 编号规则
| 对象 | 格式 | 示例 |
|---|---|---|
| 需求 ID | REQ-{需求模块缩写}-{序号} | REQ-AUTH-001 |
| 风险点 ID | RISK-{模块缩写}-{风险类型}-{序号} | RISK-CART-STOCK-001 |
| 业务规则 ID | RULE-{CAL|VAL|PERM|FLOW}-{序号} | RULE-CAL-001 |
是用例前缀，由TC_{模块}_{功能}_{序号}qa-test-case-design分配，本技能不用。 历史版本本技能的 traceability 把需求 ID 写成了TC_，已修正为REQ-。RULE-已补入docs/standards.md（原规范缺失此 ID 族）。
5. 加载时机
需要时才读，不要一上来全读：
| 什么时候读 | 读哪个 |
|---|---|
| 不知道隐性需求怎么挖，或要展开八类隐性清单 | references/three-layers.md（三层详解 + 五问法 + 反模式） |
| 逐维拆解，要子项清单 | references/five-dimensions.md（五维框架 + 每维易漏子项） |
| 写需求解构表或业务规则表 | assets/requirement-table.md（两张表模板 + 填写要求 + 自检） |
6. 产出
需求解构表：
| 需求 ID | 层次 | 显性描述 | 隐性假设 | 衍生需求 | 风险点 | 疑问 |
|---|---|---|---|---|---|---|
| REQ-AUTH-001 | 显性 | 密码至少 8 位 | 允许特殊字符？历史密码可复用？ | 密码强度提示 | 弱密码可注册 | 强度规则由谁定？ |
| REQ-AUTH-002 | 显性 | 错误 5 次锁定账号 | 锁定时长？自动解锁还是人工？ | 登录日志审计 | 锁定可被暴力破解绕过 | 锁定时长是多少？ |
| REQ-AUTH-003 | 隐性 | — | 验证码有效期、发送频率、错误次数上限 | 换绑手机号后旧码失效 | 验证码可被枚举 | 有效期与上限各是多少？ |
业务规则表（统一写成"若 X 则 Y 必须满足 Z"）：
| 规则 ID | 触发条件 | 必须满足 | 验证方法 | 风险等级 |
|---|---|---|---|---|
| RULE-CAL-001 | 若商品数量 × 单价 | 则总金额必须等于数量×单价（精度 2 位） | 构造小数位金额比对返回值 | 高 |
| RULE-PERM-001 | 若用户未登录 | 则不能访问订单详情，返回 401 | 未登录直接访问他人订单 URL | 高 |
| RULE-FLOW-001 | 若订单已支付 | 则不能取消，返回明确错误码 | 已支付订单点取消 | 高 |
本技能不产出 9 列用例表——场景与用例由 qa-scenario-tree / qa-test-case-design 完成。
7. 常见反模式
- 顺手牵羊：解构时就开始写测试用例 → 解构只做需求分析，用例是下游的事
- 隐藏不标：隐性需求挖出来不标 → 每条隐性/衍生必须带
[推断]/[假设]/[待确认] - 规则遗漏：只拆需求不拆规则 → 每条需求必须连带提取对应业务规则
- 过度衍生：衍生到不切实际 → 必须有场景支撑，否则标
[待确认] - 五维偏科：只做输入/操作 → 五维必须完整
8. 交付前自检
- 显性需求完整提取（含约束条件与非功能需求）
- 隐性需求按五问法逐条追问，且每条标了
[推断]/[假设] - 衍生需求均有场景支撑或已标
[待确认] - 五维全部拆过——状态/输出/规则三维未被跳过
- 每条需求都连带了业务规则，规则已结构化
- 规则冲突已问清优先级（未问清记入疑问）
- 疑问点已列出并交
qa-question-framework，未自行假设填充 - 需求 ID 格式为
REQ-，无TC_混用 - 未提前跳入测试用例设计
- 覆盖率已标注口径，无"全覆盖/100%"绝对化表述
评论与讨论
还没有评论，分享你的体验吧。