编程
将模糊的需求描述系统化拆分为输入、操作、状态、输出、规则五个可测试维度，同时挖掘显性需求之外的那些"没写出来但必须满足"的隐性需求和衍生需求。当用户的需求描述只有一两句话、或者看起来功能很简单但你可能遗漏了什么的时候，一定要用此技能做深度解构。适用于任何测试任务的第二步骤——无论需求文档有多详细，解构之后总能发现盲区。 本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills
将模糊的需求描述系统化拆分为输入、操作、状态、输出、规则五个可测试维度，同时挖掘显性需求之外的那些"没写出来但必须满足"的隐性需求和衍生需求。当用户的需求描述只有一两句话、或者看起来功能很简单但你可能遗漏了什么的时候，一定要用此技能做深度解构。适用于任何测试任务的第二步骤——无论需求文档有多详细，解构之后总能发现盲区。 本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills
⚠️ 安全警告：本技能的示例可能涉及订单号、支付金额、截图、身份证、手机号等敏感数据。 实际使用时请勿粘贴真实生产数据、客户信息或财务凭证；测试前应脱敏/掩码处理。 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。
专家看需求文档，看到的不只是文字，而是背后的测试模型。
关键指标：根据项目复杂度调整
| 复杂度 | 倍数 | 示例（显性5条） |
|---|---|---|
| 简单项目 | ×2 | 总需求10条 |
| 中等项目 | ×3 | 总需求15条 |
| 复杂项目 | ×4 | 总需求20条 |
复杂度判断标准：
是什么：文档明确写出的内容
提取方法：
1. 逐条阅读需求文档
2. 标注每条需求的关键词
3. 分类整理：功能需求、非功能需求、约束条件
4. 输出：显性需求清单（每条带REQ-ID）
检查清单：
- [ ] 所有功能点是否提取？
- [ ] 所有约束条件是否提取？
- [ ] 所有非功能需求是否提取？
- [ ] 每条需求是否可测试？
是什么：文档没写但隐含的需求
挖掘方法（五问法）：
1. 对每个"应该"问"如果不呢？"
2. 对每个"正常"问"异常呢？"
3. 对每个"确定"问"假设呢？"
4. 对每个"存在"问"不存在呢？"
5. 对每个"并发"问"同时操作呢？"
隐性需求类型：
├─ 业务隐含：业务流程的隐含步骤
├─ 技术隐含：技术实现的隐含约束
├─ 用户隐含：用户行为的隐含假设
├─ 环境隐含：运行环境的隐含条件
├─ 数据隐含：数据状态的隐含变化
├─ 并发隐含：并发操作的隐含冲突
├─ 时序隐含：操作顺序的隐含依赖
└─ 异常隐含：异常情况的隐含处理
检查清单：
- [ ] 库存相关隐性需求是否挖掘？
- [ ] 并发相关隐性需求是否挖掘？
- [ ] 时序相关隐性需求是否挖掘？
- [ ] 异常处理隐性需求是否挖掘？
- [ ] 数据一致性隐性需求是否挖掘？
- [ ] 安全相关隐性需求是否挖掘？
是什么：从显性和隐性需求推导出的需求
推导方法：
1. 从用户角色推导：不同角色有什么需求？
2. 从使用场景推导：不同场景有什么需求？
3. 从边界条件推导：极端情况有什么需求？
4. 从关联功能推导：相关功能有什么需求？
5. 从数据流向推导：数据在模块间怎么流？
检查清单：
- [ ] 不同用户角色需求是否推导？
- [ ] 不同使用场景需求是否推导？
- [ ] 边界条件需求是否推导？
- [ ] 关联功能需求是否推导？
- [ ] 数据流向需求是否推导？
推导示例：
用户输入什么？
├─ 输入类型：文本、数字、文件、选择
├─ 输入来源：手动输入、自动填充、第三方获取
├─ 输入限制：必填/选填、长度、格式、范围
├─ 输入异常：空值、超长、格式错误、特殊字符
└─ 输入关联：多个输入间的依赖关系
用户能做什么？
├─ 核心操作：主要功能路径
├─ 辅助操作：次要功能路径
├─ 禁止操作：不允许的操作
├─ 操作顺序：操作间的依赖关系
└─ 操作权限：谁能做什么操作
系统有哪些状态？
├─ 业务状态：待处理、处理中、已完成、已取消
├─ 数据状态：草稿、已发布、已归档
├─ 用户状态：未激活、正常、冻结、注销
├─ 状态流转：状态变更的条件和路径
└─ 状态异常：非法状态转换怎么处理
系统返回什么？
├─ 正常输出：成功时的返回内容
├─ 异常输出：失败时的返回内容
├─ 输出格式：JSON、HTML、文件
├─ 输出内容：数据、提示、错误信息
└─ 输出关联：多个输出间的一致性
业务规则是什么？
├─ 计算规则：公式、算法、精度
├─ 校验规则：格式、范围、关联
├─ 权限规则：角色、资源、操作
├─ 流程规则：步骤、条件、分支
└─ 规则冲突：规则间的优先级和矛盾
从业务规则中提取结构化描述，格式为"若X发生，则Y必须满足Z"：
| 规则ID | 触发条件 | 必须满足 | 验证方法 |
|---|---|---|---|
| RULE-001 | 若[条件] | 则[预期] | [验证方式] |
计算规则：
├─ 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 | [描述] | [假设] | [风险] | [疑问] |
获取需求文档
逐层解构
五维拆解
输出解构表
| 需求类型 | 定义 | 来源 | 挖掘方法 | 典型数量占比 |
|---|---|---|---|---|
| 显性需求 | 文档明确写出的 | 原始文档 | 直接提取、逐条编号 | 40-50% |
| 隐性需求 | 文档没写但隐含的 | 五问法推导 | 追问"如果不"/"如果异常" | 30-35% |
| 衍生需求 | 关联推导出的 | 角色/场景/边界驱动 | 换角色看、查关联功能 | 15-25% |
| 复杂度 | 特征 | 隐性与显性比例 | 建议解构深度 |
|---|---|---|---|
| 简单 | 单模块、低风险、无并发 | 1:1 | 隐性需求挖掘为主 |
| 中等 | 多模块、中风险、少量并发 | 2:1 | 隐性+衍生需求并重 |
| 复杂 | 跨模块、高风险、高并发 | 3:1 | 三层全量+五维拆解 |
用户说"帮我分析这个需求：用户登录" → 显性需求：输入用户名密码，验证通过后登录 → 隐性需求：记住密码、自动登录、密码错误次数限制、多设备管理 → 衍生需求：密码找回、账号锁定、登录日志审计 → 五维拆解：输入（用户名/密码/验证码）→操作（点击登录）→状态（登录前/登录中/已登录）→输出（成功跳转/错误提示）→规则（密码策略/锁定策略）
需求文档只说"导入Excel文件" → 检查清单驱动挖掘：文件格式、大小限制、编码、字段映射、错误处理、导入进度
解构完成后检查：
从完整性、清晰性、一致性、可测试性、可实现性五个维度系统化评审需求文档质量。当用户要求"评审这份需求"、"看看这个PRD写得怎么样"、或者测试用例设计前需要先评估需求质量时，应当使用此技能。如果需求本身有问题（模糊/矛盾/不可测试），后续的测试设计都是徒劳。不要只在用户明确说"需求评审"时才用——任何涉及需求文档的测试任务都应先过一遍需求评审。 本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills
当需求文档信息不够、不知道接下来该问产品什么、或者需要从开发那边获取更多技术细节时使用此技能。很多人测不好不是因为不会设计用例，而是因为一开始就没问对问题。提供需求调研、边界确认、规则挖掘、技术细节追问等不同场景的结构化提问模板，确保在测试设计前获取到足够上下文。每一个问题都标注了问谁、怎么问、什么时候问。 本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills
当所有分析（需求解构、场景树、边界清单、组合矩阵）都已完成，需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排。不要在分析还没做完时就跳到用例生成——没有充分的输入，用例一定是泛泛的。适用于将前面的分析产出物整合为 P0-P3 分级、可追溯的标准格式测试用例。 本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills
从需求文档自动生成结构化测试用例，覆盖功能测试、边界分析、组合测试和回归测试全流程。自动串联48个专家级子技能，按12步工作流编排执行。适用于：上传需求文档（PRD/Word/PDF/URL）需要完整测试用例时、不知道如何设计测试场景或担心遗漏边界条件时、需要AI评审测试输出并补充测试盲区时。每个步骤都有独立技能支撑，输出格式统一、需求可追溯、覆盖率可量化。
通过构建状态机、数据流图和服务依赖图来理清复杂的业务逻辑和系统边界。当需求文档复杂、涉及多个子系统交互、或者你搞不清楚数据在不同模块之间怎么流转的时候，应当使用此技能。领域建模不是为了画图而画图——它帮你发现那些"需求文档里没写的"隐式业务规则和系统边界。适用于复杂业务流程的测试范围可视化。 本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills
将需求解构的结果系统化转化为主路径、备选路径、异常路径、业务规则四类测试场景。当业务流程复杂、涉及多个页面跳转或状态变化、需要确保关键路径和异常路径都有覆盖时，应当使用此技能。不要只测"正常流程"——场景树的核心价值是暴露那些"用户可能不会按你预期操作"的分支和异常路径。每个场景都应有唯一ID（TC_{场景模块缩写}_{功能缩写}_{序号}）并关联回具体需求。 本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills