#专项测试 Agent 指令踩坑经验分享

白小浅、测小案、测小口、凤小九、端小九——5 个专项测试 Agent。

它们的指令没有一条是拍脑袋写的，全是翻车之后一条条补回来的规矩，大部分还挂着真实案例编号。

这一版只留跟“测试结论对不对”有关的经验：预期从哪来、范围怎么划、什么算缺陷、证据怎么留。状态流转、派单、重试、止损这类流程和编排规则，全部拿掉了。

一句话总结：测试 Agent 靠不靠谱，不靠模型聪明，靠把“预期、边界、证据”写死在指令里。

更多背景信息请看全流程自动化测试；相关 Agent 的完整提示词指令见测试相关 Agent 完整提示词分享。

#通用篇：多份指令里的同款规矩

下面这些坑，不是一个 Agent 踩的，是好几份指令里都补了同一条规矩。

#通用坑 1：把注释、实现当标准答案

翻车现场

有个需求本来就是“改掉旧行为”，但代码注释里还写着旧逻辑。白小浅翻到注释如获至宝，拿它当预期，把按需求改好的新行为报成了 bug——方向完全判反（HF-13554）。

另一头，测小案能读代码库，顺手就“代码是这么写的，预期就按这个写”。

现在的规矩

判断对错只认需求侧：需求正文、验收标准、产品文档、用户原话。

代码注释、提交说明、变量名、自己的推断——统统不算数。

只有注释可查、需求没写时，标“存疑，请产品确认”，不许报 bug。

读代码可以，但只许干三件事：发现需求做不到、标记观察项、标出“实现疑似不符”。

指令原话：用代码找需求的敌人，不给实现背书。

#通用坑 2：把例子当测试对象

翻车现场

任务里贴了线上 bug 的组织名。一个 Agent 把它写进用例步骤“找到该组织”，另一个真的去测试环境找——那个组织在 staging 根本不存在，白找一轮。

现在的规矩

例子给的是现象，复现要的是通用方法。

从例子里提炼触发条件（什么操作、什么状态、什么数据形态会触发），测试环境用自建数据造等价场景。

禁止去正式环境测，禁止在 staging 里找例子里的那个线上对象。

#通用坑 3：把极端场景当缺陷

翻车现场

白小浅构造过“磁盘满到只剩几十字节”，程序没扛住，报了 bug；“锁屏后一瞬间解锁”的时序窗口也一样（HF-13593 / HF-13597）。

真实用户谁的磁盘只剩几十字节？两条 bug 后来全撤销了。

现在的规矩

物理资源极限、非常规人机时序、跟改动无关的旁支失败——可以测，但只记一行“极端条件观察，无处理必要”。

不报 bug、不算不通过、不进“开发需关注”。

测小案那边同款：真实用户不会做的操作（粘贴超长文本、高频连点），除非需求明确要求，一律降为观察项。

#通用坑 4：一个维度不行，就判死整条需求

翻车现场

主流程通了，只是“即时性”没达到它自己想象的“秒级”，它把整条需求判成“未实现”。

还有把“优化建议”和“需求未实现”混在一个“失败”里的——这两种处理方式完全不同。

现在的规矩

• 结论拆维度：需求未实现 / 缺陷（哪个维度）/ 优化建议 / 预期待产品确认 / 存疑 / 观察；
• 需求没承诺的维度（“即时”“秒级”是它自己脑补的），不能当判死依据；
• 复合预期拆开写：“主流程通过；缺陷（即时性）：后台重新发现约 5 分钟”。

#通用坑 5：范围失控，数字好看但没测到点上

翻车现场

需求只是“提示不友好，优化一下文案”，测小案设计出校验逻辑、状态机、边界拦截一条龙。

更隐蔽的一种：实现里“没做 X”，它反转成“需求要求做 X”——无中生有发明预期。

现在的规矩

• 文案需求只测被改的那条提示；
• 用例配额：单点小改 1-2 条，N 个验证点最多 N+1 条，多一条都要指出对应需求哪句话；
• 需求里枚举了 N 项能力的 → 抽成清单逐项对账：每项要么有用例、要么写明为什么排除，不许借“入口相同”跨能力项合并；
• 需求没规定的文案只作观察项，禁止逐字断言——文案改一版，用例全军覆没，还都是假失败。

#通用坑 6：测试其实没跑，结论却是“通过”

翻车现场

白小浅翻了翻代码，就写“白盒测试通过”。

测小口凭记忆拼参数：enable / isEnabled 分不清，响应码写成 201 而不是 '201'——静默失败，断言形同虚设。

还有覆盖面造假的：路由生成器整块漏掉 customers 域 40 个接口，它拿生成器输出当全集对账，覆盖算出来一大片假绿。

现在的规矩

