别再写用例了：Skills 正在接管测试工程师

你有没有算过，自己一年写了多少条测试用例？其中有多少，是你凌晨加班、复制粘贴、改改字段名就糊出来的？

我认识一位工作了七年的高级测试工程师，最近跟我说了一句让我久久回味的话：

“我感觉自己每天都在用脑子做 Excel 该做的事。”

他不是在抱怨。他是在描述一个客观事实：测试用例这件事，正在变成一种纯粹的体力劳动。需求文档进来，用例模板填进去，评审、修改、归档……七年里，这个流程几乎没变过。

直到 Skills 出现。

一、什么是 Skills？

如果你用过 Claude Code，或者关注过近期 AI 工程工具的演进，你可能已经见过“Skills”这个词。简单来说，Skills 是一种封装了领域知识、执行逻辑和输出规范的 AI 能力模块。它不是一个提示词，也不是一个脚本——它更像一个经过训练的专家，知道“测试一个支付模块”意味着什么，应该覆盖哪些边界，应该输出什么格式。

更直白的比喻： Skills 就像你带了一个实习生，但这个实习生已经读完了你们公司所有的测试规范、历史用例、Bug 记录，并且永远不会累，永远不会犯同样的错误两次。

更关键的是，它可以被定制、被复用、被团队共享。这让它从“一个聪明的工具”变成了“一个可以上生产的基础设施”。

二、传统用例写作，到底哪里出了问题？

在聊 Skills 能做什么之前，我们先把这个问题说清楚。传统测试用例的问题不是“写”本身，而是写的方式。

这不是说人不重要了。恰恰相反——人变得更重要了，但重要的位置变了。

一个真实的场景：订单状态流转测试

让我们拿一个实际案例来看。假设你负责测试一个电商平台的订单状态机，状态包括：待支付、已支付、备货中、已发货、已签收、退款中、已退款、已取消。

传统方式： 你打开 Excel，开始手写每一个状态转换路径，想到哪写到哪，一两天后交出一个 200 行的用例表，然后在评审会上被产品经理问“那用户在备货中申请退款，然后商家拒绝，然后用户再投诉的路径覆盖了吗？”

然后你回去再补……

用 Skills 的方式是这样的：你把状态机的定义（可以是文档、可以是代码里的枚举值、可以是流程图截图）喂给配置了“状态机测试 Skill”的 AI，它会：

1. 自动枚举所有合法的状态转换路径（含正向和反向）
2. 识别非法状态转换，生成对应的负向用例
3. 推导多步骤组合路径（如：支付 → 退款申请 → 拒绝 → 再次退款）
4. 输出结构化的测试用例，附带预期结果和优先级标注

你的工作变成什么？审查它有没有搞错业务逻辑、补充你们系统的特殊规则、然后把这份用例推进执行。整个过程从两天压缩到半天，而且覆盖率往往更高。

三、Skills 的3种核心用法

根据当前的实践，Skills 在测试场景里主要有三个落地方向：

用法1：需求驱动生成

把 PRD、接口文档、用户故事直接投喂给 Skill，输出测试用例草稿。适用于功能测试、接口测试的初稿生成。关键点在于 Skill 的“领域知识”配置——你需要告诉它你们系统的特殊约束、常见的业务规则。

用法2：代码变更感知

结合 Git diff 或代码分析，让 Skill 识别本次变更影响了哪些模块，自动推荐需要回归的用例集合，甚至新增针对变更点的专项用例。这在 CI/CD 流程里非常有价值。

用法3：历史缺陷学习

把过去的 Bug 数据、线上故障记录导入，训练 Skill 的“高风险感知”能力。它会在生成用例时，优先覆盖历史上出过问题的场景模式。这让经验真正可以沉淀和传递。

一个具体的 Skill 配置示例

很多人觉得配置 Skill 很复杂，其实入门门槛并不高。下面是一个简化的“接口测试用例生成 Skill”的核心逻辑描述：

你是一个资深接口测试工程师。
当我给你一个接口文档或 OpenAPI Schema 时，你需要：
1. 分析每个参数的类型、约束、必填性
2. 生成正常场景用例（覆盖典型业务路径）
3. 生成边界值用例（最大值/最小值/空值/特殊字符）
4. 生成异常场景用例（非法参数/越权/重复提交）
5. 标注每个用例的优先级（P0/P1/P2）
输出格式为 Markdown 表格，列包括：
用例编号 | 场景描述 | 请求参数 | 预期结果 | 优先级

这只是一个起点。真正强大的 Skill 会包含你们团队的业务规则、常见的“陷阱”场景、输出与你们测试管理工具对齐的格式。

四、测试工程师的角色在变，但不是在消失

这里要说一个很重要的观点，因为我发现很多人对这件事的理解是错的：

Skills 不是来替代测试工程师的，它是来替代测试工程师身上那部分“应该被自动化但一直没有被自动化”的工作的。

“最好的测试工程师，本来就不应该花 70% 的时间在写用例上。”

真正需要测试工程师的事情是什么？是理解业务风险在哪里，是决定测试策略和投入权重，是发现 AI 生成的用例里逻辑上的错误，是建立适合团队的测试体系，是在线上出问题时第一时间定位根因。

这些事，Skills 做不了。至少现在做不了。

但写那 200 行 Excel？AI 现在已经比你快，而且不会在第 150 行开始走神。

五、怎么开始？给从业者的三步建议

如果你想在团队里引入 Skills 驱动的测试方式，不需要等到“完美方案”落地。以下是一个务实的起点：

1. 选一个高频、低风险的用例生成场景做试点。 比如某个内部管理后台的接口测试，需求相对稳定，出问题影响范围小。用这个场景跑通你的第一个 Skill，收集反馈。
2. 建立 Skill 的“审查机制”。 AI 生成的用例不能直接进库，必须经过一轮人工审核。这不是因为 AI 不靠谱，而是因为它不了解你们团队的上下文。审查的过程本身就是在持续优化 Skill。
3. 把 Skill 纳入团队知识库。 一个好的 Skill 是团队经验的结晶——它包含了你们踩过的坑、积累的规则、特殊的业务约束。要像维护代码一样维护它，有版本，有变更记录，有 owner。

结尾

我见过很多测试工程师对 AI 工具抱有两种极端的态度：要么完全排斥（“AI 理解不了我们的业务”），要么完全依赖（“让 AI 写，我验收就行”）。

这两种都会让你在接下来两三年里吃亏。

真正聪明的做法是：把 AI 当成一个很聪明但需要被指导的初级工程师。你的价值不在于写得比它快，而在于你知道什么是对的、什么是重要的、什么是它没想到的。

Skills 正在接管测试工程的生产层。而测试工程师，应该把精力迁移到判断层和策略层。

这是一次升级，不是替代。