1. 测试流程的老大难为什么传统自动化越跑越累做过几年测试的人大概都有同感自动化脚本写了一堆用例库越堆越大可真正到了版本发布前那几天还是得靠人肉去补漏、去定位、去判断这个失败到底是不是真 Bug。表面上看是自动化覆盖率上去了实际上维护成本、误报率、定位耗时这三座大山一点没轻。我所在的团队前两年也走过这条路。最初我们搞的是标准的录制回放 断言校验模式用例数量从几百涨到几千CI 流水线从十分钟跑到四十分钟。问题随之而来接口字段一改几十条用例集体飘红前端 DOM 结构一动选择器全废最要命的是一条用例失败之后日志里只有一句expected 200 but got 500至于为什么 500、是环境问题还是代码问题、是数据问题还是并发问题全靠人去翻日志、翻链路、翻数据库。这就是传统测试自动化的根本瓶颈它只会告诉你失败了但不会告诉你为什么失败更不会告诉你接下来该怎么办。用例生成靠人写缺陷定位靠人查整个流程里最耗时的两个环节恰恰是最依赖人的环节。Agent Skills 这套思路之所以值得拿出来聊就是因为它把生成和定位这两个最痛的环节从人驱动变成了目标驱动。你不再需要写死每一条用例而是给 Agent 一个测试目标让它自己去拆解、去执行、去判断、去归因。听起来有点玄但拆开看每一步都是可以落地、可以复现的工程实践。这篇文章我会把整套流程拆成几个部分讲清楚Agent Skills 到底解决了传统自动化的哪些具体问题、用例生成环节怎么设计才能不生成一堆垃圾、缺陷定位环节怎么让 Agent 真正给出有价值的归因、以及我在实际跑这套流程时踩过的坑和总结出来的调优经验。不管你是测试开发、QA 负责人还是想把这套思路迁移到其他工程场景的开发者应该都能从中拿到可以直接抄的东西。2. Agent Skills 到底重构了什么从脚本执行到目标闭环2.1 传统自动化与 Agent 驱动的本质差异先把概念对齐。传统自动化测试的本质是脚本执行器你告诉它做什么它就做什么做完告诉你成功还是失败。它的能力边界完全由你写的脚本决定脚本没覆盖的场景它一无所知。Agent Skills 的本质是目标闭环系统你告诉它要验证什么它自己去规划怎么做、执行、观察结果、判断是否符合预期、如果不符合就分析原因。它具备四个传统脚本没有的能力规划能力把一个模糊的测试目标拆解成可执行的步骤序列工具调用能力根据需要调用接口请求、数据库查询、日志检索、浏览器操作等工具观察与判断能力不只看断言结果还能结合上下文判断这个结果是否合理归因能力失败之后能给出可能的原因排序而不是只抛一个异常这四点里前两点解决的是用例生成问题后两点解决的是缺陷定位问题。整个重构的核心就是把测试流程从人写脚本 → 机器执行 → 人看结果变成人定目标 → Agent 规划执行 → Agent 归因 → 人做决策。2.2 为什么是现在三个前提条件成熟了这套思路放在三年前其实跑不通不是因为想法不好而是因为三个前提条件不满足。第一是模型的任务拆解能力。早期的模型只能做单轮问答你让它规划一个多步骤的测试流程它给出的步骤要么太粗要么逻辑断裂。现在具备推理能力的模型可以稳定地把验证用户下单流程拆成登录 → 加购 → 结算 → 支付 → 查订单这样的可执行序列并且能根据中间结果动态调整。第二是工具调用的标准化。以前让模型调用外部工具得自己写一堆胶水代码解析输出、拼装参数。现在工具调用的协议逐渐统一Agent 可以比较自然地调用 HTTP 请求、SQL 查询、文件读写这些基础能力工程集成成本大幅下降。第三是可观测数据的丰富度。缺陷定位要准前提是 Agent 能看到足够多的上下文——链路追踪、结构化日志、指标数据、变更记录。现在大部分团队的可观测体系已经比较完善Agent 有料可查归因才有依据。提示如果你的团队连基本的链路追踪和结构化日志都没有先别急着上 Agent 定位把可观测基建补齐否则 Agent 拿到的是一堆非结构化文本归因质量会非常差。2.3 重构后的流程长什么样我把重构后的流程画成一条线方便你对照自己团队的现状目标输入人给出测试目标比如验证优惠券在下单流程中的抵扣逻辑用例规划Agent 拆解出正常场景、边界场景、异常场景的用例清单用例生成Agent 把每条用例转成可执行的请求序列或操作步骤执行与观察Agent 执行并收集响应、日志、链路数据结果判断Agent 结合断言和上下文判断通过与否缺陷归因失败用例由 Agent 分析可能原因并排序人工决策人确认归因、决定是否提单、是否修复对比传统流程第 2、3 步替代了人写用例第 6 步替代了人查日志。这两步恰恰是传统流程里最耗时的部分。我实测下来一个中等复杂度的业务模块用例编写时间从原来的两三天压缩到半天以内缺陷定位时间从平均每条二三十分钟压缩到几分钟。3. 用例生成环节怎么让 Agent 不产出看起来对但没用的用例3.1 用例质量的分水岭目标描述的颗粒度很多人第一次用 Agent 生成用例会直接丢一句帮我测试登录功能然后得到一堆输入正确用户名密码应登录成功输入错误密码应登录失败这种废话用例。问题不在 Agent在于目标描述太粗。用例质量的分水岭就在目标描述的颗粒度。我总结了一个可用的描述模板包含四个要素业务上下文这个功能在什么业务场景下被使用关键规则有哪些业务规则、约束条件、依赖关系已知风险点历史上这个模块出过什么问题期望覆盖希望覆盖哪些类型的场景正常、边界、异常、并发举个例子同样是登录功能粗描述和细描述的产出差距巨大粗描述测试登录功能 细描述 业务上下文用户通过手机号验证码登录登录后进入个人中心 关键规则 - 验证码 5 分钟内有效过期需重新获取 - 同一手机号 60 秒内只能发送一次验证码 - 连续 5 次验证码错误锁定账号 30 分钟 已知风险点历史上出现过验证码并发校验导致重复登录的问题 期望覆盖正常登录、验证码过期、频率限制、错误锁定、并发登录细描述产出的用例会精确覆盖到验证码在第 301 秒提交应失败第 6 次错误验证码应触发锁定这种真正有价值的边界而不是泛泛而谈。3.2 用场景矩阵约束生成范围光靠描述还不够Agent 容易发散。我习惯在描述之后附一个场景矩阵明确告诉它从哪几个维度组合场景。这个矩阵本质上是把测试设计里的等价类划分和边界值分析用结构化的方式喂给 Agent。维度取值说明用户状态未注册 / 已注册未登录 / 已登录决定权限和流程分支输入类型合法 / 边界 / 非法 / 空覆盖输入校验时序条件正常 / 超时 / 并发覆盖时序相关缺陷依赖服务正常 / 超时 / 返回异常覆盖下游故障场景有了这个矩阵Agent 生成用例时就有了明确的组合空间不会漏掉关键维度也不会在某个维度上无限发散。我实测下来加上矩阵约束之后用例的维度覆盖率从大概六成提升到九成以上。3.3 生成后的用例自检三道过滤Agent 生成的用例不能直接用必须过滤。我设了三道过滤第一道是去重过滤。Agent 有时会生成语义重复的用例比如密码错误应失败和错误密码应登录失败其实是同一条。用语义相似度做一轮去重能砍掉大概一到两成的冗余。第二道是可执行性过滤。有些用例描述得很漂亮但缺少必要的前置数据或依赖根本跑不起来。这类用例要么补全前置条件要么直接剔除。第三道是价值过滤。这是最容易被忽略的一道。有些用例虽然能跑但验证的是112这种永远不会出错的逻辑跑它纯属浪费资源。判断标准很简单这条用例如果失败了是否意味着有真实的业务风险如果答案是否定的就删掉。注意价值过滤这一步最好保留人工复核。Agent 对业务风险的理解有限有些看起来没价值的用例可能在特定业务语境下是关键的。我一般让 Agent 先标记低价值用例再由人快速过一遍确认。3.4 用例的版本化管理Agent 生成的用例不是一次性的需要版本化管理。我的做法是把用例存成结构化文件YAML 或 JSON每个用例带上元信息生成时间、生成时的目标描述、覆盖的场景维度、最近一次执行结果。这样做的好处是当业务规则变化时可以快速定位到受影响的用例让 Agent 基于新规则重新生成而不是全量重来。同时用例的执行历史也能反哺 Agent——哪些用例长期稳定通过、哪些经常失败这些信息能帮助 Agent 在后续生成时调整策略。4. 缺陷定位环节让 Agent 从报错走到归因4.1 定位的本质是缩小可能性空间缺陷定位听起来很玄但拆开看它的本质就是不断缩小可能性空间。一条用例失败了可能的原因有几十种代码逻辑错、数据不对、环境配置错、依赖服务挂了、并发竞争、时序问题……定位的过程就是一步步排除最后锁定到最可能的那一个。传统方式下这个排除过程靠人做靠经验、靠直觉、靠翻日志。Agent 做这件事的优势在于它可以同时检索多个数据源不会因为翻日志翻累了而漏掉线索也不会因为上次是这个问题而产生先入为主的偏见。我设计的定位流程分四步失败信息收集响应内容、错误码、异常堆栈、链路追踪、相关日志变更关联这次失败前后代码、配置、数据有没有变更假设生成基于收集到的信息生成可能的原因假设假设验证对每个假设设计验证方法并执行逐步排除4.2 数据源接入Agent 的眼睛要够多Agent 定位准不准取决于它能看到多少东西。我给它接入了这几类数据源接口响应完整的响应体、状态码、响应头链路追踪从入口到出口的完整调用链每个 span 的耗时和状态结构化日志按 traceId 关联的应用日志、中间件日志数据库快照失败时刻相关表的数据状态变更记录近期的代码提交、配置变更、数据变更历史相似案例过去同类失败的归因记录这六类数据里变更记录和历史相似案例是最容易被忽略但价值最高的。很多缺陷的根因就是某次变更引入的Agent 如果能关联到变更定位速度会快很多。历史案例则能让 Agent 复用过去的归因经验避免重复劳动。4.3 归因输出的结构不要只给结论要给证据链Agent 定位完之后输出不能只是一句可能是数据库连接池满了。这种结论没有说服力人也没法验证。我要求 Agent 的输出必须包含证据链失败用例优惠券抵扣金额计算错误 失败现象预期抵扣 20 元实际抵扣 10 元 归因假设按可能性排序 1. 优惠券规则配置错误可能性 70% 证据变更记录显示 2 小时前该优惠券规则被修改 证据数据库中该优惠券的抵扣类型从固定金额变为百分比 验证方法查询优惠券配置表确认当前规则 2. 计算逻辑未适配新规则可能性 20% 证据代码中抵扣计算仍按固定金额处理 验证方法检查计算逻辑代码分支 3. 数据缓存未刷新可能性 10% 证据缓存中仍是旧规则 验证方法对比缓存与数据库中的规则值这种结构化的输出人一眼就能看出 Agent 的判断依据也能快速验证。我实测下来这种带证据链的归因人工确认时间从原来的十几分钟压缩到两三分钟。4.4 定位准确率的调优从能定位到定位准Agent 定位的准确率不是一上来就高的需要调优。我踩过的坑和对应的调优手段有这么几个坑一数据源太多Agent 抓不住重点。一开始我把所有日志都喂给它结果它被大量无关日志干扰归因质量反而下降。后来改成按 traceId 精准关联只喂相关日志准确率明显提升。坑二历史案例污染。早期我把所有历史失败案例都作为参考结果 Agent 经常张冠李戴把不相关的历史原因套到当前问题上。后来改成只参考相似度高的历史案例并且明确标注仅供参考需独立验证。坑三归因过于自信。Agent 有时会给一个可能性 95% 的假设但实际是错的。我调整了提示策略要求它对每个假设都给出验证方法并且明确说明如果验证不通过下一个假设是什么。这样即使首选假设错了也能快速切换到下一个。坑四忽略环境因素。很多失败其实是环境问题比如测试环境数据被污染但 Agent 倾向于往代码问题上找。我在数据源里加了环境健康检查让 Agent 先排除环境因素再往代码上找。5. 把两个环节串起来完整流程的工程落地5.1 流程编排用状态机管理整个链路用例生成和缺陷定位不是孤立的它们需要串成一条完整的流水线。我用状态机来管理目标输入 → 用例规划 → 用例生成 → 用例过滤 → 用例执行 → 结果判断 → [通过] → 记录结果 → [失败] → 缺陷定位 → 归因输出 → 人工确认每个状态都有明确的输入输出状态之间的流转有条件判断。这样做的好处是任何一个环节出问题都能快速定位也方便后续扩展比如在用例执行后面加一个性能采集状态。5.2 与现有 CI/CD 的集成这套流程不能脱离现有的 CI/CD 独立跑否则就是空中楼阁。我的集成方式是触发时机代码合并到主分支后触发或者定时触发执行环境复用现有的测试环境不单独搭建结果输出归因结果推送到现有的缺陷管理工具和通知渠道人工介入点只在人工确认这一步介入其他环节全自动这里有个经验不要试图让 Agent 全自动提单。Agent 的归因再准也有出错的时候让它自动提单会造成大量误报反而增加人工负担。我的做法是 Agent 给出归因和证据人确认后再提单这样既享受了自动化的效率又保留了人的判断。5.3 成本控制不是所有用例都值得用 Agent 跑Agent 跑用例的成本比传统脚本高因为每次执行都涉及模型调用。所以不能无脑全量跑要有策略高频核心用例用传统脚本跑稳定、便宜、快新功能用例用 Agent 跑因为规则还不稳定需要 Agent 的灵活性复杂场景用例用 Agent 跑因为传统脚本难以覆盖回归用例用传统脚本跑因为逻辑已经稳定我实测下来这种混合策略能把 Agent 的调用成本控制在可接受范围内同时保留它在新场景和复杂场景下的优势。6. 踩坑实录那些文档里不会写的经验6.1 坑一目标描述里的隐含假设有一次我让 Agent 生成用户下单的用例它生成的用例里默认用户已经登录、默认商品有库存、默认收货地址已填写。这些默认在大多数情况下成立但恰恰是这些隐含假设掩盖了真正的边界场景。后来我在目标描述里强制要求 Agent显式列出所有假设并且针对每个假设生成一条假设不成立的用例。这样隐含假设就变成了显式覆盖点用例的完整性大幅提升。6.2 坑二Agent 的过度归因Agent 有时候会过度归因把简单问题复杂化。比如一个接口返回 500明明就是空指针它非要分析出一堆可能是并发问题、可能是数据问题、可能是依赖问题。这种过度归因反而干扰判断。我的应对方式是给 Agent 设一个归因深度上限先给最直接的原因如果最直接的原因验证不通过再往深层找。不要一上来就发散。6.3 坑三用例的环境依赖被忽略Agent 生成的用例经常忽略环境依赖。比如它生成一条验证订单超时自动取消的用例但没考虑这条用例需要等待超时时间而测试环境的超时配置可能是几小时。这种用例跑起来要么超时要么根本跑不通。后来我在用例生成后加了一步环境适配检查让 Agent 检查每条用例的环境依赖是否满足不满足的要么调整参数要么标记为需人工准备环境。6.4 坑四归因结果的可复现性Agent 给出的归因有时候人验证不了因为复现不了。比如它说可能是并发竞争导致的但并发场景很难稳定复现。这种归因虽然可能是对的但没法验证价值就打折扣。我的做法是要求 Agent 对每个归因假设都给出可复现的验证方法。如果某个假设没法设计出可复现的验证方法就降低它的优先级或者标注需进一步分析。7. 效果评估与持续优化7.1 用什么指标衡量这套流程评估这套流程的效果不能只看用例数量或执行速度要看这几个指标指标说明目标用例维度覆盖率场景矩阵中各维度的覆盖比例90% 以上缺陷定位准确率归因首选假设正确的比例70% 以上定位平均耗时从失败到给出归因的时间5 分钟以内误报率Agent 判定失败但实际非缺陷的比例10% 以下人工介入时长人确认归因和决策的平均时间3 分钟以内这几个指标里缺陷定位准确率是最核心的。它直接决定了这套流程能不能真正减轻人的负担。我实测下来经过调优后准确率能稳定在七成以上剩下的三成里大部分是 Agent 给出了正确方向但具体原因需要人进一步确认。7.2 持续优化的方向这套流程不是一次搭好就完事的需要持续优化。我目前在做几个方向一是归因经验的沉淀。每次人工确认归因后把确认结果反馈给 Agent让它积累这类现象通常是什么原因的经验。积累得越多后续归因越准。二是用例库的自动演进。根据线上实际发生的缺陷反推哪些场景是用例库没覆盖的让 Agent 针对性补充用例。这样用例库能跟着业务一起演进而不是越用越旧。三是多 Agent 协作。目前用例生成和缺陷定位是两个独立的 Agent我在尝试让它们协作——定位 Agent 发现某类缺陷频繁出现时反馈给生成 Agent让它加强相关场景的用例生成。8. 一些实操建议和注意事项如果你打算在自己的团队里落地这套流程我有几个建议从小场景开始。不要一上来就覆盖整个系统先选一个业务逻辑相对独立、边界清晰的模块试点。跑通了再逐步扩展。保留人工兜底。Agent 再智能也有边界关键决策一定要保留人工确认环节。尤其是缺陷提单和修复决策不能全交给 Agent。重视数据质量。Agent 的定位能力高度依赖数据质量。日志不规范、链路不完整、变更记录缺失都会严重影响定位效果。落地这套流程之前先把可观测基建检查一遍。控制成本预期。Agent 调用是有成本的不要指望它比传统脚本便宜。它的价值在于覆盖传统脚本覆盖不了的场景以及降低人的定位负担而不是降低执行成本。持续迭代提示策略。Agent 的表现很大程度上取决于你怎么问它。目标描述怎么写、归因要求怎么提、证据链怎么组织这些都需要根据实际效果不断调整。我前后改了十几版提示策略才把准确率调到可接受的水平。最后分享一个我自己的体会这套流程最大的价值不是替代人而是把人从重复劳动里解放出来。用例生成和缺陷定位这两件事本质上是有规律可循的只是过去这些规律藏在老测试工程师的经验里没法规模化。Agent Skills 做的事情就是把这些经验显性化、可执行化让整个团队都能用上。至于它能不能完全替代人我觉得短期内不可能也没必要——人做决策、Agent 做执行和归因这个分工目前看是最稳的。 
长河君 · 2026/10/18 13:09:27 · 阅读 1.2k Agent Skills重构测试自动化：从用例生成到缺陷定位的工程实践
1. 测试流程的老大难为什么传统自动化越跑越累做过几年测试的人大概都有同感自动化脚本写了一堆用例库越堆越大可真正到了版本发布前那几天还是得靠人肉去补漏、去定位、去判断这个失败到底是不是真 Bug。表面上看是自动化覆盖率上去了实际上维护成本、误报率、定位耗时这三座大山一点没轻。我所在的团队前两年也走过这条路。最初我们搞的是标准的录制回放 断言校验模式用例数量从几百涨到几千CI 流水线从十分钟跑到四十分钟。问题随之而来接口字段一改几十条用例集体飘红前端 DOM 结构一动选择器全废最要命的是一条用例失败之后日志里只有一句expected 200 but got 500至于为什么 500、是环境问题还是代码问题、是数据问题还是并发问题全靠人去翻日志、翻链路、翻数据库。这就是传统测试自动化的根本瓶颈它只会告诉你失败了但不会告诉你为什么失败更不会告诉你接下来该怎么办。用例生成靠人写缺陷定位靠人查整个流程里最耗时的两个环节恰恰是最依赖人的环节。Agent Skills 这套思路之所以值得拿出来聊就是因为它把生成和定位这两个最痛的环节从人驱动变成了目标驱动。你不再需要写死每一条用例而是给 Agent 一个测试目标让它自己去拆解、去执行、去判断、去归因。听起来有点玄但拆开看每一步都是可以落地、可以复现的工程实践。这篇文章我会把整套流程拆成几个部分讲清楚Agent Skills 到底解决了传统自动化的哪些具体问题、用例生成环节怎么设计才能不生成一堆垃圾、缺陷定位环节怎么让 Agent 真正给出有价值的归因、以及我在实际跑这套流程时踩过的坑和总结出来的调优经验。不管你是测试开发、QA 负责人还是想把这套思路迁移到其他工程场景的开发者应该都能从中拿到可以直接抄的东西。2. Agent Skills 到底重构了什么从脚本执行到目标闭环2.1 传统自动化与 Agent 驱动的本质差异先把概念对齐。传统自动化测试的本质是脚本执行器你告诉它做什么它就做什么做完告诉你成功还是失败。它的能力边界完全由你写的脚本决定脚本没覆盖的场景它一无所知。Agent Skills 的本质是目标闭环系统你告诉它要验证什么它自己去规划怎么做、执行、观察结果、判断是否符合预期、如果不符合就分析原因。它具备四个传统脚本没有的能力规划能力把一个模糊的测试目标拆解成可执行的步骤序列工具调用能力根据需要调用接口请求、数据库查询、日志检索、浏览器操作等工具观察与判断能力不只看断言结果还能结合上下文判断这个结果是否合理归因能力失败之后能给出可能的原因排序而不是只抛一个异常这四点里前两点解决的是用例生成问题后两点解决的是缺陷定位问题。整个重构的核心就是把测试流程从人写脚本 → 机器执行 → 人看结果变成人定目标 → Agent 规划执行 → Agent 归因 → 人做决策。2.2 为什么是现在三个前提条件成熟了这套思路放在三年前其实跑不通不是因为想法不好而是因为三个前提条件不满足。第一是模型的任务拆解能力。早期的模型只能做单轮问答你让它规划一个多步骤的测试流程它给出的步骤要么太粗要么逻辑断裂。现在具备推理能力的模型可以稳定地把验证用户下单流程拆成登录 → 加购 → 结算 → 支付 → 查订单这样的可执行序列并且能根据中间结果动态调整。第二是工具调用的标准化。以前让模型调用外部工具得自己写一堆胶水代码解析输出、拼装参数。现在工具调用的协议逐渐统一Agent 可以比较自然地调用 HTTP 请求、SQL 查询、文件读写这些基础能力工程集成成本大幅下降。第三是可观测数据的丰富度。缺陷定位要准前提是 Agent 能看到足够多的上下文——链路追踪、结构化日志、指标数据、变更记录。现在大部分团队的可观测体系已经比较完善Agent 有料可查归因才有依据。提示如果你的团队连基本的链路追踪和结构化日志都没有先别急着上 Agent 定位把可观测基建补齐否则 Agent 拿到的是一堆非结构化文本归因质量会非常差。2.3 重构后的流程长什么样我把重构后的流程画成一条线方便你对照自己团队的现状目标输入人给出测试目标比如验证优惠券在下单流程中的抵扣逻辑用例规划Agent 拆解出正常场景、边界场景、异常场景的用例清单用例生成Agent 把每条用例转成可执行的请求序列或操作步骤执行与观察Agent 执行并收集响应、日志、链路数据结果判断Agent 结合断言和上下文判断通过与否缺陷归因失败用例由 Agent 分析可能原因并排序人工决策人确认归因、决定是否提单、是否修复对比传统流程第 2、3 步替代了人写用例第 6 步替代了人查日志。这两步恰恰是传统流程里最耗时的部分。我实测下来一个中等复杂度的业务模块用例编写时间从原来的两三天压缩到半天以内缺陷定位时间从平均每条二三十分钟压缩到几分钟。3. 用例生成环节怎么让 Agent 不产出看起来对但没用的用例3.1 用例质量的分水岭目标描述的颗粒度很多人第一次用 Agent 生成用例会直接丢一句帮我测试登录功能然后得到一堆输入正确用户名密码应登录成功输入错误密码应登录失败这种废话用例。问题不在 Agent在于目标描述太粗。用例质量的分水岭就在目标描述的颗粒度。我总结了一个可用的描述模板包含四个要素业务上下文这个功能在什么业务场景下被使用关键规则有哪些业务规则、约束条件、依赖关系已知风险点历史上这个模块出过什么问题期望覆盖希望覆盖哪些类型的场景正常、边界、异常、并发举个例子同样是登录功能粗描述和细描述的产出差距巨大粗描述测试登录功能 细描述 业务上下文用户通过手机号验证码登录登录后进入个人中心 关键规则 - 验证码 5 分钟内有效过期需重新获取 - 同一手机号 60 秒内只能发送一次验证码 - 连续 5 次验证码错误锁定账号 30 分钟 已知风险点历史上出现过验证码并发校验导致重复登录的问题 期望覆盖正常登录、验证码过期、频率限制、错误锁定、并发登录细描述产出的用例会精确覆盖到验证码在第 301 秒提交应失败第 6 次错误验证码应触发锁定这种真正有价值的边界而不是泛泛而谈。3.2 用场景矩阵约束生成范围光靠描述还不够Agent 容易发散。我习惯在描述之后附一个场景矩阵明确告诉它从哪几个维度组合场景。这个矩阵本质上是把测试设计里的等价类划分和边界值分析用结构化的方式喂给 Agent。维度取值说明用户状态未注册 / 已注册未登录 / 已登录决定权限和流程分支输入类型合法 / 边界 / 非法 / 空覆盖输入校验时序条件正常 / 超时 / 并发覆盖时序相关缺陷依赖服务正常 / 超时 / 返回异常覆盖下游故障场景有了这个矩阵Agent 生成用例时就有了明确的组合空间不会漏掉关键维度也不会在某个维度上无限发散。我实测下来加上矩阵约束之后用例的维度覆盖率从大概六成提升到九成以上。3.3 生成后的用例自检三道过滤Agent 生成的用例不能直接用必须过滤。我设了三道过滤第一道是去重过滤。Agent 有时会生成语义重复的用例比如密码错误应失败和错误密码应登录失败其实是同一条。用语义相似度做一轮去重能砍掉大概一到两成的冗余。第二道是可执行性过滤。有些用例描述得很漂亮但缺少必要的前置数据或依赖根本跑不起来。这类用例要么补全前置条件要么直接剔除。第三道是价值过滤。这是最容易被忽略的一道。有些用例虽然能跑但验证的是112这种永远不会出错的逻辑跑它纯属浪费资源。判断标准很简单这条用例如果失败了是否意味着有真实的业务风险如果答案是否定的就删掉。注意价值过滤这一步最好保留人工复核。Agent 对业务风险的理解有限有些看起来没价值的用例可能在特定业务语境下是关键的。我一般让 Agent 先标记低价值用例再由人快速过一遍确认。3.4 用例的版本化管理Agent 生成的用例不是一次性的需要版本化管理。我的做法是把用例存成结构化文件YAML 或 JSON每个用例带上元信息生成时间、生成时的目标描述、覆盖的场景维度、最近一次执行结果。这样做的好处是当业务规则变化时可以快速定位到受影响的用例让 Agent 基于新规则重新生成而不是全量重来。同时用例的执行历史也能反哺 Agent——哪些用例长期稳定通过、哪些经常失败这些信息能帮助 Agent 在后续生成时调整策略。4. 缺陷定位环节让 Agent 从报错走到归因4.1 定位的本质是缩小可能性空间缺陷定位听起来很玄但拆开看它的本质就是不断缩小可能性空间。一条用例失败了可能的原因有几十种代码逻辑错、数据不对、环境配置错、依赖服务挂了、并发竞争、时序问题……定位的过程就是一步步排除最后锁定到最可能的那一个。传统方式下这个排除过程靠人做靠经验、靠直觉、靠翻日志。Agent 做这件事的优势在于它可以同时检索多个数据源不会因为翻日志翻累了而漏掉线索也不会因为上次是这个问题而产生先入为主的偏见。我设计的定位流程分四步失败信息收集响应内容、错误码、异常堆栈、链路追踪、相关日志变更关联这次失败前后代码、配置、数据有没有变更假设生成基于收集到的信息生成可能的原因假设假设验证对每个假设设计验证方法并执行逐步排除4.2 数据源接入Agent 的眼睛要够多Agent 定位准不准取决于它能看到多少东西。我给它接入了这几类数据源接口响应完整的响应体、状态码、响应头链路追踪从入口到出口的完整调用链每个 span 的耗时和状态结构化日志按 traceId 关联的应用日志、中间件日志数据库快照失败时刻相关表的数据状态变更记录近期的代码提交、配置变更、数据变更历史相似案例过去同类失败的归因记录这六类数据里变更记录和历史相似案例是最容易被忽略但价值最高的。很多缺陷的根因就是某次变更引入的Agent 如果能关联到变更定位速度会快很多。历史案例则能让 Agent 复用过去的归因经验避免重复劳动。4.3 归因输出的结构不要只给结论要给证据链Agent 定位完之后输出不能只是一句可能是数据库连接池满了。这种结论没有说服力人也没法验证。我要求 Agent 的输出必须包含证据链失败用例优惠券抵扣金额计算错误 失败现象预期抵扣 20 元实际抵扣 10 元 归因假设按可能性排序 1. 优惠券规则配置错误可能性 70% 证据变更记录显示 2 小时前该优惠券规则被修改 证据数据库中该优惠券的抵扣类型从固定金额变为百分比 验证方法查询优惠券配置表确认当前规则 2. 计算逻辑未适配新规则可能性 20% 证据代码中抵扣计算仍按固定金额处理 验证方法检查计算逻辑代码分支 3. 数据缓存未刷新可能性 10% 证据缓存中仍是旧规则 验证方法对比缓存与数据库中的规则值这种结构化的输出人一眼就能看出 Agent 的判断依据也能快速验证。我实测下来这种带证据链的归因人工确认时间从原来的十几分钟压缩到两三分钟。4.4 定位准确率的调优从能定位到定位准Agent 定位的准确率不是一上来就高的需要调优。我踩过的坑和对应的调优手段有这么几个坑一数据源太多Agent 抓不住重点。一开始我把所有日志都喂给它结果它被大量无关日志干扰归因质量反而下降。后来改成按 traceId 精准关联只喂相关日志准确率明显提升。坑二历史案例污染。早期我把所有历史失败案例都作为参考结果 Agent 经常张冠李戴把不相关的历史原因套到当前问题上。后来改成只参考相似度高的历史案例并且明确标注仅供参考需独立验证。坑三归因过于自信。Agent 有时会给一个可能性 95% 的假设但实际是错的。我调整了提示策略要求它对每个假设都给出验证方法并且明确说明如果验证不通过下一个假设是什么。这样即使首选假设错了也能快速切换到下一个。坑四忽略环境因素。很多失败其实是环境问题比如测试环境数据被污染但 Agent 倾向于往代码问题上找。我在数据源里加了环境健康检查让 Agent 先排除环境因素再往代码上找。5. 把两个环节串起来完整流程的工程落地5.1 流程编排用状态机管理整个链路用例生成和缺陷定位不是孤立的它们需要串成一条完整的流水线。我用状态机来管理目标输入 → 用例规划 → 用例生成 → 用例过滤 → 用例执行 → 结果判断 → [通过] → 记录结果 → [失败] → 缺陷定位 → 归因输出 → 人工确认每个状态都有明确的输入输出状态之间的流转有条件判断。这样做的好处是任何一个环节出问题都能快速定位也方便后续扩展比如在用例执行后面加一个性能采集状态。5.2 与现有 CI/CD 的集成这套流程不能脱离现有的 CI/CD 独立跑否则就是空中楼阁。我的集成方式是触发时机代码合并到主分支后触发或者定时触发执行环境复用现有的测试环境不单独搭建结果输出归因结果推送到现有的缺陷管理工具和通知渠道人工介入点只在人工确认这一步介入其他环节全自动这里有个经验不要试图让 Agent 全自动提单。Agent 的归因再准也有出错的时候让它自动提单会造成大量误报反而增加人工负担。我的做法是 Agent 给出归因和证据人确认后再提单这样既享受了自动化的效率又保留了人的判断。5.3 成本控制不是所有用例都值得用 Agent 跑Agent 跑用例的成本比传统脚本高因为每次执行都涉及模型调用。所以不能无脑全量跑要有策略高频核心用例用传统脚本跑稳定、便宜、快新功能用例用 Agent 跑因为规则还不稳定需要 Agent 的灵活性复杂场景用例用 Agent 跑因为传统脚本难以覆盖回归用例用传统脚本跑因为逻辑已经稳定我实测下来这种混合策略能把 Agent 的调用成本控制在可接受范围内同时保留它在新场景和复杂场景下的优势。6. 踩坑实录那些文档里不会写的经验6.1 坑一目标描述里的隐含假设有一次我让 Agent 生成用户下单的用例它生成的用例里默认用户已经登录、默认商品有库存、默认收货地址已填写。这些默认在大多数情况下成立但恰恰是这些隐含假设掩盖了真正的边界场景。后来我在目标描述里强制要求 Agent显式列出所有假设并且针对每个假设生成一条假设不成立的用例。这样隐含假设就变成了显式覆盖点用例的完整性大幅提升。6.2 坑二Agent 的过度归因Agent 有时候会过度归因把简单问题复杂化。比如一个接口返回 500明明就是空指针它非要分析出一堆可能是并发问题、可能是数据问题、可能是依赖问题。这种过度归因反而干扰判断。我的应对方式是给 Agent 设一个归因深度上限先给最直接的原因如果最直接的原因验证不通过再往深层找。不要一上来就发散。6.3 坑三用例的环境依赖被忽略Agent 生成的用例经常忽略环境依赖。比如它生成一条验证订单超时自动取消的用例但没考虑这条用例需要等待超时时间而测试环境的超时配置可能是几小时。这种用例跑起来要么超时要么根本跑不通。后来我在用例生成后加了一步环境适配检查让 Agent 检查每条用例的环境依赖是否满足不满足的要么调整参数要么标记为需人工准备环境。6.4 坑四归因结果的可复现性Agent 给出的归因有时候人验证不了因为复现不了。比如它说可能是并发竞争导致的但并发场景很难稳定复现。这种归因虽然可能是对的但没法验证价值就打折扣。我的做法是要求 Agent 对每个归因假设都给出可复现的验证方法。如果某个假设没法设计出可复现的验证方法就降低它的优先级或者标注需进一步分析。7. 效果评估与持续优化7.1 用什么指标衡量这套流程评估这套流程的效果不能只看用例数量或执行速度要看这几个指标指标说明目标用例维度覆盖率场景矩阵中各维度的覆盖比例90% 以上缺陷定位准确率归因首选假设正确的比例70% 以上定位平均耗时从失败到给出归因的时间5 分钟以内误报率Agent 判定失败但实际非缺陷的比例10% 以下人工介入时长人确认归因和决策的平均时间3 分钟以内这几个指标里缺陷定位准确率是最核心的。它直接决定了这套流程能不能真正减轻人的负担。我实测下来经过调优后准确率能稳定在七成以上剩下的三成里大部分是 Agent 给出了正确方向但具体原因需要人进一步确认。7.2 持续优化的方向这套流程不是一次搭好就完事的需要持续优化。我目前在做几个方向一是归因经验的沉淀。每次人工确认归因后把确认结果反馈给 Agent让它积累这类现象通常是什么原因的经验。积累得越多后续归因越准。二是用例库的自动演进。根据线上实际发生的缺陷反推哪些场景是用例库没覆盖的让 Agent 针对性补充用例。这样用例库能跟着业务一起演进而不是越用越旧。三是多 Agent 协作。目前用例生成和缺陷定位是两个独立的 Agent我在尝试让它们协作——定位 Agent 发现某类缺陷频繁出现时反馈给生成 Agent让它加强相关场景的用例生成。8. 一些实操建议和注意事项如果你打算在自己的团队里落地这套流程我有几个建议从小场景开始。不要一上来就覆盖整个系统先选一个业务逻辑相对独立、边界清晰的模块试点。跑通了再逐步扩展。保留人工兜底。Agent 再智能也有边界关键决策一定要保留人工确认环节。尤其是缺陷提单和修复决策不能全交给 Agent。重视数据质量。Agent 的定位能力高度依赖数据质量。日志不规范、链路不完整、变更记录缺失都会严重影响定位效果。落地这套流程之前先把可观测基建检查一遍。控制成本预期。Agent 调用是有成本的不要指望它比传统脚本便宜。它的价值在于覆盖传统脚本覆盖不了的场景以及降低人的定位负担而不是降低执行成本。持续迭代提示策略。Agent 的表现很大程度上取决于你怎么问它。目标描述怎么写、归因要求怎么提、证据链怎么组织这些都需要根据实际效果不断调整。我前后改了十几版提示策略才把准确率调到可接受的水平。最后分享一个我自己的体会这套流程最大的价值不是替代人而是把人从重复劳动里解放出来。用例生成和缺陷定位这两件事本质上是有规律可循的只是过去这些规律藏在老测试工程师的经验里没法规模化。Agent Skills 做的事情就是把这些经验显性化、可执行化让整个团队都能用上。至于它能不能完全替代人我觉得短期内不可能也没必要——人做决策、Agent 做执行和归因这个分工目前看是最稳的。