• 没真跑不能叫通过：必须“测试命令真实执行 + develop 基线 + 退出码 0 + 范围相关”；静态走查只能写“白盒核验完成（未执行测试）”；
• 新增控制流分支（if/else、异常分支、状态机）必须真跑；改动太大跑不完，如实列出“未测分支清单”，严禁虚标已测；
• 接口侧：写前必过 schema 校验；接口定义（响应码/schema）改了，引用它的场景必须重新保存——否则跑的还是旧快照，改了等于白改；
• 覆盖率对账：自己解析路由表和用例库双向 diff，不信生成器。

#通用坑 7：证据找不到，等于没有证据

翻车现场

报告里写“见录屏”，没人知道看哪几秒；证据文件叫 screenshot (2).png。

现在的规矩

• 录屏引用必须“文件名 + 用例号 + 第几秒”，如 rec-C2-失败复现.mp4｜01:23-01:45；
• 文件名要能看懂（“提交成功提示”），禁止 IMG_0001.png、纯时间戳；
• 通过的用例也要录屏，作为验收依据；登录、收验证码不录；
• HTML 报告按“连环画”做：步骤时间线 + 每步截图 + 实际 vs 预期，不熟悉测试的人打开也能看懂。

#通用坑 8：满嘴术语，只给统计数

翻车现场

报告写“验证数据一致性”“覆盖状态机边界”“DOM 证据归因”，结论只有一句“通过 3 失败 1”。

产品和开发看完不知道它到底测了啥。

现在的规矩

说人话，像跟产品/开发面对面讲，四个禁止：

• 禁止术语堆砌 → 改成“确认两条路进去看到的东西一样”；
• 禁止复制需求原文；
• 禁止堆实现细节 → 不写“POST /api/xxx 响应码 200”，写“点保存后数据存上了，刷新后还在”；
• 禁止只给统计数 → “通过 3 失败 1”后面必须紧跟“通过的是什么、失败的是什么（原因一句话）”。

#通用坑 9：脏环境测出来的结论是假的

翻车现场

拿日常回归的主账号去走“新用户注册”链路——旧登录态把引导直接跳过，测了个寂寞。

上一轮的残留登录态、残留数据污染下一轮，硬测下去出了假结论。

现在的规矩

• 账号分档：普通回归用 qa-fe 系列；注册/新用户/验证码链路一律新建临时邮箱，不用个人、员工、生产邮箱；
• 每个账号独立浏览器上下文，不共享 Cookie 和登录态；
• 新用户 / 升级类测试，开场完全清理是强制前置，清理输出的自检表要引用进报告；
• 遇到疑似污染：标“环境问题”修好再测——不硬测出假结论，也不静默绕过。

#通用坑 10：载体和版本不对，测了个寂寞

翻车现场

该测客户端的任务，客户端连不上，它静默退回 Web 测完交差——客户端专属的 bug 一个没碰到。

版本旧了，bug 早就修了或根本没到，测出来的结论全是废的。

现在的规矩

• 载体不可替换：客户端连不上只能有限重试 + 回报，不许拿 Web 冒充，反过来也一样；
• 开跑前必核版本（客户端 / CLI / daemon 三端），版本过旧先升级到目标版本再测；
• 目标环境和实际环境不一致，报告里用最显眼的方式提示。

#各 Agent 独有的坑

#白小浅：白盒预检

它的活：代码合并后、测试开始前做一次预检——核验代码、分析影响面、发一篇预检评论。

#坑 1：数据兼容只测了顺向，没测反向

翻车现场

改了数据结构，只验证了“新代码读老数据”，没验证“老代码读到新数据”——灰度期间还在跑旧版本的机器直接崩。

现在的规矩

识别到数据兼容风险点，打上“数据兼容”标签，并且正反两面都要测：

• 后向：造旧格式数据样本，新代码能读、不丢字段、不报错；
• 前向与降级：新代码写的数据，放到旧版代码上下文里跑，旧版不崩、字段能优雅降级。

标签同时是给测小案的交接信号：让它补“旧数据在新版打开/编辑/导出”的黑盒用例。

#坑 2：Bug 只写动作，别人照着跑不通

翻车现场

Bug 里“怎么复现”只写“进入小队设置 → 快捷回复 → 添加”。看的人不知道用哪个账号、什么数据、弹窗开没开，从零根本走不到那一步。

现在的规矩

复现步骤必须让没参与过测试的人从零也能复现，五要素写全：

1. 环境：哪个环境、哪个入口页面；
2. 账号：用什么账号登录（写邮箱，密码不写）；
3. 前置数据：先建了什么、什么状态；
4. 系统状态：操作前系统处于什么状态；
5. 然后才是操作步骤和观察结果。

#坑 3：问题报了一堆，就是不说“值不值得修”

翻车现场

报告里列了一堆问题，但“影响谁”写着“可能影响用户体验”这种空话，也没说修起来划不划算。开发看完还是不知道先修哪个。

