AI 生成测试用例总是不靠谱？你缺的不是模型而是一套 Skill 体系

目录

• 第一篇 基础篇：理解 Skill 与提示词
• 第二篇 进阶篇：Skill 规范与设计模式
• 第三篇 高级篇：Skill 工程化方法论
• 第四篇 知识库篇：Obsidian 知识库与 Skill 集成
• 第五篇 实战篇：AI 生成测试用例的 Skill 与提示词设计
• 附录：速查表与资源

第一篇 基础篇：理解 Skill 与提示词

1.1 什么是 AI Agent 的 Skill

在 AI Agent 生态中，Skill 是一种可复用的 Prompt 增强包，通过渐进式加载机制为 Agent 注入领域知识和工作流程。

2025 年 12 月，Anthropic 将 Skill 规范作为开放标准发布，目前已被 33+ 个 Agent 产品采纳，包括 Claude Code、OpenAI Codex、GitHub Copilot、VS Code、Cursor、Gemini CLI、Kiro 等。

通俗理解：

• 如果把 Agent 比作一个人，Skill 就是这个人的「专业技能手册」
• 如果把 Agent 比作操作系统，Skill 就是「可插拔的应用程序」
• 如果把 Agent 比作 ChatGPT，Skill 就是「定制化的系统提示词 + 工具 + 参考资料的组合包」

Skill 解决的核心问题：

1.2 Skill ≠ Prompt：本质区别

很多人把 Skill 等同于「一段长提示词」，这是误解。

关键洞察： Skill 不是 Prompt——它是围绕任务、工具、流程和输出边界的结构化行为设计。

1.3 提示词工程基础

提示词工程（Prompt Engineering）是构建有效 AI 指令的技艺，是 Skill 的基础构建块。

1.3.1 提示词的基本结构

一个完整的提示词通常包含以下要素：

[角色设定] + [任务描述] + [上下文/背景] + [约束条件] + [输出格式] + [示例]

入门示例（差的提示词）：

帮我写一个登录功能的测试用例

进阶示例（好的提示词）：

你是一位拥有 10 年经验的资深 QA 工程师。

请针对以下功能编写测试用例：

• 功能：跨境电商订单系统的「取消订单」
• 业务规则：订单在支付后 30 分钟内可取消，若已发货则不可取消
• 技术栈：RESTful API + MySQL
• 约束：覆盖等价类、边界值及异常场景（如并发取消）

输出格式：Markdown 表格，包含用例ID、测试步骤、预期结果

1.3.2 提示词的核心原则

1.4 提示词的六大核心技巧

技巧一：角色设定（Role Prompting）

给 AI 分配一个专业角色，从根本上改变输出的深度和专业度。

❌ 帮我分析一下这个接口的测试点

✅ 你是一位专注 API 安全测试 8 年的高级测试工程师，擅长发现接口的鉴权漏洞、幂等性问题和并发竞态条件。请分析以下接口的测试点：[接口文档…]

技巧二：思维链（Chain of Thought）

让 AI 先思考再输出，显著提升复杂推理任务的准确率。

❌ 直接给出测试用例

✅ 请按以下步骤思考：

技巧三：少样本示例（Few-Shot）

给 AI 展示 1-3 个标准示例，瞬间拉齐输出风格和质量。

以下是标准用例格式示例：

请按照这个格式为「密码重置」功能生成测试用例。

技巧四：负面指令（Negative Instructions）

告诉 AI 不要做什么，缩小决策空间。

❌ 只写"写测试用例"

✅ 写测试用例时：

• 不要写"与UI设计稿一致"这种模糊的预期结果
• 不要遗漏异常场景
• 不要省略前置条件
• 预期结果必须包含具体的文字内容或数值

技巧五：任务分解（Task Decomposition）

将复杂任务拆成多个小步骤，每步聚焦一个目标。

❌ 帮我从需求文档生成完整的自动化测试脚本

✅ 第一步：分析需求文档，提取可测试的功能点 第二步：为每个功能点设计测试用例（含正常/边界/异常路径） 第三步：将测试用例转化为 Pytest 脚本 第四步：添加断言和错误处理

技巧六：迭代优化（Iterative Refinement）

第一版输出很少完美，通过多轮对话逐步优化。

第一轮：生成初版用例 第二轮：“请补充边界值和异常场景的用例” 第三轮：“预期结果需要更具体，写明实际的文字内容和数值” 第四轮：“请按优先级排序，P0/P1/P2”

第二篇 进阶篇：Skill 规范与设计模式

2.1 Skill 规范标准（Anthropic 开放规范）

2.1.1 文件结构

一个 Skill 的最小形态只需要一个文件：

skill-name/
├── SKILL.md # 必需：YAML 元数据 + Markdown 指令
├── scripts/ # 可选：可执行脚本
├── references/ # 可选：按需加载的参考文档
└── assets/ # 可选：模板、资源文件

2.1.2 SKILL.md 格式

SKILL.md 由两部分组成：YAML Frontmatter（元数据） 和 Markdown Body（指令主体）。

YAML Frontmatter 字段：

name 命名规则：

• ✅ pdf-processing、data-analysis、code-review
• ❌ PDF-Processing（不允许大写）、-pdf（不能连字符开头）、pdf–processing（不允许连续连字符）

description 写法三维度：

好的 description：

Extracts text and tables from PDF files, fills PDF forms, and merges multiple PDFs. Use when working with PDF documents or when the user mentions PDFs, forms, or document extraction.

差的 description：

Helps with PDFs.

2.1.3 可选目录详解

scripts/ 目录 — 存放 AI 可以运行的可执行代码

• 脚本应自包含或明确声明依赖
• 常见语言：Python、Bash、JavaScript
• 示例：scripts/validate.py、scripts/generate_report.sh

references/ 目录 — 存放按需加载的补充文档

• 建议每个文件保持聚焦，越小越好
• 示例：references/api-errors.md、references/test-standards.md

