作者介绍：胡臻荣，来自货拉拉/技术中心/质量保障部/出行组，负责出行组质量保障与效能工具建设
一、背景：当我们谈论自动化时，我们在谈论什么？
很多团队谈接口自动化，落到最后往往是一句：「脚本有了，跑起来就行。」流水线、报告、告警都自动化了；但设计用例、准备数据、写断言、修失败、补覆盖，仍高度依赖人工。
自动化，常常只自动了「最后一公里」。
1.1 三个现实，把测试同学越推越忙
- 效率： 编写与维护用例约占测试总工时两成，需求频繁变更时更高------自动化本为省时间，时间却仍耗在重复编码和维护上。
- 质量： 边界与异常易漏测，安全网常退化成「出事再补」------人力有限，经验难沉淀。
- 资源： 功能 / 接口 / 回归并行推进，「人工编写 + 执行」越来越难跟上业务节奏。
1.2 问题的本质：链路断了，而不只是跑得不够快
设计、取数、写脚本、断言、修失败、补覆盖------每个环节都要人工介入，断点多、难闭环，覆盖度依赖个人经验。
一句话：我们自动化的是「跑」，没有自动化的是「产」。
1.3 所以，我们真正要建设的是什么？
一个把高耗时的脚本编写环节，纳入 AI 辅助的闭环体系。能否稳定交付符合团队标准的高质量用例------让 LLM 负责理解与生成，让协议负责数据来源、风格对齐、断言策略与质量门禁。约束到位，人人都是测试专家，产出都是标准化用例。
测试同学的时间，应该从重复编码与跨系统查参里释放出来，回到更有价值的地方：风险判断、场景设计、结果分析。
二、从「能跑通」到「能交付」：为什么需要 Skill
接口自动化 AI 生成并非一步到位。我们经历了模板填充 → 工作流编排（LLM + MCP + Prompt）→ Skill 工程化三轮建设；每一轮打通一层能力，也暴露下一层必须攻克的问题。最终判断是：不能只靠「直接让 AI 写脚本」，而要把交付标准外置为可版本管理的 Skill 协议。
| 阶段 | 典型做法 | 主要局限 / 升级动因 |
|---|---|---|
| 1.0 模板填充 | 固定模板 + 流量回放参数注入 | 验证「自然语言 → TestNG」可行；风格僵化、断言浅、难适配多模块 |
| 2.0 工作流编排 | 智能助手 + 工作流代理 + LLM + MCP + Prompt | 打通端到端链路；规则散落、质量波动、模式扩展难、缺交付门禁 |
| 3.0 Skill 工程化 | 协议约束 + 多源数据 + 生成门禁 + 模式路由 | 可交付、可度量、可迭代、可团队推广 |
2.1 直接生成的系统性缺口
在 Cursor 等 IDE 里用自由对话生成脚本，往往需要大量人工介入：PATH、包名、断言、编译来回改；每人 Prompt 不同，返工点也不固定，本质上仍依赖个人经验。缺口集中在五层：
- 数据层：难自动拉取流量回放 / Monitor 等真实样本，易编造数据
- 风格层：不了解仓库框架、SOA 调用链与断言惯例
- 断言层 ：倾向浅层
ret=0，遗漏业务规则 - 交付层：缺少 lint / compile 门禁，问题推迟到运行期
- 协作层：结果不可复现，难以团队推广
| 维度 | 直接让 AI 生成 | Skill 约束生成 |
|---|---|---|
| 知识来源 | 模型记忆 + 当次上下文 | 流量回放 / Monitor / 业务仓源码 / 覆盖率报告 |
| 风格对齐 | 套用通用模板，易与仓库不一致 | 扫描既有测试代码仿写 |
| 字段与断言 | 易幻觉字段、浅层校验 | 禁止编造；契约 / 业务 / 语义三层断言 |
| 质量保障 | 依赖个人经验 | 静态自检 + 编译验证双层门禁 |
| 可复用性 | 经验绑定个人 Prompt | 协议版本化，团队共享同一套约束 |
2.2 Skill 工程协议与四条交付承诺
Skill 不是更长的 Prompt，而是一套面向交付的测试工程协议。它把规则与约束前置：接口数据怎么取、仓库写法怎么对齐、断言怎么分层、交付前怎么过门禁，都写进可版本管理的协议------Skill 规定做什么、按什么标准交付，MCP 拉真实数据，Agent 按步骤执行。
使用者往往只需一句自然语言指令 ，不必每次从零讲规则，也不必靠多轮对话补缺口。约束到位，人人都是测试 专家 ，产出都是标准化用例。
Skill 的核心价值，可归纳为以下四点：
1. 可信的数据闭环
接口信息必须来自 MCP 工具或用户输入；缺核心字段时停止生成，禁止静默编造。数据源优先级与查询策略在协议层统一约定，保证不同同学生成结果一致。
2. 可落地的代码形态
不套固定模板枚举，而是在目标仓库内扫描同模块既有代码仿写------包路径、SOA 调用链、断言写法与分支现状一致。
3. 可验证的质量门禁
静态自检 + 编译验证；编译失败不得交付。断言深度与语法正确性同等重要。
4. 可扩展的模式 路由
单接口、XMind 转自动化、场景级 llrunner、覆盖率补测、效能平台 JSON------每种模式独立清单，避免能力串线污染。
2.3 多模式独立路由
不同生成场景差异很大------单接口、功能用例转自动化、场景串联、覆盖率补测不应共用同一套 Prompt。Skill 通过任务识别 + 模式 路由，为每种场景加载独立步骤清单与 reference，避免能力串线、上下文失焦：
结论 ：Skill 解决的不只是 coding 能力，而是交付标准 ------让 LLM 负责生成，让协议负责约束，让人人都是测试 专家 、产出都是标准化用例。
三、整体架构设计：分层解耦，各司其职
一句自然语言指令，如何变成可提交的 TestNG 代码？我们的判断很直接：接口用例生成不是「模型写一段 Java」就结束，而是一条跨系统、跨规范的工程链路。链路若全部塞进 Prompt，产出必然不稳定------今天 path 对了，明天包名错了；这次断言还行，下次又只剩 ret=0。
因此方案将生成过程拆为交互层 → 协议层 → 数据层 → 质量层 → 产出层
3.1 各层职责
- 交互层：接收自然语言意图------用户只需表达「想测什么」，不必同时描述「怎么测、测到哪」。
- 协议层：生成过程的「中枢」。任务识别与模式路由决定走哪条生成路径；流程约束与交付标准规定数据从哪来、代码放哪、断言验到哪；仿写策略与断言策略对齐仓库写法与三层断言体系。
- 数据层：连接真实世界。模型可以「理解」业务，但不应「编造」path 与字段------真实样本、日志、源码、覆盖率报告在此注入。
- 质量层：定义交付底线。静态检查 + 编译验证，问题在合入前拦截，而非推迟到流水线才暴露。
- 产出层：可提交 TestNG 代码------path 真实、包结构对齐、断言有业务深度、编译可通过。
3.2 MCP 数据层：连接真实世界
以下能力域由 MCP 承载，Skill 通过协议约定调用策略，自身无需关心各系统鉴权细节：
| 能力域 | 解决什么问题 | 设计定位 |
|---|---|---|
| 流量回放 | 获取真实调用样本 | 接口契约与入参出参的首选来源 |
| Monitor | 补充日志侧调用记录 | 回放未命中时的递进查询 |
| 业务 代码仓 | 对齐实现细节与团队写法 | 仿写风格、实现级断言的依据 |
| 覆盖率 | 定位未覆盖代码 | 补测分支独立触发，不与常规定位混用 |
| 统一网关 | 鉴权、克隆、使用统计 | 团队基础设施，Skill 无感知接入 |
关键不在「能查多少数据源」，而在生成前先拿到真实上下文，而不是生成后再人工纠偏 。Skill 协议层统一约定数据源优先级与递进查询策略，按不同生成场景组织多重数据兜底------主源未命中时自动向下游递补，禁止静默编造 path 与字段。
- 常规定位 （单接口、XMind 转自动化、场景级串联）：默认流量回放 → Monitor 递进补全 → ldoc 定义补充 → Postman 可选兜底；用户显式指定数据源时优先执行指定源，不得静默切换。
- 覆盖率补测 ：走独立分支，先解析报告定位盲区，再触发取数与生成，不与常规定位链路混用。
- 风格与断言对齐：业务代码仓并行承担仿写风格与实现级断言依据------取数链路管「真不真」，代码仓管「像不像」。
3.3 设计原则
单一职责
数据、规则、质量三层分离------MCP 不替 Skill 定标准，Skill 不替门禁做编译，各层边界清晰。
规则外置
团队规范沉淀为可版本管理、可评审的 Skill 协议，而不是散落在个人 Prompt 或工作流节点配置里。
模式隔离
单接口、XMind 转自动化、场景级 llrunner、覆盖率补测等场景独立路由，按需加载 reference，避免能力串线、上下文失焦。
语义与工程 解耦
AI 负责理解业务与生成表达；工具与协议负责确定性转换------该确定的，不让模型赌概率。
凭证与密钥统一由 MCP 网关管理，Skill 可在 Cursor、Qoder、HClaw 等 IDE 与智能助手、服务端等多入口复用同一套能力------入口可以不同，交付标准一致。
MCP 让生成有真数据，Skill 让产出有标准，门禁让交付有底线。 只有三层各司其职，「一句话生成」才不只是口号，而是团队级可复用的能力。
四、核心能力建设：效率 · 质量 · 覆盖度
围绕效率、质量、覆盖度三维目标，沉淀核心能力：自然语言驱动生成、多源真实数据接入、三层断言体系、生成门禁交付、覆盖率闭环补全、多模式独立路由。每项能力均对应明确的建设价值与可度量产出，支撑「一句指令生成、稳定交付、持续补全」的团队级接口自动化。
4.1 效率：把人力从编码与查参中释放出来
通过自然语言驱动的一键生成，测试同学不必再反复写样板代码、跨系统查接口参数。精力可以更多投向风险判断、场景设计与业务验证------重复劳动交给 Agent，关键判断留给人。
从用户意图到可提交代码的完整生成链路：意图识别 → 多源查参 → 风格扫描 → 代码仿写 → 门禁校验，系统自动完成全流程编排。
| 模式 | 触发方式 | 产出 |
|---|---|---|
| 单接口 | 自然语言指定 appId + 接口名 | TestNG 类（扫描仿写） |
| XMind 转自动化 | .xmind + 生成意图 | 多接口 TestNG |
| 场景级 llrunner | 串联 / 链路 / 场景关键词 | Enum + Process + Test |
| 覆盖率补测 | 覆盖率报告链接或补测意图 | 补测建议 / TestNG |
| 效能平台 JSON | 结构化任务下发 | TestNG + manifest |
4.2 质量：从"事后发现"走向"事前补全"
智能断言保障自动化「验的深、验的准」；智能语法校验保障自动化「跑的稳」。
断言是我们做接口自动化的核心重点。方案将断言设计与代码结构置于同等优先级，构建递进式断言体系：
- 契约层： 响应结构、状态码、成功标识------保证接口「调得通、返得对」；
- 业务 层： 结合真实样本与业务逻辑，覆盖订单状态、金额计算、权限控制等规则，形成针对性断言组合；
- 语义驱动： 查询类侧重数据完整性；写操作类侧重状态流转；串联场景侧重跨接口字段一致性。
在 Skill 约束下，AI 可基于数据样本与语义理解，主动补全易遗漏的校验点------充分发挥 LLM 穷举优势，让自动化更擅断言、更贴业务、更能发现真实问题。
智能语法校验是代码的质量底座------断言再准，代码跑不起来也无效。
- 生成后自检： 校验 import、泛型、语法结构、命名规范，确保代码可直接编译运行。
- 执行前拦截： 无效断言写法、缺失依赖、结构不完整等问题在交付前被过滤。
- 执行中自愈：遇到可修复的语法/结构类报错，自动修正后重试，减少人工返工。
4.3 覆盖度：覆盖率驱动的智能补全
将覆盖率报告作为补测决策的客观输入，使自动化覆盖提升从依赖个人经验，转向数据定位、规则约束、持续收敛的工程化闭环。
上图呈现了覆盖率驱动补全的完整链路：覆盖率报告 → 增量分析 → 盲区定位 → 语义补测 → 门禁交付 → 回归收敛。
传统接口自动化长期停留在「有用例、能执行」，却难以量化「测到了什么、还缺什么」------代码覆盖率提供了测试有效性的客观基线，将测试资产与代码变更建立反馈关联，使测试工作从被动响应缺陷，转向主动收敛盲区。
覆盖率驱动补全的核心价值
- 精准定位：基于增量覆盖报告，将补测目标精确关联至未覆盖代码片段；
- 语义补全：结合未覆盖逻辑的完整上下文，生成具备业务语义的断言组合，而非机械叠加用例；
- 质量同源：补测用例与常规定位共用断言策略与生成门禁，保障交付标准一致；
- 闭环收敛：「报告解析 → 补测生成 → 回归验证 → 覆盖提升」形成可重复执行的改进循环。
五、效果与收益
从能力验证到规模化落地。 方案已在多条业务线稳定运行，在效率、质量、覆盖度三个维度形成可度量、可复用的收益。以下以典型场景演示与量化数据，呈现工程化落地的真实效果。
5.1 典型能力演示
自然语言一句话触发，低门槛高效产出；覆盖率缺口驱动定向补全，高质量收敛盲区；功能用例一键转接口自动化，一次投入、双向沉淀------让功能测试资产直接复用为自动化资产，避免重复建设。
5.1.1 一句话生成
输入「服务名 + 接口名」，AI 自动检索接口上下文、拉取真实样本并输出可编译的 TestNG 用例，实现从意图到代码的零门槛转化。
5.1.2 覆盖率报告驱动补全
上传覆盖率报告，智能定位未覆盖分支与路径，一键生成定向补测用例，让自动化建设有的放矢。
5.1.3 功能用例转接口自动化
将 XMind 功能用例脑图自动转换为项目内可直接运行的 Java + TestNG 代码，打通功能测试与接口自动化之间的资产壁垒。
5.1.4 提测联动：需求到脚本的闭环
通过与需求管理与提测流程打通，提测后可基于关联信息一键触发生成------将自动化建设前移至研发交付节点，缩短从提测到脚本就绪的等待时间。
传统接口自动化往往需要测试同学手动：
- 阅读提测单，确认改了哪些服务/接口
- 去流量回放、Kibana 查真实入参出参
- 对照项目风格手写 TestNG 代码
- 本地编译试跑、修断言
- 再去看覆盖率是否达标
提测联动机制（testplan-pipeline） 将上述步骤编排为一条流水线，通过.auto-testcase-work/ 临时工作区基于提测信息，自动拉取并分析业务改动Diff，借助CodeAtlas代码图谱能力快速定位溯源业务改动，Agent 会自动完成全流程，无需逐步手动介入。
注：CodeAtlas 代码图谱 是我们团队具备的另一项核心能力。它将 AST 静态扫描的严谨与 AI 分析的智能相结合，将代码结构具象化。依托图谱分析 " 按图索骥" ， 在海量代码中可精准评估影响范围及公共节点的波及程度，实现快速溯源与定位。
5.2 量化收益
5.2.1 编写提效：人力投入大幅压缩
自然语言触发、上下文自动补齐、协议约束保统一、一键生成压流程------编写环节的效率提升最为直观。
| 指标项 | 数据 | 说明 |
|---|---|---|
| 累计生成用例 | 5,648 条 | 2026 年上半年 |
| 综合采纳率 | 85%+ | 生成结果经门禁后可合入比例 |
| 单场景「编写 + 调试」耗时 | 10 min → 1 min（中位数） | 人力投入压缩 90%+ |
| 业务覆盖 | 多业务线 | 已形成规模化复用 |
编写提效是团队最先感知的变化：测试同学不必再反复写样板代码、跨系统查参，精力可转向风险判断与场景设计。
随着 Skill 协议在 Cursor、Qoder、HClaw 等多入口挂载，同一套交付标准正在不同工具间保持一致。
5.2.2 质量与覆盖：从「能执行」到「测得准、拦得住」
手工用例往往「数量多、覆盖浅」；自动化若只验主干、不测边界，价值也会打折。借助覆盖率报告驱动定向补全，配合分层断言策略，让用例不只跑得通，更能拦得住真实问题。
| 指标项 | 效果 |
|---|---|
| 核心接口 代码行 覆盖率 | 突破 80% |
| 代码行 覆盖率月均提升 | 12%+ |
| 自动化发现问题占比（同比） | 提升 45% |
覆盖率与断言深度同步提升：盲区持续收敛，核心回归场景可全面交由自动化承载；缺陷更早暴露，自动化在质量链路中的拦截作用显著增强。
六、结论：从脚本能跑到用例高质量交付
我们自动化了脚本的执行，却忽略了用例的产出。 然而真正的接口自动化，不应只是流水线上的最后一段路，而应该是从需求分析到用例交付的完整链路。
第一，补齐全链路，而非单纯追求速度
若设计、取数、编写等环节仍依赖人工，自动化将退化为繁重的维护工作。本方案旨在通过AI构建「生成 执行 回流 补全」的工程闭环：通过自然语言触发，在协议约束下实现自动取数与 AI 编码，产出高质量测试资产。
第二，确立交付标准，而非寄希望于 Prompt 的运气
AI生成虽快，但确保结构对齐、断言精准且能顺利编译才是核心门槛。通过将 Skill 约束前置，将不稳定的个体 Prompt 经验转化为可管理、可评审的团队协议，确保无论谁在操作，产出的均是标准化的专家级用例。
第三，效率、质量、覆盖度必须同步升级，拒绝单点优化
- 效率，是让人力从机械重复的编码与跨系统查参中解脱；
- 质量，是让断言深度与编译通过率拥有与「能跑通」同等的权重；
- 覆盖度，是让补测有量化报告支撑，而非凭经验盲目增加用例。
6.1 回到开篇：我们究竟在谈论什么？
我们在探讨的是如何将测试用例的稳定产出，提升至与脚本执行同等的工程化水准------使其可复用、可度量、可持续改进。
- 从 「AI 能不能写代码」转向「交付结果是否稳定」；
- 从 「依赖个人的 Prompt 经验」转向「依赖团队级的工程协议」；
- 从 「追求脚本数量的增加」转向「链路真正的闭环」。