Install
openclaw skills install @kokxi/qa-ai-prompt-strategy根据不同的测试目标和上下文,选择最佳的提示词模式来驱动AI生成高质量的测试用例。当AI输出的测试用例质量不够好、太泛泛、或者深度不够时,问题往往不在AI而在提示词。此技能提供结构化提示词模板,注入前面步骤产出的分析结果,输出包含角色定义、输出格式规范和约束条件的优化提示词。⚠️ 作为工作流的必过步骤,不得跳过。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills
openclaw skills install @kokxi/qa-ai-prompt-strategy⚠️ 本技能单独使用效果有限,建议配合完整技能集(12 步工作流)使用。安装:npx skills add Kokxi/qa-test-skills
不同的测试目标,需要不同的提问模式。
关键指标:提示词必须包含以下要素
1. 角色定义:你是[领域]资深测试专家
2. 输出数量:生成[N]条测试用例(N = 需求数量 × 5)
3. 覆盖维度:必须覆盖以下维度
- 功能测试:[具体功能点]
- 异常测试:[异常场景类型]
- 边界测试:[边界条件类型]
- 并发测试:[并发场景]
- 安全测试:[安全风险点]
- 性能测试:[性能指标]
4. 输出格式:Markdown表格,包含需求ID和风险ID
5. 质量要求:每条用例必须可执行、可验证
适用场景:需要标准化、可对比的测试用例
请按以下框架输出测试用例:
1. 用例编号:TC_{模块缩写}_{功能缩写}_{序号}(如 TC_API_LOGIN_001)
2. 用例标题:[动作] + [对象] + [条件]
3. 前置条件:[测试前需要满足的条件]
4. 测试步骤:[1. 2. 3. ...]
5. 预期结果:[具体可验证的预期]
6. 优先级:P0/P1/P2/P3
7. 风险等级:高/中/低
输出格式:Markdown表格
测试范围:[功能描述]
测试深度:覆盖正常/异常/边界/安全
适用场景:需要从特定视角深入测试
你现在是一位[角色],正在使用[功能]。
你的背景:
- 使用频率:[每天/每周/偶尔]
- 技术水平:[新手/普通/专家]
- 核心诉求:[你最关心什么]
- 常见操作:[你通常怎么用]
请从这个角色的视角,列出:
1. 你会怎么用这个功能?
2. 你会遇到什么问题?
3. 什么会让你不满意?
4. 你会怎么误用这个功能?
适用场景:复杂功能需要深度分析
请按以下步骤分析这个功能:
第1步:需求解构
- 列出所有显性需求
- 挖掘隐含假设
- 识别潜在矛盾
第2步:场景构建
- 主路径场景
- 分支路径场景
- 异常恢复场景
第3步:深度设计
- 边界条件分析
- 组合测试策略
- 状态转换覆盖
第4步:风险评估
- 高风险区域
- 建议测试深度
功能描述:[具体描述]
适用场景:AI输出后需要查漏补缺
以上是你生成的测试用例。现在请:
1. 假设挖掘
- 你在输出中做了哪些假设?
- 这些假设合理吗?
- 如果假设不成立会怎样?
2. 盲区检查
- 哪些场景你可能遗漏了?
- 哪些边界你没有覆盖?
- 并发、时序、资源竞争考虑了吗?
3. 改进建议
- 最需要补充的3个场景是什么?
- 从哪个方向迭代最有效?
适用场景:需要全面覆盖不同角度
请从以下三个视角分别分析这个功能:
【用户视角】
- 核心诉求:
- 操作路径:
- 痛点预测:
【开发视角】
- 技术实现风险:
- 边界条件:
- 异常处理:
【运维视角】
- 监控需求:
- 故障场景:
- 恢复方案:
功能描述:[具体描述]
适用场景:挑战AI的输出,逼出深层思考
我对你的输出有以下质疑:
1. [具体质疑点1]:你考虑过[特定场景]吗?
2. [具体质疑点2]:如果[极端情况]发生会怎样?
3. [具体质疑点3]:这个假设[具体假设]成立吗?
请针对每个质疑:
- 承认或反驳
- 补充你的分析
- 如果确实遗漏,补充测试场景
| 测试目标 | 推荐模式 | 优势 | 局限 | 复杂度 |
|---|---|---|---|---|
| 快速生成用例 | 结构化输出 | 标准化、高效、易对比 | 深度不足、缺乏个性 | ★★ |
| 深入理解用户 | 角色扮演 | 贴近真实场景、发现UX问题 | 依赖角色设定准确性 | ★★★ |
| 复杂功能分析 | 分步引导 | 系统化、不遗漏深度 | 耗时长、需要迭代 | ★★★★ |
| 质量评审 | 反向质疑 | 查漏补缺、打破盲区 | 需要已有输出为基础 | ★★★ |
| 全面覆盖 | 多视角 | 多维度、无死角 | 输出量大、需筛选 | ★★★★ |
| 挑战假设 | 对抗 | 逼出深层思考、验证假设 | 需要专业对抗经验 | ★★★★★ |
多个模式串联使用效果更佳:
| 组合 | 流程 | 适用场景 |
|---|---|---|
| 结构化输出 → 反向质疑 | 先生成 → 再查漏 | 日常快速迭代 |
| 分步引导 → 多视角 | 深度分析 → 多维度覆盖 | 复杂功能完整测试 |
| 角色扮演 → 对抗 | 模拟用户 → 挑战假设 | 用户体验全面验证 |
| 结构化输出 → 反向质疑 → 对抗 | 生成 → 评审 → 深度挑战 | 高安全/高风险场景 |
用户说:"帮我生成登录模块的测试用例"
普通问法(效果差):
帮我生成登录模块的测试用例
优化问法(使用结构化输出模式):
请按以下框架输出登录模块的测试用例:
- 用例编号:TC_{模块缩写}{功能缩写}{序号}(如 TC_API_LOGIN_001)
- 用例标题:[动作] + [对象] + [条件]
- 前置条件
- 测试步骤
- 预期结果
- 优先级:P0/P1/P2/P3
- 风险等级:高/中/低
输出格式:Markdown表格
测试范围:用户登录功能(用户名+密码) 测试深度:覆盖正常/异常/边界/安全/并发
选择提示词策略后检查:
不同模型对提示词的敏感度不同,同一模板在国产模型上需针对性调整:
| 模型 | 上下文窗口 | 适配要点 |
|---|---|---|
| DeepSeek | 64K-128K | 擅长中文指令理解,JSON 输出需显式声明"输出严格 JSON,不要 Markdown 代码块包裹";对分步引导模式响应好 |
| 通义千问 | 32K-100K+ | 结构化输出稳定,角色扮演模式效果好;需在角色定义中明确"你是测试工程师"避免幻觉角色 |
| 文心一言 | 8K-32K | 窗口相对小,上下文包需精简;对抗/反向质疑模式响应较弱,用多视角模式替代 |
| 豆包 | 32K-128K | 对话式交互友好,长提示词易截断;提示词尾部放最核心的约束(输出格式/编号规则) |
| Kimi | 128K-200K | 长上下文优势明显,适合完整上下文包直投;但对"必须输出 N 条"类数量约束需强调 |
适配策略:
1. 数量约束:国产模型对"生成 N 条用例"偶有缩水 → 提示词写"不少于 N 条",并加"如果不足,补充边界和异常场景"
2. 格式约束:多数国产模型默认带 Markdown 代码块 → 需显式声明"直接输出表格,不要代码块包裹"
3. 中文表达:国产模型中文流畅但对"用例标题"格式理解差异大 → 给出 1 条示例(如 TC_API_LOGIN_001 正确凭证登录成功)
4. 编号规则:部分模型会自作主张改编号 → 明确"严格使用 TC_{模块缩写}_{功能缩写}_{序号},不得改动格式"
5. 深度控制:国产模型倾向少而浅 → 用深度量化(简单×5/中等×10/复杂×15)约束用例数量级