1. 先聊聊为什么要把大模型塞进接口测试流程接口测试这件事我从手工写用例到搭框架自动化再到现在用大模型直接生成用例经历了好几个阶段。早些年做接口自动化最耗时间的并不是执行而是用例编写本身——一个稍微复杂的业务接口参数十几个正常场景、边界场景、异常场景加起来能写几十条用例写完之后还要人肉 review 一遍。这套流程熟练以后你会发现真正有价值的时间全耗在“把接口定义翻译成测试断言”这步机械劳动上。OpenClaw 自动化测试项目就是在这个背景下做的。整套思路不复杂用 OpenClaw 这个开源测试智能体框架把接口文档、参数约束、业务规则喂给 GLM-4.7-Flash让它自动产出覆盖正常和异常路径的测试用例再自动执行并把失败结果拉回来分析。GLM-4.7-Flash 在这里不是那种动不动就要烧钱的大参数模型而是偏向轻量、低延迟、支持结构化输出的版本特别适合这种“批量生成、量又大”的活儿。OpenClaw 负责的是整个编排链路解析接口定义、调度模型、校验生成结果、执行用例、汇总报告。这个项目适合谁参考第一种是做接口测试做到想吐、每天被重复用例淹没的测试开发第二种是后端团队想低成本补一批接口回归用例但没人手去写第三种是刚接触 AI 辅助测试、想找个能落地路径的人。如果你属于其中任何一类下面这套从环境搭建到跑通生成执行链路的完整记录应该能帮你省不少试错时间。2. 整体方案设计OpenClaw 和 GLM-4.7-Flash 各管哪一段2.1 系统架构与数据流向先讲整体链路再做选型分析。这套方案大概由六个模块组成数据流是单向串行加一个反馈闭环接口输入模块负责读取被测服务的接口定义。我这边主要支持 OpenAPI/Swagger 3.0 的 JSON/YAML 文件也支持手工填写的接口描述表毕竟很多老项目根本没有规范文档。用例生成模块把解析后的接口信息按模块切片配好 Prompt 模板调用 GLM-4.7-Flash 批量生成测试用例要求模型以 JSON 数组格式返回。用例校验模块这步特别关键。模型生成的用例不能直接信要拿原始接口定义去校验接口路径是否存在、必填参数是否齐全、字段类型是否匹配、期望状态码是否合理。执行引擎校验通过的用例转换成 pytest 的 parametrize 参数化用例通过 requests 会话去真实调用被测接口支持并发和失败重试。结果分析模块执行失败时把请求报文、响应报文、断言信息打包再让 GLM-4.7-Flash 做一轮快速归因区分是代码缺陷、数据问题、还是测试用例本身写错了。报告输出模块生成 JUnit XML 和 HTML 报告方便接入 CI。数据流向很简单接口文档进测试报告出。中间任何一步产生的异常用例都会被标记出来不会往下游传脏数据。2.2 为什么选 GLM-4.7-Flash 干这个活模型选型是这个项目里我最纠结的一件事。最开始试过更大参数的模型生成的用例质量确实高但一次跑几百个接口在上下文长度、响应速度、成本三个维度上都不划算。后来换到 GLM-4.7-Flash主要原因有三个第一是结构化输出能力。接口测试用例本质上就是一堆 JSON模型只要把字段写错一点点后面就没法跑。GLM-4.7-Flash 支持 JSON 模式响应我在请求里指定 response_format 为 JSON 对象模型就会老老实实返回纯 JSON不会再出现“好的下面是您需要的用例”这种混在结果里的废话。第二是速度和吞吐。用例生成是批量任务几十个接口切片并行调用模型的响应速度直接决定整个流程的耗时。实测下来单次生成十几条用例的接口级调用基本在几秒内返回这个体感完全能接受。第三是成本。接口测试用例生成是持续要做的活每轮回归都重新生成一遍成本就兜不住了。GLM-4.7-Flash 的单价定位本身就很亲民就算每天全量跑几轮费用完全可控。当然选择模型这件事没有绝对标准如果你面对的是嵌套极深的复杂接口需要更强推理能力时再往上调到更大参数的版本多一个适配层就行。2.3 OpenClaw 在链路里到底解决了什么问题OpenClaw 这个名字很多人第一反应是“又一个 AI 框架”。其实它对测试这个场景的价值很实在如果你不用它就得自己写一套胶水代码把模型调用、格式校验、用例转换、执行、重试、报告全部串起来。这些活单独看都不难但串起来之后全是琐碎的状态管理——比如某个模型调用超时了要自动重试生成结果里混入了非法 JSON 要重新修复并发执行时线程安全怎么保证。OpenClaw 把这些能力以插件和管线的方式提供出来。我只需要声明好管线节点定义好每个节点的输入输出协议框架就能把整条链跑起来。它内置的任务调度机制、可插拔的模型后端适配器、以及失败时的回退策略省了我大量基础设施层面的编码工作。我实测下来的体会是OpenClaw 不是那种“装上就自动全包”的产品它的核心价值是把链路标准化让你把精力放在调 Prompt、调校验规则、调断言策略这些真正影响用例质量的事情上。3. 环境搭建与基础配置从零到能跑通首条链路3.1 安装 OpenClaw 与依赖组件先说环境。我的本地开发环境是 Ubuntu 22.04 Python 3.10Windows 上我也试过流程基本一致只有个别命令写法不同。安装这块没有什么黑魔法直接走 pippip install openclaw pytest requests allure-pytest pydantic如果你要把 OpenAPI 文件转成内部结构可以再加一个 openapi-spec-validator用来做接口定义的合法性校验。我在项目里用 Pydantic 定义了两层模型一层是解析后的接口定义结构另一层是模型生成的测试用例结构。这两层结构越严格后面校验模型输出的时候报错就越精准。装完之后初始化一个工作目录建议目录结构按职责分开openclaw_test/ ├── config/ │ └── model_config.yaml # 模型连接配置 ├── specs/ # 接口定义文件 ├── prompts/ # Prompt 模板 ├── cases/ # 生成的用例 JSON(落盘存档) ├── tests/ # 转换后的 pytest 用例 ├── reports/ # 执行报告 └── openclaw_pipeline.py # 管线主入口3.2 配置 GLM-4.7-Flash 模型接入OpenClaw 的模型接入是插件式设计只需要在配置里声明一个后端适配器。我的 model_config.yaml 大致长这样model: backend: glm model_name: glm-4.7-flash api_base: https://your-model-endpoint/v1 # 换成实际接入地址 api_key_env: GLM_API_KEY temperature: 0.2 max_tokens: 4000 json_mode: true这里有两个参数我必须强调。第一个是 temperature我建议固定到 0.2 甚至更低。用例生成是确定性任务不是创意写作温度太高会导致同一个接口两次生成的用例差异很大给后续回归带来噪音。第二个是 json_mode务必打开它会让模型从协议层面返回合法 JSON这是后面所有解析逻辑能成立的前提。接入完成后先跑一个最简单的冒烟调用让模型返回一个固定的 JSON 结构确认密钥、地址、超时配置都没问题。这一步不要跳过很多后续报错其实都是模型接入没对上。3.3 被测接口准备与 Mock 方案要验证整条链路你需要一个被测对象。内部环境里有现成系统最好要是没有我建议用 FastAPI 快速搭一个包含典型业务接口的 Mock 服务。我的 Mock 里放了三类接口用户信息类 GET 请求、订单创建类 POST 请求、以及一个带鉴权头的查询接口。三类接口分别覆盖了路径参数、查询参数、请求体参数、Header 参数这几种常见场景。搭建成本很低一个 main.py 几十行代码的事但它能帮你把链路里的每一种参数传递方式都覆盖到非常值。4. 核心实现接口定义到用例生成的关键细节4.1 接口信息的结构化处理模型要看懂接口前提是接口信息得结构化地喂进去。直接丢一大段 YAML 给模型不是不行但效果不稳定。我先把 OpenAPI 文件解析成统一的接口描述结构每个接口包含接口名称、HTTP 方法、完整路径、参数列表每个参数的名、类型、是否必填、默认值、枚举范围、请求体结构、响应结构概要。这一步用什么工具不重要重要的是输出格式要固定。我最后把它序列化成紧凑的 JSON作为 Prompt 的主要内容。对没有 OpenAPI 文件的老接口我也做了一版手工描述模板字段基本一致只是由人工填写。实际经验是只要结构统一模型生成质量就没有明显差别差别主要取决于描述里提供了多少信息量。4.2 Prompt 工程设计让模型稳定产出测试用例Prompt 是整个生成环节的灵魂。我试过几个版本踩过不少坑最后沉淀出这样一套 Prompt 分层结构系统提示词固定框架说明角色是资深测试工程师任务是根据接口定义生成可直接执行的接口测试用例所有输出必须是 JSON 数组格式并且给出输出字段的完整 schema 定义。用户提示词按批次填充包含本次要处理的一个或多个接口描述以及明确的用例要求——每个接口至少包含正常场景、必填参数缺失、参数类型错误、边界值、非法枚举值这几类用例同时要求期望状态码必须符合 REST 风格。我举个生成用例 JSON 的 schema 简版{ cases: [ { case_id: C001, name: 获取用户信息-正常场景, method: GET, path: /users/{user_id}, headers: {Authorization: Bearer test_token}, path_params: {user_id: 10001}, query_params: {}, body: null, expected_status: 200, assertions: [ {type: jsonpath, expression: $.code, value: 0}, {type: response_time, value: 500} ] } ] }特别注意一点不要在 Prompt 里塞“请尽量生成高质量用例”这种模糊要求。模型对模糊指令的响应方差很大你给它越明确的约束和枚举清单它输出的用例就越规范。我还在 Prompt 里固定了几个 few-shot 示例每个示例对应一种参数类型错误用例的写法模型跟着示例走格式一致性提升非常明显。4.3 校验与修复不能百分百信任模型输出模型生成的用例必须过三道校验缺一道后面执行阶段都会爆炸。第一道是 JSON 结构校验。用 Pydantic 模型去反序列化模型返回内容任何字段缺失或类型错误都会在这一步被捕获。遇到解析失败我的策略是自动重试一次并在 Prompt 里附上“上次输出格式不符合要求请严格按 schema 输出”的提示。实测重试一次的成功率能提升到九成以上。第二道是接口匹配校验。逐个检查用例里的 method、path 是否真实存在于被测接口集合里。这一道专门防模型“编造接口”——模型确实会在上下文模糊时脑补出类似的路径这种用例直接丢弃不能手软。第三道是业务合理性校验。这一道比较轻量检查期望状态码与请求方式是否矛盾比如 GET 请求期望 500 这种。严格来说状态码是允许有业务特例的所以这里只做强冲突拦截不做过度限制。校验通过的用例统一落盘到 cases 目录。落盘很有必要方便追溯这轮用例是哪次生成的、基于哪个接口版本。4.4 断言策略不是状态码对了就完事生成用例时模型默认只断言状态码。但这在真实业务里不够用很多接口状态码 200返回体里的业务码却是失败的。我在断言生成策略里分了三个层级让模型按场景选择基础断言状态码是否符合预期。响应体断言对 JSON 响应里的关键字段做存在性、类型、取值校验用 JSONPath 表达式定位字段。业务规则断言针对特定接口写业务逻辑校验例如创建订单接口成功之后订单号必须以特定前缀开头、金额字段不能为负数。对第二、三层断言我在 Prompt 里提供了枚举的断言模板类型模型只需要填表达式和期望值不需要自己发明断言格式。执行引擎再做一次白名单解析碰到模板匹配不了的断言风格就直接忽略并告警。5. 用例执行与结果回写让生成的东西真正跑起来5.1 执行引擎设计与并发控制用例生成完执行阶段我用了两条路。调试期用单线程按序执行把所有输出完整打印出来方便观察。稳定之后切到并发模式用线程池控制并行度。OpenClaw 的执行插件会在运行前把 cases 目录里的 JSON 转换成 pytest 的参数化用例。每个用例对应一个测试函数所有用例共用同一个 requests.Session但每个用例独立构造请求参数。这个转换动作本身很机械真正值得关注的是并发数。我自己的经验是并发数不要拍脑袋填要观察被测服务的承受能力。本地 Mock 服务我开到 20 并发没问题线上环境我会保守地压到 5 以内并且加上每秒请求数的限制避免把被测系统打挂。5.2 重试机制与结果归因接口执行失败的原因千差万别但我把它们粗分为三类瞬时类失败网络抖动、连接超时、服务端偶发 5xx。数据类失败测试数据被前面用例污染、依赖的数据状态不对。真缺陷类失败被测接口确实有 bug。OpenClaw 的重试插件支持按状态码和异常类型配置重试策略。我只对超时和连接类异常做自动重试重试次数设 2 次重试间隔按指数退避500 这种业务侧状态码一律不重试直接进入归因流程。这个设计很关键否则一个真实的 500 缺陷会因为盲目重试浪费时间甚至把日志刷得没法看。结果归因我让 GLM-4.7-Flash 来做输入是请求参数、响应内容、断言结果输出是失败原因分类和建议动作。这部分的 Prompt 我又单独设计了一套核心要求是“只基于给出的报文分析不要脑补接口逻辑”并且要求输出固定枚举值。跑了一个多月归因准确率在多数场景下够用来辅助筛单真正疑难的问题还是得人工介入。5.3 测试报告与 CI 集成执行完的报告我接了 Allure。pytest 夹具里给每个用例附加了接口路径、用例类型、错误信息等标签Allure 报告里可以按接口模块筛选失败用例能直接看到请求和响应报文。接入 CI 的方式也很常规在流水线里增加一个阶段先启动被测服务再执行 openclaw_pipeline.py跑完以后上传报告产物并设置失败阈值。对于回归测试我设置了失败率超过 5% 就阻断后续发布流程防止质量下滑被静默吞掉。6. 常见问题与排查技巧实录问题现象可能原因解决办法模型返回内容解析失败未启用 JSON 模式或温度过高打开 json_mode温度降到 0.2 以下生成的接口路径不存在模型脑补接口用接口定义集合做路径白名单校验直接过滤断言对字段值要求过严模型不理解字段动态特性断言改为类型和格式校验具体值只在枚举场景使用并发执行压垮被测服务并发数设置过大压到 5 以内并加请求速率限制重复执行时后置接口依赖前序数据用例间数据耦合生成时给关键字段加时间戳或随机后缀模型生成用例里混入无关说明文字指令不够强或未启用结构化输出增强系统提示词的强制 JSON 约束这里重点展开说两个我踩得最深的坑。第一个是“用例间数据耦合”。一开始生成订单接口用例时用例里写死的用户 ID 是同一个导致第一条用例创建完数据后第二条查询用例拿到的状态已经变了。这类问题非常隐蔽因为单条用例单独跑全对整套回归跑就挂。解决办法是让模型给创建类接口的参数值加上唯一标识后缀同时执行引擎对依赖前序数据的用例做标注安排它们在串行模式下按顺序执行。第二个是“断言过度拟合”。模型特别喜欢对响应里的具体数值做断言比如某个列表返回 3 条数据就断言长度等于 3。可实际运行环境里数据量一变用例立刻变红。我在校验阶段加了一个规则凡是响应体的数组长度、时间戳、ID 这类容易变动的字段禁止生成精确值断言只允许断言类型或非空。这个规则实现起来就是一次字符串模式匹配但是它在提升用例可靠性的贡献非常大。再补充一点经验生成阶段不要一次性把所有接口全部塞进一个 Prompt。模型在上下文长度达到一定阈值后后面接口的生成质量会肉眼可见地下降。我是按照业务模块切片每批不超过 30 个接口并且每个接口的描述信息尽量精简只保留生成用例必要的信息。这个调整做完之后高价值用例的生成成功率提升了一截。7. 实测效果与后续玩法这套链路在模拟项目 X 的接口集上跑了一轮完整对比。被测服务一共 24 个接口我手工花了大概一个工作日写了约 200 条基础用例用 OpenClaw 加 GLM-4.7-Flash 自动生成全程耗时不到 20 分钟生成用例 350 多条去重和过滤之后有效用例 280 条左右。覆盖维度上自动生成在参数边界和异常场景上明显更全手工用例则在业务规则断言的深度上好一些。我的结论是两者不是替代关系而是互补关系——模型负责广度和速度人负责深度和业务判断。后续我有三个想继续扩展的方向。第一是把这套生成链路接到线上接口变更事件上接口定义一旦有改动自动对比生成增量用例。第二是把普通接口用例泛化到消息队列的协议测试上目前很多系统的核心逻辑不在 HTTP 层而在异步消息链路里这部分用同样的思路理论上也能打通。第三是积累一批经过线上验证的高质量用例样本反哺到 Prompt 的 few-shot 示例里让模型越生成越贴合自己系统的风格。最后分享一个我个人的经验这类项目的成败很多时候不取决于模型的聪明程度而取决于你对输出结果的控制力度。模型给的是原料校验规则、断言策略、执行策略这些工程部分才是保质量的防线。把这道防线扎牢了换什么模型都只是换一个生成源而已。 
长河君 · 2026/10/20 8:42:23 · 阅读 1.2k OpenClaw+GLM-4.7-Flash：接口测试用例自动生成实战
1. 先聊聊为什么要把大模型塞进接口测试流程接口测试这件事我从手工写用例到搭框架自动化再到现在用大模型直接生成用例经历了好几个阶段。早些年做接口自动化最耗时间的并不是执行而是用例编写本身——一个稍微复杂的业务接口参数十几个正常场景、边界场景、异常场景加起来能写几十条用例写完之后还要人肉 review 一遍。这套流程熟练以后你会发现真正有价值的时间全耗在“把接口定义翻译成测试断言”这步机械劳动上。OpenClaw 自动化测试项目就是在这个背景下做的。整套思路不复杂用 OpenClaw 这个开源测试智能体框架把接口文档、参数约束、业务规则喂给 GLM-4.7-Flash让它自动产出覆盖正常和异常路径的测试用例再自动执行并把失败结果拉回来分析。GLM-4.7-Flash 在这里不是那种动不动就要烧钱的大参数模型而是偏向轻量、低延迟、支持结构化输出的版本特别适合这种“批量生成、量又大”的活儿。OpenClaw 负责的是整个编排链路解析接口定义、调度模型、校验生成结果、执行用例、汇总报告。这个项目适合谁参考第一种是做接口测试做到想吐、每天被重复用例淹没的测试开发第二种是后端团队想低成本补一批接口回归用例但没人手去写第三种是刚接触 AI 辅助测试、想找个能落地路径的人。如果你属于其中任何一类下面这套从环境搭建到跑通生成执行链路的完整记录应该能帮你省不少试错时间。2. 整体方案设计OpenClaw 和 GLM-4.7-Flash 各管哪一段2.1 系统架构与数据流向先讲整体链路再做选型分析。这套方案大概由六个模块组成数据流是单向串行加一个反馈闭环接口输入模块负责读取被测服务的接口定义。我这边主要支持 OpenAPI/Swagger 3.0 的 JSON/YAML 文件也支持手工填写的接口描述表毕竟很多老项目根本没有规范文档。用例生成模块把解析后的接口信息按模块切片配好 Prompt 模板调用 GLM-4.7-Flash 批量生成测试用例要求模型以 JSON 数组格式返回。用例校验模块这步特别关键。模型生成的用例不能直接信要拿原始接口定义去校验接口路径是否存在、必填参数是否齐全、字段类型是否匹配、期望状态码是否合理。执行引擎校验通过的用例转换成 pytest 的 parametrize 参数化用例通过 requests 会话去真实调用被测接口支持并发和失败重试。结果分析模块执行失败时把请求报文、响应报文、断言信息打包再让 GLM-4.7-Flash 做一轮快速归因区分是代码缺陷、数据问题、还是测试用例本身写错了。报告输出模块生成 JUnit XML 和 HTML 报告方便接入 CI。数据流向很简单接口文档进测试报告出。中间任何一步产生的异常用例都会被标记出来不会往下游传脏数据。2.2 为什么选 GLM-4.7-Flash 干这个活模型选型是这个项目里我最纠结的一件事。最开始试过更大参数的模型生成的用例质量确实高但一次跑几百个接口在上下文长度、响应速度、成本三个维度上都不划算。后来换到 GLM-4.7-Flash主要原因有三个第一是结构化输出能力。接口测试用例本质上就是一堆 JSON模型只要把字段写错一点点后面就没法跑。GLM-4.7-Flash 支持 JSON 模式响应我在请求里指定 response_format 为 JSON 对象模型就会老老实实返回纯 JSON不会再出现“好的下面是您需要的用例”这种混在结果里的废话。第二是速度和吞吐。用例生成是批量任务几十个接口切片并行调用模型的响应速度直接决定整个流程的耗时。实测下来单次生成十几条用例的接口级调用基本在几秒内返回这个体感完全能接受。第三是成本。接口测试用例生成是持续要做的活每轮回归都重新生成一遍成本就兜不住了。GLM-4.7-Flash 的单价定位本身就很亲民就算每天全量跑几轮费用完全可控。当然选择模型这件事没有绝对标准如果你面对的是嵌套极深的复杂接口需要更强推理能力时再往上调到更大参数的版本多一个适配层就行。2.3 OpenClaw 在链路里到底解决了什么问题OpenClaw 这个名字很多人第一反应是“又一个 AI 框架”。其实它对测试这个场景的价值很实在如果你不用它就得自己写一套胶水代码把模型调用、格式校验、用例转换、执行、重试、报告全部串起来。这些活单独看都不难但串起来之后全是琐碎的状态管理——比如某个模型调用超时了要自动重试生成结果里混入了非法 JSON 要重新修复并发执行时线程安全怎么保证。OpenClaw 把这些能力以插件和管线的方式提供出来。我只需要声明好管线节点定义好每个节点的输入输出协议框架就能把整条链跑起来。它内置的任务调度机制、可插拔的模型后端适配器、以及失败时的回退策略省了我大量基础设施层面的编码工作。我实测下来的体会是OpenClaw 不是那种“装上就自动全包”的产品它的核心价值是把链路标准化让你把精力放在调 Prompt、调校验规则、调断言策略这些真正影响用例质量的事情上。3. 环境搭建与基础配置从零到能跑通首条链路3.1 安装 OpenClaw 与依赖组件先说环境。我的本地开发环境是 Ubuntu 22.04 Python 3.10Windows 上我也试过流程基本一致只有个别命令写法不同。安装这块没有什么黑魔法直接走 pippip install openclaw pytest requests allure-pytest pydantic如果你要把 OpenAPI 文件转成内部结构可以再加一个 openapi-spec-validator用来做接口定义的合法性校验。我在项目里用 Pydantic 定义了两层模型一层是解析后的接口定义结构另一层是模型生成的测试用例结构。这两层结构越严格后面校验模型输出的时候报错就越精准。装完之后初始化一个工作目录建议目录结构按职责分开openclaw_test/ ├── config/ │ └── model_config.yaml # 模型连接配置 ├── specs/ # 接口定义文件 ├── prompts/ # Prompt 模板 ├── cases/ # 生成的用例 JSON(落盘存档) ├── tests/ # 转换后的 pytest 用例 ├── reports/ # 执行报告 └── openclaw_pipeline.py # 管线主入口3.2 配置 GLM-4.7-Flash 模型接入OpenClaw 的模型接入是插件式设计只需要在配置里声明一个后端适配器。我的 model_config.yaml 大致长这样model: backend: glm model_name: glm-4.7-flash api_base: https://your-model-endpoint/v1 # 换成实际接入地址 api_key_env: GLM_API_KEY temperature: 0.2 max_tokens: 4000 json_mode: true这里有两个参数我必须强调。第一个是 temperature我建议固定到 0.2 甚至更低。用例生成是确定性任务不是创意写作温度太高会导致同一个接口两次生成的用例差异很大给后续回归带来噪音。第二个是 json_mode务必打开它会让模型从协议层面返回合法 JSON这是后面所有解析逻辑能成立的前提。接入完成后先跑一个最简单的冒烟调用让模型返回一个固定的 JSON 结构确认密钥、地址、超时配置都没问题。这一步不要跳过很多后续报错其实都是模型接入没对上。3.3 被测接口准备与 Mock 方案要验证整条链路你需要一个被测对象。内部环境里有现成系统最好要是没有我建议用 FastAPI 快速搭一个包含典型业务接口的 Mock 服务。我的 Mock 里放了三类接口用户信息类 GET 请求、订单创建类 POST 请求、以及一个带鉴权头的查询接口。三类接口分别覆盖了路径参数、查询参数、请求体参数、Header 参数这几种常见场景。搭建成本很低一个 main.py 几十行代码的事但它能帮你把链路里的每一种参数传递方式都覆盖到非常值。4. 核心实现接口定义到用例生成的关键细节4.1 接口信息的结构化处理模型要看懂接口前提是接口信息得结构化地喂进去。直接丢一大段 YAML 给模型不是不行但效果不稳定。我先把 OpenAPI 文件解析成统一的接口描述结构每个接口包含接口名称、HTTP 方法、完整路径、参数列表每个参数的名、类型、是否必填、默认值、枚举范围、请求体结构、响应结构概要。这一步用什么工具不重要重要的是输出格式要固定。我最后把它序列化成紧凑的 JSON作为 Prompt 的主要内容。对没有 OpenAPI 文件的老接口我也做了一版手工描述模板字段基本一致只是由人工填写。实际经验是只要结构统一模型生成质量就没有明显差别差别主要取决于描述里提供了多少信息量。4.2 Prompt 工程设计让模型稳定产出测试用例Prompt 是整个生成环节的灵魂。我试过几个版本踩过不少坑最后沉淀出这样一套 Prompt 分层结构系统提示词固定框架说明角色是资深测试工程师任务是根据接口定义生成可直接执行的接口测试用例所有输出必须是 JSON 数组格式并且给出输出字段的完整 schema 定义。用户提示词按批次填充包含本次要处理的一个或多个接口描述以及明确的用例要求——每个接口至少包含正常场景、必填参数缺失、参数类型错误、边界值、非法枚举值这几类用例同时要求期望状态码必须符合 REST 风格。我举个生成用例 JSON 的 schema 简版{ cases: [ { case_id: C001, name: 获取用户信息-正常场景, method: GET, path: /users/{user_id}, headers: {Authorization: Bearer test_token}, path_params: {user_id: 10001}, query_params: {}, body: null, expected_status: 200, assertions: [ {type: jsonpath, expression: $.code, value: 0}, {type: response_time, value: 500} ] } ] }特别注意一点不要在 Prompt 里塞“请尽量生成高质量用例”这种模糊要求。模型对模糊指令的响应方差很大你给它越明确的约束和枚举清单它输出的用例就越规范。我还在 Prompt 里固定了几个 few-shot 示例每个示例对应一种参数类型错误用例的写法模型跟着示例走格式一致性提升非常明显。4.3 校验与修复不能百分百信任模型输出模型生成的用例必须过三道校验缺一道后面执行阶段都会爆炸。第一道是 JSON 结构校验。用 Pydantic 模型去反序列化模型返回内容任何字段缺失或类型错误都会在这一步被捕获。遇到解析失败我的策略是自动重试一次并在 Prompt 里附上“上次输出格式不符合要求请严格按 schema 输出”的提示。实测重试一次的成功率能提升到九成以上。第二道是接口匹配校验。逐个检查用例里的 method、path 是否真实存在于被测接口集合里。这一道专门防模型“编造接口”——模型确实会在上下文模糊时脑补出类似的路径这种用例直接丢弃不能手软。第三道是业务合理性校验。这一道比较轻量检查期望状态码与请求方式是否矛盾比如 GET 请求期望 500 这种。严格来说状态码是允许有业务特例的所以这里只做强冲突拦截不做过度限制。校验通过的用例统一落盘到 cases 目录。落盘很有必要方便追溯这轮用例是哪次生成的、基于哪个接口版本。4.4 断言策略不是状态码对了就完事生成用例时模型默认只断言状态码。但这在真实业务里不够用很多接口状态码 200返回体里的业务码却是失败的。我在断言生成策略里分了三个层级让模型按场景选择基础断言状态码是否符合预期。响应体断言对 JSON 响应里的关键字段做存在性、类型、取值校验用 JSONPath 表达式定位字段。业务规则断言针对特定接口写业务逻辑校验例如创建订单接口成功之后订单号必须以特定前缀开头、金额字段不能为负数。对第二、三层断言我在 Prompt 里提供了枚举的断言模板类型模型只需要填表达式和期望值不需要自己发明断言格式。执行引擎再做一次白名单解析碰到模板匹配不了的断言风格就直接忽略并告警。5. 用例执行与结果回写让生成的东西真正跑起来5.1 执行引擎设计与并发控制用例生成完执行阶段我用了两条路。调试期用单线程按序执行把所有输出完整打印出来方便观察。稳定之后切到并发模式用线程池控制并行度。OpenClaw 的执行插件会在运行前把 cases 目录里的 JSON 转换成 pytest 的参数化用例。每个用例对应一个测试函数所有用例共用同一个 requests.Session但每个用例独立构造请求参数。这个转换动作本身很机械真正值得关注的是并发数。我自己的经验是并发数不要拍脑袋填要观察被测服务的承受能力。本地 Mock 服务我开到 20 并发没问题线上环境我会保守地压到 5 以内并且加上每秒请求数的限制避免把被测系统打挂。5.2 重试机制与结果归因接口执行失败的原因千差万别但我把它们粗分为三类瞬时类失败网络抖动、连接超时、服务端偶发 5xx。数据类失败测试数据被前面用例污染、依赖的数据状态不对。真缺陷类失败被测接口确实有 bug。OpenClaw 的重试插件支持按状态码和异常类型配置重试策略。我只对超时和连接类异常做自动重试重试次数设 2 次重试间隔按指数退避500 这种业务侧状态码一律不重试直接进入归因流程。这个设计很关键否则一个真实的 500 缺陷会因为盲目重试浪费时间甚至把日志刷得没法看。结果归因我让 GLM-4.7-Flash 来做输入是请求参数、响应内容、断言结果输出是失败原因分类和建议动作。这部分的 Prompt 我又单独设计了一套核心要求是“只基于给出的报文分析不要脑补接口逻辑”并且要求输出固定枚举值。跑了一个多月归因准确率在多数场景下够用来辅助筛单真正疑难的问题还是得人工介入。5.3 测试报告与 CI 集成执行完的报告我接了 Allure。pytest 夹具里给每个用例附加了接口路径、用例类型、错误信息等标签Allure 报告里可以按接口模块筛选失败用例能直接看到请求和响应报文。接入 CI 的方式也很常规在流水线里增加一个阶段先启动被测服务再执行 openclaw_pipeline.py跑完以后上传报告产物并设置失败阈值。对于回归测试我设置了失败率超过 5% 就阻断后续发布流程防止质量下滑被静默吞掉。6. 常见问题与排查技巧实录问题现象可能原因解决办法模型返回内容解析失败未启用 JSON 模式或温度过高打开 json_mode温度降到 0.2 以下生成的接口路径不存在模型脑补接口用接口定义集合做路径白名单校验直接过滤断言对字段值要求过严模型不理解字段动态特性断言改为类型和格式校验具体值只在枚举场景使用并发执行压垮被测服务并发数设置过大压到 5 以内并加请求速率限制重复执行时后置接口依赖前序数据用例间数据耦合生成时给关键字段加时间戳或随机后缀模型生成用例里混入无关说明文字指令不够强或未启用结构化输出增强系统提示词的强制 JSON 约束这里重点展开说两个我踩得最深的坑。第一个是“用例间数据耦合”。一开始生成订单接口用例时用例里写死的用户 ID 是同一个导致第一条用例创建完数据后第二条查询用例拿到的状态已经变了。这类问题非常隐蔽因为单条用例单独跑全对整套回归跑就挂。解决办法是让模型给创建类接口的参数值加上唯一标识后缀同时执行引擎对依赖前序数据的用例做标注安排它们在串行模式下按顺序执行。第二个是“断言过度拟合”。模型特别喜欢对响应里的具体数值做断言比如某个列表返回 3 条数据就断言长度等于 3。可实际运行环境里数据量一变用例立刻变红。我在校验阶段加了一个规则凡是响应体的数组长度、时间戳、ID 这类容易变动的字段禁止生成精确值断言只允许断言类型或非空。这个规则实现起来就是一次字符串模式匹配但是它在提升用例可靠性的贡献非常大。再补充一点经验生成阶段不要一次性把所有接口全部塞进一个 Prompt。模型在上下文长度达到一定阈值后后面接口的生成质量会肉眼可见地下降。我是按照业务模块切片每批不超过 30 个接口并且每个接口的描述信息尽量精简只保留生成用例必要的信息。这个调整做完之后高价值用例的生成成功率提升了一截。7. 实测效果与后续玩法这套链路在模拟项目 X 的接口集上跑了一轮完整对比。被测服务一共 24 个接口我手工花了大概一个工作日写了约 200 条基础用例用 OpenClaw 加 GLM-4.7-Flash 自动生成全程耗时不到 20 分钟生成用例 350 多条去重和过滤之后有效用例 280 条左右。覆盖维度上自动生成在参数边界和异常场景上明显更全手工用例则在业务规则断言的深度上好一些。我的结论是两者不是替代关系而是互补关系——模型负责广度和速度人负责深度和业务判断。后续我有三个想继续扩展的方向。第一是把这套生成链路接到线上接口变更事件上接口定义一旦有改动自动对比生成增量用例。第二是把普通接口用例泛化到消息队列的协议测试上目前很多系统的核心逻辑不在 HTTP 层而在异步消息链路里这部分用同样的思路理论上也能打通。第三是积累一批经过线上验证的高质量用例样本反哺到 Prompt 的 few-shot 示例里让模型越生成越贴合自己系统的风格。最后分享一个我个人的经验这类项目的成败很多时候不取决于模型的聪明程度而取决于你对输出结果的控制力度。模型给的是原料校验规则、断言策略、执行策略这些工程部分才是保质量的防线。把这道防线扎牢了换什么模型都只是换一个生成源而已。