跳转至

Can LLMs Generate High-Quality Test Cases for Algorithm Problems? TestCase-Eval

会议: ACL 2025 (Short)
arXiv: 2506.12278
代码: https://github.com/FlowRays/TestCase-Eval
领域: 文本生成
关键词: 测试用例生成, 算法题, 代码测试, 故障覆盖, LLM评估

一句话总结

提出 TestCase-Eval 基准评估 LLM 生成算法题测试用例的能力，包含 500 道 Codeforces 算法题和 10 万条人工解答，聚焦两个任务——故障覆盖（测试集能覆盖多少潜在错误）和故障暴露（能否为特定错误代码生成暴露性测试），对 19 个 SOTA LLM 的评估揭示了当前模型在测试生成上的能力和局限。

研究背景与动机

  1. 领域现状：LLM 在代码生成上表现出色，但测试用例生成——检验代码正确性的关键环节——研究较少。高质量测试用例应该能发现代码中的各种 bug。
  2. 现有痛点：(a) 缺乏系统基准评估 LLM 的测试生成能力；(b) 不清楚 LLM 生成的测试用例是否能覆盖多样的故障模式；(c) 针对特定错误生成定向测试用例更具挑战性。
  3. 核心矛盾：生成代码的 LLM 可能生成测试用例来测自己的代码——但测试质量和代码质量是不同的能力维度。
  4. 本文要解决什么？ 构建系统基准并全面评估 LLM 在算法题测试用例生成上的能力。
  5. 切入角度：利用 Codeforces 平台的大量人工提交（含正确和错误解答）作为故障检测的 ground truth。
  6. 核心idea一句话：用10万真实人工解答验证LLM生成的测试用例是否真的能发现bug。

方法详解

整体框架

两个评估任务：(1) 故障覆盖（Fault Coverage）——给定算法题，LLM 生成一组测试用例，评估这些测试能覆盖多大比例的潜在错误类型（通过在 10 万人工解答上运行统计）；(2) 故障暴露（Fault Exposure）——给定算法题+一段特定的错误代码，LLM 生成能暴露该错误的测试输入。

关键设计

  1. 故障覆盖评估:
  2. 做什么：衡量 LLM 测试集的广度
  3. 核心思路：从 10 万人工解答中筛选出错误解答，统计 LLM 生成的测试集能让多少错误解答产生错误输出
  4. 指标：覆盖率 = 被检出的错误解答数 / 总错误解答数

  5. 设计动机：好的测试集应该能覆盖各种常见的 bug 模式

  6. 故障暴露评估:

  7. 做什么：衡量 LLM 定向找 bug 的能力
  8. 核心思路：给 LLM 展示一段错误代码，要求生成能让该代码产出错误结果的特定测试输入
  9. 指标：成功率 = 能正确暴露错误的测试比例

  10. 设计动机：这比覆盖更难——需要理解错误代码的具体漏洞

  11. 大规模数据支撑:

  12. 500 道算法题（难度从 800 到 2800 rating）
  13. 10 万人工解答（来自 Codeforces 竞赛提交）
  14. 19 个 LLM 包含开源和闭源模型
  15. 设计动机：大规模数据确保评估的可靠性

损失函数 / 训练策略

  • 纯评估基准——无训练组件
  • 19 个 LLM 包括 GPT-4o、Claude-3.5、Llama-3.1、DeepSeek 等

实验关键数据

主实验

LLM 故障覆盖率(↑) 故障暴露成功率(↑) 说明
GPT-4o 最高之一 最高之一 闭源最强
Claude-3.5-Sonnet 高 高 接近 GPT-4o
DeepSeek-Coder-V2 中高 中高 开源最强
Llama-3.1-70B 中 中 故障暴露较弱
小模型(7B级) 低 低 能力不足

关键发现

  • 故障覆盖比故障暴露容易——大多数 LLM 能生成一般性测试集但难以针对性找 bug
  • 问题难度越高，LLM 测试生成能力下降越快——rating>2000 的题目测试质量锐降
  • 代码能力和测试能力正相关但非等价——有些模型写代码好但测试能力一般
  • 边界案例测试是 LLM 的弱点——大多数 LLM 倾向于生成"正常"输入而非边界/极端输入
  • 闭源模型整体优于开源，但差距在缩小

亮点与洞察

  • "测试能力 ≠ 编码能力"是重要发现——评估 LLM 不应只看代码生成，还应看测试生成。
  • 10万人工解答作为ground truth是独特且有价值的资源——可以验证测试的实际 bug 发现能力。
  • 故障暴露任务特别有挑战性——需要深入理解代码的语义和潜在漏洞。
  • 该基准可用于评估和改进 LLM 的代码理解能力。

局限性 / 可改进方向

  • 仅覆盖算法竞赛题——真实软件的 bug 模式更复杂
  • 仅评估功能正确性测试——性能/安全等其他测试类型未涵盖
  • Codeforces 解答可能已在 LLM 训练数据中——存在数据泄露风险

相关工作与启发

  • vs FEA-Bench: FEA-Bench 评估仓库级代码生成；TestCase-Eval 评估测试生成——不同角度
  • vs HumanEval: HumanEval 只有简单测试用例；TestCase-Eval 专注测试质量
  • vs LLM-based test generators: 之前的 LLM 测试生成工作缺乏系统评估；本文提供了标准基准

评分

  • 新颖性: ⭐⭐⭐⭐ 首个系统评估LLM测试生成能力的基准
  • 实验充分度: ⭐⭐⭐⭐⭐ 500题+10万解答+19个LLM，规模大
  • 写作质量: ⭐⭐⭐⭐ 任务定义清晰
  • 价值: ⭐⭐⭐⭐ 对代码LLM的评估和改进有价值