从脚本到Skills：测试智能体的下一步，让AI学会“如何测而不是测什么”
最近测试圈子里讨论最多的一件事：某大厂测试团队用AI自动生成接口测试脚本，结果线上事故翻了一倍。
不是AI不努力。脚本写得快，覆盖率高，执行也稳。但漏测的case，全是那些“脚本里没写到”的场景——参数组合异常、状态机跳变、业务规则冲突。
很多人已经开始感觉到：AI能帮你写脚本，但写什么脚本，AI还不行。
这还不是最焦虑的。更让人不安的是，另一家公司的测试负责人公开分享了一个案例：他们让AI做回归测试的用例扩写，AI把登录模块的200个用例扩到了800个，覆盖率从65%涨到92%，但缺陷发现率反而下降了。
因为AI在重复验证同一个逻辑，而不是在探索未知风险。
这件事的本质，不是AI能力不够，而是我们用错了AI。
我们现在给AI的指令，本质上还是在让它“执行测试”——写断言、发请求、比对结果。但真正值钱的测试能力，从来不是执行，而是判断：测哪里、怎么测、什么时候该停下来。
这就引出了今天想聊的核心问题：测试智能体的下一步，必须从“告诉AI测什么”转向“让AI学会如何测”。
目录
一、现象：脚本越写越快，漏测越来越多
二、本质变化：测试决策权正在从人转移到模型
三、核心机制拆解：Skills框架下的测试智能体
四、典型案例对比：硬编码脚本 vs Skill-based智能体
五、工程落地启示：你现在就该做的三件事
六、留给你的一个问题
一、现象：脚本越写越快，漏测越来越多
过去一年，测试行业最直观的变化是：写脚本的效率提升了5到10倍。
用Copilot生成API测试代码，用ChatGPT写UI自动化断言，用各类AI工具补全测试数据——这些已经成为常态。
但诡异的是，缺陷逃逸率并没有下降。
我最近复盘了三个不同行业的测试团队数据：
金融支付团队：脚本产出量涨了3倍，P0级漏测没变
电商交易链路：自动化覆盖从40%涨到80%，但线上故障次数反而上升了20%
SaaS产品：测试用例数翻倍，但客户报的bug类型跟半年前一模一样
问题的根因不复杂：AI加速的是“已知问题的自动化验证”，而不是“未知风险的探测”。
传统模式下，测试人员花60%时间写脚本，40%时间思考策略。现在AI把写脚本的时间压缩到10%，但很多人把省出来的时间又拿去写更多脚本，而不是做策略思考。
这就产生了一个认知陷阱：你以为你在用AI提效，实际上你只是在用AI把错误的事情做得更快。
二、本质变化：测试决策权正在从人转移到模型
要理解下一步往哪走，先看清楚现在发生了什么。
过去三年的演进路径，本质上是测试决策权的迁移：
阶段一（AI辅助）：人决定测什么，AI负责执行。典型场景：Copilot帮你补全断言。
阶段二（AI增强）：人给出测试目标，AI生成测试方案。典型场景：输入“测试登录功能”，AI输出10个测试点。
阶段三（AI代理）：人只给测试意图，AI自主决策测什么、怎么测、何时停。这就是智能体的雏形。
我们现在大部分团队卡在阶段一到阶段二之间。
问题在于，阶段二的AI仍然依赖人的“测试点输入”。换句话说，AI的测试覆盖率上限，等于人的思维盲区边界。
这就是为什么前面那个例子中，AI扩写到800个用例反而效果更差——因为扩写的逻辑是基于已有的200个用例做变体，而不是基于业务风险重新建模。
真正的转折点在于：让AI掌握“测试策略”而不是“测试步骤”。
两者的区别在于：
测试步骤：调用登录接口，传username和password，断言code=200
测试策略：登录是状态变更操作，需要考虑会话保持、防重放、并发、异常回滚等多维度风险，并根据代码变更和业务影响动态调整测试深度
前者可以写死在脚本里。后者需要推理、规划和反馈闭环。
三、核心机制拆解：Skills框架下的测试智能体
要让AI学会“如何测”，不能靠堆prompt，需要一个可执行的架构。最近在工程上验证可行的方案是Skills框架。
核心三要素：
1. 工具集（Tools）
AI可以调用的原子能力。不是“执行登录测试”这种高层指令，而是“发送HTTP请求”“解析JSON”“读取数据库”“对比Schema”这种不可再分的能力。
关键设计：每个工具必须包含输入输出契约和失败模式说明。因为AI需要自己判断什么时候该用哪个工具，以及工具失败了意味着什么。
2. 决策模型（Reasoning）
这是最核心的变化。传统脚本的决策逻辑是硬编码的if-else。Skills框架下，决策逻辑由LLM在运行时动态生成。
举个例子：
测试目标：验证支付接口的幂等性 AI的推理链： 1. 幂等性需要同一个请求发两次，结果一致 2. 需要先生成一个唯一订单号 3. 第一次调用后记录返回结果 4. 第二次调用同一订单号 5. 比对两次结果的关键字段 6. 如果结果不一致，需要区分是业务逻辑错误还是环境问题这个过程不是预先写好的，而是AI根据测试目标实时推理出来的。
3. 反馈闭环（Feedback Loop）
这是被80%的测试智能体实现忽略的部分。AI执行完一个测试后，需要判断：
测试通过/失败？但更重要的是
这个测试结果是否可信？
是否需要补充其他角度的测试？
当前的测试深度够不够？
实现方式上，我们在一线落地时用了双模型校验：一个模型执行测试并生成结论，另一个模型对这个结论做元评估（meta-evaluation），判断是否存在误判、覆盖盲区、环境干扰。
这个架构解决了三个关键问题：
首先，可解释性。AI的每一步决策都有推理链，人可以回溯为什么AI选择测这个不测那个。
其次，边界可控。工具集限定了AI的能力边界，不会出现AI突发奇想去测生产环境这种事。
最后，持续进化。反馈闭环产生的数据可以反哺决策模型，同一个测试目标，跑100次后会比第1次聪明很多。
四、典型案例对比：硬编码脚本 vs Skill-based智能体
用真实场景说明差异。测试一个“用户提现”功能，业务约束：
单日限额5万
需要二次验证
提现后账户余额实时扣减
风控规则：短时间内多次提现触发人工审核
传统硬编码脚本的做法
测试人员需要提前想清楚：
正常流程：登录-申请提现-输入金额-二次验证-验证余额-检查订单状态
异常流程：超额、余额不足、验证码错误、网络超时
边界值：49999、50000、50001
然后针对每一条写断言。写完之后，脚本能测到的场景就固定了。如果代码改动引入了一个新的风险点——比如并发提现导致余额被重复扣减——只要这个场景不在脚本里，它就永远测不到。
Skill-based智能体的做法
输入测试意图：“测试提现功能的正确性和健壮性”
AI的自主推理过程：
第一步，识别核心风险。提现涉及三个状态变化：余额、订单、风控。每个状态变化都可能被并发、重试、回滚等操作干扰。
第二步，规划测试策略。不是一次性写死所有case，而是采用模糊探索+聚焦验证的双层策略：
模糊探索：随机生成金额、时间间隔、并发数，快速扫描异常信号
聚焦验证：一旦在探索中发现异常苗头（比如两次提现间隔50ms时出现罕见的数据不一致），立即启动深度聚焦，围绕这个点做参数化攻击
第三步，动态调整。执行到第12个测试时，AI发现一个现象：单次提现正常，连续三次提现时第二次和第三次的订单号出现了非连续跳变。它自动判断这个现象可能暗示着数据库自增主键被回滚，于是转而专门测试事务隔离级别。
整个过程没有一行硬编码的if-else。
核心差异一句话概括：硬编码脚本测试的是“开发人员说会发生的”，Skill智能体测试的是“实际上可能发生的”。
五、工程落地启示：你现在就该做的三件事
看完上面的拆解，可能会觉得这东西离你还有点远。但实际上有三个可以立刻开始做的事。
第一，重新定义你的“测试资产”
很多团队还在把“测试用例数量”当作核心资产。这个思路在Skills框架下完全不适用。
真正值钱的资产变成两类：
测试意图库（test intentions）：不是具体的步骤，而是“为什么要测这个”
反馈数据集：AI做错的判断、漏掉的风险、环境误判的案例
建议从现在开始，每个测试用例旁边加一个字段：这个用例试图验证的不可违背的业务约束是什么。比如“提现后余额+冻结金额+在途金额=原始余额”。这些约束才是AI需要学习的核心。
第二，构建你的工具集边界
不要一开始就想着让AI能做所有事。先圈定一个能力范围，把最常用的20个原子操作封装成工具。
关键原则：工具要做“窄接口”。一个工具只做一件事，输入输出明确，失败模式清晰。AI调用时不需要理解这个工具怎么实现的，只需要知道它能做什么、什么时候不能用。
很多团队踩过的坑：把“执行完整回归测试”封装成一个工具。AI完全无法理解这个工具的内部逻辑，也就无法做策略判断。正确做法是拆成“查询代码变更影响范围”“筛选关联用例”“执行指定用例”“分析失败原因”四个独立工具。
第三，建立元评估机制
这是最容易被忽略但最关键的环节。
在没有反馈闭环的情况下，AI的测试判断会有一个系统性偏差：倾向于通过。因为大多数测试在大多数时候确实是通过的，模型学到的先验就是“没问题是常态”。
破解方法是引入独立的元评估模型，专门质疑主模型的判断。可以简单理解为：一个模型负责干活，另一个模型负责找茬。
落地时可以从规则+模型混合开始：
规则层：断言失败就是失败，没有争议
模型层：对于断言成功但执行路径异常的case（比如超时后重试成功），元评估模型判断这是否掩盖了潜在的性能或稳定性问题
这套机制跑起来后，你会发现一个有意思的现象：AI开始自己学会“怀疑”了。
六、留给你的一个问题
我最近在评审一个金融项目的测试方案时，发现整个回归测试集跑了8个小时，通过率98%，但上线后依然出了两个P0事故。
事后复盘，两个事故对应的场景，测试集里都有覆盖，但测试通过的断言是“接口返回200”，而实际业务逻辑已经错了。
我们的测试工具一直在说“测完了”，但它不知道“测对了没有”。
你现在的测试系统中，有没有一个能回答“这次测试真的可信吗”的反馈闭环？
如果没有，那你的AI加速，可能只是在加速犯错。