qa-question-framework

SKILL.md

---
name: qa-question-framework
description: >-
  当需求文档信息不够、不知道接下来该问产品什么、或者需要从开发那边获取更多技术细节时使用此技能。很多人测不好不是因为不会设计用例，而是因为一开始就没问对问题。提供需求调研、边界确认、规则挖掘、技术细节追问等不同场景的结构化提问模板，确保在测试设计前获取到足够上下文。每一个问题都标注了问谁、怎么问、什么时候问。 触发场景：不知道该问什么、怎么获取信息、需求不清楚、需要澄清、问什么问题、提问模板、和产品对需求、和开发沟通细节、需求文档信息不足需要补充时。 Use when the user asks about: structured questions to ask product and engineering to unblock test design — requirements research, boundary confirmation, rule mining, and technical detail follow-up.
license: MIT
allowed-tools: Read Grep Glob
metadata:
  display-name: "Question Framework"
  version: "1.8.0"
  when-to-use: "用户说\"不知道该问什么\"、\"怎么获取信息\"、\"需求不清楚\"、\"需要澄清\"、\"问什么问题\"、\"提问模板\"、\"和产品对需求\"、\"和开发沟通细节\"、需要和PM/开发沟通需求细节、需求文档信息不足需要补充时"
  related-skills: "{\"upstream\":[],\"downstream\":[\"qa-req-deconstruction\",\"qa-bug-reporting\",\"qa-requirement-review\"]}"
  references: "[\"references/question-scenarios.md\"]"
  input-format: "{\"required\":[{\"name\":\"测试上下文\",\"type\":\"string\",\"description\":\"待测试的功能或场景描述\"}],\"optional\":[{\"name\":\"需求文档\",\"type\":\"string\",\"description\":\"相关需求文档\"},{\"name\":\"已知约束\",\"type\":\"string\",\"description\":\"技术或业务约束条件\"}]}"
  output-format: "{\"traceability\":[\"本技能设计提问，不产出唯一ID\"],\"structure\":[\"覆盖率：标注口径（基于现有需求/输入文档），禁止\\\"全覆盖/100%\\\"绝对化表述；缺失模块标注\\\"未覆盖+原因\\\"\",{\"question_list\":\"结构化提问清单\"},{\"exploration_areas\":\"探索领域建议\"},{\"clarification_needs\":\"需澄清的问题列表\"}]}"
  error-recovery-guidance: "{\"on_failure\":\"提问未能获取关键信息时回退到需求文档补充上下文\",\"retry_behavior\":\"补充上下文后重新设计提问\"}"
  categories: "[\"Development\",\"Testing\"]"
  depth-requirement: "{\"reference_value\":\"根据信息缺口调整提问深度：简单×3/中等×5/复杂×7\",\"minimum\":\"至少覆盖需求调研、边界确认、技术细节3类问题\"}"
---
> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills

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

# 提问框架

## 核心原则

专家不是"知道答案"，而是"知道该问什么"。

## 加载时机

| 什么时候读 | 读哪个 |
|-----------|--------|
| 确定提问类别后，取对应模板 | [`references/question-scenarios.md`](references/question-scenarios.md) |

> `四大提问场景`的完整内容已下沉至 `references/question-scenarios.md`，避免每次触发都占用上下文。

## 提问技巧

### 5W1H 质疑法
```text
What：这是什么？做什么用的？
Why：为什么要做？为什么这样做？
Who：谁在用？谁负责？
When：什么时候用？什么时候上线？
Where：在哪里用？数据从哪来？
How：怎么用？怎么实现？
```

### "如果不" 逆向思维
```text
如果用户不按预期操作会怎样？
如果网络异常会怎样？
如果数据为空会怎样？
如果并发访问会怎样？
如果依赖服务挂了会怎样？
```

### "那又怎样" 追问法
```text
发现一个问题 → 那又怎样？影响什么？
影响一个功能 → 那又怎样？还影响什么？
影响一个用户 → 那又怎样？还影响谁？
```

## 提问场景速查

### 需求澄清场景
| 用户说 | 该问什么 | 目的 |
|--------|---------|------|
| "加个搜索功能" | 搜索范围？搜索结果包含哪些字段？支持模糊搜索吗？ | 明确实现边界 |
| "优化一下性能" | 优化到什么标准？响应时间目标？并发量目标？ | 定义量化目标 |
| "做个报表功能" | 报表维度？数据源？更新频率？导出格式？ | 锁定功能范围 |
| "增加权限控制" | 有多少角色？怎么分配？谁管理？ | 确认权限模型 |
| "对接第三方" | 对方接口文档？鉴权方式？数据格式？ | 明确集成方案 |

### 用例评审场景
| 发现问题 | 追问 | 检查方向 |
|----------|------|----------|
| 用例全是P0 | 怎么定义的优先级？按什么标准分类？ | 优先级合理性 |
| 缺少异常用例 | 这个功能可能出什么异常？最坏情况是什么？ | 异常覆盖 |
| 预期结果模糊 | "应该正常"和"应该成功"具体指什么表现？ | 结果可验证性 |
| 前置条件不写 | 这个用例依赖什么数据？数据从哪来？ | 条件完备性 |

### Bug报告场景
| 开发者会问 | 报告前自检 | 对应提问链 |
|-----------|-----------|-----------|
| "怎么复现？" | 复现步骤清晰吗？从哪一步开始？ | 现象确认层 |
| "什么环境？" | 浏览器/版本/网络/数据状态写了吗？ | 环境信息层 |
| "影响多大？" | 影响到什么功能？多少用户？ | 影响评估层 |
| "可能什么原因？" | 日志/截图有吗？相关模块排查了吗？ | 根因推测层 |

## 应用场景

**用户只说"帮我测登录功能"（信息不足）**
→ 场景1提问链：业务目标是什么？→ 用户角色是什么？→ 登录方式有哪些？→ 约束条件是什么？

**评审测试用例时发现遗漏**
→ 场景2提问链：这个场景的异常情况是什么？→ 边界条件是什么？→ 隐含假设是什么？

**报Bug前自检**
→ 场景3提问链：复现条件是什么？→ 预期结果是什么？→ 实际结果是什么？→ 有没有附件？

## 自检清单

提问完成后检查：
- [ ] 是否覆盖了业务目标？
- [ ] 是否明确了功能边界？
- [ ] 是否识别了业务规则？
- [ ] 是否考虑了非功能需求？
- [ ] 是否挖掘了隐含假设？
- [ ] 是否识别了潜在风险？


## 检查清单

- [ ] 信息缺口是否识别？
- [ ] 提问是否覆盖3类（需求/边界/技术）？
- [ ] 提问是否具体可答？
- [ ] 优先级是否标注？
- [ ] 回答后是否更新解构？