现在的规矩

每个问题点必须写清三项：

• 影响谁：具体到用户场景（“弱网下提交表单的用户会重复建单”）——说不出现实场景的，就不该报；
• 值不值得修：成本档 × 影响档 → 明确倾向（“小改大益，建议修”）；
• 请你做什么：具体动作 + 完成动作。

倾向仅供参考，最终由处理人拍板。

#坑 4：给开发写小作文

翻车现场

内测功能，它写了三层门控的开启教程，开发回了一句：“我只要那条 INSERT。”（HF-12818）

现在的规矩

固定三样：flag 名 + 一条能直接执行的 SQL + 一句话怎么开。

SQL 装进小折叠块，别的不写。

#测小案：用例设计

它的活：读需求、读预检、读接口分析，输出精简用例表。不执行、不审批。

#坑 1：会读代码，就读出“实现即预期”

翻车现场

它有读代码库的能力，于是顺手“代码就是这么写的，预期就按这个写”。实现和需求打架时，它甚至想按实现改预期。

现在的规矩

代码永远不定义“应该是什么”。 读代码只许三种用途：

1. 发现需求根本做不到 → 写进待确认；
2. 需求没覆盖的 → 记观察项；
3. 发现实现疑似有错 → 预期照需求写，标“重点验证”。

#坑 2：需求没结论，就反问用户

翻车现场

需求没写某个行为该怎样，它列一堆“待确认”问题抛给用户——人没回答，用例就干等。

现在的规矩

需求没结论时，以当前实现为准：实现的实际行为就是本轮预期基准。

在需求总结后紧跟一句“实现判断：实现是什么——合理 / 存疑 + 一句理由”。

判断存疑才按需求写预期并标“疑似不符，重点验证”。

不为此向用户提问——保证没人回答也能继续跑。

#坑 3：“没做 X”被反转成“需求要求做 X”

翻车现场

实现里迁移前不校验父目录是否存在，它把这句观察写成需求要求，用例预期凭空多出一条硬性拦截——测试对象根本不是这次要改的东西。

现在的规矩

实现里“没做 X”不等于需求要“做 X”。

这类点只能写成观察项（记录实际行为 + 一句合理性判断）；只有需求明确要求或产品确认过，才写成硬性预期。

#坑 4：拿界面文案当断言

翻车现场

需求没规定文案，它拿实现里的提示语逐字断言通过/失败——文案改一版，用例全军覆没，还都是假失败。

现在的规矩

需求没规定的文案只能作观察项；同一需求点多入口、多语言的文案检查合并成一条，不铺成多条正式用例。

#测小口：接口用例维护

它的活：维护 Apifox 里的接口和场景用例，做接口层的影响分析和覆盖。

#坑 1：凭记忆拼参数

翻车现场

enable 和 isEnabled 分不清；响应码写成数字 201 而不是 '201'，静默失败，断言形同虚设。

指令原话：“本项目实测中‘凭记忆拼 payload’是最大浪费来源。”

现在的规矩

动手前必查官方技能和 --help；写入前必过 schema 校验；报错先查文档，不许猜。

#坑 2：接口定义改了，场景还在跑旧快照

翻车现场

接口的响应码或 schema 改了，引用它的场景没重存——跑的还是旧快照，定义改了等于白改，测出来的通过是假的。

现在的规矩

接口定义（响应码/schema）变更后，引用它的场景必须重新保存，并回读核验。

#坑 3：信了代码生成器，覆盖率一片假绿

翻车现场

路由生成器整块漏过 customers 域 40 个接口，它拿生成器输出当全集做对账，覆盖算出来一大片假绿。

现在的规矩

自己解析路由表和 Apifox 双向 diff，缺了就补录，不绕过。

#坑 4：query 参数配了，请求里就是没有

翻车现场

它在用例上配了 query 参数，跑起来请求里根本没有。排查半天才发现：case 级参数不持久化不会发送，接口定义的参数还会反向覆盖脚本注入的值。

现在的规矩

query 参数一律脚本注入，不依赖用例级配置。

连带教训：CLI 会给 body 垫示例模板，空占位值（language:""）服务端直接拒——前置脚本统一做“占位值剔除”。

#坑 5：断言太软，等于没断言

翻车现场

只看 HTTP 200 就判过；错误场景也只断言“不是 200”——接口返回一个空对象照样绿。

现在的规矩

业务断言三件套，缺一不可：

• 提取 id 非空；
• 详情字段与创建值一致；
• 列表里能查到新建对象。

负向断言要落到 error.code；创建类 POST 的响应码按接口定义（201）来。

#坑 6：拿不准就裸抛问题给人

翻车现场

接口行为变了，它直接问人：“这是 bug 还是有意变更？”——人还得自己去翻代码。

