腾讯 WorkBuddy + Skills 实战：构建 AI 测试用例质检工具

摘要： AI 生成测试用例越来越方便，但用例写出来以后，谁来检查需求覆盖、边界遗漏和预期结果？腾讯 WorkBuddy 支持通过 Skills 封装可复用的工作规则。本文带你创建一个测试用例质量评审助手，借助 SKILL.md 固定评审标准，并通过一组故意设置问题的登录测试用例，学习如何验证 AI Skill 的实际效果。

AI 生成测试用例，现在已经不是什么稀奇事了。

把需求文档交给大模型，要求它按照功能、异常、边界值设计用例，很快就能拿到一份表格。

但实际工作中，还有一个容易被忽略的问题：

AI 生成的测试用例，谁来负责检查质量？

比如，需求规定密码长度8—20位，用例只测了8位和20位，却没有7位和21位；预期结果写着“系统正常处理”，却没有明确的验收标准；还有些测试场景，看起来设计得很完整，实际上用了产品从未确认过的业务规则。

如果团队每次评审都要反复检查这些问题，有没有办法把常用的评审规则沉淀下来？

腾讯 WorkBuddy 的 Skills，提供了一种实现思路。

今天我们不做普通的测试用例生成工具，而是动手创建一个测试用例质量评审 Skill。

它不负责替你生成100条用例，而是按照既定规则，检查已有用例的质量，并输出可以追溯的问题清单。

更重要的是，创建完成后，我们还要反过来测试这个 AI 助手，看它是否真的能够发现问题。

一、为什么需要测试用例评审 Skill？

先弄清楚一个概念：Skill 到底是什么？

简单理解，Skill 就是把某一类任务需要的操作说明、处理流程、规则和辅助资源组织起来，让 AI 在适当的场景中复用。

普通 Prompt 当然也能实现部分相同功能，但两者的使用和维护方式存在区别。

假设你每次检查测试用例，都需要提醒 AI：

“别漏掉边界值。”

“预期结果必须能够验证。”

“没有明确的业务规则不能乱编。”

这些要求其实已经形成了一套固定的评审方法。

我们可以把它们整理成一个 Skill，让 WorkBuddy 在评审任务中按照这些规则工作。

不过，Skill 解决的是规则复用问题，不意味着 AI 的判断自动变得可靠。

因此，这篇文章除了介绍如何创建 Skill，还会重点讲解如何对它进行测试。

二、设计 Skill：先确定5项质量检查规则

开始创建之前，先回答一个问题：

什么样的测试用例，才算质量合格？

如果连评审标准都没有明确，AI 很容易输出“建议完善异常场景”“建议优化预期结果”这类泛泛的意见。

我们先把评审标准整理成下面5项。

举个例子。

某条登录用例写的是：

• 测试场景：正确账号密码登录。
• 操作步骤：输入账号密码，点击登录。
• 预期结果：系统正常。

这条用例至少有两个明显的质量问题。

一是缺少明确的测试账号、密码数据和必要的前置条件；二是“系统正常”无法作为具体的验收标准。

更合理的预期，应该明确验证登录成功后进入个人中心，并根据已确认的需求检查登录状态。

除了这5项标准，我们还要为 Skill 设置几条约束：

不能编造业务规则，不能虚构执行结果，不能把待澄清的问题当作已证实缺陷，也不能未经允许直接修改原始用例。

这些约束会影响后面 Skill 的输出质量。

三、动手创建：从 Prompt 到 SKILL.md

WorkBuddy 支持通过技能管理功能创建和管理 Skills。

这里采用官方文档介绍的技能创建方式，先让 WorkBuddy 帮我们形成技能初稿，再检查生成的规则文件。

第一步：创建技能

打开 WorkBuddy，进入技能相关页面，找到创建技能的入口。

不同客户端版本的菜单位置可能存在差异，具体以实际界面为准。

在创建技能时，输入以下指令：

创建技能提示词（可直接复制）

请创建一个名为 test-case-reviewer 的 Skill。

中文名称：
测试用例质量评审助手

用途：
对已有的软件测试用例进行静态质量评审，
不是重新生成测试用例。

输入资料：
1. 产品需求文档
2. 已有测试用例
3. 可选的业务规则及接口规范

