如果你正在用 LLM 生成的测试去评价两个候选实现谁更好建议先看完这篇文章再动手。最近我在做代码方案对比实验时反复遇到一个令人警觉的现象同样一个需求不同实现都能通过自己“配套”的测试但放到对方的测试里就会失败。问题不在实现而在测试本身——用 LLM 生成的测试当裁判裁判可能早就被某一种实现“暗示”了答案。这篇文章会完整拆解这个问题的成因和应对方式。你会看到LLM 生成测试的机制是什么测试断言如何悄悄隐含实现细节为什么同一个实现在不同测试集下会输赢反转以及在做技术选型或代码评估时如何避免被这种偏差误导。1. 背景与核心概念1.1 什么是 LLM 生成的测试在传统测试工程里单元测试主要由开发人员根据需求文档、接口定义和业务规则手工编写。最近几年大语言模型LLM改变了这个流程。所谓“LLM 生成的测试”是指把函数签名、需求描述甚至源码片段交给模型让模型输出一组测试用例。开发者再把这些用例收集起来放到 pytest、JUnit 等测试框架里运行用来验证实现是否符合预期。这类做法越来越流行原因很直接。一方面LLM 可以快速生成覆盖范围可观的测试草稿省去大量机械性工作另一方面代码生成领域也大量使用自动生成测试来判断模型生成的实现是否正确。在很多 benchmark 中拿一个模型生成的函数去跑一组人工或 LLM 生成的测试统计通过率作为“效果指标”。测试已经不只是工程质量保障工具它还变成了一种评价尺度。1.2 为什么测试能决定“哪个实现赢”当测试被用来横向比较多个实现时它的“裁判”属性就会非常突出。一个实现能不能通过测试取决于测试断言是否认可它的行为。如果测试期望state-of-the-art算 1 个单词那么按空格切分的实现可以通过但按连续字母数字切分的实现会返回 3自然失败。反过来如果测试期望它算 3 个单词胜者又会变成正则实现。也就是说两个实现可以放在同一个需求下都说得通但测试选择了其中一种“说得通”作为唯一标准。如果这组测试是由 LLM 生成的模型在生成时很可能已经看过某一个实现或者在训练数据中形成了对“标准答案”的统计偏好。于是LLM 生成哪类测试就基本决定了哪一类实现会被判胜。这就是本文要重点讨论的“LLM-generated tests can change which implementation wins”。1.3 规范、实现与测试的关系为了理解问题根源需要先区分三个概念规范、实现和测试。规范描述“应该做什么”。例如“统计句子中的单词数量”业务方认可即可。实现描述“怎么做”。例如用正则还是使用split()这是内部细节。测试描述“如何验证”。它把规范转成可执行的断言。理想情况下测试必须独立于实现只依据规范生成。但 LLM 生成的测试往往不满足这个原则因为模型生成测试时会参考源码或参考训练数据中常见实现的行为从而不知不觉把实现细节编码到测试断言中。很多开发者只关注“测试跑没跑过”却忽略了“测试本身是不是中立”这正是问题隐蔽的原因。2. 为什么“偏心测试”难以察觉2.1 测试里藏着隐性假设测试看起来是一堆输入输出断言实际上每条断言都包含一个假设“这个输入应该产生这个输出”。如果需求只写了“统计单词数”那么dont应该算 2 还是 1并没有客观答案。但测试一旦写死成 1就相当于假设了“撇号是单词内部字符”写死成 2则相当于假设“撇号是分隔符”。这种隐性假设在阅读测试函数时很难被发现因为测试本身读起来非常合理。尤其是 LLM 生成的测试通常会使用“覆盖正常输入、标点、边界”等套话让测试看起来全面且中立。真正执行测试时它也不会提醒我们“这个断言来自某个实现的内部逻辑”只会给出 PASS 或 FAIL。2.2 实现细节泄漏的三条路径第一条路径是提示词泄漏。如果把实现 A 的源码贴给 LLM让模型“为这个函数写测试”模型会倾向于模仿源码中的行为包括边界逻辑。这种方式生成的测试本质上是“实现 A 自证正义”。第二条路径是训练数据泄漏。即使不贴源码只给接口描述模型也可能按照训练数据中最常见的实现模式补全测试。比如遇到“单词数量”问题模型可能默认使用split()的行为因为这是 GitHub 等代码仓库中最常见、最直观的实现方案。第三条路径是验证逻辑泄漏。有些模型生成的测试会 mock 内部方法例如assert mock_parser.parse.called这类测试和具体实现强绑定。换一个没有parse方法的实现测试直接失败根本来不及比较业务行为。2.3 为什么这种偏差不容易被发现因为生成测试会运行通过而且可能覆盖率很高。如果工作人员只看“测试都过了”很容易得出“这个实现没有错”的结论。实际上这个结论只是在“测试的假设”下成立。没有用同一组测试去跑另一个实现也没有逆向检查测试断言是否来自规范就很难发现裁判已经偏了。更隐蔽的是这种偏差不会产生报错也不会影响测试稳定性。它和常见的“环境不稳定导致测试失败”是完全不同的表现形式。正因如此它更容易被当成“正常结果”接受。3. 环境准备与示例项目3.1 运行环境本文示例使用 Python 3.8 和 pytest 7。如果你还没有安装 pytest可以创建虚拟环境后执行pip install pytest示例不依赖某个具体 LLM API。我们会模拟模型可能生成的两组测试结果来验证原理。如果你想实际接入模型可以选择本地开源模型或云端 API不同模型和版本输出会有所差异但“测试偏向实现”的机制是通用的。3.2 项目结构为了便于复现建议按下面的结构创建目录llm-test-bias-demo/ ├── implementations/ │ ├── __init__.py │ ├── regex_impl.py │ └── split_impl.py ├── generated_tests/ │ └── __init__.py ├── evaluate.py └── requirements.txtimplementations目录存放两个候选实现generated_tests用于存放 LLM 生成的测试文件evaluate.py用于统一对比两组测试下的结果。3.3 示例需求我们的需求非常简单“计算一段文本中的单词数量。”故意不定义数字、标点、连字符和撇号的处理方式因为现实中很多需求描述就是这么模糊。两个实现都自称能“统计单词数”但对边界输入的处理不同。4. 演示LLM 生成的测试如何改变胜负4.1 两个合理的实现实现 A 使用正则表达式把“单词”定义为连续的字母或数字序列。它会认为dont是don和t两个单词也会认为state-of-the-art是三个单词。# implementations/regex_impl.py import re def count_words_regex(text: str) - int: if not isinstance(text, str): raise TypeError(text must be str) return len(re.findall(r[A-Za-z0-9], text))实现 B 使用字符串的split()方法按空白符切分。它会把dont和state-of-the-art都当成一个单词因为连字符和撇号都不是空白符。# implementations/split_impl.py def count_words_split(text: str) - int: if not isinstance(text, str): raise TypeError(text must be str) if text.strip() : return 0 return len(text.split())两个实现单独看都有道理但它们对边界输入的返回值不同。如果需求没有明确定义“单词”的边界这两者都算符合需求。真正的分歧在于测试选择了哪种解释。4.2 模拟 LLM 生成的两组测试现在我们模拟两种常见的 LLM 使用方式。第一种方式把实现 A 的源码给模型让模型“根据源码写测试”。模型很可能写出期望state-of-the-art为 3、dont为 2 的测试因为这是在模仿正则表达式源码的行为。第二种方式把实现 B 的源码给模型让模型“根据源码写测试”。模型很可能写出期望state-of-the-art为 1、dont为 1 的测试因为这是在模仿split()源码的行为。为了让对比更清晰我们直接在evaluate.py中用两组测试用例表示这两类“模型输出”# evaluate.py from implementations.regex_impl import count_words_regex from implementations.split_impl import count_words_split # 模拟“看过正则实现后 LLM 生成的测试” REGEX_BIASED_TESTS [ (, 0), (hello world, 2), (Hello, world!, 2), (state-of-the-art, 3), (dont, 2), ] # 模拟“看过 split 实现后 LLM 生成的测试” SPLIT_BIASED_TESTS [ (, 0), (hello world, 2), (Hello, world!, 2), (state-of-the-art, 1), (dont, 1), ] def run(func, tests): failed [] for text, expected in tests: actual func(text) if actual ! expected: failed.append((text, expected, actual)) return failed def report(): for impl_name, func in [ (regex_impl, count_words_regex), (split_impl, count_words_split), ]: regex_fail run(func, REGEX_BIASED_TESTS) split_fail run(func, SPLIT_BIASED_TESTS) print(f{impl_name} on regex-biased tests: f{PASS if not regex_fail else FAIL str(regex_fail)}) print(f{impl_name} on split-biased tests: f{PASS if not split_fail else FAIL str(split_fail)}) if __name__ __main__: report()运行方式很简单python evaluate.py预期输出如下regex_impl on regex-biased tests: PASS regex_impl on split-biased tests: FAIL [(state-of-the-art, 1, 3), (dont, 1, 2)] split_impl on regex-biased tests: FAIL [(state-of-the-art, 3, 1), (dont, 2, 1)] split_impl on split-biased tests: PASS4.3 结果说明了什么从输出可以清楚看到采用哪组测试直接决定了哪个实现胜出。如果模型根据正则实现生成测试那么regex_impl通过split_impl失败正则实现胜出。如果模型根据split()实现生成测试那么split_impl通过regex_impl失败split()实现胜出。同一个需求同一个代码仓库只因为“谁先生成测试”就得出两个相反结论。测试在这里不是客观度量工具而是“用统计方式复刻某一种实现偏好”的传声筒。这就是我们把标题翻译成日常语言时常说的LLM 生成的测试真的能改变哪个实现获胜。5. LLM 为什么会产生这种偏向5.1 训练数据形成“最常见实现”先验大语言模型的本质是语言模型它的知识来自海量代码、文档和技术问答。在训练数据里“统计单词数量”最常见的 Python 解法就是str.split()。因此当模型面对一个模糊需求时它更倾向于生成符合split()行为的测试比如把dont当成一个单词。这种偏好不是 bug而是统计学习的结果。模型会对训练数据中高频出现的模式赋予更高概率。如果需求对边界没有明确约束模型就会默认采用“最常见的边界行为”来写断言。5.2 提示词中的实现先验会改变输出当提示词中直接包含某个实现源码时情况会更明显。模型会把源码当作“标准答案”然后生成与源码行为完全一致的测试。此时测试的生成过程已经不是“验证实现是否符合需求”而是“验证实现是否符合它自己”。这种测试对于代码生成模型的自评尤其危险。如果目标是评测“模型 A 生成的实现”和“模型 B 生成的实现”而测试又恰好从其中一个实现或提示词中推断而来那么本质上是在帮助模型自我验证。5.3 测试失去独立性统计评测通常要求测试集与训练集、候选对象相互独立。LLM 生成测试时看到了候选实现独立性就被破坏了。即使没有直接看到源码它也可能携带训练数据中关于“正确实现”的倾向。因此用 LLM 生成的测试去比较两个实现就像让一个提前看过选手彩排的评委来打分表面形式很公平结果却早已被影响。5.4 与普通测试脆弱性的区别普通测试脆弱指的是测试依赖内部状态、网络环境或时序导致运行不稳定。这里的问题更隐蔽测试断言本身和某一种实现逻辑强相关但它不会报错反而运行得很稳定。它不是“不稳定”而是“不公平”。所以在排查问题时要区分两者不能用“测试稳定通过”来判断测试质量好。6. 如何缓解偏差得到更公平的评估6.1 规范优先的测试生成最直接的改进方法是让模型只根据规范生成测试不提供任何实现源码。提示词里应该只写需求、接口签名和需要覆盖的输入类型同时明确要求模型不要假设内部实现。一个规范优先的提示词模板可以长这样请根据以下需求编写 PyTest 单元测试 需求实现 count_words(text: str) - int统计一段英文文本中的单词数量。 约束请只基于需求不要假设任何实现细节。 需要覆盖空字符串、普通句子、标点、连字符、撇号、多个连续空格。 输出只输出 Python 测试代码不要包含额外说明。这样生成出来的测试至少不会直接复制某个实现的边界逻辑。不过要注意如果需求本身太模糊模型仍可能在边界上做默认选择。因此在实际操作时最好先把“单词”的定义写清楚比如“单词是由字母或数字组成的连续序列”这样模型才有规范可循。6.2 双盲测试生成如果确实希望比较两个实现在同一需求下的表现可以尝试“双盲”测试生成。给两个实现都起匿名代号让模型看不到具体实现只提供相同的需求和接口。最终把模型生成的测试交给两个实现执行再对比结果。另一种做法是使用多个模型、多次温度采样生成多组测试集合。这样可以观察哪些边界断言在不同模型间稳定出现哪些断言是某一次生成的偶然结果。稳定性高的边界断言更可能来自需求或常识而不只是某一个实现。6.3 引入属性测试作为补充单元测试适合检查具体输入输出但属性测试更适合检查“所有满足条件的输入都应该具有的性质”。属性测试不绑定某个实现可以减少偏见。例如我们可以断言“在所有文本后面追加一个空格单词数量不应该增加”“两个用多个空格连接的句子分开写和连在一起写的单词数量应该一致”。这类属性可以人工编写也可以让 LLM 生成后人工审查。属性测试把关注点从“某个边界输入等于几”转移到“所有实现都必须满足的性质”这样就不容易偏向某一种编码风格。6.4 不要用单一测试集当最终裁判如果必须用测试分数来选择实现建议不要只依赖一组测试。可以用 10 组独立生成的测试集分别跑两个实现统计通过组数和平均通过率。注意记录每组测试的生成方式是否有源码、模型版本、温度、提示词版本等。这样做不是为了让评估更复杂而是要让结论对“测试生成方式”这一因素更鲁棒。如果换一组测试结论就反转说明现有评估方法不可靠。与其强行下结论不如先补充需求文档或增加人工评审。6.5 保持人工审查环节LLM 生成的测试在进入评估流程之前必须经过人工 review。重点检查边界输入对应的期望值是否来自需求而不是来自某个实现。如果期望值无法从需求中推导出来说明需求本身有歧义需要先补充需求而不是让测试去“替需求拍板”。人工审查还能发现模型生成的测试是否 mock 了内部方法、是否依赖特定库版本、是否检查了不应该检查的异常类型。这些细节用自动化工具很难完全识别。7. 常见问题与排查7.1 同一个实现不同测试集下结果不同问题现象常见原因解决思路同一实现换一组 LLM 测试后通过率变化很大测试集存在隐式实现偏好对比两组测试的边界断言检查是否来自源码或常见实现两个实现分别在自己的测试下通过测试由各自实现生成失去独立性改为规范优先生成或使用双盲测试测试覆盖率很高但结论并不可靠覆盖率无法反映断言中立性补充人工 review 和属性测试这类现象的本质是测试内部隐含了“某个实现更合理”的假设。排查时不要只看通过率要逐条检查测试中涉及边界语义的输入例如连字符、撇号、大小写、多个空格等。7.2 pytest 提示 no tests found for given includes这是 pytest 使用中非常常见的报错。现象是明明写了测试文件但执行pytest时提示没有找到测试。常见原因有三个文件名不是以test_开头或者没有以_test.py结尾测试文件所在目录缺少__init__.py导致 pytest 没有把目录作为包处理执行命令时指定的路径和文件实际路径不一致。解决思路也很直接把测试文件命名为test_*.py在需要导包的项目根目录运行 pytest确认rootdir和pythonpath配置正确。这个报错和“测试偏向”没有直接关系但它会让整个评估流程更脆弱也需要一并排查。7.3 两个实现都通过或都失败如果两组测试下两个实现都通过说明测试没有覆盖到会区分行为的边界输入。比如只测试了普通句子没有测试连字符、撇号、数字和标点组合。如果两个实现都失败则说明测试断言可能和实际需求都不一致需要回头审核需求文档。解决方法是扩充差异化的边界输入。可以对比两个实现的行为找出它们输出不同的输入集合再将这些输入加入测试集。这样至少能让测试具备“区分能力”而不是让两条实现都浑水摸鱼。7.4 测试 mock 内部方法导致换实现失败另一种常见问题是 LLM 生成的测试为了模拟依赖直接 mock 了实现 A 的内部函数。把实现 B 放进去时B 根本没有这个内部函数测试直接报错。这种情况属于测试与实现过度耦合和“测试偏向”有重叠之处。解决方法是删除对内部方法的 mock改为对公开接口的输入输出断言。如果确实需要 mock 外部依赖也应该将测试集中在接口行为上而不是某个实现特有的调用链。8. 最佳实践与工程建议8.1 给生成测试建立来源记录在项目中引入 LLM 生成测试时建议在测试目录里附带一个说明文件记录每个测试文件的生成方式。记录内容包括生成日期、使用的模型名称和版本、温度参数、提示词版本、输入给模型的是“需求”还是“源码”。这种记录在后续排查“为什么这个实现会胜出”时非常有用。如果未来测试结果出现了反转快速定位是“实现变化”还是“测试生成方式变化”非常重要。没有来源记录就只能靠猜。8.2 把生成测试当作普通 PR 来审查LLM 生成的测试不应该直接合入主分支。它应该和业务代码一样经过同行评审检查测试断言的合理性和覆盖范围。团队可以约定如果测试中出现了需求文档里没有提到的边界期望值必须先在需求文档中补充说明然后再合入测试。这一步看起来额外增加工作量但它能显著降低“测试偏见导致错误技术决策”的风险。尤其当生成测试被用于代码生成模型评测时测试集的审查更应该谨慎。8.3 在 CI 中使用生成测试时限制作用域生成测试可以放在 CI 里作为“补充回归测试”但不要太早作为“代码合并的唯一门槛”。因为 LLM 生成的测试可能有非确定性问题不同模型版本、不同温度下生成的测试会变化。如果直接把生成测试作为发布阻断条件会让流水线变得很难稳定。一个可落地的方案是生成测试先以“review 后固定”的方式存入版本库再像普通测试一样执行。不要每次 CI 都现场调用模型生成测试否则生成结果不可控也难以追溯。8.4 安全边界不能放松LLM 生成的测试代码本身也可能是危险的。测试中可能包含执行子进程、读写临时文件、访问网络等操作。如果测试运行在 CI 或生产环境的机器上建议在隔离的沙箱环境中运行。同样当使用 LLM API 时要注意不要把包含敏感业务逻辑的源码直接发送给外部模型。可以先用接口签名和脱敏数据替代真实源码或者使用本地模型处理私有代码。8.5 把“测试是否中立”纳入评估报告做代码生成模型对比时不要只输出“A 通过 90% 测试B 通过 85% 测试”。评估报告里应该增加一栏测试集来源、测试集是否包含实现源码、边界断言是否由人工确认。如果测试集来源不同直接对比通过率就没有意义。一个负责任的报告至少应该说明“这组测试是根据规范生成还是根据实现 A 生成”。只有让测试生成方式透明化结论才有说服力。9. 总结与进一步学习方向本文通过一个可运行的 Python 示例展示了 LLM 生成的测试如何改变两个实现之间的胜负关系。核心问题并不在于 LLM 不够聪明而在于测试生成过程丢失了独立性。当测试断言依据某个实现的源码或训练数据中的“常见实现偏好”生成时测试就不再是中立裁判而是披着客观外衣的参赛选手。如果你想深入掌握这个方向可以继续学习三块内容第一是软件测试基础理论特别是黑盒测试、白盒测试和基于属性的测试第二是代码生成模型评估方法学习 benchmark 中如何避免测试集泄漏第三是 LLM 应用工程的提示词设计掌握“规范优先”“双盲生成”等可落地的操作技巧。在实际项目里永远保留一份独立于所有候选实现的人工测试集。在查看“A 胜出”的评估报告时先问一句这组测试是谁写的它见过答案吗这句话值得贴在每一位做代码评估的工程师工位上。