Lua和C混合组件的新增代码覆盖率检查怎么处理

交流互助区
1

背景

我在storage组件里面的sml层新增了大量C代码，最后提交的时候因为C的部分无法编写UT导致新增代码覆盖率不达标，想问一下这种情况应该怎么处理

分析

storage类似的提交： 【修改描述】sml库代码移到storage仓-storage-AtomGit | GitCode

image
image1185×126 18.9 KB

https://ci-log.openubmc.cn/storage/163/coverage_2025_10_29_20_30_46.html
image
这里的代码屏蔽是如何解决覆盖率不达标的问题的

2

答案内容由AI生成，仅供参考：

五、总结与建议

项目 建议
:file_folder: 不可测 C 代码 使用 --coverage_exclude 排除
:white_check_mark: 可测 Lua 逻辑 必须编写 UT，确保覆盖率达标
:memo: PR 提交说明 主动说明屏蔽原因及范围
:locked_with_key: CI 门禁配合 支持人工审核与临时放行机制
点击此处查看详细分析解答

Lua和C混合组件的新增代码覆盖率检查处理方案

当在 storage 组件的 sml 层新增大量 C 代码时，由于无法为这些 C 代码编写单元测试（UT），会导致新增代码的覆盖率不达标，从而影响代码合并门禁通过。以下是从架构机制、工具支持和实践流程三个层面提供的完整解决方案。

一、问题背景分析

在 storage 组件中，SML（System Management Library）层通常包含大量与硬件直接交互的 C/C++ 代码。这类代码具有以下特点：

  • 难以进行单元测试：依赖底层硬件或系统资源，难以在 UT 环境中模拟。
  • 属于基础适配代码：如驱动封装、寄存器访问、芯片通信等，逻辑简单但不可或缺。
  • 占比较高：一次提交可能新增数百行 C 代码，显著拉低整体增量覆盖率。

因此，若强制要求所有新增 C 代码都必须被 UT 覆盖，则会严重阻碍正常开发流程。

二、解决方案：代码屏蔽机制（Code Exclusion）

openUBMC 的 CI 门禁系统支持通过 代码屏蔽（Code Exclusion）机制 来合理排除某些无法测试的代码区域，避免其影响覆盖率统计结果。

1. 什么是代码屏蔽？

代码屏蔽是指在覆盖率分析阶段，将指定文件或代码段排除在覆盖率计算之外。这适用于：

  • 自动生成的代码
  • 硬件相关驱动代码
  • 适配性封装代码
  • 第三方库代码

:magnifying_glass_tilted_left: 参考链接：openLiBing

该页面展示了某次 MR 提交中的覆盖率检查报告，其中明确列出了需要“代码屏蔽审核”的内容。

2. 如何配置代码屏蔽？

方法一：使用 --coverage_exclude 参数（推荐）

在执行 bingo test 命令时，可通过 --coverage_exclude 参数指定一个白名单文件，列出不需要参与覆盖率统计的源码路径。

bingo test -ut -cov --coverage_exclude ./coverage_exclude.txt

其中 coverage_exclude.txt 示例内容如下：

# 排除 sml 层的 C/C++ 源文件
src/lualib_src/1_sml/*.cpp
src/lualib_src/1_sml/*.c
src/lualib_src/1_sml/*.h

此方式可在本地测试和 CI 流程中统一应用，确保覆盖率报告不包含这些文件。

方法二：在构建配置中声明排除规则

在组件的 test 配置节中定义 coverage_exclude 字段（取决于项目配置结构）：

test:
  coverage_exclude:
    - "src/lualib_src/1_sml/**/*.c"
    - "src/lualib_src/1_sml/**/*.cpp"

CI 系统会自动读取该配置并在生成覆盖率报告时跳过指定路径。

三、门禁流程中的应对策略

1. 主动申报 + 审核机制

当提交包含大量不可测 C 代码时，应遵循以下流程：

  1. 在 PR/MR 描述中说明情况：

    • 明确指出新增了哪些 C 代码
    • 说明为何无法编写 UT（如依赖硬件、仅做封装等）
    • 提供 coverage_exclude.txt 文件路径

  2. 提交代码屏蔽申请：

    • CI 系统检测到覆盖率不足后，自动生成屏蔽待审核项
    • 相关负责人需登录 openLibing 平台查看并审批

  3. 审批通过后门禁放行：

    • 审批完成后，系统将临时允许本次 PR 的覆盖率不达标
    • 或自动加载屏蔽规则重新生成覆盖率报告

2. 保证其他部分的高覆盖率

尽管 C 代码可以被排除，但仍需确保其他可测部分（尤其是 Lua 层逻辑）具有较高的测试覆盖率。

建议做法：

  • 为 Lua 调用接口编写完整的 UT 和 IT
  • 使用 luacov 工具验证 Lua 代码覆盖率是否达到标准（如 ≥80%）
  • 在 temp/coverage/luacov.report.html 中查看详细报告

四、参考案例：storage 组件实践

根据您提供的提交记录：

【修改描述】sml库代码移到storage仓-storage-AtomGit | GitCode

该提交涉及将 SML 库从独立仓库迁移至 storage 组件，必然引入大量原有 C/C++ 代码。

:white_check_mark: 正确处理方式应为：

  1. 创建 coverage_exclude.txt 文件，排除 src/lualib_src/1_sml/ 下的所有 .c/.cpp 文件
  2. 在 bingo test 中启用 --coverage_exclude
  3. 在 MR 描述中注明：“SML 层 C 代码已屏蔽，因依赖硬件环境无法 UT”
  4. 提交后等待门禁系统触发审批流程，并由负责人完成审核

五、总结与建议

项目 建议
:file_folder: 不可测 C 代码 使用 --coverage_exclude 排除
:white_check_mark: 可测 Lua 逻辑 必须编写 UT，确保覆盖率达标
:memo: PR 提交说明 主动说明屏蔽原因及范围
:locked_with_key: CI 门禁配合 支持人工审核与临时放行机制

:white_check_mark: 最终建议命令

# 执行带排除规则的覆盖率测试
bingo test -ut -cov --coverage_exclude ./coverage_exclude.txt

并通过门禁平台完成代码屏蔽审核，即可顺利通过覆盖率门禁检查。

相关链接：

  1. account组件本地IT失败
  2. rackmount组件测试覆盖率失败
  3. bmcgo gen工具优化建议
  4. 【启航行动】openUBMC社区开发者赋能培训（第2期）--openUBMC整体框架&代码结构
  5. 组件的独立测试 | 文档中心 | openUBMC
3

查看bingo最新issue，发现 [任务]: dt覆盖率测试支持组件同时修改c和lua代码 - openUBMC/bingo - AtomGit | GitCode
对应PR： 无test_package目录不计算c代码增量覆盖率-bingo-AtomGit | GitCode
即默认情况下不再计算C代码增量覆盖率 @xuhaijun 类似PR考虑合入25.12 LTS分支吗

4

PR对应的组件仓是bingo，你升级到新版本的bingo即可，合入25.12分支是指什么？

5

这个PR是合入的main分支，没有合入br_release_openUBMC2512_20261231_LTS，基于稳定性考量，大家更倾向于使用LTS分支

image
image605×380 27.9 KB

6

bingo工具类软件，单分支演进，新功能会有兼容性处理，用户升级到最新版本就行。