← 返回 PaperDaily 视觉与图像

复旦+字节跳动ISSTA'26：一招让LLM学会API测试常识

API测试最头疼的“冷启动”问题——没有OpenAPI规范、没有历史日志，只有一个请求样本，能自动写出靠谱断言吗？Restor告诉你，用强化学习（GRPO）微调一个轻量LLM，这事儿能成，而且字节跳动已经在生产环境跑起来了，采纳率直接干到96%以上。一篇来自复旦和字节跳动的ISSTA'26工作，实打实的工业级神器。

龙哥读论文发布于 2026-09-05 00:31:11 阅读 4 查看原文

#强化学习 #大语言模型 #AI应用

原论文信息如下：

论文标题:
RESTOR: Automated Test Oracle Generation for RESTful APIs via Reinforcement Learning

发表日期:
2026年7月

发表单位:
复旦大学 & 字节跳动

原文链接:
https://arxiv.org/pdf/2607.23963v1.pdf

冷启动下的API测试困境：无规范、无日志，如何写断言？

在软件工程的世界里，微服务和RESTful API（表述性状态传递应用程序接口）早已是架构设计的核心。然而，一个让无数QA（质量保证）工程师头疼的“冷启动”问题始终存在：当一个全新的API接口上线，既没有一份靠谱的OpenAPI规范文档，也还没有积累下海量的历史请求日志，甚至连服务端的代码都像“黑盒”一样不可见时，测试用例中的断言该从何写起？

传统的测试工具大多依赖规则模板或历史统计数据。没有规范，它们就“瞎了”；没有日志，它们就“哑了”。在字节跳动这样的公司，每天有成百上千的API在迭代，这个问题尤为突出。工程师们常常只能靠自己的“常识”和领域知识，对着一次手动冒烟测试抓下来的单个请求-响应样本，手动编写断言逻辑,比如检查`subscribe_type`字段的值是否属于["auto", "un-auto"]这个枚举集。这种工作不仅枯燥、耗时，而且效率极其低下。

你可能觉得，现在大语言模型（LLM）这么火，让它来写不就行了？确实，让LLM来生成测试代码已经是一个热门方向。但问题在于，大型通用模型（比如DeepSeek-V3）部署成本高、推理延迟大，在每天执行成千上万次测试的CI/CD（持续集成/持续部署）流水线里根本跑不动。而小一点的通用模型，又缺乏足够的“测试常识”，容易产生幻觉或者写出太脆弱、动不动就失败的“flaky”（不稳定）测试。

这就陷入了一个两难：要么用大模型，但成本和速度都扛不住；要么用小模型，但智商又跟不上。有没有一种平衡的解决方案？

答案就在《RESTOR: Automated Test Oracle Generation for RESTful APIs via Reinforcement Learning》这篇论文中。来自复旦大学和字节跳动的研究团队，提出了一种名为Restor的框架，它利用强化学习（RL）来微调一个轻量级的LLM，让这个小模型硬生生学会了测试专家才具备的“常识”，从而能够仅凭一个请求-响应样本，就生成高质量、可执行的测试断言。

单样本也能生成高质量测试预言：Restor的核心思路

Restor的核心理念非常直观：既然无法依赖外部规范或历史日志，那就让模型从“一次成功的交互”中学习并泛化。为了讲清楚具体怎么做，龙哥还是先放一下论文中的整体框架图，让大家有个直观的印象。

图2：Restor框架概览。工作流程包括两个主要阶段：（1）数据集构建（上半部分）和（2）模型训练（下半部分）。

Restor的整个框架分为两个紧密协作的阶段：

第一阶段：数据集构建（Dataset Construction）这是训练的基础，也是最体现工程智慧的地方。团队面临一个核心难题：强化学习需要“奖励信号”来告诉模型生成的断言是好是坏。但在测试预言生成这个任务中，我们并没有一个唯一的、标准答案（ground truth），因为同一个语义约束可以用不同的代码行来表达。为了解决这个问题，Restor设计了一套巧妙的数据增强流程。