assets/ 目录 — 存放静态资源

• 模板文件、图片、数据文件
• 示例：assets/test-case-template.xlsx、assets/schema.json

2.1.4 完整示例

—
name: expense–report
description: >
根据公司政策，归档和验证员工报销单。
当用户询问报销、提交费用或消费限额时使用。
license: MIT
compatibility: 需要 Python 3.8+
metadata:
author: finance–team
version: "1.0.0"
—

# 报销单处理

## 工作流程

1. 首先收集用户的报销信息，包括消费金额、消费日期、消费凭证
2. 调用 scripts/validate.py 脚本，验证报销单是否符合公司政策
3. 验证通过后，自动归档到指定文件夹；验证失败，提示用户补充材料

## 异常处理

– 如果单笔金额超过 5000 元，需要提醒用户提供主管审批意见
– 如果缺少消费凭证，直接提示用户上传凭证照片

## 参考文档

– 完整报销政策：references/reimbursement–policy.md
– 费用类别标准：references/expense–categories.md

2.2 三层渐进式加载机制

这是 Agent Skills 规范最精妙的设计，借鉴了 UI/UX 领域的渐进式信息披露策略：

关键价值： 即使安装了 20 个 Skill，初始加载也仅 1000-2000 tokens。相比单体式提示词，上下文使用量减少约 90%。

加载流程：

Agent 启动
│
▼ 加载所有 Skill 的 L1（name + description）
Agent 知道有哪些 Skill 可用
│
▼ 用户发送请求
模型判断：当前任务是否匹配某个 Skill 的 description？
│
├─ 不匹配 → 不加载，正常处理
│
▼ 匹配
加载该 Skill 的 L2（完整 SKILL.md body）
Agent 知道怎么做
│
▼ 执行过程中需要更多知识？
加载该 Skill 的 L3（references/ 等文件）
Agent 获得详细参考

L3 按需加载的设计技巧 — 在 SKILL.md 中明确告诉 Agent 何时加载参考文档：

参考文档加载规则

• 当 API 返回非 200 状态码时，读取 references/api-errors.md
• 当需要判断报销合规性时，读取 references/reimbursement-policy.md
• 其他情况不需要加载额外文档

2.3 触发机制设计

Skill 的触发完全依赖 description 字段，由模型自主判断（Model-driven Activation），而非关键词硬编码匹配。

触发测试案例设计：

[
{ "query": "帮我审查一下这段代码有没有安全问题", "should_trigger": true },
{ "query": "review this PR for security vulnerabilities", "should_trigger": true },
{ "query": "帮我写一个Python函数", "should_trigger": false },
{ "query": "解释一下什么是SQL注入", "should_trigger": false }
]

实验数据表明，包含触发短语+时序定位+领域关键词三个维度的 description，其 Skill 加载率比仅包含其中一维的高出约 3-5 倍。

2.4 五大核心设计模式

模式一：线性流程模式（Linear Flow）

适用场景： 执行步骤明确、无分支的操作性任务

典型场景： 应用部署、环境配置、软件安装、数据迁移

核心结构： Step 1 → Step 2 → Step 3 → … → Done

关键写作技巧：

反模式： 仅包含"快乐路径"的线性流程会使 LLM 在面对异常时陷入无指示状态。

模式二：决策树模式（Decision Tree）

适用场景： 需要覆盖大量选项的平台导航或问题诊断

典型场景： 云服务平台选型、错误日志诊断、技术方案评估

核心结构： 树形导航 + 按需加载

关键写作技巧：

反模式： 在单一文件中包含所有分支的完整文档，导致 SKILL.md 膨胀。

模式三：循环迭代模式（Iterative Loop）

适用场景： 需要反复执行"做→验证→改进"闭环的任务

典型场景： 测试驱动开发（TDD）、代码审查-修复循环、超参数调优

核心结构： 做 → 验证 → 改进 → 循环（满足退出条件则 Done）

关键写作技巧：

反模式： 循环没有明确的退出条件，LLM 可能无限循环。

模式四：接力棒循环模式（Baton Loop）

适用场景： 跨多个 Session 或多个 Agent 协作的长期项目

典型场景： 长期项目维护、多 Agent 协作的 CI/CD 流水线、跨周持续交付

核心机制： 将对话状态"外部化"——通过读写外部文件（通常命名为 next-prompt.md）来保存当前状态和下一步指令。

接力棒文件标准内容：

• 已完成部分：哪些任务已经完成，结果如何
• 未完成部分：哪些任务待执行
• 关键决策：已做出的重要决策及理由
• 已知问题/风险：当前面临的阻碍
• 下一步指令：下一个执行者需要做什么

反模式： 依赖 LLM 的上下文记忆来维持状态。跨 session 时上下文完全丢失。

模式五：多阶段 + 检查点模式（Multi-Phase + Checkpoints）

适用场景： 跨多天/多周、风险较高的复杂工作流

典型场景： 从需求到部署的全栈开发、从审计到修复的完整安全运维

核心结构： Phase N → [Decision Point: Go/No-Go] → Phase N+1

关键写作技巧：

反模式： 一个 Skill 试图覆盖从开始到结束的所有阶段，导致文件膨胀。

2.5 模式选择决策矩阵

核心原则：选择最轻量的模式解决问题。 过度设计不仅浪费 token，还会增加 LLM 的理解负担。

第三篇 高级篇：Skill 工程化方法论

3.1 完整开发生命周期（6 阶段闭环）

阶段一：需求捕获

理解意图、明确触发场景、确定输出格式、区分客观可验证 vs 主观创意型。

需求捕获清单：

• Skill 要解决什么问题？
• 目标用户是谁？他们怎么描述这个需求？
• 触发场景有哪些？（列出 5-10 个用户表述）
• 输出格式是什么？（文档、代码、报告、表格？）
• 可量化验证的验收标准是什么？
• 需要什么外部知识/工具？
• 是否需要对接知识库？知识库中有哪些可用的知识？