检查维度：
1. 需求可追溯性
2. 等价类与边界值覆盖
3. 前置条件完整性
4. 操作步骤可执行性
5. 预期结果可验证性

输出：
1. 质量问题清单
2. 需求覆盖对照表
3. 待澄清问题列表
4. 修改建议

强制要求：
- 不得编造业务规则
- 不得虚构测试执行结果
- 每个问题尽量关联原始用例ID
- 无法确认的内容标记为待澄清
- 不得直接修改原始用例

请按照兼容的 Skill 结构生成技能文件，
并说明技能触发场景。

创建之后，需要检查技能是否已经安装或启用，不能只凭对话里的“创建成功”就认定配置完成。

第二步：检查 SKILL.md

SKILL.md 是这个技能的核心说明文件。

下面是一份可以参考的简化版本：

---
name: test-case-reviewer
description: >
  Review existing software test cases against
  requirements for coverage, boundary values,
  preconditions, steps, and verifiable results.
---

# 测试用例质量评审助手

## 任务目标

审查已有测试用例质量，
发现遗漏、歧义和不可验证的问题。

## 输入资料

- 原始需求文档
- 测试用例表
- 已确认业务规则（可选）

## 评审流程

1. 提取明确的需求规则。
2. 标记待澄清的需求。
3. 读取原始测试用例。
4. 按五项质量维度进行检查。
5. 生成问题清单和修改建议。
6. 输出需要人工确认的问题。

## 输出要求

每个问题包含：

- 问题编号
- 原始用例ID
- 问题类型
- 问题依据
- 修改建议

## 质量约束

- 不得编造业务规则。
- 不得虚构执行记录。
- 不得将待澄清项判为已证实缺陷。
- 不得直接修改原始用例。
- 不得以用例数量代替覆盖质量。

这份文件可以分为四个关键部分：

这里值得特别关注的是 description。

它需要准确描述技能的适用范围，帮助 Agent 在相关任务中识别和使用技能。

另外，创建 Skill 后，最好保存一份原始配置，便于后续修改和比较效果。

到这里，一个基础的测试用例质量评审助手就具备了初步结构。

但它究竟有没有用，不能只看配置文件，还需要实际测试。

四、准备测试数据：故意设计6类质量问题

我们使用一份简单的登录功能需求作为测试材料。

产品需求（教学示例）

需要注意，需求没有明确手机号格式、连续失败限制、错误提示具体文案等规则。

接下来准备5条故意存在问题的测试用例。

这些用例看起来都有测试场景和预期结果，但实际存在多个需要检查的问题。

我们先建立一份人工参考答案。

这6项问题就是本次练习的人工参考检查点。

注意，它们并不是全部潜在问题。例如，这份简化用例还缺少完整操作步骤、测试账号状态，以及部分需求规则的覆盖证据。

我们故意保留这些问题，就是为了验证 Skill 能不能真正按照评审规则工作。

如果 AI 发现了其他有依据的问题，也可以记录，但不能只凭它输出的问题数量评价好坏。

五、运行 WorkBuddy：让 Skill 生成质量评审报告

准备好需求文档和测试用例后，就可以开始调用 Skill。

如果前面创建的 test-case-reviewer 已经正确安装、启用，可以尝试使用下面的任务指令：

用例评审任务指令

请使用 test-case-reviewer 技能，
评审当前提供的登录需求和测试用例。

重点检查：

1. 需求可追溯性
2. 等价类和边界值覆盖
3. 前置条件完整性
4. 操作步骤可执行性
5. 预期结果可验证性

要求：

- 保留原始用例ID
- 所有问题说明发现依据
- 不得自行补充业务规则
- 不得修改原始测试用例
- 不得虚构测试执行结果

请输出：
1. 质量问题清单
2. 需求覆盖表
3. 待澄清问题
4. 具体修改建议

如果没有按预期调用技能，应先检查技能安装状态、启用状态和任务描述是否匹配，而不是直接认定技能已经运行。

应该得到什么样的结果？

以下是按照前面测试数据人工编写的参考结果，并非 WorkBuddy 的实际运行记录。

一份质量较好的评审报告，不应该只告诉你“建议增加边界测试”。