首先，由字节跳动的专业QA工程师，从真实的服务器响应中人工标注出“关键字段”（Key Fields），比如`errmsg`（错误消息）、`product_id`（产品ID）、`begin_time`（开始时间）等。这些字段承载着核心的业务逻辑。标注过程本身也遵循一套标准化的流程：工程师会先查看API的请求参数和响应结构，然后结合业务文档和自己的领域知识，标记出那些在测试中必须被验证的字段。例如，在一个支付相关的API中，`amount`（金额）、`status`（状态）、`transaction_id`（交易ID）通常都会被标记为关键字段，而像`server_timestamp`（服务器时间戳）或`request_id`（请求ID）这类动态生成、与业务逻辑无关的字段则会被排除在外。

然后，针对每一个关键字段，专家们推测出它的语义约束。例如，对于`begin_time`字段，其约束是“应该是一个非负的Unix时间戳”。基于这个约束，系统会自动构造出两种样本：

正样本（Spos）：将原始响应中的值替换成另一个同样符合约束的值。例如，把时间戳`1750832254`改成`1750832255`。这能防止生成的断言“死记硬背”住原始样本的值。更具体地说，正样本的构造策略是多样化的：对于数值型字段，会在合法范围内随机选取一个不同的值；对于枚举型字段，会从合法的枚举集合中随机选取另一个值；对于字符串型字段，如果约束是“非空字符串”，则会替换成另一个非空字符串。这种多样性确保了模型不会简单地记住原始值，而是真正理解字段的合法取值范围。

负样本（Sneg）：故意构造违反约束的异常值。例如，在字段中注入`-1`（非法时间戳）或者字符串`"true"`（对布尔字段）。这能确保断言具有足够的敏感性，可以检测出数据异常。负样本的构造同样经过精心设计：对于数值型字段，会尝试边界值（如`0`、`-1`、`999999999`）以及类型错误的值（如字符串`"abc"`）；对于枚举型字段，会使用一个完全不在枚举集合中的值（如`"invalid_value"`）；对于布尔型字段，会尝试字符串`"true"`或整数`1`。这种系统化的负样本构造策略，使得模型能够学习到各种可能的异常模式。

通过这种方式，Restor创建了一个可以自动评估断言质量的“校验场”。这个校验场本质上是一个自动化的测试环境：给定一个断言，它会自动在原始响应、所有正样本和所有负样本上执行该断言，并记录执行结果。如果断言在原始响应上执行失败（例如语法错误或访问了不存在的键），则直接判负；如果断言在正样本上失败（即误报），或者在负样本上通过（即漏检），都会降低奖励分数。只有那些在原始响应上成功执行、在所有正样本上通过、并且在所有负样本上失败的断言，才能获得最高的奖励分数。

第二阶段：模型训练（Model Training）有了这个“校验场”，Restor就可以开始训练它的“大脑”——一个轻量级的LLM（基于字节内部开发的Doubao-Seed-1.6-flash模型）。训练的目标不是让模型模仿某一个标准答案，而是通过强化学习算法GRPO（Group Relative Policy Optimization，群体相对策略优化），让模型自己去探索如何写出“好”的断言。

强化学习+轻量级LLM：GRPO如何让模型学会测试“常识”

为什么Restor不直接使用传统的监督微调（SFT），而要大费周章地采用强化学习？

原因在于，测试断言没有一个独一无二的“标准答案”。比如，让模型“检查`subscribe_type`字段必须是auto或un-auto”，它既可以用`assert subscribe_type in ["auto", "un-auto"]`，也可以写成`assert subscribe_type != "manual"`。这两种写法在逻辑上是等价的，但语法结构完全不同。监督微调要求模型去“记住”一个特定格式的答案，这既限制了模型的探索，也浪费了其潜力。更糟糕的是，如果训练数据中只包含了一种写法，模型在面对新的、类似的约束时，可能会因为“没见过”其他写法而无法泛化。