阶段二：编写 Skill

编写 SKILL.md（含 YAML frontmatter + 指令主体）+ 准备辅助资源。

编写检查清单：

• name 是否符合命名规范？
• description 是否包含触发短语 + 时序定位 + 领域关键词？
• 正文是否在 500 行以内？
• 是否使用了最轻量的设计模式？
• 是否包含退出条件和异常处理？
• references/ 中的文件是否按需加载？
• 知识库查询指令是否清晰？

阶段三：测试执行

设计 2-3 个测试用例 → 并行启动 with_skill 和 without_skill 两组子 Agent（A/B 测试）。

测试用例设计原则：

• 覆盖典型触发场景
• 包含边界情况
• 包含不应触发的负例
• 知识库查询是否准确触发

阶段四：评估与评审

量化评分 → 聚合基准数据 → 分析模式 → 人工评审 → 收集反馈。

评估维度：

• 正确性： 输出是否符合预期？
• 完整性： 是否覆盖了所有必要内容？
• 格式一致性： 输出格式是否稳定？
• 效率： Token 消耗是否合理？
• 知识库利用度： 是否正确查询和引用了知识库内容？

阶段五：迭代改进

分析反馈 → 泛化改进方向（避免过拟合）→ 重写 Skill → 回到阶段三。

关键原则：泛化而非过拟合。 遇到顽固问题，尝试换个隐喻或推荐不同的工作模式，而不是加更多死板约束。

阶段六：优化与发布

Description 优化 → 训练/测试集分割 → 自动迭代改进描述 → 校验 → 打包发布。

3.2 质量标准门禁

3.3 五大通用写作技巧

技巧一：教学式写作

不仅要告诉 LLM 做什么，还要解释为什么。LLM 对"理解原理"后的执行质量远高于"背诵流程"。

❌ 执行测试

✅ 执行测试以验证新代码没有破坏已有功能。我们在每个函数上至少需要三个测试用例：正常输入、边界条件和错误输入。这是因为历史上 70% 的回归 bug 出现在边界条件上。

技巧二：借口反驳表

前置声明常见的"偷懒"借口并一一反驳，防止 LLM 提前退出循环。

• “这个步骤可以省略” → 反驳：不可省略。每一步都是流程的必要组成部分。
• “根据我的判断，当前情况不需要” → 反驳：请列出你基于什么具体标准做出判断。
• “用户可能不希望” → 反驳：不要替用户做决定。展示选项，让用户选择。

技巧三：Good/Bad 对比示例

LLM 对示例的理解远优于对抽象规则的理解。

【Good】明确描述：修复 SQL 注入漏洞，将拼接查询改为参数化查询 【Bad】模糊描述：提高代码安全性

技巧四：用负面指令补充正面指令

正面指令：在部署前运行测试 负面指令：不要在未运行测试的情况下跳过部署

技巧五：设置量化阈值

❌ 确保测试覆盖率足够高 ✅ 每个函数至少有三个测试用例：正常路径、边界条件和错误路径

3.4 五个常见陷阱

陷阱一：单一文件过度膨胀

当 SKILL.md 超过 10K tokens 时，LLM 对文件中后部内容的关注度显著下降（注意力机制的"中间遗忘"问题）。

解决方案： 将详细文档拆分为 references/ 中的按需加载文件。

陷阱二：模糊的退出条件

没有明确退出条件意味着 LLM 可能会无限循环，或在错误的时间点退出。

解决方案： 每个循环体必须有可量化的检查清单。

陷阱三：假设 LLM 有"常识"

LLM 的"常识"与人类的常识不同。不要假设 LLM 知道"通常怎么做"。

解决方案： 把每一步都写清楚，包括那些看起来"显而易见"的步骤。

陷阱四：忽略安全约束

Skill 赋予 LLM 执行操作的能力，但如果没有安全约束，LLM 可能执行危险操作。

解决方案： 明确列出禁止的操作、在关键步骤前设置确认点、对高影响操作设置双重验证。

陷阱五：让 LLM 替用户做决策

LLM 倾向于"帮忙到底"，包括替用户做本应由人类做的决策。

解决方案： 在关键决策点，明确转入"等待用户决策"状态，并提供完整的选项清单和推荐理由。

3.5 高级提示词技术

3.5.1 思维链（Chain of Thought, CoT）

让模型在给出答案前先展示推理过程。

隐式 CoT（零样本）：

请一步步思考，然后给出答案。

显式 CoT（少样本）：

示例： Q: 商店有23个苹果，卖了15个，又进货了8个，现在有多少个？ A: 让我一步步思考。初始有23个苹果，卖了15个，所以剩余23-15=8个。又进货了8个，所以现在有8+8=16个。答案是16。

现在请解答：[新问题]

3.5.2 自我反思（Self-Reflection / Reflexion）

让 Agent 审视和修正自己生成的输出。Andrew Ng 四大 Agent 设计模式之一。

请先生成一份测试用例。

然后以资深QA的视角审视这份用例：

如果发现问题，请修改后输出最终版本。

3.5.3 ReAct 模式（Reasoning + Acting）

将推理和行动交替进行，是 Agent 最常用的执行模式。

Thought: 我需要先了解这个接口的请求参数 Action: 读取接口文档 Observation: 接口需要3个参数：userId(必填)、date(选填)、type(选填) Thought: 现在我可以为这个接口设计测试用例了 Action: 生成测试用例

3.5.4 Plan-and-Execute 模式

先规划再执行。适合复杂的多步任务。

成本优化技巧： 用强模型做规划，用便宜模型做执行，可降低 70-90% 成本。

3.5.5 多 Agent 协作（Multi-Agent Collaboration）

多个专业化的 Agent 各司其职：

• Planner Agent： 负责任务分解和规划
• Executor Agent： 负责具体执行
• Reviewer Agent： 负责质量评审
• Fixer Agent： 负责修复问题