它至少需要说明：哪条用例有问题、问题依据是什么、建议怎么调整，以及是否需要产品进一步确认。

因此，我们可以用以下四项条件判断这次输出是否具备基本可用性。

如果输出没有满足这些要求，需要回到 SKILL.md 调整规则。

不过，报告看起来不错还不够。

接下来才是测试工程师真正应该关注的部分：如何系统地验证这个 Skill 的质量。

六、反过来测试 AI：检查漏报、误报和回归

很多 AI 工具教程写到这里就结束了。

工具搭好了，能够输出结果，于是宣布成功。

但如果从测试开发的角度考虑，我们还需要进一步回答：

这个 Skill 能不能稳定发现指定问题？会不会遗漏？会不会误报？

这就需要建立一套简单的评测方法。

第一步：准备带有人工参考标签的测试数据

可以先建立以下测试矩阵：

这张表既是输入场景，也是我们评估 Skill 的参考依据。

第二步：区分漏报和误报

假设人工确认某批用例中有10个明确问题，Skill 找到了其中8个。

另外，它还错误指出了2个实际上不存在的问题。

这种情况下，至少需要关注两个维度：

按照上述示例：

召回率 = 8 ÷ 10 = 80%

精确率 = 8 ÷（8 + 2）= 80%

这只是用于说明计算方法的假设数据，不是对 WorkBuddy 的实际测评结果。

此外，还应该观察两类问题。

规则遵循： AI 有没有擅自补充业务规则、虚构执行结果？

可追溯性： AI 的每一条问题，能否定位到原始用例或需求规则？

这些维度不一定要一开始就全部做成复杂的自动化评测系统，但至少需要记录下来。

第三步：修改 Skill，再做回归验证

假设第一轮测试中，Skill 经常漏掉边界值。

我们可以回到 SKILL.md，补充更具体的检查要求：

对于需求明确规定的整数闭区间，
优先检查以下代表性测试数据：

1. 下边界外
2. 下边界
3. 下边界内
4. 区间内代表值
5. 上边界内
6. 上边界
7. 上边界外

若没有对应测试用例，
应指出可能的覆盖遗漏。

不得对需求未明确的边界自行设定数值。

然后使用相同的评测数据再次执行。

这个过程可以概括为：

准备人工基准 → 运行 Skill → 比较结果 → 分析漏报和误报 → 修改规则 → 回归验证。

这里还有一个工程实践上的注意点：

不要只拿调整规则时使用的测试数据进行验证。

因为 Skill 可能只是在已知案例上表现得更好，换一个业务场景就不一定可靠。

因此，可以把评测数据分成两部分：

• 一部分用来发现问题、迭代 Skill。
• 另一部分保留下来，检验修改后的 Skill 能否处理未参与调优的新案例。

对于更复杂的项目，还可以把这些评测数据、规则文件和执行结果纳入版本管理，逐步建立可重复运行的评测与回归流程。

当我们开始验证 AI 助手是否可靠时，实际上已经进入 AI 测试开发的工作范畴。

七、从一个 Skill，到可复用的测试能力

回头看今天的实践，我们做的事情并不只是创建一个 AI 工具。

整个过程可以归纳为以下几个环节：

如果后续想做得更完整，可以继续加入 Python 数据校验脚本、Excel 字段完整性检查、固定评测数据集和自动化报告。

还可以基于类似的方法，开发缺陷报告质量检查、接口测试结果分析、需求歧义检查等不同的 Skills。

但不建议一开始就把所有功能放进同一个技能里。

先把一个任务定义清楚、验证稳定，再扩展到更多场景，往往更容易维护。

最后还想强调一点。

Skills 不是一个更长的 Prompt，也不是创建完就能永久保证正确的智能工具。

它真正有价值的地方，在于让我们能够把经验转化成规则，把规则组织成可复用的任务能力，再通过测试与评测持续检查结果是否可靠。

对于正在学习 Python 测开、AI Agent 或 AI 测试开发的工程师来说，这个过程比单纯让 AI 生成几百条测试用例，更值得动手实践。

因为以后我们不仅需要测试业务系统，还需要测试那些帮助我们完成工作的 AI 工具。

当 AI 开始参与测试，如何测试 AI 的工作质量，本身就是一项新的工程能力。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。