1. 测试流程的老问题为什么人肉写用例越来越跑不动了做测试这行的大概都经历过这样的场景需求评审刚结束开发还在画架构图测试负责人就已经在催用例什么时候能出。然后你打开文档对着需求文档一行一行抠把用户登录拆成输入正确账号密码输入错误密码账号为空密码为空账号不存在……一个模块下来几十条用例写得手酸评审的时候还被问边界值考虑了吗异常流覆盖了吗。这套流程在业务简单、迭代慢的年代是能跑的。但现在的情况是一周一个版本需求文档可能上午改下午又改接口字段说加就加。你辛辛苦苦写完的用例开发一句这个逻辑调整了一半要重写。更别提那些藏在代码分支里的边界条件靠人脑去穷举漏测几乎是必然的。我真正开始认真思考测试流程能不能用 Agent Skills 重构是在连续两个版本都出现用例写了但没覆盖到的线上问题之后。复盘的时候发现漏掉的那个场景其实在代码里写得很清楚——某个字段在特定状态下会返回空数组而我们的用例只覆盖了有数据和请求失败两种情况。这不是态度问题是人脑在处理组合爆炸时的天然短板。Agent Skills 这个概念说白了就是把大模型的能力拆成一个个可复用、可编排的技能单元每个技能负责一个明确的子任务然后通过流程把它们串起来。放到测试场景里就是让读需求生成用例分析代码定位缺陷这些动作各自有专门的技能来处理而不是指望一个通用对话窗口包打天下。这篇文章想聊的就是我怎么用这套思路把测试流程从人肉驱动改成技能驱动的。核心会围绕三件事展开用例怎么从需求和代码里自动长出来、缺陷定位怎么从猜变成查、以及这套东西落地时踩过的那些坑。适合已经有一定测试经验、想把手上的重复劳动交给工具的同学参考也适合刚接触 Agent 概念、想知道它在真实工程里怎么用的朋友。2. 拆解测试动作哪些环节适合交给 Agent Skills在动手之前我先做了一件事把自己日常的测试工作完整录了一遍从拿到需求到提交缺陷报告一共拆出十七个动作。然后逐个判断哪些是规则明确、输入输出清晰的哪些是依赖直觉、需要经验判断的。这个判断很关键因为 Agent Skills 擅长的是前者硬塞后者只会得到一堆看似合理但没法用的结果。2.1 三类高价值可自动化动作第一类是信息提取与结构化。比如从需求文档里抽出功能点输入条件预期结果从接口定义里抽出字段名类型必填性取值范围。这类动作的特点是输入是非结构化文本输出是结构化数据规则相对固定大模型做起来准确率很高。第二类是组合生成与穷举。拿到结构化后的条件按照等价类划分、边界值分析、判定表这些经典方法生成覆盖各种组合的用例。人脑做这个容易累、容易漏机器做这个正好。第三类是代码与日志的关联分析。给定一个缺陷现象去代码库里找相关逻辑去日志里找异常堆栈把现象和原因之间的链路补全。这类动作以前靠人翻代码现在可以让技能去检索和比对。2.2 我实际搭建的技能清单经过几轮迭代我最终稳定下来的技能有这么几个技能名称输入输出核心逻辑需求解析器需求文档片段功能点列表、条件表按触发条件-处理逻辑-预期结果三元组抽取接口契约提取接口定义文件字段约束表解析类型、必填、枚举、边界用例生成器条件表约束表用例集等价类边界值场景法组合代码检索器关键词/现象描述相关代码片段语义检索调用链追踪日志分析器日志片段异常模式、时间线模式匹配时序对齐缺陷定位器现象代码日志可疑位置排序多源证据加权这张表不是一开始就长这样的。最早我只做了用例生成器后来发现生成的用例质量不稳定追根溯源是需求解析那一步抽得不准才回头补了需求解析器。再后来发现缺陷定位还是靠人又把代码检索和日志分析加进来。技能清单是长出来的不是设计出来的这一点后面还会细说。2.3 为什么不做成一个全能大技能有人可能会问为什么不直接写一个超级提示词让模型一次性完成读需求→生成用例→分析代码→定位缺陷我试过结论是链路越长误差累积越严重。第一步抽错一个条件后面全歪。而且出了问题没法定位是哪一步的锅。拆成独立技能之后每个技能可以单独测试、单独优化、单独替换。需求解析器抽得不准我就专门给它加 few-shot 示例用例生成器覆盖不全我就调整它的组合策略。这种分而治之的思路是整套流程能稳定跑起来的前提。3. 用例生成技能从需求文本到可执行用例的完整链路用例生成是整套流程里最先跑通、也是收益最直观的一环。我拿一个中等复杂度的模块做过对比人工写用例大概需要四到六小时用技能生成加人工复核压缩到四十分钟左右而且覆盖的场景数量是人工的两倍多。下面把这套链路拆开讲。3.1 需求解析把人话变成条件表需求文档里最常见的一句话是用户提交订单时如果库存充足则扣减库存并生成订单否则提示库存不足。人读这句话脑子里自动就补出了条件分支。但要让机器处理得先把这句话拆成结构化的东西。我给需求解析器定的输出格式是这样的{ feature: 订单提交, conditions: [ {id: C1, desc: 库存充足, type: business}, {id: C2, desc: 库存不足, type: business} ], actions: [ {condition_ref: C1, action: 扣减库存并生成订单}, {condition_ref: C2, action: 提示库存不足} ], inputs: [用户ID, 商品ID, 购买数量], expected: [订单状态, 库存变化, 提示信息] }这个格式的关键在于把条件和动作分开并且给每个条件一个 ID。这样后面生成用例的时候可以明确知道每条用例覆盖了哪个条件覆盖率是可计算的而不是拍脑袋说应该覆盖全了。实操中有一个坑需求文档里经常有隐含条件。比如库存充足这句话其实隐含了商品存在商品未下架购买数量大于零这些前置条件。解析器如果只抽显式条件就会漏。我的做法是在提示词里明确要求列出所有使该条件成立的前置假设并且在输出里用assumptions字段单独标记。这些假设后面会变成额外的测试用例。3.2 组合策略等价类、边界值、场景法怎么配合拿到条件表之后用例生成器要做的是把条件组合成具体的测试用例。这里我用的是三层策略第一层是等价类划分。把每个输入字段的取值范围分成有效类和无效类。比如购买数量这个字段有效类是 1 到库存数无效类包括 0、负数、超过库存、非数字。每个等价类至少取一个代表值。第二层是边界值分析。在等价类的边界上取值比如库存刚好等于购买数量、购买数量等于库存加一、购买数量等于零。边界值是缺陷高发区这一层不能省。第三层是场景法。把多个条件组合成一个完整的业务场景比如库存充足用户有优惠券收货地址有效这样的组合。场景法用来覆盖条件之间的交互等价类和边界值覆盖的是单个字段场景法覆盖的是字段之间的关系。这三层的输出会合并去重最终形成用例集。我实测下来一个包含五个输入字段、三个业务条件的模块生成出来的用例大概在六十到八十条之间人工复核后保留五十条左右比人工写的三十条覆盖更全。3.3 用例可执行化让生成的用例能直接跑生成的用例如果只是文字描述价值有限。我做的进一步处理是让用例生成器同时输出可执行的请求模板。比如针对一个 HTTP 接口用例里会带上完整的请求方法、路径、请求体、预期状态码和预期响应字段。# 生成的用例示例伪代码结构 case { id: TC-ORDER-012, desc: 库存刚好等于购买数量时提交订单, request: { method: POST, path: /api/order/submit, body: {userId: U001, skuId: S100, qty: 5} }, precondition: 该 SKU 库存为 5, expected: { status: 200, body.orderStatus: CREATED, body.stockAfter: 0 } }这样生成的用例可以直接喂给接口测试框架去跑省掉了把文字用例翻译成脚本这一步。这一步的收益在回归测试阶段特别明显——每次版本更新重新生成一遍用例直接跑不用再手工维护脚本。注意生成的请求模板一定要经过人工确认再接入自动化。我遇到过生成器把预期状态码写成 200 但实际业务返回 201 的情况如果直接跑会误报一堆失败。4. 缺陷定位技能把猜原因变成查证据用例生成解决的是测什么的问题缺陷定位解决的是为什么错的问题。后者其实更耗时间——一个线上问题从发现到定位到根因经常要花掉大半天。我搭缺陷定位技能的初衷就是把这半天压缩到半小时以内。4.1 缺陷定位的难点在哪传统定位流程是这样的看到报错现象先猜可能是哪个模块然后去翻代码翻着翻着发现调用链很深又去翻日志日志里一堆噪音得一条条筛。整个过程高度依赖对系统的熟悉程度换个不熟的模块效率直接腰斩。更麻烦的是很多缺陷的现象和原因之间隔了好几层。比如订单列表加载慢可能是数据库慢查询可能是缓存失效可能是某个下游接口超时也可能是前端渲染问题。光看现象根本判断不了往哪个方向查。4.2 多源证据加权代码、日志、变更记录一起看我的做法是让缺陷定位器同时检索三类信息然后做加权排序代码证据根据现象里的关键词比如接口路径、字段名、错误码在代码库里做语义检索找到相关函数和调用链。日志证据在日志里找同一时间窗口内的异常、警告、慢查询记录按时间线对齐。变更证据查最近的代码提交记录看相关文件在问题出现前后有没有改动。这三类证据各自给出一个可疑位置列表然后按权重合并。代码证据权重最高因为它是逻辑的源头日志证据次之因为它反映运行时状态变更证据作为辅助用来解释为什么以前没问题现在有问题。实际跑下来这个加权策略能把可疑位置从几十个缩小到三到五个人工只需要在这几个里面确认就行。4.3 一次完整的定位过程还原举个我实际处理的例子。现象是某接口在特定用户下返回 500。我把现象描述丢给定位器它做了这么几件事第一步从现象里抽出关键词接口路径500特定用户去代码库检索找到该接口的处理函数以及它调用的三个下游服务。第二步去日志里找同一时间该接口的调用记录发现异常堆栈指向一个空指针位置在下游服务 B 的返回处理逻辑里。第三步查变更记录发现下游服务 B 的返回结构在两天前改过新增了一个可选字段但接口处理函数没有做空值判断。三步下来根因就清楚了下游改了返回结构上游没同步适配。整个过程大概花了十几分钟其中大部分时间是我在确认定位器的结论而不是自己在翻代码。这里有个经验定位器的输出一定要带证据链也就是它为什么认为某个位置可疑。没有证据链的结论即使对了也不敢信因为没法验证。5. 技能编排怎么把独立技能串成一条流水线单个技能跑通之后下一个问题是怎么把它们串起来。我的原则是能并行就并行能缓存就缓存能人工介入就留出口。5.1 编排框架的选择我试过两种编排方式。一种是用通用的工作流引擎把每个技能包装成一个节点用配置文件定义依赖关系。另一种是直接用脚本串每个技能是一个函数按顺序调用。通用引擎的好处是可视化、易维护坏处是学习成本高而且调试的时候隔了一层出问题不好查。脚本的好处是直观、好改坏处是复杂流程写起来乱。最后我选的是混合方案主干流程用脚本串保证可控需要并行或者有复杂依赖的部分用轻量级的任务队列处理。这样既保留了灵活性又不至于失控。5.2 数据在技能之间怎么流转技能之间的数据格式统一用 JSON每个技能的输出必须符合预定义的 schema。这样做的好处是任何一个技能出问题我可以单独拿它的输入和输出来复现不用跑整条链路。举个数据流转的例子需求文档 → [需求解析器] → 条件表.json → [用例生成器] → 用例集.json → [用例执行器] → 执行结果.json → [缺陷定位器] → 定位报告.json每一环的产物都落盘保存这样出问题的时候可以逐环排查。我踩过的一个坑是早期为了省事技能之间直接传内存对象结果某个技能偶发失败根本没法复现因为输入数据已经没了。落盘之后这个问题就解决了。5.3 人工介入点怎么设计全自动听起来很美但实际落地必须留人工介入点。我留了三个第一个在需求解析之后。解析器抽出的条件表需要人工扫一眼确认没有漏掉关键条件。这一步大概花五分钟但能避免后面全盘皆错。第二个在用例生成之后。生成的用例集需要人工复核删掉明显不合理的补充业务特有的场景。这一步花十五分钟左右。第三个在缺陷定位报告之后。定位器给出的可疑位置需要人工确认根因然后才进入修复流程。这三个介入点看起来增加了工作量但实际上它们把返工的风险控制在了早期。如果不留介入点等到用例跑完发现方向错了返工成本要高得多。6. 落地过程中踩过的坑与应对这套东西从想法到稳定运行大概花了三个月。中间踩的坑不少挑几个有代表性的说说。6.1 生成用例的幻觉覆盖早期版本的用例生成器有个毛病它会生成一些看起来合理、但实际上业务上不可能发生的用例。比如用户 ID 为空但购买数量为负数且库存充足这种组合逻辑上成立但业务上根本不会出现因为用户 ID 为空的话请求根本进不来。这种幻觉覆盖的危害在于它让用例数量虚高覆盖率看起来很好看但实际有效的没几条。我的应对办法是在生成器里加一层业务约束过滤把不可能的组合提前排除。约束规则来自需求文档里的前置条件以及和开发确认过的系统边界。6.2 代码检索的语义漂移代码检索器用的是语义匹配好处是能理解订单提交和创建订单是一回事坏处是有时候会漂移。比如搜库存扣减它可能把库存查询的代码也捞出来因为语义相近。这个问题没有完美的解法我的做法是加一层调用链过滤检索出来的代码片段只保留那些在目标接口调用链上的。调用链信息可以从代码的静态分析里拿到虽然不完美但能过滤掉大部分无关结果。6.3 日志分析的时间对齐难题日志分析最头疼的是时间对齐。不同服务的日志时间戳精度不一样有的到秒有的到毫秒还有的有时区问题。早期我直接按时间戳排序结果经常把不相关的事件排到一起。后来改成按请求 ID 对齐每个请求在入口处生成一个唯一 ID透传到所有下游服务日志里都带上这个 ID。分析的时候先按请求 ID 分组再在组内按时间排序。这样对齐准确多了代价是需要推动各个服务在日志里加请求 ID算是一个前期投入。6.4 技能更新的回归验证技能不是写完就完了后面还要不断调优。每次调整提示词或者换模型都可能影响输出质量。我吃过一次亏优化了需求解析器的提示词结果用例生成器的输入格式对不上了整条链路跑挂。从那以后我给每个技能都建了一套回归用例准备一批固定的输入每次改动后跑一遍对比输出有没有异常变化。这套回归用例不追求覆盖所有情况但能挡住大部分低级错误。7. 这套流程适合什么样的团队最后聊聊适用性。这套东西不是万能的它有明确的适用边界。如果你的团队是业务稳定、迭代慢、测试用例几年不变的那种那这套流程的收益有限因为用例生成的边际价值不高。但如果你是快速迭代、需求频繁变更、测试人力紧张的团队那这套流程能明显缓解压力。另外一个前提是代码和日志的可访问性。缺陷定位技能依赖代码检索和日志分析如果代码库权限管得很死或者日志格式混乱没有统一规范那定位技能的准确率会大打折扣。这种情况下建议先把日志规范做起来再考虑上定位技能。我个人在实际操作中的体会是不要追求一步到位。先把用例生成跑通拿到收益建立信心再逐步加缺陷定位。每一步都要有可量化的对比比如用例编写时间从 X 降到 Y缺陷定位时间从 A 降到 B。有了数据推动后续优化才有说服力。还有一点技能的输出永远需要人工把关。Agent Skills 是放大器不是替代品。它把你从重复劳动里解放出来让你有精力去做更有价值的判断。把这一点想清楚落地的时候心态会稳很多。