[Paper] SPARC：场景规划与推理用于自动化 C 单元测试生成

Source: arXiv - 2602.16671v1

概述

本文提出了 SPARC，一个新颖的框架，将大型语言模型（LLM）生成与经典程序分析相结合，自动为 C 代码创建高质量的单元测试。通过将模型的推理基于程序的控制流图和精心挑选的辅助操作集合，SPARC 大幅降低了通常困扰纯 LLM 基础测试合成的“跳转到代码”失败。

关键贡献

• 神经符号流水线，将 LLM 驱动的合成与静态分析（CFG）以及经过验证的 操作映射（可复用的辅助函数）相结合。
• 基于场景的测试生成：每个测试针对特定的执行路径，确保对分支和边缘情况进行系统化覆盖。
• 迭代自我纠正循环，将编译错误和运行时反馈返回给 LLM，自动修复无法编译或不稳定的测试。
• 在 59 个真实世界和算法 C 代码对象上的实证评估，显示相较于普通提示基线，行覆盖率提升最高达 31%，分支覆盖率提升 26%，并且在变异分数上与符号执行器 KLEE 竞争。
• 以人为本的度量指标：SPARC 的测试在可读性和可维护性评分上获得开发者更高的评价，且 94.3% 的生成测试在修复循环中无需人工干预即可通过。

方法论

1. 控制流图（CFG）提取 – 将目标 C 函数解析以构建 CFG，暴露所有可能的执行路径。
2. 操作映射构建 – 创建一个精心策划的 “实用助手” 库（例如安全指针包装器、内存分配模式）。每个助手在使用前都经过类型检查和单元测试，确保 LLM 只能调用已验证的构建块。
3. 路径针对性提示 – 对于每条 CFG 路径，组装一个提示，内容包括 (a) 描述路径的条件，(b) 列出操作映射中相关的助手，(c) 要求 LLM 输出一个驱动执行沿该路径的测试用例。
4. 迭代验证与修复 – 编译生成的测试；任何语法或类型错误都会被捕获并作为纠正提示反馈给 LLM。随后执行测试；运行时失败（例如段错误、断言违规）会触发另一轮 LLM 引导的修复。该循环重复，直至测试能够编译、运行顺利并满足路径约束。

整体设计通过具体、可验证的程序构件约束 LLM 的创造力，将 “自由形式” 的生成转化为一种有纪律的推理过程。

结果与发现

关键要点

• 场景驱动的方法迫使 LLM 明确考虑每个分支，从而直接提升覆盖率。
• 自我纠正循环消除了大多数编译时失败，这些失败通常导致 LLM 生成的测试不可用。
• 在复杂、指针密集的代码库中，SPARC 的覆盖率与 KLEE 相当或更高，同时生成的人类可读测试——这是符号执行工具常常难以做到的。

实际意义

• 传统 C 代码库：维护数十年历史 C 系统的公司可以在不为每个模块手动编写测试的情况下，快速搭建回归测试套件。
• 持续集成 (CI)：SPARC 可以作为夜间任务集成，在新增函数时自动扩大测试覆盖率。
• 开发者生产力：通过提供可读、可维护的测试，SPARC 减少了审查自动生成代码的开销，使工程师能够专注于更高层次的设计工作。
• 安全测试：更高的分支和变异覆盖率意味着能够更好地检测边缘案例错误，包括低层代码中常见的内存安全问题。
• 工具生态系统：Operation Map 概念可以在项目之间共享，为 C 开发者创建可复用的“LLM 友好”API 接口。

限制与未来工作

• 对准确 CFG 的依赖：复杂的宏使用或条件编译可能会混淆静态分析阶段，限制路径提取。
• 操作映射的维护：辅助库必须与项目特定的编码约定和自定义分配器保持同步，这会带来一定的维护成本。
• 对大规模代码库的可扩展性：虽然作者在 59 个案例上进行了测试，但将路径枚举和迭代修复扩展到数百万行代码可能需要更智能的路径优先级启发式策略。
• 超出 C 语言的泛化：当前设计利用了 C 语言特有的构造（指针、手动内存管理）。将 SPARC 扩展到 C++ 或 Rust 将需要额外的语言特定操作映射和安全检查。

未来的研究方向包括：从现有测试套件中自动发现新辅助函数、基于覆盖率反馈的自适应路径选择，以及与 CI 流水线的更紧密集成，以实现测试生成、执行和缺陷分拣之间的闭环。

作者

• Jaid Monwar Chowdhury
• Chi-An Fu
• Reyhaneh Jabbarvand

论文信息

• arXiv ID: 2602.16671v1
• 分类: cs.SE, cs.AI
• 出版日期: 2026年2月18日
• PDF: 下载 PDF