而强化学习则更聪明。Restor把模型（LLM）看作一个“智能体”，它每次“思考”后生成的断言代码就是它的“动作”。GRPO这个强化学习算法扮演“教练”的角色，它不关心模型的动作是不是和“标准答案”一样，它只关心这个动作“好不好”。那如何定义“好”呢？Restor设计了一个复合奖励函数。

这个奖励函数R(A)把对断言的评估分成了几个层次：

公式（4）：复合奖励函数R(A)的定义。其中Exec(A, resp)是断言在原始响应上的执行结果，Rident是字段识别奖励，Rsem是语义准确性奖励。

我们来拆解一下这个“教练”的评分标准：

1. 有效性检查（Validity Check，守门员）这是最基本的“生死线”。如果模型生成了一段无法在原始响应上成功执行的代码（比如访问了一个不存在的键，或者语法错误），那就直接判负分（惩罚分ρfail = -1）。这能有效杜绝模型胡编乱造。具体来说，有效性检查会尝试在Python环境中执行生成的断言代码，如果执行过程中抛出任何异常（如`KeyError`、`TypeError`、`SyntaxError`等），则判定为无效。这个检查确保了模型输出的代码至少是语法正确且能在给定响应上运行的。

2. 关键字段识别（Rident，考覆盖）模型生成的断言中访问了哪些字段？这个奖励函数会计算这些字段与专家标注的关键字段集合K之间的准确率和召回率。目的是引导模型把注意力放在业务核心字段上，而不是去检查那些动态变化的、与业务逻辑无关的噪音字段（比如`log_id`、`systime`等）。Rident的计算方式如下：首先，通过静态代码分析提取断言中访问的所有字段名；然后，计算这些字段名与关键字段集合K的交集；最后，基于交集计算精确率（Precision）和召回率（Recall），并取F1分数作为Rident的值。例如，如果关键字段集合是{`amount`, `status`}，而断言只检查了`amount`，那么召回率就是0.5，精确率是1.0，F1分数约为0.67。

3. 语义准确性（Rsem，考逻辑）这是最核心的部分。模型生成的断言会被放在之前构造好的“校验场”中测试：对于正样本Spos（有效变形），断言应该通过（即不报错）；对于负样本Sneg（异常值），断言应该失败（即报错）。这个奖励函数就是要最大化这种“杀死率”的差异——既不能放过坏人（漏检），也不能冤枉好人（误报）。一个完美的断言，能让所有的正样本通过，所有的负样本失败。Rsem的具体计算方式是：对于每个正样本，如果断言执行通过（即没有抛出异常），则得1分，否则得0分；对于每个负样本，如果断言执行失败（即抛出了异常），则得1分，否则得0分。然后，将所有样本的得分求和，再除以样本总数，得到最终的Rsem值。这个值在0到1之间，越接近1表示语义越准确。

通过这个精心设计的奖励函数，GRPO算法可以有效地指导模型进行探索。每轮训练，模型会为同一个API上下文生成多个候选断言。GRPO算法首先执行所有断言，并计算出每个断言获得的奖励分数。然后，它会对这一组分数进行归一化处理，找出哪些断言的“相对表现”更好。最后，它会“表扬”那些相对更好的断言对应的生成路径，推动模型在未来的生成中更多地选择这条路径。具体来说，GRPO会计算每个候选断言的奖励分数相对于组内平均奖励的偏移量，然后根据这个偏移量来调整模型的策略参数。如果某个断言的奖励远高于组内平均，那么生成这个断言的路径就会被强化；反之，如果奖励远低于平均，那么对应的路径就会被抑制。

这种“优胜劣汰”的机制，使得模型无需依赖昂贵的“标准答案”数据集，就能摸索出在各种复杂业务场景下最健壮、最合理的断言模式。最终，一个原本平平无奇的轻量级LLM，被锻造成了一个精通测试“常识”的专家。值得注意的是，GRPO相比传统的PPO（Proximal Policy Optimization）算法有一个关键优势：它不需要一个独立的“评论家”模型来估计状态价值函数，而是直接使用同一组候选断言的奖励分数进行相对比较。这大大简化了训练流程，降低了计算开销，使得在轻量级模型上进行强化学习训练变得更加可行。

