HumanEval：测试用例覆盖

可视化演示

展示HumanEval测试用例覆盖：功能/边界/异常用例覆盖度、覆盖度提升对评测的影响、高覆盖提升评测有效性，通过交互理解评测可信度的关键因素。

评测原理基础

教了二十年编程的张老师，这学期想从两百名学生里挑出真正会写代码的人。他连夜出了一张试卷：164 道编程题，每道题给出函数签名和一段中文描述，让学生补全实现。可当他真的开始判卷，才发现问题——程序题不像选择题，没有标准答案可以比对，两百份代码逐行读下来，他一个月都不用睡觉了。

2021 年，OpenAI 在 Codex 论文里也遇到了同样的难题。他们要评测大模型写代码的能力，于是发布了 HumanEval：164 道由人类专家手写的编程题。每道题由三部分组成：函数签名（比如 def sum_list(xs):）、任务描述（docstring）、以及几组隐藏在幕后的测试用例。和文本类评测不同，代码有一个天然优势——程序行为可以被机器客观检查，不必依赖人的主观判断。

张老师的做法，就是把“水平高低”这种模糊概念压缩成一道清晰的是非题：程序必须通过测试集里每一条用例才算正确。这个判定规则用数学写出来就是：

就这样，张老师的考试变成了一本会自己批改的试卷册。每一道题的命运，完全系在那些藏在幕后的测试用例身上——这是整个 Humaneval 评测体系的地基。

测试用例角色

出完试卷，张老师开始写评分细则。以“列表求和”这道题为例，他提笔写下了三条用例：输入 [2, 4, 6] 应该输出 12；输入 [3] 应该输出 3；输入 [-2, 3, 7] 应该输出 8。这三条用例就像是考场上的三个检查点，学生的代码必须逐点通过，才能拿到这道题的分数。

在 HumanEval 里，这些检查点是 Python 的 assert 风格单元测试。它们承担着三个角色。第一个角色是功能验证：确认代码能完成题目描述的基本任务，相当于检查学生“有没有听懂题目”。第二个角色是边界检测：试探空输入、极大极小值、特殊情况，看看代码在悬崖边上会不会失足。第三个角色是评分依据：模型从头到尾只能看到函数签名和描述，看不到任何一条测试，因此无法针对“已知答案”作弊。

一条测试用例的本质，就是一次输入与输出的严格比对：

张老师靠着这几条检查点判卷，就像厨师靠尝一口菜判断整锅汤的味道——每尝一口就多一分把握。可问题是，他只尝了三口。

覆盖缺口风险

考试结果出来了，学生小陈的“列表求和”得了满分，张老师却隐隐觉得不对劲。小陈的代码是把第一个元素直接当初始值，然后遍历剩余元素累加。用张老师的三条用例一测，全绿通过。可如果传入空列表 []，这段代码会直接崩溃——因为空列表根本没有“第一个元素”。

这就是典型的覆盖缺口：HumanEval 每个问题平均只有约 7.7 条用例，远远覆盖不了所有输入条件。空列表、极大整数、重复元素、特殊字符……这些边界条件就像没有设防的关卡，放走了大量“表面正确、暗藏 bug”的代码。后来研究者构建了 HumanEval+ 扩展套件，把用例扩充到原来的约 80 倍，发现不少模型的 pass@1 明显下滑——说明原来的高分里，掺着相当一部分“侥幸通过”。

为什么几条用例的差别会这么大？用数学看一眼就明白了。假设一段含 bug 的代码，面对第 i 条用例时有 p_i 的概率侥幸通过，那它通过全部 N 条用例的概率是：

小陈的成功不是实力，是运气。他那道“全绿”的答案之所以能骗过判卷，不是因为写对了，而是因为张老师的评分细则太薄——每一道没设防的边界，都是给侥幸留下的后门。

用例设计策略

考试风波之后，年轻的助教主动请缨，帮张老师扩充评分细则。助教没有简单地把正数列表多加几组，而是先问了一个问题：这道题的输入空间到底长什么样？这就像一位认真的美食品鉴师，不会只吃刚出锅的那一口——还要尝尝放凉的、回锅的、加过量的盐的，才能判断这道菜真实的水准。

这种思考方式在软件测试里叫“等价类划分”：把行为相似的输入归成一类，从每一类里挑一个代表来写用例。对“列表求和”来说，正数列表、负数列表、零元素列表、空列表、超长列表，各自就是一类。每类挑一条，用最少的用例覆盖最广的输入空间。

在此基础上，还要做边界值分析。空输入、单元素列表、极大极小数值，这些悬崖边上的输入最容易暴露 bug，必须单独设卡。再往深处，还要考虑组合条件和异常输入：多参数函数要测“全真、全假、一真一假”的组合；遇到类型不匹配、超大整数、特殊字符时，代码能不能体面地失败而不是崩溃。这些策略可以浓缩成一个数学表达：

助教的新评分细则一上考场，不仅拦住了小陈的空列表崩溃，还揪出了另外三个学生的隐藏 bug。这件事让张老师明白了一个道理：好用例来自对问题空间的拆分，而不是用例数量的堆叠。

评分指标解读

考试进入第二轮，张老师做了一个大胆的决定：每个学生可以交多份答案，只要其中任何一份通过了检查点，这道题就算答对。他给了学生 k 次机会，让学生们高兴坏了——小陈的同桌交了三次答案，第三次终于蒙对了一个边界情况，拿到了一分。

