以下按LDRA Testbed来写。Testbed里覆盖率看起来“不准”，常见原因往往不是工具本身只算错了一点，而是你看的覆盖率口径、插桩构建、交付构建和编译优化根本不是同一件事。LDRA官方对结构覆盖的表述本身就把源码覆盖和对象码覆盖分开来看，同时强调编译器优化会改变控制流，必要时要做Source to Object Code Traceability和Object Code Verification。

　　一、Testbed代码覆盖率不准

　　这一步先不要急着怀疑报告数值，而要先把“你现在到底在看哪一种覆盖率”弄清楚。只要覆盖率口径和构建口径没对齐，后面看到的百分比再漂亮，也不一定能代表最终交付程序的真实执行情况。

　　1、先确认你看的到底是源码覆盖还是对象码覆盖

　　LDRA官方明确说明，结构覆盖通常首先指源码层面的statement、decision、MC/DC等覆盖，但在高完整性场景下也可能需要对象码级别的覆盖和源到目标代码追踪。如果团队把源码覆盖结果直接当成交付可执行文件的最终结论，最容易出现“看起来全覆盖，实际仍有漏项”的误判。

　　2、先确认本次测试是否真的用了覆盖率采集链路

　　LDRA官方把Testbed和LDRAcover都定义为覆盖率分析的核心能力，但前提是当前这轮测试确实走了对应的动态分析和覆盖采集流程。排查时先确认这次执行是不是带了正确的Testbed覆盖配置、是不是在真正的测试构建上跑的，而不是把一次普通运行的结果误当成覆盖率结果。

　　3、再核对测试构建和交付构建是不是同一套口径

　　如果单元测试用的是低优化调试构建，而你最后交付的是高优化发布构建，那么同一段源码在目标码层面可能已经不是同一套控制流。LDRA关于对象码验证的说明明确指出，编译后的对象码控制流不必然是源码控制流的镜像，这正是很多“覆盖率不准”争议的根因。

　　4、编译优化一高，先怀疑控制流和防御代码被改写

　　LDRA官方专门提醒，编译优化可能把看似合理的防御性代码删除，或者改变源码中的控制结构和对象码中的实际路径。只看源码覆盖时，某些路径看似被测试到了，但在最终可执行文件里可能已经被优化掉，或者反过来生成了额外目标码。

　　5、单元测试通过不代表系统目标码覆盖也可信

　　LDRA官方白皮书直接指出，同一个函数在单元测试桩环境下生成的对象码，可能与它在完整系统里生成的对象码差别很大。所以如果你是在桩环境下拿到“覆盖率很好看”的结果，但整机或完整集成后结论变了，这并不罕见。

　　二、Testbed编译选项与优化影响怎么排查

　　这一节的目标是把问题从“覆盖率不对”缩到“哪一组编译选项导致覆盖率口径变化”。最有效的方法不是直接改一堆参数，而是固定编译器、固定目标、固定优化级别，然后做可对照的两到三组构建。

　　1、先锁编译器版本、目标架构和优化级别

　　排查第一步就是把编译器版本、目标芯片、链接方式和优化级别写成固定清单。因为LDRA官方对对象码验证的说明反复强调，源码到对象码的映射关系高度依赖编译器和生成条件，不锁这些前提，后面比较没有意义。

　　2、做一组低优化构建和一组发布构建对照

　　最实用的办法是至少准备两组构建，一组低优化或便于调试的构建，一组真实发布构建，再在同一套测试输入上比较覆盖结果。如果低优化下覆盖正常、发布构建下覆盖异常，问题大概率就不是测试用例缺失，而是优化改变了控制流或生成了额外对象码。

　　3、把预处理宏、条件编译和库版本一起纳入排查

　　覆盖率异常不一定只来自-O选项，预处理宏、特性开关、库版本和链接布局同样会改变最终对象码。LDRA关于完整系统对象码和单元环境对象码可能显著不同的说明，本质上也在提醒你，构建上下文本身就是变量。

　　4、重点检查内联、死代码消除和不可达路径处理

　　如果某些函数在源码里看起来存在，但在对象码里被内联、折叠或删除，源码覆盖率和最终交付行为就会错位。LDRA对compiler optimization的官方说明特别点到，不可验证的路径和防御性代码最容易在优化后失真。

　　5、源码覆盖解释不通时，直接上对象码验证

　　当你已经确认测试输入没问题、源码覆盖也够高，但结果仍然和实际可执行行为对不上时，就不要再围着源码报表打转。LDRA官方把TBobjectbox定义为完整的Object Code Verification方案，既能做source to object traceability，也能做对象码覆盖分析，这就是这种场景下最直接的收敛路径。

　　三、LDRA Testbed覆盖率复核该怎么做

　　真正让覆盖率结果“站得住”的，不是一张报表，而是一套固定的复核动作。只要把构建口径、覆盖率口径和对象码差异检查固定下来，后续无论是版本升级还是编译器升级，排查都会快很多。

　　1、先固定覆盖率口径

　　先明确本轮看的是statement、decision、MC/DC，还是已经扩展到source to object code traceability。LDRA官方对不同标准下的覆盖目标划分很清楚，口径不先写明，后续讨论很容易混掉。

　　2、再固定构建口径

　　把编译器版本、优化级别、预处理宏、目标板卡和链接方式一并归档，不允许一边改编译口径一边比较覆盖率。这样后面出现差异时，才能明确是测试变化还是构建变化。

　　3、对同一套测试输入做双构建对照

　　至少保留一组低优化构建和一组发布构建，用同一批测试输入复跑并比较覆盖率结果。这样最容易识别“测试不足”和“优化改流”分别占多少因素。

　　4、对未覆盖项继续下钻到对象码

　　如果源码层面已经解释不通，就不要停在源码报表上。LDRA官方给出的标准做法就是把对象码验证拉进来，确认有没有编译器新增代码、控制流变化或不可直接追踪的序列。

　　5、把报表和结论一起归档

　　最终归档时不要只留一份百分比报表，还要把当时的编译口径、优化级别、未覆盖项说明和对象码验证结论一起留下。这样下次再出现“覆盖率不准”的争议时，能直接按同一套证据链复查。

　　总结

　　按LDRA Testbed来看，代码覆盖率“不准”最常见的根因不是测试工具算错，而是源码覆盖、对象码覆盖、编译优化和交付构建被混在一起解读。排查时先分清覆盖率口径，再锁定编译器和优化级别，用低优化构建与发布构建做对照，必要时直接引入TBobjectbox做对象码验证和源到目标代码追踪。把这套复核动作固定下来，后面无论是编译器升级还是发布构建变化，定位都会快很多。