现在的规矩（这条最值得抄）

“我们是 vibecoding 团队，开发去确认也是问 AI，不如先把代码读了把答案给出。”

AI 自己读代码回答四个问题（有意的吗 / 影响面 / 旧数据兼不兼容 / 有边缘风险吗），给 A/B 建议 + commit 证据。

人只做终审；置信度很高时直接按判断执行，报告里注明“自判：A，依据：xxx”。

#凤小九：Web 黑盒 / UI 执行

它的活：按确认好的用例用真实浏览器执行，只执行不设计。

#坑 1：没包要么不敢测，要么全量脑补

翻车现场

用户没给 TestPackage、测小案也没出用例——它要么觉得“没有授权不能测”，要么自己脑补出接口联动、视觉还原、性能兼容十类测试全跑一遍。

现在的规矩

用户明确要求执行 = 授权。此时只执行能可靠确定的最低必要核心主流程，不自动增加任何测试类型。

核心对象、入口、预期可确认的执行；不清的标“未执行/待确认”，不伪造细节。

#坑 2：账号混用，链路互相污染

翻车现场

拿日常回归的主账号去走“新用户注册”链路——旧登录态把引导直接跳过；多角色验证共用一个浏览器上下文，Cookie 串台。

现在的规矩

• 普通回归用 qa-fe 系列；
• 注册/新用户/验证码链路一律新建临时邮箱，不用个人、员工、生产邮箱；
• 每个账号独立浏览器上下文，不共享登录态。

#坑 3：把环境/工具问题报成产品 Bug

翻车现场

选择器失效、环境没起来、账号没权限，全被写成“功能不可用”。

现在的规矩

判定产品问题必须同时满足四条：

1. 现象能在真实页面/客户端里观察到；
2. 复现路径清晰且稳定；
3. 实际结果与明确预期或可确认的业务要求不一致；
4. 证据能证明问题。

组织、权限、环境、账号、外部授权、选择器、工具异常、需求争议、无法稳定复现——默认标阻塞 / 低置信度 / 待确认，不伪装成产品 Bug。

#坑 4：读代码读着读着，读出了“预期”

翻车现场

遇到疑点去翻代码，翻完把代码行为当成了“应该这样”——读码从解释现象变成了定义预期。

现在的规矩

读代码只解释“为什么会产生你看到的现象”，不改“应该是什么”。

最多花 5 分钟，找不到就如实写“读了代码未定位到原因”。

结论用大白话写：看了代码，这个行为是因为什么，所以疑似 bug / 设计如此 / 配置问题。

#端小九：客户端执行

它的活：在真实 Windows / macOS 客户端里测：升级验证、新用户上手、需求黑盒。

#坑 1：版本不对，测了个寂寞

翻车现场

客户端测试的独有坑：版本旧了，bug 早就修了或根本没到，测出来的结论全是废的。

现在的规矩

开跑前必核三端版本（客户端 / CLI / daemon）；版本过旧先升到目标版本再测。

升级前（X）与升级后（Y）的版本和在线状态都必须留证据；升级后版本没变时先等自动更新轮询几分钟再复测，不直接判失败。

#坑 2：载体偷偷换

翻车现场

该测客户端的任务，客户端连不上，它静默退回 Web 测完交差——客户端专属的 bug 一个没碰到。

现在的规矩

载体不可替换。 客户端连不上只能有限重试 + 回报，不许拿 Web 冒充；反过来也一样。

#坑 3：上一轮的脏数据，造出这一轮的假结论

翻车现场

上一轮的登录态、旧版本残留、脏数据还在，新用户/升级测试直接跑出错误结论。

现在的规矩

• 新用户/升级类测试，开场完全清理是强制前置，清理输出的“用户等价自检表”必须引用进报告；
• 谁弄脏谁恢复：临时对象用完即删，配置改回原值；恢复不了的列清单移交，不留隐形垃圾；
• 发现疑似污染，标“环境问题”、修好再测，不硬测出假结论。

#这些坑是怎么变成规矩的

1. 预期必须有出处——需求没写的，代码、注释、推断都不算；说不清出处的，最多写到“存疑”。
2. 规矩写成可数的条件——三种用途、六档结论、最多 N+1 条用例、5 分钟读码上限。可数的规矩 AI 才执行得动，“谨慎使用”这种口号不行。
3. 能力要配白名单——会读代码就写死读代码的合法用途；能做什么 ≠ 可以随便做。
4. 结论要能拆维度——一个维度不达标，不等于整条需求失败；“需求未实现”和“优化建议”必须分开。
5. 证据要可直达——文件名 + 用例号 + 秒数，通过也要录屏；找不到片段的证据等于没有证据。
6. 一处改进，全队生效——同一条规矩在几份指令里几乎逐字出现，一个 Agent 踩的坑，全队补同一条规矩。