AI 测试用例生成总跑偏？六维封装法让 Skill 从“能用“变“好用“

## 一、开篇：测试用例 Skill 写不好，问题出在哪？

测试用例 Skill 写不好，AI 生成的用例不是幻觉编造就是输出格式三天两头变——问题不在 AI 不够聪明，而在于你的 Skill 没做"封装"。 本文提出「六维封装法」：边界锚点 / 角色方法论 / 正反样本库 / 粒度层级 / 输出契约 / AI 自检，六个维度系统化封装一个高质量 Skill。文末附可直接照搬的 Checklist 与 Skill 模板骨架。读完后你能得到：一个能稳定输出、可入库、可演进的高质量 Skill 工程方法论。

先看一道几乎每个测试团队都踩过的体验曲线：

• 第一天：惊艳——“这用例写得比我实习生还快！”
• 第三天：皱眉——“这个登录功能什么时候支持声纹识别了？需求文档里根本没有。”
• 第七天：放弃——“算了，改它生成的东西比我自己写还累。”

把 AI 当成一个能力极强、但对你的业务一无所知的新员工来看待。你会怎么带新人？你会给他：

这就是本文要讲的 六维封装法：把"带新人"的经验，工程化为 Skill 的六个封装维度。这套方法在我们的测试团队落地后，用例生成的一次可用率（生成后无需大改即可入库的比例）从不到 40% 提升到了 80% 以上。

先看全貌：

下面逐一拆解。

二、维度一：边界锚点——如何治好 AI 的"幻觉病"？

2.1 痛点

AI 最危险的不是不会写，而是写得太像真的。

让 AI 根据 PRD 生成登录模块的用例，它可能顺手给你补上"第三方账号登录"“声纹登录”“异地登录二次验证”——需求文档里一个字都没提。这些用例读起来逻辑通顺、步骤完整，如果不和原文比对，很容易被直接入库，变成一堆"测了个寂寞"的伪需求用例。

2.2 封装原则

核心原则：禁止编造。"没用"的兜底不如不写。

很多人写 Skill 时喜欢加一句"如果信息不足，请合理推演补充"——这是幻觉的助燃剂。正确做法是反向操作：给 AI 划定一个明确的知识边界，边界之外，宁可空着，不许编着。

2.3 落地示例

在 Skill 中明确写入这类锚点条款：

【边界约束】
1. 所有用例必须严格基于《XX系统 V2.3 需求规格说明书》原文生成，
不得引入文档之外的任何功能假设。
2. 每条用例必须能对应到至少一条原始需求条目，
并在"需求追溯"字段标注需求编号。
3. 禁止推演未提及的功能；如发现需求描述存在歧义或缺口，
不要自行补全，将问题列入"待确认清单"单独输出。
4. 无法从原文获得前置条件时，前置条件字段写"待补充（需求未明确）"，
严禁编造。

注意第 3 条的精妙之处：它没有让 AI 闭嘴，而是给了它一个合法的出口——把疑问放进"待确认清单"。信息缺口被显式地暴露出来，而不是被幻觉悄悄填平。实践中，这份"待确认清单"本身往往就是一份高价值的测试左移产出，可以直接拿去和产品经理对齐。

三、维度二：角色和方法论——怎样避免 AI 漏测？

3.1 痛点

只给 AI 一个"资深测试工程师"的人设，它生成的用例往往有两个毛病：

• 方法单一：90% 的用例都是正向功能验证，异常分支、组合条件大面积缺失；
• 正向泛滥：正向用例占比过高，而真正容易漏掉 Bug 的恰恰是异常和边界场景。

这是漏测的直接来源。

3.2 封装原则

人设是虚的，方法论是实的。 与其告诉 AI"你是专家"，不如直接把专家的分析框架喂给它——让 AI 执行一套确定性的算法，而不是模仿一种模糊的气质。

3.3 落地示例

【角色与方法论】
角色：你是测试团队的用例设计专家，严格遵循本团队设计规范。