工业实战：字节跳动部署后采纳率超96%

理论讲得再好，最终还是要看实战。Restor最令人信服的部分，莫过于它在字节跳动生产环境中的真实部署结果。研究人员进行了一系列详尽的实验，来回答三个关键问题：有效性如何？专家觉得好用吗？工业部署效果怎样？

实验设置与基线对比

他们从字节跳动的内部平台收集了超过2300个真实的API流量样本，覆盖了246个服务和15条业务线，数据量相当可观。训练集、验证集和测试集按照8：1：1的比例划分，在包含229个未见过API样本的测试集上进行最终评估。这些API样本涵盖了多种业务场景，包括用户管理、内容推荐、支付结算、消息推送等，确保了评估结果的全面性和代表性。

Restor对比了两个基线模型，它们都没有经过强化学习微调：

Doubao-Seed-1.6-flash (Base Model)：Restor的基础模型，一个轻量级LLM，未经过专门微调，用于量化GRPO微调带来的纯粹增益。这个模型本身已经具备一定的代码生成能力，但在API测试断言生成这个特定任务上，缺乏领域知识。

DeepSeek-V3.1-Terminus (Large Generalist)：一个大型通用模型，代表了当前顶尖的模型能力。选择这个基线是为了回答一个关键问题：在API测试断言生成这个特定任务上，一个经过专门微调的轻量级模型，能否超越一个未经微调的强大通用模型？

RQ1：有效性评估

这是大家最关注的“硬指标”对比。研究人员从关键字段识别和语义准确性两个维度进行了定量分析。

表2：在关键字段识别任务上，Restor取得了高达85.42%的F1分数，而大型通用模型DeepSeek-V3.1-Terminus和基础模型Doubao-Seed-1.6-flash的得分分别是83.61%和69.48%。虽然绝对数值的提升可能看起来不是“颠覆性”的，但F1分数在80%以上的区间内，每提升1个百分点都极其困难。更重要的是，Restor在一个更关键的指标上展现了统治力——预测精确度。Restor的精确率达到了87.3%，意味着它生成的断言中，有87.3%的字段检查都是针对真正关键的业务字段，而DeepSeek-V3.1的精确率只有81.2%，基础模型更是只有65.7%。这表明Restor更擅长区分“哪些字段值得检查”和“哪些字段只是噪音”。

表3：在语义准确性评估中，Restor生成的精确匹配断言（Exact Match）数量达到663个，远超DeepSeek-V3.1的595个和基础模型的537个。更亮眼的是，Restor的漏检次数（Missed Validations）仅为28次，远远低于DeepSeek-V3.1的66次和基础模型的128次。同时，其误报次数（False Alarms）也控制在最低水平，仅为9次。这些数据清晰地表明，Restor生成的断言不仅更准确，而且更“懂事”，能做到精准打击，绝不放过坏人，也绝不冤枉好人。为了进一步验证结果的统计显著性，研究人员还进行了配对t检验，结果显示Restor与两个基线模型之间的差异在p<0.01的水平上显著，排除了偶然因素。

RQ2：专家评估

A/B测试和指标只能证明“更好”，但到底“好在哪里”，还需要听一线专家的感受。字节跳动的6名资深QA工程师盲评了Restor和两个基线模型生成的断言。每位工程师都独立评估了从测试集中随机抽取的50个API样本对应的断言，评估维度包括：断言的正确性（是否准确反映了业务逻辑）、完整性（是否覆盖了所有关键字段）、可读性（代码是否清晰易懂）以及可维护性（是否需要大量修改才能投入使用）。每个维度采用1-7分的李克特量表进行评分。

表4：用户研究表明，Restor生成的断言获得了最高的评估分数（Average = 6.2），远超DeepSeek-V3.1（5.0）和基础模型（4.6）。在“需要最少编辑量”这一项上，Restor也是表现最好的。专家们普遍反馈，Restor生成的断言“噪音更少”、“可操作性更强”，几乎可以直接投入版本控制系统，不需要他们费神去修改。一位参与评估的QA工程师特别提到：“Restor生成的断言看起来就像是我自己写的，它知道哪些字段是真正重要的，而且检查逻辑非常干净。”这也解释了为什么它能在生产环境中获得如此高的采纳率。

