返回技能市场
Question Framework
当需求文档信息不够、不知道接下来该问产品什么、或者需要从开发那边获取更多技术细节时使用此技能。很多人测不好不是因为不会设计用例，而是因为一开始就没问对问题。提供需求调研、边界确认、规则挖掘、技术细节追问等不同场景的结构化提问模板，确保在测试设计前获取到足够上下文。每一个问题都标注了问谁、怎么问、什么时候问。
SKILL.md
⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills
⚠️ 安全警告：本技能的示例可能涉及订单号、支付金额、截图、身份证、手机号等敏感数据。 实际使用时请勿粘贴真实生产数据、客户信息或财务凭证；测试前应脱敏/掩码处理。 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。
提问框架
核心原则
专家不是"知道答案"，而是"知道该问什么"。
加载时机
| 什么时候读 | 读哪个 |
|---|---|
| 确定提问类别后，取对应模板 | references/question-scenarios.md |
四大提问场景的完整内容已下沉至references/question-scenarios.md，避免每次触发都占用上下文。
提问技巧
5W1H 质疑法
What：这是什么？做什么用的？
Why：为什么要做？为什么这样做？
Who：谁在用？谁负责？
When：什么时候用？什么时候上线？
Where：在哪里用？数据从哪来？
How：怎么用？怎么实现？
"如果不" 逆向思维
如果用户不按预期操作会怎样？
如果网络异常会怎样？
如果数据为空会怎样？
如果并发访问会怎样？
如果依赖服务挂了会怎样？
"那又怎样" 追问法
发现一个问题 → 那又怎样？影响什么？
影响一个功能 → 那又怎样？还影响什么？
影响一个用户 → 那又怎样？还影响谁？
提问场景速查
需求澄清场景
| 用户说 | 该问什么 | 目的 |
|---|---|---|
| "加个搜索功能" | 搜索范围？搜索结果包含哪些字段？支持模糊搜索吗？ | 明确实现边界 |
| "优化一下性能" | 优化到什么标准？响应时间目标？并发量目标？ | 定义量化目标 |
| "做个报表功能" | 报表维度？数据源？更新频率？导出格式？ | 锁定功能范围 |
| "增加权限控制" | 有多少角色？怎么分配？谁管理？ | 确认权限模型 |
| "对接第三方" | 对方接口文档？鉴权方式？数据格式？ | 明确集成方案 |
用例评审场景
| 发现问题 | 追问 | 检查方向 |
|---|---|---|
| 用例全是P0 | 怎么定义的优先级？按什么标准分类？ | 优先级合理性 |
| 缺少异常用例 | 这个功能可能出什么异常？最坏情况是什么？ | 异常覆盖 |
| 预期结果模糊 | "应该正常"和"应该成功"具体指什么表现？ | 结果可验证性 |
| 前置条件不写 | 这个用例依赖什么数据？数据从哪来？ | 条件完备性 |
Bug报告场景
| 开发者会问 | 报告前自检 | 对应提问链 |
|---|---|---|
| "怎么复现？" | 复现步骤清晰吗？从哪一步开始？ | 现象确认层 |
| "什么环境？" | 浏览器/版本/网络/数据状态写了吗？ | 环境信息层 |
| "影响多大？" | 影响到什么功能？多少用户？ | 影响评估层 |
| "可能什么原因？" | 日志/截图有吗？相关模块排查了吗？ | 根因推测层 |
应用场景
用户只说"帮我测登录功能"（信息不足） → 场景1提问链：业务目标是什么？→ 用户角色是什么？→ 登录方式有哪些？→ 约束条件是什么？
评审测试用例时发现遗漏 → 场景2提问链：这个场景的异常情况是什么？→ 边界条件是什么？→ 隐含假设是什么？
报Bug前自检 → 场景3提问链：复现条件是什么？→ 预期结果是什么？→ 实际结果是什么？→ 有没有附件？
自检清单
提问完成后检查：
- 是否覆盖了业务目标？
- 是否明确了功能边界？
- 是否识别了业务规则？
- 是否考虑了非功能需求？
- 是否挖掘了隐含假设？
- 是否识别了潜在风险？
检查清单
- 信息缺口是否识别？
- 提问是否覆盖3类（需求/边界/技术）？
- 提问是否具体可答？
- 优先级是否标注？
- 回答后是否更新解构？
评论与讨论
0/2000
还没有评论，分享你的体验吧。