3.5.6 提示词模板化

创建可复用的提示词模板，减少重复劳动：

TEST_CASE_PROMPT = """
你是一位{experience_level}的{role}。

请针对以下功能编写测试用例：
– 功能：{feature_name}
– 业务规则：{business_rules}
– 技术栈：{tech_stack}
– 约束：{constraints}

输出格式：{output_format}
{few_shot_examples}
"""

第四篇 知识库篇：Obsidian 知识库与 Skill 集成

本篇重点讲解：当你的 Agent 有明确的知识库（Obsidian Vault）时，Skill 和提示词应该如何设计与编写。

4.1 为什么知识库对 Skill 如此重要

核心矛盾： Skill 的 SKILL.md 建议控制在 5000 tokens 以内，但专业领域知识往往远超这个上限。

没有知识库的 Skill： 把所有知识塞进 SKILL.md → 文件膨胀 → LLM 注意力衰减 → 执行质量下降

有知识库的 Skill： SKILL.md 只放核心流程和规则 → 知识库存放详细知识 → 按需查询 → 精准注入

4.2 Obsidian Vault 在 Agent 架构中的角色

Obsidian Vault 在 Agent 系统中有三种用法：

用法一：作为 Skill 的 references 扩展

SKILL.md 中的 references/ 目录存放的是静态文件，而 Obsidian Vault 是一个活的、可搜索的知识库。

references/ 目录 = 静态文档（写死在 Skill 里）
Obsidian Vault = 动态知识库（可搜索、可更新、可积累经验）

用法二：作为跨 Skill 的共享知识源

不同 Skill 可以查询同一个 Vault 中的不同笔记，避免知识重复维护。

Skill A（测试用例生成）→ 查询 Vault 中的「测试方法论」「历史缺陷模式」
Skill B（视觉测试执行）→ 查询 Vault 中的「操作经验」「元素定位策略」
Skill C（缺陷分析） → 查询 Vault 中的「缺陷分类」「根因分析模板」

用法三：作为经验沉淀的目标

Agent 执行完任务后，将新发现的经验写回 Vault，形成知识飞轮。

执行任务 → 发现新经验 → 写入 Vault → 下次查询时可用 → 执行质量提升

4.3 Obsidian Vault 的组织设计

4.3.1 目录结构建议

ObsidianVault/
├── 测试方法论/
│ ├── 等价类划分.md
│ ├── 边界值分析.md
│ ├── 状态转换测试.md
│ └── 探索性测试.md
├── 领域知识/
│ ├── 车机IVI/
│ │ ├── 导航模块测试要点.md
│ │ ├── 蓝牙模块测试要点.md
│ │ └── 语音交互测试要点.md
│ └── 移动端App/
│ ├── 登录模块测试要点.md
│ └── 支付模块测试要点.md
├── 历史经验/
│ ├── 缺陷模式/
│ │ ├── 空指针崩溃模式.md
│ │ ├── 网络超时处理模式.md
│ │ └── 并发竞态模式.md
│ ├── 操作经验/
│ │ ├── ADB常用命令.md
│ │ ├── 截图断言技巧.md
│ │ └── 元素定位策略.md
│ └── 测试用例模板/
│ ├── 表单类用例模板.md
│ ├── 列表类用例模板.md
│ └── 流程类用例模板.md
└── 项目配置/
├── 环境信息.md
├── 测试设备清单.md
└── 已知问题.md

4.3.2 笔记编写规范

每篇 Obsidian 笔记应遵循统一结构，方便 Agent 解析和检索：

—
tags: [测试方法论, 边界值分析]
aliases: [BVA, Boundary Value Analysis]
created: 2026-06-05
updated: 2026-06-05
—

# 边界值分析

## 概述
边界值分析（BVA）是一种黑盒测试技术，专注于输入边界处的错误检测。

## 核心规则
– 对于范围 [a, b]，测试点：a-1, a, a+1, b-1, b, b+1
– 对于 n 个值的集合，测试：第1个、第2个、第n-1个、第n个
– 对于字符串长度限制 L，测试：0, 1, L-1, L, L+1 个字符

## 车机 IVI 常见边界值
| 输入项 | 范围 | 边界值测试点 |
|—|—|—|
| 导航目的地字符数 | 1-50 | 0, 1, 2, 49, 50, 51 |
| 蓝牙设备列表 | 0-8 | 0, 1, 7, 8, 9 |
| 音量等级 | 0-30 | -1, 0, 1, 29, 30, 31 |

## 历史缺陷案例
– 2026-03-15: 导航目的地输入51字符时App崩溃 → 已修复，增加截断逻辑
– 2026-04-20: 连接第9个蓝牙设备时系统卡死 → 已修复，限制最大8个

## 相关笔记
– [[等价类划分]]
– [[状态转换测试]]
– [[车机IVI/导航模块测试要点]]

关键设计要点：

4.4 知识库查询的三种策略

策略一：Python 侧预查询（推荐）

适用场景： Agent 执行自动化任务，Python 脚本控制流程

原理： 在调用 LLM 之前，由 Python 侧先搜索 Vault，将相关笔记内容直接注入 prompt。

def generate_test_cases_with_vault(requirement_doc, feature_name):
"""结合 Obsidian 知识库生成测试用例"""

# Step 1: 从 Vault 中检索相关知识
search_results = obsidian_client.search(
query=feature_name,
tags=["测试方法论", "领域知识"],
limit=5
)

# Step 2: 读取相关笔记内容
vault_context = ""
for note in search_results:
vault_context += f"\\n### {note.title}\\n{note.content[:500]}\\n"

# Step 3: 注入到 prompt 中
prompt = f"""
你是一位资深 QA 工程师。

## 以下是从知识库中检索到的相关经验：
{vault_context}

## 当前需求文档：
{requirement_doc}

请基于知识库中的经验和方法论，为上述需求生成测试用例。
"""