RQ3：工业部署结果

这才是整个研究最激动人心的部分，也是让龙哥最佩服的地方。Restor被集成到字节跳动内部的自动化测试用例生成平台，直接在生产环境的CI/CD流水线中运行。部署过程分为两个阶段：首先，在预发布环境中进行为期两周的A/B测试，将Restor生成的断言与原有方案生成的断言进行对比；然后，在确认效果稳定后，逐步将流量切换到Restor，最终实现全量部署。

图6：结果表明，在部署Restor之前，平台原有方案生成的测试用例，工程师的采纳率（Adoption Rate）为74.1%。而部署Restor之后，这个数字直接跃升并稳定在96%以上。这个数字说明，几乎每一次Restor生成的测试用例，工程师们都选择直接接受并使用，而不是自己重写。这意味着，Restor已经将QA工程师们从繁琐的断言编写中解放了出来，让他们可以专注于更具创造性的测试设计任务。这是AI赋能软件测试领域一个标志性的胜利。此外，部署Restor后，API测试用例的编写时间平均缩短了约70%，从原来的每人每天编写20-30个用例提升到了可以处理60-80个用例，显著提升了测试团队的效率。

如果从F1分数和专家评估的角度看，Restor确实非常能打。它在关键字段识别上超越了大型通用模型DeepSeek-V3.1-Terminus，同时语义准确性指标（精确匹配数量、漏检次数）更是全面领先，而且响应速度和推理成本远低于大模型。在字节跳动的生产环境中，采纳率从74.1%飙升至96%以上，这是一个极具说服力的工业级验证。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

Restor和直接使用大模型做提示词工程相比，最大的优势是什么？最大的优势在于成本和效果的平衡。像DeepSeek-V3这样的大模型，通过精心设计的提示词也能生成不错的断言，但每次推理都需要巨大的计算量，延迟高、成本高。在CI/CD流水线中，每天可能要执行成千上万次这种任务，成本根本无法接受。而Restor微调的是一个轻量级模型，推理速度快、部署成本低，并且通过强化学习内化了测试“常识”，在API测试这个特定场景下，其效果甚至超越了通用大模型。具体来说，Restor的推理延迟通常在100-200毫秒之间，而DeepSeek-V3的推理延迟通常在1-2秒甚至更长，这意味着在相同的硬件条件下，Restor可以处理5-10倍的请求量。

Restor方法的一个核心前提是人工标注了关键字段和约束，这个成本是不是很高？它算是“无监督”学习吗？这个问题问到点子上了。这恰恰是Restor这篇论文最聪明的设计之一。这确实不是完全的“无监督”学习，它是一种“知识蒸馏”的过程：由3位QA工程师花费大约2周时间，为一个包含数百个API样本的训练集标注关键字段并构造正负样本。这个成本并不低，但这是一次性的投入。一旦模型训练完毕，它在面对全新的、未见过的API时，完全不需要任何人工干预，就能直接生成断言。而且，这个过程和代价，要比去编写和维护数千个API的断言脚本要小得多。可以说，它把专家的知识“蒸馏”到了模型里。从长期来看，这种一次性投入的ROI（投资回报率）非常高——以字节跳动的规模，每天有数百个API在迭代，仅仅几周的人工标注成本，换来的是持续、自动化的断言生成能力，其价值不言而喻。

Restor生成的测试预言能完全替代人工吗？从字节跳动的部署结果看，采纳率超过96%表明它在绝大多数情况下生成的断言已经非常可靠，可以近乎替代人工。但这不意味着QA工程师就完全“失业”了。工程师的角色从“手工编写”转变成了“审核与决策”。他们不再需要写那些枯燥的断言脚本，而是可以把精力放在更复杂的测试场景设计上，比如探索API的边界值、设计组合测试等。2026年了，AI的能力边界在不断拓展，未来的开发、测试模式都会有很大变化。实际上，在字节跳动部署Restor后，QA团队的工作重心已经发生了转移：他们现在更多地参与测试策略的制定、异常场景的挖掘以及测试基础设施的优化，而不是被繁琐的断言编写所困住。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★☆