方法论（每个功能点必须综合使用以下方法，并标注所用方法）：
– 等价类划分：有效/无效等价类均需覆盖
– 边界值分析：取 min-1 / min / min+1 / max-1 / max / max+1
– 场景法：覆盖基本流 + 每一条备选流
– 判定表：存在多输入组合的功能必须构造判定表
– 正交法：参数组合爆炸时用正交表裁剪

结构化约束：
1. 正向用例占比 <= 35%，其余为异常、边界、组合场景。
2. 每个功能点必须至少覆盖一条正常流程（Happy Path）作为基线。
3. 若某方法不适用于当前功能，需说明原因，不得静默跳过。

第 2 条值得强调："正向占比 ≤ 35%"和"必须覆盖正常流程"并不矛盾。前者防止正向用例挤占异常场景的坑位，后者保证基线场景不丢——有基线，异常才有参照系。

标注"所用方法"还有个额外收益：评审时可以一眼看出哪个功能点只用了一种方法，方法论覆盖的盲区直接可视化。

四、维度三：正反样本库——为什么一条反面样本胜过十句嘱咐？

4.1 痛点

你在 Skill 里写"用例要简洁、聚焦、可执行"，AI 依然会输出这样的东西：

步骤 1：打开浏览器，输入网址，进入登录页面，观察页面加载是否正常。
步骤 2：在输入框中仔细查看，然后输入正确的用户名和密码，注意不要输错。
步骤 3：点击登录按钮，耐心等待系统响应，查看是否跳转到首页。

步骤冗长、验证点含糊、一条步骤塞进三个动作。你反复修改提示词里的形容词，收效甚微。

4.2 封装原则

不要跟 AI 讲道理，给它看例子。

大模型的上下文学习（In-Context Learning）能力，远强于它对抽象形容词的理解力。"简洁"有一万种理解，但一条具体的反面样本只有一种含义。 AI 不要写流水账？你给它看一条"禁止写成这样"，它立刻就懂。

4.3 落地示例

在 Skill 中维护一个正负样本库：

【正向样本】（团队公认的标准写法）
用例编号：TC-LOGIN-001
用例标题：正确的账号密码登录成功
前置条件：账号 user01 已注册且状态正常
操作步骤：
1. 在登录页输入 user01 / 正确密码
2. 点击【登录】
预期结果：
1. 跳转至系统首页，右上角显示 user01 昵称

【负向样本】（绝对不能这么写）
用例标题：测试一下登录功能好不好用
操作步骤：
1. 打开浏览器输入网址进入登录页面观察页面是否正常
2. 在输入框中仔细查看然后输入正确的用户名和密码注意不要输错
3. 点击登录按钮耐心等待系统响应查看是否跳转到首页
错误点：标题无验证点 | 步骤动作堆叠 | 口语化描述 | 无独立预期结果

注意负向样本的最后一行——把错误点显式标注出来。这相当于不仅给 AI 看了"错误的答案"，还讲了"为什么错"。模型对这种"错误归因"式标注的响应非常敏感，规避效果显著。

样本库的位置也有讲究：建议放在 Skill 靠后的位置（临近生成指令），因为上下文学习对"离指令最近的示例"记忆最牢。

五、维度四：粒度和层级——如何控制用例粒度，一个测试点一条用例？

5.1 痛点

粒度失控有两种极端：

• 过粗：“验证登录模块全部功能”——一条用例塞了十几个验证点，执行失败后无法定位是哪一步的问题，也无法单独标记通过/失败；
• 过碎：“点击输入框”“输入字符 a”“输入字符 b”——步骤被拆成了原子操作，用例数量爆炸，维护成本指数级上升。

5.2 封装原则

一条用例 = 一个独立的测试点。 用例是最小的可执行、可判定、可追溯单元。

判断标准很简单：这条用例的预期结果，能否用一个"是/否"来判定？如果一条用例有五个预期结果、五个验证维度，那它其实是五条用例穿着一件马甲。

5.3 落地示例

