Qa Question Framework

SKILL.md

---
name: qa-question-framework
version: 1.6.0
description: >-
  当需求文档信息不够、不知道接下来该问产品什么、或者需要从开发那边获取更多技术细节时使用此技能。很多人测不好不是因为不会设计用例，而是因为一开始就没问对问题。提供需求调研、边界确认、规则挖掘、技术细节追问等不同场景的结构化提问模板，确保在测试设计前获取到足够上下文。每一个问题都标注了问谁、怎么问、什么时候问。

when_to_use: 用户说"不知道该问什么"、"怎么获取信息"、"需求不清楚"、"需要澄清"、"问什么问题"、"提问模板"、"和产品对需求"、"和开发沟通细节"、需要和PM/开发沟通需求细节、需求文档信息不足需要补充时
allowed-tools: Read Grep Glob
related_skills:
  upstream: []  # 基础层技能
  downstream:
    - qa-req-deconstruction      # 影响：需求挖掘完整性
    - qa-bug-reporting           # 影响：Bug报告完整性
    - qa-requirement-review
input_format:
  required:
    - name: 测试上下文
      type: string
      description: 待测试的功能或场景描述
  optional:
    - name: 需求文档
      type: string
      description: 相关需求文档
    - name: 已知约束
      type: string
      description: 技术或业务约束条件
output_format:
  traceability:
    - 本技能设计提问，不产出唯一ID
  structure:
    - question_list: 结构化提问清单
    - exploration_areas: 探索领域建议
    - clarification_needs: 需澄清的问题列表
categories: ['Development','Testing']
depth_requirement_quantification:
  reference_value: "根据信息缺口调整提问深度：简单×3/中等×5/复杂×7"
  minimum: "至少覆盖需求调研、边界确认、技术细节3类问题"
error_recovery_guidance:
  on_failure: "提问未能获取关键信息时回退到需求文档补充上下文"
  retry_behavior: "补充上下文后重新设计提问"
---
> **⚠️ 安全警告**：本技能的示例可能涉及订单号、支付金额、截图、身份证、手机号等敏感数据。
> 实际使用时请勿粘贴真实生产数据、客户信息或财务凭证；测试前应脱敏/掩码处理。
> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。

# 提问框架

## 核心原则

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

## 四大提问场景

### 场景1：拿到需求时的提问链

**目标**：从模糊需求中挖掘完整信息

```text
第一层：业务目标
├─ 这个功能要解决什么问题？
├─ 目标用户是谁？有几个角色？
├─ 核心价值是什么？用户能得到什么？
└─ 成功标准是什么？怎么衡量做成了？

第二层：功能边界
├─ 功能包含什么？不包含什么？
├─ 核心流程是什么？有几条路径？
├─ 输入是什么？输出是什么？
└─ 约束条件有哪些？限制是什么？

第三层：业务规则
├─ 有哪些业务规则？规则间有什么关系？
├─ 异常情况怎么处理？有降级方案吗？
├─ 状态怎么流转？状态变更条件是什么？
└─ 数据怎么存储？有数据迁移需求吗？

第四层：非功能需求
├─ 性能要求是什么？响应时间、并发量？
├─ 安全要求是什么？权限、数据保护？
├─ 兼容性要求是什么？浏览器、设备、系统？
└─ 可用性要求是什么？容错、恢复？
```

**示例提问**：
```text
"这个登录功能要解决什么问题？只是验证身份，还是有其他目的？"
"除了用户名密码登录，还有其他登录方式吗？"
"登录失败后怎么处理？有锁定机制吗？"
"登录状态保持多久？需要记住我功能吗？"
```

### 场景2：评审用例时的提问链

**目标**：识别测试用例的不足

```text
第一层：完整性检查
├─ 主路径场景都覆盖了吗？
├─ 分支路径都考虑了吗？
├─ 异常场景都设计了吗？
└─ 边界条件都分析了吗？

第二层：深度检查
├─ 边界分析够深吗？有隐含边界吗？
├─ 并发场景考虑了吗？
├─ 时序依赖分析了吗？
└─ 资源竞争测试了吗？

第三层：风险检查
├─ 高风险区域深挖了吗？
├─ 资金相关场景重点测了吗？
├─ 安全相关场景覆盖了吗？
└─ 数据一致性验证了吗？

第四层：可执行性检查
├─ 测试数据能构造吗？
├─ 测试环境能搭建吗？
├─ 测试步骤能执行吗？
└─ 预期结果能验证吗？
```

**示例提问**：
```text
"这个用例的前置条件能实现吗？数据从哪来？"
"这个预期结果怎么验证？有具体指标吗？"
"这个场景考虑过并发情况吗？"
"这个边界真的够深吗？还有其他边界吗？"
```

### 场景3：报Bug前的提问链

**目标**：确保Bug报告完整有效

```text
第一层：现象确认
├─ Bug的具体表现是什么？
├─ 在什么条件下出现？
├─ 复现步骤是什么？
└─ 出现频率是多少？

第二层：环境信息
├─ 在什么环境下出现？
├─ 使用什么浏览器/设备？
├─ 网络环境是什么？
└─ 数据状态是什么？

第三层：影响评估
├─ 影响范围有多大？
├─ 影响哪些用户？
├─ 有 workaround 吗？
└─ 优先级是什么？

第四层：根因推测
├─ 可能的原因是什么？
├─ 相关日志/截图有吗？
├─ 之前出现过类似问题吗？
└─ 哪个模块/接口可能有问题？
```

**示例提问**：
```text
"能详细描述一下Bug现象吗？"
"在什么条件下会出现这个问题？"
"能提供复现步骤吗？从头开始操作一遍"
"这个问题影响多大？有用户受影响吗？"
```

### 场景4：复盘时的提问链

**目标**：从问题中提取改进点

```text
第一层：事实还原
├─ 发生了什么问题？
├─ 什么时候发现的？
├─ 影响范围多大？
└─ 处理过程是怎样的？

第二层：根因分析
├─ 直接原因是什么？
├─ 根本原因是什么？
├─ 为什么没提前发现？
└─ 流程哪里出了问题？

第三层：改进措施
├─ 怎么防止再次发生？
├─ 流程需要怎么优化？
├─ 工具需要怎么改进？
└─ 知识需要怎么沉淀？

第四层：资产沉淀
├─ 这次学到了什么？
├─ 哪些经验可以复用？
├─ checklist需要更新吗？
└─ 培训材料需要补充吗？
```

**示例提问**：
```text
"这次问题的根本原因是什么？不是表面原因"
"为什么测试没发现这个问题？是覆盖不足还是方法问题？"
"下次怎么防止类似问题？具体措施是什么？"
"这次的经验怎么沉淀？checklist需要更新吗？"
```

## 提问技巧

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

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

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

## 提问场景速查

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

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

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

## 应用场景

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

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

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

## 自检清单

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


## 检查清单

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