论文的核心创新在于将GRPO强化学习算法引入到API测试预言生成领域，并设计了一套完整、且经过工业验证的“数据增强+奖励函数”训练流程。虽然每个子模块都不是完全原创，但组合成一个能解决实际工业难题的整体方案，体现了很强的系统创新性。

实验合理度：★★★★★

实验设计非常扎实。不仅有标准化的自动化指标对比（F1分数、精确匹配等），还设计了用户研究（专家的盲审打分），最后更是拿出了生产环境中的采纳率数据。三个研究问题层层递进，从实验室评测到真实世界验证，非常有说服力。基线模型的选择也公平合理，对比了自己的基础模型和一线大模型。

学术研究价值：★★★★☆

这篇工作展示了强化学习微调轻量级LLM在软件工程任务中的巨大潜力。它可能启发更多研究者探索将类似范式应用到其他需要“专家常识”的工程任务中，例如代码审查、日志分析、安全漏洞检测等。其实验方法和评价指标也具备很高的参考价值。

稳定性：★★★★☆

由于模型是通过强化学习优化后的产物，生成的断言具有非常高的稳定性和鲁棒性。从生产环境采纳率超过96%就可以看出，它很少产生误报或漏报，能够在复杂的、多变的真实流量下可靠运行。

适应性以及泛化能力：★★★★☆

Restor的测试数据覆盖了字节跳动246个不同服务、15条业务线，这本身证明了它强大的泛化能力。它能够适应从订阅服务到计费系统等不同领域的API。不过，这种泛化能力很大程度上依赖于训练数据的多样性和质量，如果是一个全新的、与训练数据特征差异巨大的领域，可能需要额外的微调。

硬件需求及成本：★★★★★

这是一个巨大的亮点。Restor的最终目的是部署一个轻量级模型，其训练和推理成本远低于大型通用模型。在节省硬件成本的同时，推理速度也能满足高频的CI/CD流水线要求。最终结果是，用更少的资源，取得了更好的效果。

复现难度：★★☆☆☆

虽然论文描述了详细的方法和模型结构，但核心的轻量级LLM（Doubao-Seed-1.6-flash）是字节跳动内部的模型，大概率不会开源。而数据增强和奖励函数等代码也未见开源。对于一个外部团队来说，想要完全复现其效果，必须找到或者训练一个类似性能和规模的轻量级模型作为基础，这本身就非常有挑战性。因此复现难度较高。

产品化成熟度：★★★★★

这篇工作本身就是顶级的产品化实践。它不只是一个研究原型，而是已经成功部署在字节跳动的生产环境CI/CD流水线中。从采纳率数据看，它已经是一个成熟、可靠的产品组件，对任何有类似测试痛点的团队来说，都具有极高的参考和迁移价值。

可能的问题：论文中的奖励函数设计和正负样本构造完全依赖于QA专家的领域知识，是一次性的成本投入。如果要跨行业或公司应用，这个“专家标注”流程必须重做。此外，方法假设API响应是JSON格式，对于ProtoBuf等更复杂的格式没有涉及。强化学习训练的计算开销和参数调优难度不小，这从论文提到的单次训练也能看出来。

主要参考文献

[1] Xun Zhou, Zhen Dong, Mingyu Ren, et al. RESTOR: Automated Test Oracle Generation for RESTful APIs via Reinforcement Learning. In Proceedings of ISSTA, 2026.

[2] Shao, Z., Wang, P., Zhu, Q., et al. DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. arXiv preprint, 2025.

[3] Schulman, J., Wolski, F., Dhariwal, P., et al. Proximal Policy Optimization Algorithms. arXiv preprint, 2017.

*本文仅代表个人理解及观点，不构成任何论文审核或项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～想了解更多原文细节的小伙伴，可以点击"阅读原文"，查看更多原论文细节哦！