【粒度约束】
1. Web 功能测试中，一条用例只对应一个独立测试点，
预期结果聚焦单一验证目标。
2. 单条用例的操作步骤控制在 3-5 步；超过 5 步时，
必须评估是否应拆分为多条用例。
3. 层级要求：模块 → 功能点 → 用例，三层结构，
用例编号体现层级（如 TC-LOGIN-PWDERR-001）。
4. 登录功能按测试点拆分示例：
– TC-LOGIN-001 正确账号密码登录成功
– TC-LOGIN-002 密码错误登录失败并提示
– TC-LOGIN-003 账号锁定后登录被拒
– TC-LOGIN-004 密码连续错误 N 次触发锁定
（而不是一条"验证登录的各种情况"）

“3-5 步"这个数字不是铁律，而是一个强制反思的触发器：当 AI 想写第 6 步时，它必须先停下来问自己"这是不是该拆了？”。粒度约束的本质不是限制步骤数，而是限制思维发散。

六、维度五：输出契约——如何把输出格式写成"合同"？

6.1 痛点

今天生成 Markdown，明天生成 Word；今天字段叫"预期结果"，明天变成"期望输出"；今天 6 列表格，明天混进两行散文。下游的用例管理系统、评审流程、自动化脚本对接全部遭殃——输出不稳定，Skill 就永远只是个玩具，进不了工程管线。

6.2 封装原则

交付格式是 Skill 与下游系统之间的合同，必须一次性谈死。 格式、字段、顺序、命名，全部写进 Skill，不留任何"由 AI 自行决定"的空间。

6.3 落地示例

【输出契约】
1. 输出格式：Markdown，用例以表格呈现。
2. 表头及顺序（固定，不得增删改列名）：
| 用例编号 | 用例标题 | 所属功能点 | 优先级 | 前置条件 |
| 操作步骤 | 预期结果 | 设计方法 | 需求追溯 |
3. 字段规则：
– 用例编号：TC-模块-序号，全大写
– 优先级：P0/P1/P2 三级
– 操作步骤：有序列表，每步一个动作
– 需求追溯：需求编号（REQ-xxx），无对应时填"待确认"
4. 表格之后单独输出两节：【待确认清单】【覆盖度统计】。
5. 除上述内容外，不得输出任何寒暄、解释性文字。

第 5 条常被忽略却极其关键：“不得输出寒暄”。AI 天然喜欢在正文前后加"好的，以下是根据您的需求生成的用例……“这类废话，对自动化解析是致命的。合同不仅约定"必须有什么”，还要约定"必须没有什么"。

七、维度六：AI 自检——为什么 Skill 必须能自己查自己？

7.1 痛点

即便前五个维度都做了，AI 偶尔还是会"失手"：某条用例忘了标需求追溯，正向占比悄悄涨到了 50%。而 Skill 一旦写完就束之高阁，错误模式就会持续复现——没有反馈闭环的质量，是无法演进的。

7.2 封装原则

让 AI 在交付前执行一次自检，把评审规则前置到生成环节。 更进一步：自检清单本身也由 AI 根据历次评审意见生成和迭代——这是 Skill 从"静态脚本"进化为"活文档"的关键机制。

7.3 落地示例

【AI 自检清单】（交付前逐项核对，输出核对结果）
□ 所有用例均可追溯到需求编号，无"编造功能"嫌疑
□ 正向用例占比 <= 35%
□ 每个功能点至少一条正常流程用例
□ 单条用例步骤 <= 5 步，单一验证点
□ 输出符合契约：字段、列序、编号规则完全一致
□ 边界值用例覆盖了 min-1/max+1 两侧
□ 歧义与缺口已列入【待确认清单】

【自检结果输出格式】
– 通过项：…（简列）
– 未通过项：…（说明原因及修正动作）
– 修正后重新交付完整结果。

落地节奏上，建议这样运营这份清单：

一个能自我检查、持续吸收评审反馈的 Skill，才是团队真正的资产，而不是某个人电脑里的一份提示词。

八、收尾：六维封装法落地 Checklist

最后，把六个维度压缩成一张可以直接照着做的 Checklist。下次写（或重构）Skill 时，逐项打勾：

## Skill 六维封装 Checklist

