你寫了十年測試案例，其實一直在寫 Skill，只是以前沒有 SKILL.md

2026-10-27 8

版权

版权声明：

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 本文揭示测试工程师十年经验与AI时代Skill的深层关联：你写的每条测试用例（前置条件、步骤、断言、异常处理）本质就是一份SKILL.md——只是过去由人执行，如今可交由Agent自动运行。只需结构化改造，即可将用例库、Bug记录、检查清单转化为可复用、可执行的智能判定逻辑。

前阵子，团队里一个做了十年测试的老同事跑来找我，表情有点困惑。

“哥，我看你们天天聊Skill、SKILL.md，我看了一下，这不就是写提示词吗？跟我写测试用例有什么关系？”

我说：“你把你上个月写的那份‘优惠券叠加规则’的用例，打开给我看看。”

他打开了一个Excel，里面是40多条用例：前置条件、操作步骤、预期结果、优先级，按正常流程、异常场景、边界值分好了组，每条用例的断言写得清清楚楚。

我看完说了一句话，他愣住了。

“你这份Excel，就是一份SKILL.md。你写了十年测试用例，其实一直在写Skill，只是之前没有SKILL.md这个容器。 ”

一、你以为你在写用例，其实你在封装“判定逻辑”
先别急着反驳。我们把一份测试用例拆开看。

一条标准的测试用例，长这样：

前置条件：用户已登录，账户余额大于0
操作步骤：进入提现页 → 输入金额100 → 点击提交
预期结果：提现申请创建成功，余额减少100，流水记录生成
异常分支：金额为负数时提示错误，余额不足时拦截
现在把这条用例，翻译成一段SKILL.md的正文：

任务

验证用户提现流程是否按预期执行。

前置条件

• 用户已登录
• 账户余额大于0

执行步骤

1. 进入提现页
2. 输入金额100
3. 点击提交

断言

• 提现申请创建成功
• 余额减少100
• 流水记录生成

异常处理

• 金额为负数：提示错误，不创建提现单
• 余额不足：拦截，不创建提现单
  发现了吗？内容一模一样。 你写测试用例时做的“前置条件、步骤、预期结果、异常分支”，就是Skill正文里的“前置条件、执行步骤、断言、异常处理”。

你不是在“写用例”，你是在把“怎么判断一个功能对不对”这件事，封装成一套可执行的判定逻辑。

而这，就是Skill的本质。

二、测试用例和Skill，到底差在哪？
差在三个地方，而且这三个地方，恰恰是测试工程师的强项。

第一个差别：用例是“给人看的”，Skill是“给Agent执行的”
你写的用例，是给测试同事看的。测试同事看完，知道“哦，这里要验余额，那里要验流水”。但这句话里有很多隐含信息——“流水记录生成”这个断言，到底是查哪张表、看哪个字段、什么值算“生成”？

人脑能补全这些隐含信息，Agent不能。

Skill要求你把“人脑补全的部分”显式写出来。 这正是测试工程师最擅长的——你写用例的时候，本来就在训练自己“把模糊的需求变成明确的判定”。

第二个差别：用例是“一次性的”，Skill是“可复用的”
你写了一份“优惠券叠加”的用例，下一个项目来了类似的促销规则，你会怎么办？复制一份，改改字段名。

Skill的做法是：把“优惠券叠加”的判定逻辑封装成一个Skill，下一个项目调用它，只需要传入新的规则参数。

测试工程师本来就有“复用”的意识——你写用例时，会把公共的登录步骤抽成前置条件，会把重复的校验抽成公共断言。Skill只是把这种复用，从“人工复制”升级成了“Agent自动调用”。

第三个差别：用例靠“人执行”，Skill靠“Agent执行”
这是最根本的差别。你写的用例再好，也需要一个人坐在电脑前，一步步操作、一条条核对。

Skill写好了，Agent可以自己执行、自己判断、自己重试。你从“执行者”变成了“规则制定者”。

但注意：Agent能执行的前提，是你把规则写得足够明确。 这恰恰是你写十年用例练出来的能力——把“我觉得这里应该没问题”变成“我验证了这三个字段，值分别是X、Y、Z”。

三、怎么把你的“用例经验”翻译成Skill？
不用从头学。你现有的测试用例，稍微改一下结构，就是一份可用的SKILL.md。

第一步：把“用例集”改成“任务定义”
你原来的用例集，是按功能模块分的。改成Skill，第一步是把“这个Skill要完成什么任务”说清楚。

原来：优惠券叠加规则测试用例（40条）

改成：

任务

验证优惠券叠加场景下的金额计算和状态流转是否正确。
第二步：把“前置条件”改成“输入约束”
你写的“用户已登录、账户余额大于0、优惠券在有效期内”，在Skill里叫“输入约束”。这不是文字游戏，是让Agent知道“什么条件下这个Skill适用，什么条件下不适用”。

