之前用 LLM 生成测试用例去评估几个候选实现时碰到一个挺值得琢磨的现象同一份需求描述让两个不同的 LLM 生成测试再用这两组测试去跑同一个实现结果一组测试全绿另一组测试挂了好几个。代码没改需求没变只是“测试由谁来写”变了结论就完全不一样了。这其实不是偶然。LLM 生成测试并不是一个“中立”的过程它会把模型对需求的理解、对边界条件的假设、对自然语言歧义的默认处理方式全部通过断言写进测试里。而测试一旦被当作评判标准它就不再只是“验证程序是否正确”的工具而是变成了“定义程序应该长什么样”的规格说明。这篇文章就从这个现象切入系统拆解 LLM 生成测试、实现选择、以及测试规格之间的三角关系并通过一个可以直接复现的 Python 案例展示“LLM 生成的测试如何改变哪个实现获胜”。1. 背景与核心概念1.1 什么是 LLM 生成测试LLM 生成测试简单说就是让大语言模型根据需求描述、接口签名、示例代码甚至已有文档自动生成一组可运行的测试用例。它在很多场景下都在被使用开发者在写完一个函数后让 LLM 先补充一批单元测试测试平台或 CI 流程中自动生成冒烟测试代码生成模型的评估基准中用 LLM 生成测试来评判模型生成的代码是否正确在重构阶段用 LLM 快速补充回归测试。相比人工写测试LLM 的优势很明显速度快、覆盖常规路径省力、可以批量生成。但它的劣势同样明显LLM 并不真正“理解”需求它只是在做概率预测把训练数据中最常见的模式填充进去。这个特性放在测试生成场景下会带来一个隐蔽但重要的问题——测试断言里藏着一大堆未经确认的假设。1.2 “哪个实现获胜”是什么意思在代码生成、竞赛编程、算法题评判、甚至日常代码评审中“哪个实现获胜”通常不是靠人一眼看出来的而是靠测试决定的。基本流程是给定一个需求描述多个开发人员或模型分别实现用同一组测试去跑这些实现通过测试数量多、速度快、代码质量高的实现胜出。在这个流程里测试扮演着“裁判”的角色。听起来很客观测试用例是固定的所有实现面对同样的裁判谁对谁错一目了然。但问题恰恰出在这里——裁判并不是中立的。如果这组测试是人工精心设计的需求映射那的确相对可靠。但如果这组测试是 LLM 生成的那么 LLM 在生成过程中对需求的解释、对边界条件的猜测、对自然语言歧义的默认偏好都会被固化成断言。不同的 LLM 生成不同的测试就会改变“谁正确”的判定结果。1.3 核心观点测试不是中立的裁判本文的核心观点可以概括成一句话测试的本质是一种行为契约LLM 生成的测试会把它的隐性假设写进契约里从而改变符合需求的实现方案之间的竞争结果。换句话说当你让 LLM 先生成测试、再让另一批实现去“通过”这些测试时你实际上是用 LLM 对需求的主观理解作为唯一标准。这个标准可能偏向某一种实现风格、某一种边界处理方式甚至某一种错误容忍策略。结果就是实现本身可能没有问题但它没有满足 LLM 隐含的那个假设于是被判失败。理解这一点对两类人尤其重要使用 LLM 辅助日常开发的工程师需要知道自己让 LLM 生成的测试可能带偏实现做代码生成模型评估的研究者或平台开发者需要意识到 LLM 生成测试作为评估协议时可能让模型排名失真。2. 测试如何约束实现核心原理拆解2.1 测试即规格在很多工程团队里TDD测试驱动开发的核心思想是先写测试再写实现。测试定义了程序应该具备的行为实现只要让测试通过即可。因此测试本身就成了一份可执行的规格说明。规格说明有一个特点它不需要覆盖所有真实世界的情况它只需要定义“在这个项目里什么是正确的”。比如一个函数内部用什么算法、用不用缓存、怎么处理异常只要测试断言中没有涉及实现就有自由发挥的空间。而一旦测试断言中写了某个边界值的结果所有实现都必须在这个边界值上和测试保持一致。这带来的一个直接推论是测试断言写得越细实现的自由度越低测试断言的选择越偏向某种假设最终胜出的实现就越可能是符合这个假设的实现。2.2 LLM 生成测试时会做哪些隐性假设LLM 生成测试时并不是在“理解需求”而是在“补全最可能的测试代码”。它会基于训练数据中的统计规律自动补齐很多需求描述里没有明确写出来的细节。常见的隐性假设包括边界值假设需求说“超过 100 元打折”那 100 元整到底打不打LLM 可能按“大于”理解也可能按“大于等于”理解类型假设输入一定是字符串吗如果传入 None 或数字会怎样LLM 通常会按“合法输入”设计测试忽略异常输入格式化假设输出是保留 1 位小数还是 2 位是四舍五入还是截断LLM 会从常见代码片段中取一个语义边界假设例如“单词”怎么定义连字符算不算分隔符数字算不算单词标点是否完全忽略这些假设在人工阅读需求时往往会通过提问或常识来澄清但 LLM 生成测试时通常不会提问而是直接选择一个“最常见”的解释写进断言。这种“最常见”可能和你的业务场景不同也可能和你团队的既有实现约定不同于是冲突就产生了。2.3 三个最容易被测试“改变胜负”的维度结合日常经验以下三个维度最容易因为测试假设不同而让实现胜负反转边界值归属。例如“超过 100 打折”100 算不算超过不同测试断言会让使用和的实现出现完全不同的通过率。输入清洗策略。例如“统计单词数”是否需要去除标点是否需要把连字符当作单词分隔符不同断言直接区分了split()实现和正则实现。错误与异常处理。例如遇到空字符串、None、超大整数时函数是返回默认值还是抛出异常如果测试期望不抛异常那么严格做参数校验的实现反而会“输掉”。理解这三个维度后我们就能带着具体目标去看实战案例了。3. 完整实战一个函数、两套测试、两种实现下面通过一个非常简单的例子完整演示“LLM 生成的测试改变了哪个实现获胜”。这个案例可以直接在你的电脑上复现。3.1 需求描述假设我们有这样一个需求请实现一个 Python 函数count_words(text)输入一个字符串返回字符串中“单词”的数量。单词是由字母或数字组成的连续序列。标点符号不是单词的一部分。空字符串返回 0。这个需求看起来并不复杂但它并没有明确说明连字符-算不算分隔符带引号的文本怎么处理数字算不算单词这些模糊地带正是后续分歧的起点。3.2 项目结构与环境先创建一个实验目录mkdir llm-test-implementation cd llm-test-implementation目录结构如下llm-test-implementation/ ├── text_utils.py # 候选实现 ├── test_text_utils_v1.py # 第一套 LLM 生成测试 ├── test_text_utils_v2.py # 第二套 LLM 生成测试 └── README.md # 说明文档本文使用 Python 3.9 或以上版本测试框架使用 pytest。如果还没安装 pytest先执行pip install pytest版本可以根据你的项目实际情况调整重点是演示思路。3.3 LLM 生成的第一套测试我们把上面的需求描述直接提交给一个 LLM要求它生成 pytest 测试用例。下面是它生成的一组典型结果保存在test_text_utils_v1.pyimport pytest from text_utils import count_words def test_empty_string(): assert count_words() 0 def test_simple_two_words(): assert count_words(hello world) 2 def test_punctuation_ignored(): assert count_words(hello, world!) 2 def test_multiple_spaces(): assert count_words(hello world) 2 def test_hyphenated_word_as_one(): assert count_words(state-of-the-art) 1 def test_numbers_as_words(): assert count_words(I have 3 apples) 4 def test_tabs_and_newlines_separate(): assert count_words(hello\tworld\nfoo bar) 4注意test_hyphenated_word_as_one这个用例。它把state-of-the-art视为一个单词期望返回 1。这是 LLM 基于英文常见统计习惯做出的假设——很多英文写作规范把连字符复合词当作一个整体。3.4 实现 Asplit 版本我们在text_utils.py中先写入第一种实现使用str.split()按空白字符切分# 文件路径text_utils.py def count_words(text): if not isinstance(text, str): raise TypeError(text must be a string) if text.strip() : return 0 return len(text.split())这个实现对连字符没有特殊处理state-of-the-art会被当作一个整体因为split()默认只按空白字符切分不会拆开连字符。这一点和第一套测试的假设一致。3.5 实现 B正则版本我们换一种实现使用正则表达式\b\w\b来匹配“由字母或数字组成的连续序列”# 文件路径text_utils.py覆盖为以下内容 import re def count_words(text): if not isinstance(text, str): raise TypeError(text must be a string) return len(re.findall(r\b\w\b, text))正则表达式中\b是单词边界\w匹配字母、数字和下划线。注意state-of-the-art中每个由连字符分隔的部分都会被\b识别为独立单词所以这个实现返回 4。为了让实验更清晰我们创建两个不同的模块来保存两种实现避免反复覆盖。可以调整为llm-test-implementation/ ├── impl_a_split.py # 实现 A ├── impl_b_regex.py # 实现 B ├── test_text_utils_v1.py ├── test_text_utils_v2.py实现 A 文件# 文件路径impl_a_split.py def count_words(text): if text.strip() : return 0 return len(text.split())实现 B 文件# 文件路径impl_b_regex.py import re def count_words(text): tokens re.findall(r\b\w\b, text) return len(tokens)3.6 先在实现 A 上运行第一套测试要让test_text_utils_v1.py测试实现 A可以直接在测试文件中导入impl_a_splitimport pytest from impl_a_split import count_words运行python -m pytest test_text_utils_v1.py -v预期结果collected 7 items test_text_utils_v1.py::test_empty_string PASSED test_text_utils_v1.py::test_simple_two_words PASSED test_text_utils_v1.py::test_punctuation_ignored PASSED test_text_utils_v1.py::test_multiple_spaces PASSED test_text_utils_v1.py::test_hyphenated_word_as_one PASSED test_text_utils_v1.py::test_numbers_as_words PASSED test_text_utils_v1.py::test_tabs_and_newlines_separate PASSED 7 passed in 0.02s实现 A 在第一套测试下全部通过。接着在实现 B 上运行同一套测试。修改测试文件导入from impl_b_regex import count_words再运行python -m pytest test_text_utils_v1.py -v预期结果collected 7 items test_text_utils_v1.py::test_empty_string PASSED test_text_utils_v1.py::test_simple_two_words PASSED test_text_utils_v1.py::test_punctuation_ignored PASSED test_text_utils_v1.py::test_multiple_spaces PASSED test_text_utils_v1.py::test_hyphenated_word_as_one FAILED test_text_utils_v1.py::test_numbers_as_words PASSED test_text_utils_v1.py::test_tabs_and_newlines_separate PASSED 6 passed, 1 failed in 0.02s第一套 LLM 测试下的赢家是实现在 A7 比 6。如果按“通过更多测试”来评判实现 A 胜出。3.7 换一套 LLM 测试结果反转现在我们把同一份需求换一个提示词再提交给 LLM或者在提示词中额外加一句“连字符应该作为单词分隔符标点符号应该完全忽略”。LLM 很可能生成下面这组测试保存在test_text_utils_v2.pyimport pytest from text_utils import count_words def test_empty_string(): assert count_words() 0 def test_simple_two_words(): assert count_words(hello world) 2 def test_punctuation_removed(): assert count_words(hello, world!) 2 def test_hyphen_splits_words(): assert count_words(state-of-the-art) 4 def test_numbers_count_as_words(): assert count_words(I have 3 apples) 4 def test_quoted_text_counted(): assert count_words(He said hello world) 4现在先在实现 A 上运行from impl_a_split import count_wordspython -m pytest test_text_utils_v2.py -v预期结果collected 6 items test_text_utils_v2.py::test_empty_string PASSED test_text_utils_v2.py::test_simple_two_words PASSED test_text_utils_v2.py::test_punctuation_removed PASSED test_text_utils_v2.py::test_hyphen_splits_words FAILED test_text_utils_v2.py::test_numbers_count_as_words PASSED test_text_utils_v2.py::test_quoted_text_counted PASSED 5 passed, 1 failed in 0.02s然后在实现 B 上运行from impl_b_regex import count_wordspython -m pytest test_text_utils_v2.py -v预期结果collected 6 items test_text_utils_v2.py::test_empty_string PASSED test_text_utils_v2.py::test_simple_two_words PASSED test_text_utils_v2.py::test_punctuation_removed PASSED test_text_utils_v2.py::test_hyphen_splits_words PASSED test_text_utils_v2.py::test_numbers_count_as_words PASSED test_text_utils_v2.py::test_quoted_text_counted PASSED 6 passed in 0.02s第二套 LLM 测试下的赢家是实现在 B5 比 6。胜负完全反转。3.8 对比汇总测试套件实现 Asplit实现 B正则赢家第一套 LLM 测试连字符算一个词7 通过6 通过实现 A第二套 LLM 测试连字符拆开5 通过6 通过实现 B这个表格清晰展示了一个结论实现代码没有变化唯一的变量是 LLM 生成的测试而它直接改变了“哪个实现获胜”。4. 为什么会这样深入 LLM 的测试生成机制理解了现象我们再看本质。为什么 LLM 生成的测试会如此敏感地影响胜负下面从三个层面展开。4.1 LLM 用“最常见答案”做默认值LLM 的训练数据来自海量代码仓库、技术博客、开源项目和问答社区。在这些数据里“如何统计单词数”有着多种的常见实现。有的教程用split()有的用nltk有的用正则。当 LLM 生成测试时它会倾向于选择训练数据中出现频率最高的行为模式作为预期结果。比如在英文文本处理场景中state-of-the-art到底算 1 个词还是 4 个词并没有统一的工程约定。有的语料统计单位把它当一个词条有的分词工具把它拆开。LLM 选择哪种取决于它的训练数据里哪种情况更多。这不是 LLM 的 bug而是概率模型的固有属性。但恰恰是这个属性让测试生成过程变得不可控。4.2 提示词措辞对测试假设的影响进一步实验可以发现提示词的措辞会明显影响 LLM 生成的测试假设。比如在需求描述中增加一句“单词是由字母或数字组成的连续序列连字符不算字母或数字”LLM 就大概率会生成test_hyphen_splits_words这个用例。而如果只说“统计文本中的单词数量”不解释单词定义LLM 就可能按“连字符复合词是一个词”的常见语料习惯去生成测试。这说明LLM 生成测试时的“隐性假设”并不是凭空出现的它直接来源于需求描述的详细程度。需求描述里的模糊空间就是 LLM 发挥“常识”补全的空间。4.3 边界值测试最容易暴露测试偏见再看一个小实验。假设需求是“实现一个函数判断年龄是否成年成年标准是 18 岁”。LLM 生成的测试可能出现两种情况# 版本 1 def test_age_18(): assert is_adult(18) is True def test_age_17(): assert is_adult(17) is False# 版本 2 def test_age_18(): assert is_adult(18) is False def test_age_19(): assert is_adult(19) is True两种测试分别对应“大于等于 18”和“大于 18”两种规则。如果需求没有写清楚LLM 可以用两种方式理解。而这两种测试会让严格遵循“大于等于”的实现和严格遵循“大于”的实现分别胜出。边界值测试是 LLM 最容易出错、也最容易体现偏见的场景。因为它通常不是逻辑问题而是需求语义问题。逻辑上两种实现都能自洽只是业务上只能二选一。5. 常见问题与排查思路5.1 运行测试时报 “no tests found for given includes:”这个问题在收集 LLM 生成的测试文件时经常遇到。刚把 LLM 生成的测试代码复制到项目里运行 pytest 却提示ERROR: no tests found for given includes:常见原因有三个测试文件名不是test_*.py或*_test.pypytest 默认不收集LLM 生成的测试文件里 import 了不存在的模块导致整个文件收集失败命令行指定的测试节点 ID 和实际测试函数名不匹配。排查思路# 先检查 pytest 能否收集到测试 python -m pytest --collect-only -q # 再单独运行某个文件 python -m pytest test_text_utils_v1.py -v如果文件没被收集先检查文件名如果提示 import 错误检查测试文件里的from xxx import yyy是否对应实际模块和函数名如果是指定节点确保类名::方法名写对了。更稳妥的做法是直接运行整个目录让 pytest 自动发现测试。5.2 LLM 生成的断言自相矛盾有时 LLM 在长测试文件里会出现前后矛盾。比如前面断言state-of-the-art是 1 个词后面又断言另一个类似格式的字符串是多个词。这通常是因为 LLM 在长上下文中丢失了最初的规则设定。处理方法不是机械地删掉一条断言而是回到需求文档把规则明确下来再人工修正冲突断言。这也是“LLM 生成测试必须人工 review”的重要原因。5.3 不同 LLM 生成同一需求的测试差异过大不同 LLM 的训练偏好不同生成的测试集会很大差异。甚至在同一个 LLM 下换一种提示词风格测试断言也会变化。面对这种差异不要迷信任何一个输出。可以把多组测试合并、去重、再补充边界值形成一个更完整的测试集合。如果担心“共谋”可以让生成测试的模型和生成实现的模型分开。5.4 LLM 生成的测试对性能或类型做了不现实的假设有些 LLM 测试会假设函数在超大输入下也能快速返回或者在输入非法类型时默认不抛异常。这些假设往往是训练数据中常见模式的混合不一定符合你的工程约束。遇到这种情况优先检查测试是否与你项目的实际错误处理策略一致。测试不是越“严格”越好它必须反映业务契约。6. 最佳实践与工程建议6.1 把测试生成纳入需求澄清流程既然 LLM 生成的测试会把隐性假设写进断言那么最有效的控制手段就是在生成测试之前先在需求层面把边界条件说清楚。一个实用的做法是把需求描述和“边界条件清单”一起提交给 LLM。比如请实现函数count_words(text)。要求单词由字母或数字组成连字符不作为单词内部字符state-of-the-art按 4 个单词计数标点符号不参与计数空字符串返回 0输入非字符串时抛出TypeError。请根据以上规则生成 pytest 测试用例。把规则前置到提示词中可以大幅减少测试生成的随机性。6.2 多模型交叉生成扩大测试覆盖面在测试生成场景中单一 LLM 的输出相当于“一个人的主观意见”。更合理的方式是让多个 LLM 分别生成测试然后合并取并集或按需求规则筛选。合并测试时要注意去重保留那些能表达不同语义假设的用例。这样既保留了 LLM 的效率优势又避免被某一个模型的偏好带偏。6.3 用需求评审清单约束 LLM给 LLM 一个结构化的评审清单让它逐项生成测试比让它自由发挥更可靠。推荐清单正常输入空输入边界值特殊字符不同类型输入超大输入并发或重复调用如适用。每生成一组测试都对照清单检查是否有遗漏。这相当于把测试设计经验固化到提示词里。6.4 在评估场景中隔离“测试生成偏差”如果你是做代码生成模型评估的要尤其注意如果测试和实现都来自同一个 LLM 体系模型可能会倾向于生成“自己最容易通过的测试”。这会导致评估结果虚高。一种缓解策略是实现模型和测试模型分开另一种策略是多组测试交叉验证取更稳定的指标。就像工程环境中不能只依赖一条用例评价系统一样模型评估也不能只依赖一组 LLM 测试。6.5 落地工作流建议综合来看一个比较稳妥的 LLM 测试生成工作流是用自然语言写出需求并显式列出所有边界规则让 LLM 生成测试初稿人工快速 review 测试断言重点检查边界值和异常处理把测试纳入 pytest 或其他测试框架运行如果发现实现和测试冲突先回到需求判断“哪一边错了”沉淀常见的边界规则模板下次直接复用。这套流程兼顾了 LLM 的效率和人工的专业判断比较适合实际项目落地。7. 总结与下一步学习方向回到本文开头的那个现象同一份需求、同一个实现因为 LLM 生成的测试不同出现了完全不同的胜负结论。这背后是“测试即规格”的深层逻辑——测试断言决定了什么是正确行为而 LLM 在生成断言时会带入大量隐性假设。读到这里你应该掌握了几件事LLM 生成测试并不中立它会通过边界值、输入清洗策略和异常处理偏好影响实现的选择在需求模糊的场景下测试对胜负的影响尤其明显通过把边界规则写进提示词、多模型交叉生成、人工 review 断言可以减少这种偏差。下一步可以试着在真实项目里做一个小实验找一个你自己写的函数去掉边界说明让 LLM 生成测试再换一种更精确的需求描述让 LLM 生成另一组测试观察两组测试对实现的影响。你可能会发现之前很多“实现不对”的判断其实只是“测试假设和实现假设不一致”。如果本文对你有帮助可以收藏备用后续遇到 LLM 生成测试相关的问题时再翻出来对照排查。