### 维度 1：边界锚点
– [ ] 明确了知识来源（哪些文档/哪些范围）
– [ ] 写入"禁止编造"条款，禁止 AI 自行补全需求
– [ ] 为信息缺口提供合法出口（待确认清单）
– [ ] 要求用例可追溯到原始需求条目

### 维度 2：角色和方法论
– [ ] 人设之外，给出了具体的设计方法清单
– [ ] 量化了结构约束（如正向占比 <= 35%）
– [ ] 要求标注所用方法，保证方法论可审计
– [ ] 明确正常流程的基线要求

### 维度 3：正反样本库
– [ ] 提供 1-2 条团队公认的正向样本
– [ ] 提供典型负向样本，并标注错误点
– [ ] 样本库放置在临近生成指令的位置
– [ ] 样本与团队最新规范保持同步

### 维度 4：粒度和层级
– [ ] 定义了"一条用例一个测试点"的判定标准
– [ ] 设定步骤数上限（建议 3-5 步）作为拆分触发器
– [ ] 规定了编号规则与层级结构
– [ ] 给出了拆分正确与拆分过碎的对比例子

### 维度 5：输出契约
– [ ] 固定了输出格式与完整字段列表
– [ ] 列名、顺序、取值枚举全部显式约定
– [ ] 约定了"禁止输出"的内容（寒暄、解释）
– [ ] 输出可直接进入下游系统（评审/入库/解析）

### 维度 6：AI 自检
– [ ] 内置了自检清单，交付前强制执行
– [ ] 自检结果随正文一起输出
– [ ] 建立了评审意见回流机制（月度迭代）
– [ ] 指定了 Skill 的 Owner 和版本记录

一个可以直接套用的 Skill 模板骨架

# [Skill 名称]：测试用例生成

## 1. 角色
你是 XX 团队的用例设计专家，严格遵循以下全部规范。

## 2. 边界锚点
（知识来源 / 禁止编造 / 追溯要求 / 待确认出口）

## 3. 方法论
（等价类 / 边界值 / 场景法 / 判定表 / 正交法 + 结构约束）

## 4. 粒度与层级
（一用例一测试点 / 3-5 步 / 编号规则）

## 5. 正反样本库
（正向样本 x1-2 / 负向样本 x1 + 错误点标注）

## 6. 输出契约
（格式 / 字段 / 列序 / 禁止项 / 附加输出节）

## 7. AI 自检清单
（逐项核对 / 未通过项修正后重交）

八、附：本文要点速查（FAQ）

Q1：什么是 Skill 六维封装法？
A：把"带新人"的经验工程化为 Skill 设计的六个封装维度——边界锚点、角色方法论、正反样本库、粒度层级、输出契约、AI 自检。

Q2：六维中哪一维最关键？
A：边界锚点（治幻觉）和输出契约（定格式）。先做这两维，一周内就能看到明显改善。

Q3：正反样本库放在 Skill 的哪个位置？
A：放在 Skill 靠后位置（临近生成指令），上下文学习对"离指令最近的示例"记忆最牢。

Q4：粒度约束的"3-5 步"是铁律吗？
A：不是铁律，而是"强制反思的触发器"。超过 5 步时先问是否该拆，而非机械执行。

Q5：AI 自检清单怎么冷启动？
A：先由人工评审 AI 产出，把高频问题逐条沉淀进清单；清单稳定后让 AI 每次输出自检结果。

九、写在最后

六维封装法的本质，是完成一次视角转换：

写 Skill 不是在"许愿"，而是在"带人"。

• 边界锚点，是不让新人越权；
• 方法论，是给他标准作业流程；
• 正反样本，是给他看好活和烂活的实物对比；
• 粒度契约，是约定交付颗粒度；
• 输出契约，是签好接口协议；
• AI 自检，是建立转正前的复核机制。

AI 的能力上限由模型决定，但能力下限由你的 Skill 决定。模型每个月都在换代，而"如何把人的经验封装给机器"这套工程方法，会长期保值。

从今天起，别再让 AI "自由发挥"了——用六维封装法，把它变成一个真正靠谱的团队成员。