return llm.generate(prompt)

优点：

• LLM 不需要自己决定是否查询知识库（LLM 倾向直接输出，不主动查知识库）
• 查询时机和范围完全可控
• 可以对查询结果做预处理（截断、摘要、排序）

缺点：

• 需要额外的检索逻辑
• 如果检索关键词不准，可能召回不相关的笔记

策略二：Skill 中声明查询指令

适用场景： Agent 自主执行，需要 LLM 自行判断何时查询

在 SKILL.md 中写入知识库查询指令：

## 知识库查询规则

你可以通过 search_files 工具搜索 Obsidian Vault。查询时机：

1. 当需求文档涉及「导航」相关功能时
→ 搜索 "导航模块测试要点" 和 "边界值分析"
2. 当需求文档涉及「蓝牙」相关功能时
→ 搜索 "蓝牙模块测试要点"
3. 当不确定某个输入项的边界值时
→ 搜索 "边界值分析" + 具体输入项名称
4. 当需要参考历史缺陷模式时
→ 搜索 "缺陷模式" + 功能模块名称

查询时使用 search_files("关键词")，返回相关笔记列表。
选择最相关的 1-3 篇笔记阅读全文，将其中有用的经验融入测试用例。

不要查询的情况：
– 需求文档已经足够清晰
– 功能非常简单（如纯展示页面）
– 你已经对这类功能非常熟悉

优点：

• 灵活，LLM 可以根据实际情况决定是否查询
• 不需要额外的 Python 逻辑

缺点：

• LLM 可能不主动查询（特别是视觉测试场景，LLM 倾向直接输出 action）
• 查询次数和 token 消耗不可控

策略三：混合策略（最佳实践）

Python 侧预查询 + Skill 中的补充查询指令

## 知识库查询规则

系统已为你预加载了以下知识库内容（已注入上下文）：
– {vault_context}

如果预加载的内容不足以回答当前问题，你可以：
1. 使用 search_files("关键词") 搜索更多笔记
2. 优先搜索 tags 包含 "测试方法论" 或 "历史经验" 的笔记
3. 如果搜索结果超过 3 篇，只阅读最相关的 2 篇

新发现的测试经验，请在任务结束后写入 Vault：
– 笔记路径：历史经验/{模块名}/
– tags 包含：[历史经验, {模块名}]
– 内容包含：发现的缺陷模式、有效的测试策略、需要注意的边界条件

4.5 知识库场景的 SKILL.md 完整模板

以下是一个对接了 Obsidian 知识库的 Skill 模板：

—
name: test–case–generator–vault
description: >
根据需求文档生成结构化测试用例，自动查询 Obsidian 知识库中的
测试方法论、历史缺陷模式和领域知识。当用户要求生成测试用例、
写用例、分析需求写用例，或提到"测试设计"、"用例设计"时使用。
metadata:
author: qa–team
version: "2.0"
requires_vault: true
—

# 测试用例生成 Skill（知识库增强版）

## 核心原则

你是一位拥有 10 年经验的资深 QA 工程师。你会主动查询知识库中的历史经验，
而不是仅凭自身知识生成用例。这是因为知识库中沉淀了团队多年的真实缺陷模式
和测试策略，这些经验远比你单次推理更可靠。

## 工作流程

### Phase 1: 需求分析 + 知识库预查询

1. 读取用户的需求文档
2. 提取功能模块列表和关键词
3. 根据功能模块搜索知识库：
– 搜索 "测试方法论/{功能类型}" 获取方法论指导
– 搜索 "领域知识/{功能模块}" 获取领域特定测试要点
– 搜索 "历史经验/缺陷模式" 获取相关缺陷模式
4. 将知识库检索到的经验融入后续的用例设计

### Phase 2: 测试策略选择

根据功能类型和知识库中的经验选择策略：
– 表单类 → 等价类 + 边界值 + 输入校验
– 列表类 → 数据加载 + 空状态 + 分页 + 筛选
– 流程类 → 状态转换 + 正/逆向 + 并发
– 设置类 → 默认值 + 持久化 + 重置
– 不确定时 → 查询知识库中的 "测试方法论" 目录

### Phase 3: 测试用例生成

按四个维度生成用例：正向路径、边界值、异常路径、交互细节

生成时参考知识库中的：
– 历史缺陷案例 → 避免遗漏同类问题
– 边界值具体数值 → 使用真实数据而非猜测
– 测试用例模板 → 保持格式一致性

### Phase 4: 自我审查 + 知识库交叉验证

审查检查清单：
– [ ] 每个输入项有边界值用例？
– [ ] 预期结果具体？
– [ ] 异常场景 ≥ 30%？
– [ ] 知识库中的历史缺陷是否已覆盖？
– [ ] 知识库中的边界值数据是否已使用？

### Phase 5: 经验沉淀

用例生成完成后，将新发现的经验写入知识库：
– 如果发现了知识库中没有的新缺陷模式 → 写入 历史经验/缺陷模式/
– 如果发现了新的边界值 → 更新对应的领域知识笔记
– 如果知识库的某篇笔记内容过时 → 标记 [待更新]

## 知识库查询指令

### 何时查询
– 需求文档涉及你不太熟悉的领域
– 需要确定边界值的具体数值
– 需要参考历史缺陷模式
– 需要查找测试用例模板

### 如何查询
search_files("关键词") 搜索 Vault，优先选择 tags 匹配的笔记

### 查询后如何处理
– 将知识库内容作为参考，不要原样照搬
– 标注哪些用例参考了知识库中的经验
– 如果知识库内容与当前需求不一致，以当前需求为准

## 输出格式

| 用例编号 | 测试模块 | 测试场景 | 前置条件 | 测试步骤 | 预期结果 | 优先级 | 知识库参考 |

4.6 Obsidian Vault 查询提示词模板

模板一：Python 侧预查询的完整代码

