![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/20f18cba2bb14a1c2a6577b0264bcbe2.png)
**摘要：** 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 当然也能实现部分相同功能，但两者的使用和维护方式存在区别。

| 对比维度 | 普通 Prompt | WorkBuddy Skill |
|---|---|---|
| 使用方式 | 在对话中输入要求 | 安装后可重复调用 |
| 规则组织 | 依赖提示词内容 | 通过 SKILL.md 等文件组织 |
| 工作流程 | 针对当前任务指定 | 可预先定义步骤 |
| 适用场景 | 临时分析、一次性任务 | 高频、重复性任务 |
| 后续维护 | 修改提示词 | 更新技能文件及资源 |

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

“别漏掉边界值。”

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

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

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

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

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

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

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/e1290300e77516e0cfe2019cb6806c40.png)


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

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

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

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

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

| 检查维度 | 检查内容 |
|---|---|
| 需求可追溯 | 用例是否关联明确的需求规则 |
| 边界与覆盖 | 关键有效、无效及边界场景是否遗漏 |
| 前置条件 | 执行所需的数据和业务状态是否清楚 |
| 操作步骤 | 其他测试人员能否复现 |
| 预期结果 | 是否具体、明确、可验证 |

举个例子。

某条登录用例写的是：

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

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

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

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

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

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

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

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

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

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

### 第一步：创建技能

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

不同客户端版本的菜单位置可能存在差异，具体以实际界面为准。
![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/6565edf758252b48ca87641998da5ddd.png)

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

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

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

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

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

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

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

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

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

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

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

### 第二步：检查 SKILL.md

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

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

```markdown
---
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
- 问题类型
- 问题依据
- 修改建议

## 质量约束

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

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

| 文件内容 | 作用 |
|---|---|
| name / description | 定义技能身份与适用任务 |
| 任务目标、输入资料 | 告诉 AI 要解决什么问题 |
| 评审流程、输出要求 | 约束具体工作步骤和结果格式 |
| 质量约束 | 防止编造规则和错误下结论 |

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

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

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

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

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

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

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

**产品需求（教学示例）**

| 需求ID | 需求规则 |
|---|---|
| R-01 | 用户输入手机号和密码后点击登录 |
| R-02 | 密码长度限制为8—20位 |
| R-03 | 验证成功后进入个人中心 |
| R-04 | 验证失败时显示错误提示 |

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

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

| 用例ID | 测试场景 | 预期结果 |
|---|---|---|
| TC-001 | 正确账号密码登录 | 系统正常 |
| TC-002 | 使用7位密码登录 | 提示错误 |
| TC-003 | 使用8位密码登录 | 登录成功 |
| TC-004 | 使用20位密码登录 | 登录成功 |
| TC-005 | 连续输错5次密码 | 锁定账号30分钟 |

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

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

| 检查对象 | 预设质量问题 |
|---|---|
| TC-001 | 预期结果模糊，不可直接验证 |
| TC-002 | 未明确长度不合法时需要验证的行为 |
| TC-003 | 缺少账号密码匹配等必要条件 |
| TC-004 | 将长度合法与登录成功混为一谈 |
| TC-005 | 使用未经确认的账号锁定规则 |
| 用例集合 | 缺少21位密码的上边界外测试 |

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

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

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

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

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

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

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

**用例评审任务指令**

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

重点检查：

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

要求：

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

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

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

### 应该得到什么样的结果？

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

| 用例ID | 问题类型 | 修改建议 |
|---|---|---|
| TC-001 | 预期模糊 | 明确页面跳转和登录状态 |
| TC-002 | 结果不可验证 | 补充长度校验行为 |
| TC-003 | 前置条件缺失 | 明确有效账号与正确密码 |
| TC-004 | 验收逻辑不完整 | 区分长度合法与身份验证成功 |
| TC-005 | 需求未确认 | 将锁定规则标记为待澄清 |
| 用例集合 | 边界遗漏 | 补充21位密码测试 |

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/8d49ef0319061607b1b37a8611026f1a.png)

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

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

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

| 检查项 | 判断标准 |
|---|---|
| 问题定位 | 能对应原始用例或整个用例集合 |
| 规则依据 | 能指出对应需求或评审规则 |
| 建议质量 | 修改方向具体、能够执行 |
| 事实边界 | 不把猜测写成已确认的需求 |

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

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

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

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

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

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

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

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

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

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

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

| 测试输入 | Skill 应有的表现 |
|---|---|
| 预期写“系统正常” | 指出结果不可验证 |
| 缺少21位密码场景 | 识别边界遗漏 |
| 5次失败锁定30分钟 | 标记规则待澄清 |
| 前置条件为空 | 指出条件不完整 |
| 仅提供用例，无需求 | 不断言需求已充分覆盖 |
| 提供完整且符合需求的用例 | 不强行编造问题 |

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

### 第二步：区分漏报和误报

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

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

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

| 指标 | 含义 |
|---|---|
| 召回率 Recall | 人工标注的真实问题发现了多少 |
| 精确率 Precision | AI 报告的问题中有多少确实成立 |

按照上述示例：

召回率 = 8 ÷ 10 = 80%

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

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

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

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

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

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

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

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

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

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

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

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

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

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

这个过程可以概括为：

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

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/1774159896bf67f5bac4a566059b986a.png)


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

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

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

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

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

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

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

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

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

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

| 工程环节 | 本次完成的工作 |
|---|---|
| 任务定义 | 明确只做测试用例质量评审 |
| 规则设计 | 提炼5项质量检查标准 |
| 技能封装 | 使用 SKILL.md 固定规则和流程 |
| 数据准备 | 构造有已知问题的测试用例 |
| 质量评测 | 检查检出情况、漏报与误报 |
| 持续改进 | 修改规则并进行回归验证 |

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

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

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

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

最后还想强调一点。

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

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

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

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

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

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


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

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

本文介绍如何用腾讯WorkBuddy Skills打造“测试用例质量评审助手”：通过SKILL.md固化5项评审标准（需求追溯、边界覆盖、前置条件等），结合故意设错的登录用例验证AI能否精准识别漏边界、模糊预期等问题，并强调需系统评测召回率与精确率——让AI评审可衡量、可迭代、可信赖。

人工智能

测试

开发工具

创建测试用例质量评审助手：利用腾讯WorkBuddy的Skills功能，将5项质量检查规则封装为可复用技能。通过SKILL.md固定评审标准，用6类故意设计的问题用例验证AI能力，涵盖漏报、误报与回归测试，实现从用例生成到质量校验的闭环。

身份验证

软件测试

代码解释

WorkBuddy 

Python

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

腾讯 WorkBuddy + Skills 实战：构建 AI 测试用例质检工具-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