前言
做Agent测试之前，我以为这不过是自动化测试的升级版。真正做进去才发现，问题根本不在工具变了，而是 正确答案 消失了。
传统测试的底层逻辑是：存在一个正确答案，我来验证系统有没有达到它。

但Agent测试不是这样的。同一个输入，每次回答可能都不一样。你没办法说哪个”对”、哪个”错”，你只能去定义——什么范围内的回答是可接受的，然后想办法把系统行为控制在这个范围里。

这一个假设的变化，导致整个验证体系都要重建。
这篇文章不想泛谈趋势，想结合我这段时间做Agent和RAG项目的实践，说清楚两件事：
第一，AI时代测试到底变了什么；
第二，测试工程师现在应该把能力往哪里迁移。

一、先把问题分清楚：AI对测试的影响有两条线
很多人谈AI时代测试工程师的未来，容易把两件事混在一起说。
但我觉得这两条线是不一样的，必须分开看。

第一条线：AI辅助传统测试。
这条线上，AI是工具，测试对象还是传统系统。

AI能做的事情包括：根据需求生成测试点、生成接口测试脚本、跑回归并输出初步分析、脚本失败后辅助归因。

我自己试过用Playwright配合AI做UI自动化，脚本失败后把trace和报错丢进去，它能分析原因、给修改建议，简单问题直接修复再跑。

这条线的本质是：把测试里重复性高、规则清晰的执行工作，逐步交给AI来做。
测试工程师的价值，从”亲手写脚本”，迁移到”设计验证方案、判断结果是否可信”。

第二条线：AI系统本身的测试。
这条线上，测试对象变了——你要测的是一个Agent或RAG系统。
这里问题完全不一样，也是我感受最深的地方。

二、Agent测试最大的挑战：正确答案消失了
做传统功能测试，你心里是有底的。
用户登录成功，跳转到首页，这就是正确答案。要么对，要么错。
但做Agent测试，这个底没了。
同一个用户输入，Agent今天这样回，明天那样回，后天又不一样。你没办法说哪个”对”——你只能去定义，什么范围内的回答是可以接受的。

这个变化导致整个验证逻辑都要重建：
    ∙    不再是”对比预期答案”，而是”判断输出是否在可接受范围内”
    ∙    不再是”跑一次验证”，而是”建回归集，持续守住质量边界”
    ∙    不再是”发现问题报Bug”，而是”定义规则，让问题可复现、可回归”

所以Agent测试最核心的工作，其实是两件事：
第一，先把”什么叫正确”定义清楚。
比如我在做工作记录Agent时，要定义的不是”它说了什么”，而是：
1.什么情况下应该调用记录Tool
 2.什么情况下不应该调用
 3.模糊表达会不会误触发
 4.多轮对话下行为会不会漂移
这些规则，不是模型自己知道的，需要测试工程师把它提炼出来、写清楚、变成可验证的东西。

第二，建测试集，把系统行为控制在可控范围内。
我现在会明显区分两类数据集：
1. 回归集：验证正常流程稳定性，每次迭代后跑一遍
 2.Bad Case集：专门覆盖边界、异常、高风险场景
每条数据不只有输入，还要带上明确预期——是否应该调用Tool、是否应该拒答、输出里不能出现什么。
这样每次系统变化后，才能真正做到可回归、可对比。

三、我在项目里踩过的一个坑
说一个真实案例，比讲道理更直接。
我在做Agent项目时，用JSONL做记录存储。
并发写入的时候，出现了空行。后续读取时直接报KeyError，整个流程断掉。
表面看是个工程Bug，但这个问题给我的触动很大——
AI系统出问题，不一定是模型答错了，很多时候是状态层没有守住。
状态写入不稳定，后续的行为和输出都不可信。你看到的”AI回答不对”，可能根本不是AI的问题。

这也是为什么做Agent测试，会把验证拆成三层：
行为层：系统有没有在正确时机做正确的事，Tool调用对不对，参数对不对，有没有越权。

状态层：数据写入是否稳定，并发下是否一致，多轮交互后上下文有没有被污染。

输出层：结果是否可信，有没有幻觉，该拒答的时候有没有拒答，输出结构是否符合预期。

三层分开看，问题更容易定位，Bad Case更容易设计，回归也更有针对性。

四、RAG测试：验证的是决策，不是答案
RAG场景再补充一点，因为它跟Agent又有些不同。
RAG系统的核心不是”它说了什么”，而是”它凭什么这样说”。
用户问题进来，系统后面要经过一连串判断：
1.有没有命中相关内容
 2.命中的内容够不够支撑回答
 3.当前问题是不是应该拒答
 4.有没有跨文档内容混入
 5.最终生成有没有引用错误chunk
所以RAG测试真正要验证的，是这些决策对不对，而不只是最终答案像不像。

常见问题包括：没检索到内容却硬答、引用了错误chunk、该拒答的问题没有拒答、输出结构不稳定。
这些问题如果你只看最终答案，很容易漏掉。

五、测试工程师现在应该把能力往哪里迁移
说完变化，最后回到落地。
结合这段时间的实践，我觉得迁移方向就是四件事：

第一，从写步骤到写规则。
少纠结点击顺序、等待时间、断言怎么组织。多关注：什么行为才算符合预期，哪些动作绝对不能发生，哪些场景必须拒答。
测试代码的价值在下降，测试规则的价值在上升。

第二，把经验沉淀成可回归的数据集。
测试团队最值钱的资产，不是脚本数量，而是可复现、可回归、可比较的数据集。
而且数据集要带预期，不只是输入，还要有”这种情况下系统应该怎么做”的明确定义。

第三，把测试能力封装成可调用工具。
Agent想做事，但没有工具可调——这是很多团队落地卡住的真实原因。
造数接口、清数接口、日志查询、状态校验、回归执行入口，这些能力如果没有被标准化，AI就只能给建议，没办法真正帮你做事。

第四，建立分层验证思维。
不要用单点思维看AI系统的问题。行为、状态、输出三层分开验证，问题才能定位清楚。

结语
AI时代，测试工程师不会消失。
但”只执行、不设计”的测试，会越来越难找到位置。
因为AI最先接管的，就是那些重复性高、规则清晰、可以被标准化的执行工作。

而测试真正有壁垒的部分，是在没有标准答案的系统里，定义什么叫”够好”——
把模糊的业务要求，转成明确的验证规则；
把一次次踩过的坑，沉淀成可复现、可回归的数据集；
把质量边界守住，不是靠人工盯，而是靠体系兜。
这件事，AI目前还做不了。