import openai
from hermes import HermesClient

class VaultEnhancedTestCaseGenerator:
"""结合 Obsidian Vault 知识库的测试用例生成器"""

def __init__(self, vault_path, llm_endpoint):
self.vault = HermesClient(vault_path=vault_path)
self.llm = openai.Client(base_url=llm_endpoint)

def search_vault(self, query, tags=None, limit=5):
"""搜索 Vault 中的相关笔记"""
results = self.vault.search_files(query=query, limit=limit)
if tags:
results = [r for r in results if any(t in r.tags for t in tags)]
return results

def generate(self, requirement_doc, feature_name):
"""生成知识库增强的测试用例"""

# Step 1: 预查询知识库
methodology = self.search_vault(
query="测试方法论",
tags=["测试方法论"],
limit=3
)
domain_knowledge = self.search_vault(
query=feature_name,
tags=["领域知识"],
limit=3
)
defect_patterns = self.search_vault(
query=f"{feature_name} 缺陷模式",
tags=["历史经验"],
limit=3
)

# Step 2: 组装上下文
vault_context = self._format_vault_context(
methodology, domain_knowledge, defect_patterns
)

# Step 3: 生成测试用例
prompt = self._build_prompt(requirement_doc, vault_context, feature_name)
response = self.llm.chat.completions.create(
model="qwen3.6-27b",
messages=[{"role": "user", "content": prompt}],
temperature=0.3
)

return response.choices[0].message.content

def _format_vault_context(self, *note_groups):
"""格式化知识库笔记为 prompt 上下文"""
context = "## 知识库检索结果\\n\\n"
for group_name, notes in [
("测试方法论", note_groups[0]),
("领域知识", note_groups[1]),
("历史缺陷模式", note_groups[2])
]:
if notes:
context += f"### {group_name}\\n"
for note in notes:
context += f"**{note.title}** (tags: {', '.join(note.tags)})\\n"
context += f"{note.content[:800]}\\n\\n"
return context

def _build_prompt(self, requirement_doc, vault_context, feature_name):
"""组装完整 prompt"""
return f"""
你是一位资深 QA 工程师。请根据需求文档和知识库经验生成测试用例。

{vault_context}

## 当前需求
{requirement_doc}

## 生成要求
1. 参考知识库中的测试方法论和历史缺陷模式
2. 边界值使用知识库中的具体数值，不要猜测
3. 预期结果必须具体化
4. 异常场景 ≥ 30%
5. 标注哪些用例参考了知识库经验

## 输出格式
| 用例编号 | 测试场景 | 前置条件 | 测试步骤 | 预期结果 | 优先级 | 知识库参考 |
"""

模板二：直接在对话中使用知识库的提示词

你是一位资深 QA 工程师。你可以搜索 Obsidian 知识库来辅助生成测试用例。

## 知识库使用指南

你可以使用 search_files("关键词") 搜索知识库。建议搜索策略：

1. 先搜索功能模块名称（如 "导航模块"），了解领域测试要点
2. 再搜索 "边界值分析" + 具体输入项，获取精确的边界值数据
3. 最后搜索 "缺陷模式" + 功能模块名称，了解历史常见问题

每次搜索后，阅读最相关的 1-2 篇笔记，将其中有用的经验融入测试用例。

## 当前任务

请为以下功能生成测试用例：
{feature_description}

## 约束

– 预期结果必须具体化
– 异常场景 ≥ 30%
– 标注知识库参考来源

模板三：Hermes Agent SOUL.md 集成知识库的写法

# 角色定义

你是一位 AI 视觉自动化测试执行 Agent。你的职责是根据测试用例在车机 IVI 上执行操作，
通过截图验证结果，并将发现的问题和经验沉淀到知识库。

## 核心行为模式

{think}
{action}

## 知识库使用规则

### 何时查询知识库
1. 执行前：搜索当前测试模块的操作经验（如 "导航操作经验"）
2. 执行中：遇到不确定的界面元素时，搜索元素定位策略
3. 执行后：将新发现的经验写入知识库

### 何时不需要查询
– 任务明确、操作步骤清晰时，直接输出 action
– 已经有足够的上下文信息时

### 经验沉淀格式
每次执行完一个测试用例后，如果发现了新的经验：
– 笔记路径：历史经验/{模块名}/{日期}.md
– tags：[历史经验, {模块名}]
– 内容：发现的界面变化、新的定位策略、异常处理方法

## Vault 结构

测试方法论/ → 测试设计方法论指导
领域知识/车机IVI/ → 各模块测试要点
历史经验/ → 缺陷模式和操作经验
项目配置/ → 环境信息和设备清单

4.7 知识库场景的常见问题与解决方案

问题一：LLM 不主动查询知识库

现象： LLM 倾向直接输出答案，即使知识库中有更好的经验也不查。

根因： LLM 默认认为"我知道答案"，缺乏"我可能不知道"的自我怀疑能力。

解决方案：

问题二：查询召回不相关内容

现象： 搜索结果与当前任务无关，浪费 token。

解决方案：

问题三：知识库内容过时

现象： Vault 中的笔记内容与当前版本不一致。

解决方案：

问题四：知识库与 Skill 指令冲突

现象： 知识库中的做法与 SKILL.md 的指令不一致。

解决方案：

第五篇 实战篇：AI 生成测试用例的 Skill 与提示词设计

5.1 需求分析

场景描述

我们有一个 AI 视觉自动化测试 Agent，需要根据 UI 式样文档（需求文档）自动生成测试用例。Agent 有 Obsidian 知识库，其中沉淀了测试方法论、历史缺陷模式和领域知识。

需求拆解

核心痛点

5.2 模式选择

最终选择：线性流程为主干，嵌套决策树 + 循环迭代 + 知识库集成

5.3 完整 Skill 设计

目录结构