输入约束

• 用户已登录
• 优惠券状态为“未使用”且未过期
• 订单金额大于0
• 不适用于：已取消订单、已退款订单
  第三步：把“预期结果”改成“分层断言”
  这是最关键的一步。你原来写的“提现成功”，在Skill里要拆成三层：

断言

协议层

• HTTP状态码 200

  数据层

• 响应体 code 字段为 0
• 响应体 data.withdraw_id 非空

  业务层

• 数据库 withdraw 表新增一条记录，状态为“处理中”
• 用户余额 = 原余额 - 提现金额
• 流水表新增一条“提现”类型记录
  你写用例时本来就在做这件事——你知道“提现成功”不只是页面弹个提示，还要查余额、查流水、查状态。只是以前你把这些写在“备注”里，现在要写进“断言”里。

第四步：把“异常用例”改成“异常处理规则”
你写的“金额为负数时提示错误”“余额不足时拦截”，在Skill里是“异常处理”。但要注意——不要只写“提示错误”，要写清楚“错误码是什么、错误信息包含什么、系统状态有没有变化” 。

异常处理

• 金额为负数：返回400，错误码 AMOUNT_INVALID，不创建提现单，余额不变
• 余额不足：返回400，错误码 BALANCE_INSUFFICIENT，不创建提现单，余额不变
• 重复提交：返回409，错误码 DUPLICATE_REQUEST，返回已存在的提现单ID
  四、一个真实的对比：同一个经验，两种写法
  我们拿“退款金额校验”这个场景做对比。

用例写法（你写了十年的方式）：

用例编号：REF-012 场景：退款金额超过订单实付金额 前置条件：订单已支付，实付金额100元 步骤：发起退款，金额输入150元 预期结果：退款失败，提示“退款金额不能超过实付金额”

Skill写法（同一份经验，换了个容器）：

断言

• 协议层：HTTP 400
• 数据层：响应体 code = REFUND_AMOUNT_EXCEEDED
• 业务层：
  • 退款单未创建
  • 订单状态保持“已支付”不变
  • 用户余额未增加
  • 操作日志记录一条“退款金额超限”事件
    内容没有变，变的是“颗粒度”和“可执行性”。

用例写法里，“退款失败”是一个人可以理解的结论。Skill写法里，“退款失败”被拆成了四个可验证的事实。Agent拿到后者，才知道该去查哪张表、看哪个字段、比对什么值。

五、避坑指南
坑一：把用例原文直接粘进SKILL.md。 用例是给人看的，里面有大量隐含信息（“验证成功”“检查正确”）。SKILL.md要的是显式规则，不能有“你懂的”这种假设。

坑二：断言只写一层。 只写“HTTP 200”的断言，等于没写。三层断言（协议、数据、业务）是底线。

坑三：异常处理只写“提示错误”。 要写清楚错误码、错误信息、系统状态有没有变化。Agent需要这些信息来判断“失败得对不对”。

坑四：Skill写得太长。 一份SKILL.md超过500行，就要拆分。把详细的用例模板、业务规则库放到references/目录，SKILL.md只留核心流程。

坑五：写完不验证。 写完Skill，用你原来的用例集跑一遍，看看Agent执行的结果和你人工执行的结果是否一致。不一致的地方，就是你没写清楚的地方。

六、你早就有的三个“Skill资产”
写了十年用例，你手里其实已经有三样东西，可以直接变成Skill。

第一，你的用例库。 那些写得最细、断言最完整的用例，就是最好的SKILL.md素材。挑出你最有信心的10条，按上面的四步翻译一遍。

第二，你的Bug记录。 每一个你发现过的Bug，背后都有一条“AI不知道的判定规则”。“用户用特殊字符密码可以绕过验证”——这条规则写进Skill，下次Agent就会去测特殊字符。

第三，你的检查清单。 你每次上线前都要过一遍的那个“脑子里的清单”——接口通不通、数据对不对、异常拦没拦住——把它写下来，就是一份Skill。

最后
Skill不是新东西。它是你写用例时，一直在做的那件事——把模糊的“应该没问题”，变成明确的“验证了这三个字段”。

只是以前，这份判定逻辑的“执行者”是人。现在，执行者可以是Agent。

你不需要重新学一套方法论。你只需要把你写了十年的用例，换一个容器装。

那个老同事后来把“优惠券叠加”那份Excel，花了一个下午改成了SKILL.md。第二天他跑了一遍，Agent生成的用例覆盖了他漏掉的三个边界场景。

他说了一句话：“原来我十年前就该写这个。 ”
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。