需求解构

将模糊的需求描述系统化拆分为输入、操作、状态、输出、规则五个可测试维度，同时挖掘显性需求之外的那些"没写出来但必须满足"的隐性需求和衍生需求。当用户的需求描述只有一两句话、或者看起来功能很简单但你可能遗漏了什么的时候，一定要用此技能做深度解构。适用于任何测试任务的第二步骤——无论需求文档有多详细，解构之后总能发现盲区。 本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills

⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills

⚠️ 安全警告：本技能的示例可能涉及订单号、支付金额、截图、身份证、手机号等敏感数据。 实际使用时请勿粘贴真实生产数据、客户信息或财务凭证；测试前应脱敏/掩码处理。 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。

核心原则

专家看需求文档，看到的不只是文字，而是背后的测试模型。

需求挖掘深度要求（参考值）

关键指标：根据项目复杂度调整

复杂度	倍数	示例（显性5条）
简单项目	×2	总需求10条
中等项目	×3	总需求15条
复杂项目	×4	总需求20条

复杂度判断标准：

• 简单：单模块、低风险、无并发
• 中等：多模块、中风险、少量并发
• 复杂：跨模块、高风险、高并发

需求三层次模型

第1层：显性需求

是什么：文档明确写出的内容

text

提取方法：
1. 逐条阅读需求文档
2. 标注每条需求的关键词
3. 分类整理：功能需求、非功能需求、约束条件
4. 输出：显性需求清单（每条带REQ-ID）

检查清单：
- [ ] 所有功能点是否提取？
- [ ] 所有约束条件是否提取？
- [ ] 所有非功能需求是否提取？
- [ ] 每条需求是否可测试？

第2层：隐性需求

是什么：文档没写但隐含的需求

text

挖掘方法（五问法）：
1. 对每个"应该"问"如果不呢？"
2. 对每个"正常"问"异常呢？"
3. 对每个"确定"问"假设呢？"
4. 对每个"存在"问"不存在呢？"
5. 对每个"并发"问"同时操作呢？"

隐性需求类型：
├─ 业务隐含：业务流程的隐含步骤
├─ 技术隐含：技术实现的隐含约束
├─ 用户隐含：用户行为的隐含假设
├─ 环境隐含：运行环境的隐含条件
├─ 数据隐含：数据状态的隐含变化
├─ 并发隐含：并发操作的隐含冲突
├─ 时序隐含：操作顺序的隐含依赖
└─ 异常隐含：异常情况的隐含处理

检查清单：
- [ ] 库存相关隐性需求是否挖掘？
- [ ] 并发相关隐性需求是否挖掘？
- [ ] 时序相关隐性需求是否挖掘？
- [ ] 异常处理隐性需求是否挖掘？
- [ ] 数据一致性隐性需求是否挖掘？
- [ ] 安全相关隐性需求是否挖掘？

第3层：衍生需求

是什么：从显性和隐性需求推导出的需求

text

推导方法：
1. 从用户角色推导：不同角色有什么需求？
2. 从使用场景推导：不同场景有什么需求？
3. 从边界条件推导：极端情况有什么需求？
4. 从关联功能推导：相关功能有什么需求？
5. 从数据流向推导：数据在模块间怎么流？

检查清单：
- [ ] 不同用户角色需求是否推导？
- [ ] 不同使用场景需求是否推导？
- [ ] 边界条件需求是否推导？
- [ ] 关联功能需求是否推导？
- [ ] 数据流向需求是否推导？

推导示例：

• 显性："密码至少8位" → 隐性：密码强度规则？特殊字符？
• 显性："发送验证码" → 隐性：验证码有效期？发送频率限制？

五维拆解框架

维度1：输入拆解

text

用户输入什么？
├─ 输入类型：文本、数字、文件、选择
├─ 输入来源：手动输入、自动填充、第三方获取
├─ 输入限制：必填/选填、长度、格式、范围
├─ 输入异常：空值、超长、格式错误、特殊字符
└─ 输入关联：多个输入间的依赖关系

维度2：操作拆解

text

用户能做什么？
├─ 核心操作：主要功能路径
├─ 辅助操作：次要功能路径
├─ 禁止操作：不允许的操作
├─ 操作顺序：操作间的依赖关系
└─ 操作权限：谁能做什么操作

维度3：状态拆解

text

