[Paper] EmbC-Test：如何使用 LLMs 和 RAG 加速嵌入式软件测试

Source: arXiv - 2603.09497v1

概述

测试嵌入式 C 代码历来工作量大，许多团队在跟上快速发布周期时会遇到瓶颈。论文 EmbC‑Test 提出了一种检索增强生成（Retrieval‑Augmented Generation，RAG）流水线，将大型语言模型（LLM）与项目特定的源代码制品相结合，自动生成高质量的嵌入式软件单元测试。在一次工业案例研究中，该方法将测试工作量降低了最高达三分之二，同时保持了完整的语法正确性。

关键贡献

• 基于 RAG 的测试生成流水线：将大型语言模型与代码、头文件和文档的可检索索引相结合，使模型在目标项目中保持依据。
• 幻觉缓解：在生成之前检索具体代码片段，系统显著降低生成无效或上下文不符的测试代码的风险。
• 实证验证：对真实嵌入式代码库的工业评估显示，语法正确率 100%，运行时验证通过率 85%。
• 生产力提升：测得生成速度约为每小时 270 条测试，估计手动编写测试时间减少 66%。
• 开源工具原型：作者发布了一个最小实现，可嵌入现有 CI 流水线。

方法论

1. 工件收集 – 将所有相关的项目文件（C 源码、头文件、构建脚本和设计文档）使用向量存储（例如 FAISS）进行索引。
2. 检索步骤 – 当请求对特定函数进行测试时，流水线会查询索引，获取语义上最相似的代码片段（函数定义、相关宏、注释）。
3. 提示构建 – 将检索到的片段插入提示中，指示 LLM（例如 GPT‑4‑Turbo）按照预定义的模板（setup、stimulus、assertion）生成单元测试。
4. 生成与后处理 – 对原始 LLM 输出进行解析，使用 clang-format 进行格式化，并使用项目的编译器进行类型检查，以确保语法有效。
5. 运行时验证 – 将生成的测试编译并在硬件在环（HIL）仿真器上执行；通过的测试保留，失败的测试记录下来以供人工审查。

该流水线通过轻量级的 Python 包装器进行编排，便于嵌入现有的构建系统（Make、CMake、Bazel）。

结果与发现

高通过率表明检索到的上下文足以让 LLM 生成功能正确的测试。剩余 15 % 的失败测试主要是由于硬件特定的时序约束，模型仅凭静态代码无法推断出来。

实际影响

• 更快的上市时间：团队可以在一夜之间生成大量回归测试套件，让工程师专注于边缘案例测试和功能开发。
• 一致的测试风格：由于 LLM 采用统一模板，生成的测试代码会自动遵循项目的编码规范。
• 降低入职摩擦：新开发者可以依赖自动生成的测试来了解遗留模块的预期行为，而无需翻阅晦涩的文档。
• CI 集成：该流水线可以作为夜间任务触发，随着代码库的演进持续扩充测试套件。
• 成本节约：对于拥有大量嵌入式产品的公司而言，手动测试工作量降低 66 %，意味着显著的人工成本下降和更少的进度超支。

限制与未来工作

• 硬件特定细微差别：当前模型在处理对时序要求严格或由中断驱动的代码时表现不佳，因为运行时行为依赖于未在静态工件中捕获的外部刺激。
• 领域适应：虽然 RAG 方法可以减轻幻觉现象，但它仍然依赖于已索引文档的质量和完整性；文档稀疏或过时会降低测试质量。
• 检索可扩展性：对于非常大的代码库，索引和查询延迟会成为瓶颈；未来工作可以探索分层检索或增量索引。
• 更广泛的语言支持：原型聚焦于 C；将其扩展到 C++ 或 Rust 嵌入式栈需要对提示模板和验证工具进行调整。

作者建议探索与硬件模拟器更紧密的集成，并引入基于强化学习的反馈回路，以进一步提升生成测试的通过率。

作者

• Maximilian Harnot
• Sebastian Komarnicki
• Michal Polok
• Timo Oksanen

论文信息

• arXiv ID: 2603.09497v1
• 分类: cs.SE
• 发布时间: 2026年3月10日
• PDF: 下载 PDF