qa-question-framework

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

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

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

提问框架

核心原则

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

加载时机

什么时候读	读哪个
确定提问类别后，取对应模板	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类（需求/边界/技术）？
• 提问是否具体可答？
• 优先级是否标注？
• 回答后是否更新解构？