系统有哪些状态？
├─ 业务状态：待处理、处理中、已完成、已取消
├─ 数据状态：草稿、已发布、已归档
├─ 用户状态：未激活、正常、冻结、注销
├─ 状态流转：状态变更的条件和路径
└─ 状态异常：非法状态转换怎么处理

维度4：输出拆解

text

系统返回什么？
├─ 正常输出：成功时的返回内容
├─ 异常输出：失败时的返回内容
├─ 输出格式：JSON、HTML、文件
├─ 输出内容：数据、提示、错误信息
└─ 输出关联：多个输出间的一致性

维度5：规则拆解

text

业务规则是什么？
├─ 计算规则：公式、算法、精度
├─ 校验规则：格式、范围、关联
├─ 权限规则：角色、资源、操作
├─ 流程规则：步骤、条件、分支
└─ 规则冲突：规则间的优先级和矛盾

业务规则结构化

从业务规则中提取结构化描述，格式为"若X发生，则Y必须满足Z"：

规则提取模板

规则ID	触发条件	必须满足	验证方法
RULE-001	若[条件]	则[预期]	[验证方式]

规则类型示例

text

计算规则：
├─ RULE-CAL-001：若商品数量×单价，则总金额必须等于数量×单价
└─ RULE-CAL-002：若使用优惠券，则最终金额必须扣减优惠金额

校验规则：
├─ RULE-VAL-001：若手机号输入，则必须为11位数字
└─ RULE-VAL-002：若邮箱输入，则必须符合邮箱格式

权限规则：
├─ RULE-PERM-001：若用户未登录，则不能访问订单详情
└─ RULE-PERM-002：若用户非管理员，则不能删除其他用户

流程规则：
├─ RULE-FLOW-001：若订单已支付，则不能取消
└─ RULE-FLOW-002：若商品库存为0，则不能下单

需求解构表

需求ID	显性描述	隐性假设	风险点	疑问
REQ-001	[描述]	[假设]	[风险]	[疑问]

工作流程

1. 获取需求文档

   • 读取上传的文件
   • 获取URL链接内容
   • 接收用户描述

2. 逐层解构

   • 提取显性需求
   • 挖掘隐性需求
   • 推导衍生需求

3. 五维拆解

   • 输入/操作/状态/输出/规则

4. 输出解构表

   • 结构化整理
   • 标注风险和疑问

需求类型速查表

需求类型	定义	来源	挖掘方法	典型数量占比
显性需求	文档明确写出的	原始文档	直接提取、逐条编号	40-50%
隐性需求	文档没写但隐含的	五问法推导	追问"如果不"/"如果异常"	30-35%
衍生需求	关联推导出的	角色/场景/边界驱动	换角色看、查关联功能	15-25%

复杂度评估表

复杂度	特征	隐性与显性比例	建议解构深度
简单	单模块、低风险、无并发	1:1	隐性需求挖掘为主
中等	多模块、中风险、少量并发	2:1	隐性+衍生需求并重
复杂	跨模块、高风险、高并发	3:1	三层全量+五维拆解

输出示例

用户说"帮我分析这个需求：用户登录" → 显性需求：输入用户名密码，验证通过后登录 → 隐性需求：记住密码、自动登录、密码错误次数限制、多设备管理 → 衍生需求：密码找回、账号锁定、登录日志审计 → 五维拆解：输入（用户名/密码/验证码）→操作（点击登录）→状态（登录前/登录中/已登录）→输出（成功跳转/错误提示）→规则（密码策略/锁定策略）

需求文档只说"导入Excel文件" → 检查清单驱动挖掘：文件格式、大小限制、编码、字段映射、错误处理、导入进度

检查清单

解构完成后检查：

• 显性需求是否完整提取？
• 隐性需求是否充分挖掘？
• 衍生需求是否合理推导？
• 五维拆解是否全面？
• 风险点是否识别？
• 疑问点是否明确？

常见反模式

1. 顺手牵羊：解构时开始设计测试用例 → 解构只做需求分析，不提前跳入测试设计
2. 隐藏不标：隐性需求挖掘出来不标注 → 每条隐性/衍生需求必须有标识（[推断]/[假设]）
3. 规则遗漏：只拆需求不拆规则 → 每个需求必须连带提取对应的业务规则
4. 过度衍生：衍生需求推导到不切实际 → 衍生需求必须有合理场景支撑，否则标[待确认]
5. 五维偏科：只做输入/操作拆解，忽略状态/输出/规则 → 五维必须完整使用，不可选择性跳过