在 HumanEval 里，这个“多次机会”的设定就是 pass@k。模型为每个问题独立采样 n 个候选程序，其中有 c 个通过了全部测试用例。pass@k 问的是：如果从中随机挑 k 个，至少捞到一个正确解的概率是多少？如果用最简单的方式直接算，很容易得到有偏的估计；论文里用的是无偏估计公式：

但张老师很快发现，多给机会并不总是坏事，真正危险的是评分细则太薄。当测试用例覆盖不足时，pass@k 的每一个 k 值都被注了水——“正确”变成了“碰巧骗过了少数检查点”。机会越多，运气就越容易伪装成实力。

评测质量维护

考试结束后，张老师把助教叫到办公室，认真复盘了整套评分细则。他意识到，一份值得长期使用的试卷，必须像软件团队的测试套件一样持续维护：人工审查每一条用例是否真的表达了题意，发现漏洞就补，跑完一轮再迭代。这不是一次性的工作，而是一个反复循环。

在真实的评测体系里，这套维护动作对应着几件具体的事。人工审查：确认每条用例断言的是“正确行为”而非“错误行为”，防止测试本身写错。用例扩增：像 HumanEval+ 那样，用程序化生成加人工筛选的方式，把边界用例铺满输入空间。持续迭代：警惕数据污染——如果模型训练时见过这些用例，分数就会失真，需要定期更换或扩展测试集。

维护的效果，可以用覆盖率来衡量。覆盖率就是“被用例摸到的条件数”占“全部该摸的条件数”的比例：

经过整整一个月的维护，张老师的评分细则从每道题 3 条扩展到了 20 多条，覆盖了空值、极值、异常等所有他能想到的边界。他终于敢对学生们说：这份试卷，确实能测出真本事。

未来演进方向

张老师的试卷在学校里出了名，其他老师纷纷来抄作业。可没过多久，最聪明的学生又开始满分了——他们摸清了出题套路。于是学校决定升级考试制度：不再只考单函数，而是考真实的工程任务；不再只有 Python，而是加入 JavaScript、Java、SQL；不再只看函数返回值，而是看整个仓库能不能跑通测试。

这正是 HumanEval 之后整个评测生态的演进路线。HumanEval 本身有天然的局限：只有 Python、只写短函数、只看单函数正确性，测不出真实工程能力。后续的 MBPP 增加了更多基础编程题，DS-1000 聚焦数据科学场景，SWE-bench 直接让模型修复真实代码仓库里的 issue——但无论怎么演进，最核心的逻辑没变：每个任务背后都藏着测试用例，用覆盖度决定对错。

在这个演进中，“覆盖”始终是地基。多语言扩展要求每种语言都有健壮的测试套件；复杂任务要求用例能模拟真实的调用上下文；仓库级评测要求隐藏测试覆盖到集成环节。再加上数据污染的追踪、动态执行的验证、智能体式评测的引入，未来的基准会越来越难“碰运气”。

张老师在学期总结上说了一句让学生们记了很多年的话：任何考试的信誉，都藏在考官看不见的评分细则里。对大模型评测来说，这句话翻译过来就是——测试用例覆盖，决定了你眼前那份漂亮分数，到底是真金还是掺了水的沙。

AI 应用场景

Python 演示

def sum_list(xs):    """返回列表元素之和（空列表会抛异常，即边界遗漏的典型 bug）。"""    total = xs[0]    for x in xs[1:]:        total += x    return total  def run_case(func, inp, expected):    """执行单条测试用例，异常也算失败。"""    try:        return func(inp) == expected    except Exception:        return False  BASIC_CASES = [    ([2, 4, 6], 12),    ([3], 3),    ([-2, 3, 7], 8),] EDGE_CASES = [    ([], 0),    ([0, 0, 0], 0),    ([-5, -1], -6),    (list(range(100)), 4950),]  def evaluate(func, cases):    """返回 (通过条数, 总条数, 失败用例列表)。"""    failed = []    passed = 0    for inp, expected in cases:        if run_case(func, inp, expected):            passed += 1        else:            failed.append(inp)    return passed, len(cases), failed  def leak_probability(p_single, n_tests):    """若每条用例有 p_single 概率放走 bug，N 条时的漏判率。"""    return p_single ** n_tests  def main():    p0, n0, f0 = evaluate(sum_list, BASIC_CASES)    p1, n1, f1 = evaluate(sum_list, EDGE_CASES)    print(f"原版 3 条用例: {p0}/{n0} 通过, 失败输入 {f0}")    print(f"扩展 4 条用例: {p1}/{n1} 通过, 失败输入 {f1}")    print(f"单条用例放走率 0.7 时: 3 条套件漏判率 {leak_probability(0.7, 3):.3f}, "          f"10 条套件漏判率 {leak_probability(0.7, 10):.4f}")  if __name__ == "__main__":    main()

1. total = xs[0]直接拿第一个元素当初始值，空列表在这里抛 IndexError，是有意埋下的边界 bug。
2. except Exception:评测时异常也按“失败”处理，和真实评测套件的容错逻辑一致。
3. BASIC_CASES = [...]对应原版 HumanEval 稀疏的普通输入用例，只覆盖常见路径。
4. EDGE_CASES = [...]对应扩展测试套件：空列表、全零、负数、超长列表。
5. return p_single ** n_tests实现正文第三节的漏判率连乘公式：用例越多，漏判率越小。

常见误区

面试题