test-case-generator-vault/
├── SKILL.md
├── scripts/
│ ├── format_excel.py # 格式化 Excel 输出
│ ├── validate_coverage.py # 检查覆盖率
│ └── vault_search.py # 知识库查询辅助脚本
├── references/
│ ├── test-methodology.md # 测试设计方法论（静态备份）
│ └── boundary-value-guide.md # 边界值分析指南（静态备份）
└── assets/
└── excel-template.xlsx # Excel 格式模板

SKILL.md 完整内容

—
name: test–case–generator–vault
description: >
根据需求文档生成结构化测试用例，自动查询 Obsidian 知识库中的
测试方法论、历史缺陷模式和领域知识。当用户要求生成测试用例、
写用例、分析需求写用例，或提到"测试设计"、"用例设计"、"test case"时使用。
metadata:
author: qa–team
version: "2.0"
requires_vault: true
—

# 测试用例生成 Skill（知识库增强版）

## 核心原则

你是一位拥有 10 年经验的资深 QA 工程师，擅长从需求文档中提炼测试点
并生成高质量测试用例。

**为什么预期结果必须具体化？** 因为模糊的预期结果（如"与设计稿一致"）
无法判断用例是否通过，导致测试失去意义。

**为什么必须覆盖异常路径？** 历史数据显示，生产环境的 bug 中 70% 出现在
异常路径上。只测正常流程看似完整，实际漏掉了最大的风险区域。

**为什么必须查询知识库？** 知识库中沉淀了团队多年的真实缺陷模式和测试
策略，这些经验比你单次推理更可靠。不查知识库等于放弃团队最宝贵的资产。

## 工作流程

### Phase 1: 需求分析

1. 读取用户提供的需求文档
2. 提取功能模块列表
3. 识别每个模块的：
– 输入项（字段、按钮、下拉框等）
– 业务规则（校验规则、状态转换、权限约束）
– 交互逻辑（点击、滑动、长按等）
– 数据范围（数值范围、字符限制、可选值）
4. 明确排除不参与测试的区域（如系统栏、第三方组件）

### Phase 2: 知识库查询

根据 Phase 1 提取的功能模块，搜索知识库：

1. 搜索 "测试方法论/{功能类型}" 获取方法论指导
2. 搜索 "领域知识/{功能模块名}" 获取领域特定测试要点
3. 搜索 "历史经验/缺陷模式" 获取相关缺陷模式

查询策略：
– 每个搜索关键词尝试 2–3 种表述（如 "导航" 和 "navigation"）
– 每次搜索返回结果中选择最相关的 1–2 篇阅读
– 如果搜索无结果，回退到 references/ 目录中的静态文档

### Phase 3: 测试策略选择（决策树）

根据功能类型和知识库经验选择策略：

– 表单输入类 → 等价类划分 + 边界值分析 + 输入校验
– 列表展示类 → 数据加载 + 空状态 + 分页 + 排序筛选
– 流程审批类 → 状态转换图 + 正向/逆向流程 + 并发操作
– 设置配置类 → 默认值 + 修改生效 + 持久化 + 重置
– 多媒体类 → 加载状态 + 异常资源 + 缓存 + 格式兼容
– 不确定时 → 等价类划分 + 边界值分析（默认组合）

### Phase 4: 测试用例生成

对每个功能模块，按以下维度生成用例：

**1. 正向路径（Happy Path）**
– 正常操作流程，使用合法输入数据
– 预期结果必须包含具体的文字内容、数值或界面状态

**2. 边界值（Boundary Values）**
– 数值型：最小值、最小值–1、最小值+1、最大值、最大值+1
– 字符型：空值、1字符、最大长度、最大长度+1
– 列表型：0项、1项、最大项数
– 优先使用知识库中的具体边界值数据

**3. 异常路径（Error Path）**
– 必填项为空、格式错误、超出范围
– 网络异常、并发操作、权限不足
– 参考知识库中的历史缺陷模式

**4. 交互细节（UI Interaction）**
– 按钮状态（可点击/禁用）、加载状态
– 错误提示文案、键盘交互

### Phase 5: 自我审查（循环迭代）

审查检查清单：
– [ ] 每个输入项有边界值用例？
– [ ] 每个业务规则有验证用例？
– [ ] 预期结果具体（含实际文字/数值）？
– [ ] 无"与设计稿一致"模糊描述？
– [ ] 异常场景 ≥ 30%？
– [ ] 知识库中的历史缺陷已覆盖？
– [ ] 知识库中的边界值数据已使用？

常见偷懒借口与反驳：
– "这个场景不太可能出现" → 反驳：测试的目的是发现潜在问题
– "预期结果就是正常显示" → 反驳：什么是"正常"？请描述具体界面状态
– "知识库可能没相关内容" → 反驳：你查了吗？先查再下结论

不满足检查清单则补充，最多 3 轮迭代。

### Phase 6: 经验沉淀

用例生成完成后，将新发现的经验写入知识库：
– 新缺陷模式 → 写入 历史经验/缺陷模式/
– 新边界值数据 → 更新对应领域知识笔记
– 知识库内容过时 → 标记 [待更新] 并说明原因

### Phase 7: 格式化输出

1. 使用 assets/excel–template.xlsx 格式模板
2. 生成 Excel 文件，含统计汇总 sheet
3. 维护人列留空
4. 格式样式与模板完全一致，不得修改

## 预期结果具体化要求

❌ 与UI设计稿一致
❌ 正常显示
❌ 提示错误信息

✅ 页面跳转至首页，右上角显示用户名"testuser"
✅ 密码输入框下方显示红色提示文字"密码长度需6–16位"
✅ 登录按钮变为灰色不可点击状态

## 优先级定义

| 优先级 | 定义 | 示例 |
|—|—|—|
| P0 | 核心功能，阻塞性问题 | 正常登录、核心业务流程 |
| P1 | 重要功能，影响用户体验 | 边界值、格式校验 |
| P2 | 次要功能，体验优化 | 样式细节、极端异常 |

## 例外处理

