TestCase-Eval: A Systematic Evaluation of Fault Coverage and Exposure¶
会议: ACL 2025
arXiv: 2506.12278
代码: FlowRays/TestCase-Eval
领域: LLM/NLP
关键词: 测试用例生成, LLM评测, 故障覆盖, 故障暴露, 竞赛编程
一句话总结¶
提出TestCase-Eval基准，包含500道Codeforces竞赛题和10万份人类提交代码，通过Fault Coverage和Fault Exposure两个任务系统评估19个LLM在算法问题测试用例生成方面的能力，发现最强模型Qwen3-32B仅达43.8%暴露率，远低于人类专家的93.3%。
研究背景与动机¶
领域现状: LLM在代码生成领域取得了显著进展，但高质量测试用例的生成——至关重要的软件质量保障环节——尚未得到系统性评估。现有基准如TestEval基于LeetCode使用传统行/分支覆盖率评估，最佳模型已接近100%，区分度不足。
现有痛点: (1) 现有代码评测基准主要关注代码生成能力，测试用例生成作为独立能力被忽视；(2) LeetCode题目难度不够，6.7B参数模型即可达90%+覆盖率；(3) 传统行覆盖/分支覆盖指标在算法竞赛场景下不够精准，无法区分不同层次的错误。
核心矛盾: LLM在代码生成领域不断进步，但我们缺乏足够困难和精细的基准来评估它们是否真正理解程序逻辑并能设计出暴露特定错误的测试用例。
本文目标: 构建一个系统性的、具有挑战性的基准来评估LLM在算法问题测试用例生成方面的能力，包括广泛覆盖多种错误和精确暴露特定错误两个维度。
切入角度: 基于Codeforces竞赛平台，利用真实人类的错误提交（而非合成错误代码）构建评测数据，并设计两个互补的任务：Fault Coverage衡量测试覆盖广度，Fault Exposure评估精准暴露特定漏洞的能力。
核心 idea: 用Codeforces真实错误代码构建基准，通过覆盖率和暴露率双维度评估LLM测试用例生成能力。
方法详解¶
整体框架¶
TestCase-Eval包含两个核心评测任务：(1) Fault Coverage: 给定题目描述，LLM生成N个测试用例，尽可能覆盖更多类型的错误提交，评估指标为 \(\text{Cov}@N = \frac{|\bigcup_{i=1}^{N} \mathcal{F}(t_i)|}{|\mathcal{F}_{\text{total}}|}\)；(2) Fault Exposure: 给定题目描述和一份特定的错误代码，LLM生成一个测试用例精准暴露该代码的错误，灵感来自Codeforces的"hack"环节。
关键设计¶
-
真实错误代码数据收集
- 功能: 提供高质量、多样化的错误代码样本
- 核心思路: 从2024年Codeforces竞赛中收集500道题，每题200份错误提交（共10万份），涵盖C++、Python、Java三种语言。排除需要special judge的题目，确保评测确定性
- 设计动机: 使用真实人类错误而非合成错误，确保错误模式反映实际编程中的真实缺陷分布
-
错误难度分层（Easy/Medium/Hard）
- 功能: 评估LLM在不同难度错误上的表现差异
- 核心思路: 根据错误代码首次失败的测试用例序号（Codeforces平台提供）进行分层——早期失败为Easy，后期失败为Hard，因为后者通常涉及更隐蔽的逻辑错误
- 设计动机: 提供更细粒度的分析，帮助理解LLM在处理简单边界情况和复杂逻辑错误上的能力差异
-
错误类型分析框架
- 功能: 按WA、RE、TLE、MLE四种类型分解分析
- 核心思路: 利用Codeforces平台提供的错误类型标签（Wrong Answer、Runtime Error、Time Limit Exceeded、Memory Limit Exceeded），分析LLM对不同错误机制的检测能力
- 设计动机: 逻辑错误（WA）与资源效率问题（TLE/MLE）需要不同的测试策略，分类分析可揭示LLM的能力边界
损失函数 / 训练策略¶
本文为评测基准工作，不涉及训练。评测通过ExecEval沙箱环境进行代码执行和测试输入评估。同时评估Direct Output和Chain-of-Thought两种提示策略。
实验关键数据¶
主实验¶
19个LLM在TestCase-Eval上的表现（CoT提示）：
| 模型 | Cov@1 | Cov@5 | Cov@20 | Fault Exposure (Overall) |
|---|---|---|---|---|
| Human Expert | 56.2 | 85.7 | 97.2 | 93.3 |
| Qwen3-32B | 50.8 | 82.3 | 95.7 | 43.8 |
| Qwen3-8B | 46.2 | 78.5 | 92.1 | 41.3 |
| R1-Distill-Qwen-32B | 31.9 | 65.3 | 82.6 | 41.6 |
| GPT-4.1 | 45.3 | 67.5 | 80.0 | 36.5 |
| Llama-3.1-70B | 47.8 | 75.4 | 90.9 | 34.3 |
| Qwen2.5-72B | 38.2 | 57.8 | 73.1 | 29.0 |
消融实验¶
按错误类型的Fault Exposure率分解（Top模型）：
| 模型 | WA | RE | TLE | MLE | Overall |
|---|---|---|---|---|---|
| Qwen3-32B | 52.2 | 38.7 | 21.2 | 22.3 | 43.8 |
| R1-Distill-Qwen-32B | 48.0 | 37.8 | 23.9 | 30.3 | 41.6 |
| GPT-4.1 | 42.0 | 35.4 | 20.9 | 25.1 | 36.5 |
| Qwen3-8B | 48.0 | 39.0 | 22.8 | 26.9 | 41.3 |
| Gemma-3-12B | 35.8 | 35.1 | 27.7 | 30.9 | 33.8 |
关键发现¶
- 巨大的人机差距: 最强LLM(Qwen3-32B)的Fault Exposure仅43.8%，人类专家93.3%，差距超过一倍
- 推理模型优势明显: Qwen3系列和R1-Distill等推理导向模型在两个任务上均领先，说明测试用例生成高度依赖逻辑推理能力
- 开源模型强于闭源: Qwen3-32B在覆盖率上超越GPT-4.1（Cov@20: 95.7 vs 80.0）
- 逻辑错误vs资源错误: 所有模型在检测WA和RE方面显著优于检测TLE和MLE，说明LLM更擅长逻辑推理而非效率分析
- CoT显著有效: 链式推理提示在两个任务上均显著优于直接输出提示
- Python代码更易暴露: 由于动态类型和灵活语法，Python代码的错误暴露率高于C++和Java
亮点与洞察¶
- 发现了"测试用例生成"这一被忽视但重要的LLM能力，与代码生成能力并不完全正相关
- 使用Codeforces真实错误代码而非合成数据，保证了基准的生态效度
- Fault Exposure任务极具挑战性——需要同时理解题意和分析错误代码，是理解程序语义的硬核测试
- 推理模型的优势主要来自更强的WA检测能力，暗示逻辑推理能力是核心驱动因素
局限与展望¶
- 仅评估量化指标，未分析LLM生成测试用例时的具体失败模式
- 难度分层基于测试用例序号的启发式方法，非明确错误类型分类
- 未系统测试性能瓶颈（TLE/MLE）的检测能力
- 可扩展至Bug定位和根因分析等更全面的调试任务
相关工作与启发¶
- TestEval: 基于LeetCode的测试生成基准，但区分度不足
- LiveCodeBench: 无污染的代码评测基准，本文在数据时间段选择上借鉴了其思路
- 与Codeforces的"hack"机制天然对齐的评测设计非常巧妙
评分¶
- 新颖性: 4/5 — 填补了测试用例生成评估的空白
- 技术深度: 3/5 — 以基准构建和实验分析为主
- 实验充分度: 5/5 — 19个模型、多维度分析、人类基线
- 实用性: 4/5 — 对理解和改进LLM代码能力有重要参考
- 综合评分: 4/5