– 需求文档不清晰 → 列出需澄清的问题，不猜测
– 功能依赖外部系统 → 标注依赖关系
– 预期结果不确定 → 标记 [待确认]
– 知识库无相关内容 → 使用 references/ 静态文档兜底

5.4 提示词模板

模板一：基础版（无知识库）

你是一位拥有 10 年经验的资深 QA 工程师。

请针对以下功能编写测试用例：
– 功能名称：{feature_name}
– 业务规则：{business_rules}
– 技术栈：{tech_stack}

要求：
1. 覆盖正向路径、边界值、异常路径
2. 预期结果必须具体化，包含实际文字内容或数值
3. 不要写"与UI设计稿一致"这种模糊描述
4. 维护人列留空

输出格式：Markdown 表格
| 用例编号 | 测试场景 | 前置条件 | 测试步骤 | 预期结果 | 优先级 |

模板二：进阶版（含方法论引导）

你是一位专注 {domain} 领域 10 年的资深 QA 工程师，擅长等价类划分、
边界值分析和状态转换测试。

## 任务
为以下功能生成测试用例。

## 功能描述
{feature_description}

## 业务规则
{business_rules}

## 技术约束
– 接口协议：{api_protocol}
– 数据库：{database}
– 特殊限制：{constraints}

## 测试设计要求（思维链）

第一步：分析功能，列出所有输入项及其取值范围
第二步：对每个输入项进行等价类划分（有效/无效等价类）
第三步：识别边界值（最小值、最大值、临界值）
第四步：绘制状态转换图（如涉及状态变化）
第五步：基于以上分析生成测试用例

## 用例生成规则
1. 每个输入项至少覆盖：正常值、边界值、非法值
2. 每个业务规则至少有一个正向验证和一个逆向验证
3. 预期结果必须具体：
– 界面类：描述具体的文字内容、颜色、位置
– 接口类：描述返回码、返回字段、具体值
– 数据类：描述数据库中的具体状态
4. 优先级：P0（核心流程）、P1（边界+校验）、P2（极端异常）
5. 异常场景占比不低于 30%

## 参考示例
| LOGIN-001 | 正常登录 | 已注册账号user1，密码Pass@123 | 1.打开登录页 2.输入user1 3.输入Pass@123 4.点击登录 | 页面跳转至首页，右上角显示"user1" | P0 |

模板三：知识库增强版（推荐）

你是一位资深 QA 工程师，擅长结合知识库经验生成高质量测试用例。

## 知识库检索结果（已预加载）

{vault_context}

—

## 当前需求

{requirement_doc}

## 生成要求

1. 参考知识库中的测试方法论和历史缺陷模式
2. 边界值优先使用知识库中的具体数值，不要猜测
3. 如果知识库中有相关的历史缺陷案例，确保生成对应的覆盖用例
4. 预期结果必须具体化，包含实际文字内容或数值
5. 异常场景 ≥ 30%
6. 标注哪些用例参考了知识库经验

## 输出格式
| 用例编号 | 测试场景 | 前置条件 | 测试步骤 | 预期结果 | 优先级 | 知识库参考 |

模板四：车机 IVI 专用版（含知识库）

你是一位专注于车机 IVI 系统测试的资深 QA 工程师，拥有 8 年车载系统测试经验。

## 知识库经验（已预加载）

{vault_context}

—

## 任务
根据以下车机 IVI 需求文档生成测试用例。

## 需求文档
{ivi_requirement_doc}

## 车机测试特殊要求
1. 多模态交互：触摸/语音/旋钮/方向盘控制，每种交互方式都需测试
2. 驾驶安全约束：行驶中部分功能需限制，需测试行驶/驻车状态切换
3. 系统资源限制：长时间运行、多应用切换
4. 异常场景重点：GPS丢失、蓝牙断连、USB拔插、网络切换、低电量/高温、来电打断
5. 屏幕适配：不同分辨率和 DPI
6. 多语言：中英文切换、长文本溢出

## 测试步骤要求
– 每个步骤必须明确操作方式：触摸/语音/旋钮
– 预期结果需描述：界面状态 + 语音反馈 + 按键响应
– 涉及行驶状态切换的，标注"⚠️ 需实车环境"
– 优先使用知识库中的真实边界值和缺陷模式数据

## 输出格式
| 用例编号 | 功能模块 | 测试场景 | 前置条件 | 操作方式 | 测试步骤 | 预期结果 | 优先级 | 知识库参考 |

5.5 测试与迭代

A/B 测试方案

评估指标：

• 正向/边界/异常用例比例
• 预期结果具体化率
• 异常场景覆盖率
• 历史缺陷模式覆盖率（C组专有）
• 知识库边界值数据使用率（C组专有）

迭代改进方向

附录：速查表与资源

A. Skill 编写速查表

SKILL.md = YAML Frontmatter + Markdown Body

Frontmatter 必填：
name: 小写字母+数字+连字符，1-64字符，与文件夹名一致
description: 1-1024字符，含触发短语+时序定位+领域关键词

Frontmatter 可选：
license / compatibility / metadata / allowed-tools

Body 结构建议：
1. 角色定义
2. 核心原则（解释为什么）
3. 工作流程（分步骤）
4. 知识库查询规则（如有 Vault）
5. 输出格式
6. 异常处理
7. 经验沉淀规则（如有 Vault）

Token 预算：
Frontmatter < 100 tokens
Body < 5000 tokens（500行）
References 按需加载

B. 知识库查询策略速查表

C. 提示词模式速查表

D. 测试用例提示词公式

无知识库版：

角色设定 + 业务背景 + 技术栈 + 测试方法论 + 约束条件 + 输出格式 + Few-Shot示例

有知识库版：

角色设定 + 知识库检索结果（预注入） + 业务背景 + 技术栈 + 测试方法论
+ 约束条件 + 输出格式 + 知识库参考标注要求 + Few-Shot示例