LDRA Testbed的代码覆盖率来自动态分析：工具先对待测代码进行插桩，再在主机、模拟器或目标板上运行测试，最后根据回传的执行数据统计哪些语句、分支和函数真正被执行。处理“Testbed怎么设置代码覆盖率，Testbed代码覆盖率统计不完整如何排查”时，关键是把分析范围、插桩版本和实际运行程序对应起来，否则测试明明执行过，报告里仍可能出现大片未覆盖代码。LDRA支持语句、分支/判定、函数调用以及MC/DC等结构覆盖指标。

　　一、Testbed怎么设置代码覆盖率

　　代码覆盖率不能只靠静态扫描生成，必须让经过插桩的程序实际运行。开始配置前，应先确定项目要求统计到什么级别，再决定使用主机测试还是目标机测试。

　　1、先确定需要统计的覆盖类型

　　①打开当前Testbed工程，确认本次动态分析包含的源文件和函数范围。

　　②根据项目要求选择【语句覆盖】、【分支/判定覆盖】或【函数调用覆盖】。

　　③航空、功能安全等项目需要更高结构覆盖时，再确认是否需要【MC/DC】。

　　④不要为了追求数字同时开启全部指标，应按照项目采用的标准和验证目标选择。

　　LDRAcover可以统计Statement、Branch/Decision、Procedure/Function Call以及MC/DC等覆盖指标，并按函数、文件和整个系统汇总结果。

　　2、对待测代码完成覆盖率插桩

　　①确认工程使用的编译器、目标平台和源代码版本已经固定。

　　②在动态分析配置中启用需要的【结构覆盖】采集。

　　③重新生成经过Testbed插桩的源码或测试程序。

　　④检查插桩阶段是否存在无法处理的源文件、编译错误或被排除的函数。

　　⑤重新编译并链接，确保实际执行的是本次生成的插桩版本。

　　LDRA的结构覆盖数据通常通过源代码插桩采集，也就是在测试版本中加入用于记录执行路径的探针。只有插桩后的代码真正运行，后续才会产生有效覆盖数据。

　　3、运行测试并生成覆盖结果

　　①在主机、模拟器或目标板上运行已经插桩的程序。

　　②执行本轮需要统计的单元测试、集成测试或系统测试场景。

　　③保证程序按照正常流程结束，或按项目方式完成覆盖数据回传。

　　④将运行产生的动态数据导回Testbed。

　　⑤生成覆盖报告，分别查看函数、文件和系统级统计。

　　⑥打开未覆盖代码列表，确认哪些语句或分支还没有实际执行。

　　LDRA支持在主机环境以及目标平台上采集结构覆盖，也可以通过系统测试得到大部分覆盖数据，再使用单元测试补充正常运行时难以触发的防御性代码。

　　二、Testbed代码覆盖率统计不完整如何排查

　　覆盖率统计不完整时，先观察具体表现。某几个函数始终是0%，通常更像分析范围或插桩问题；只有部分测试数据缺失，则更可能发生在运行和数据回传阶段；代码明明改过但报告仍显示旧结果，还要检查源码与测试程序是否属于同一版本。

　　1、确认缺失代码有没有被纳入分析范围

　　①打开覆盖报告，找到完全没有覆盖信息的文件或函数。

　　②回到工程分析范围，确认对应源文件确实已经加入本轮动态分析。

　　③检查文件或函数是否被设置为【排除】。

　　④确认条件编译没有让该部分代码在当前构建中被移除。

　　⑤重新完成静态分析和插桩，再查看目标函数是否出现在覆盖模型中。

　　如果某段源码本身没有进入插桩范围，无论后续测试执行多少次，都不会得到对应覆盖记录。

　　2、确认实际运行的是插桩版本

　　①检查本次测试程序的生成时间和输出目录。

　　②确认目标板或模拟环境下载的是最新插桩后的可执行文件。

　　③清理旧的目标文件和中间文件后重新编译。

　　④存在Debug、Release或多个硬件配置时，确认Testbed分析配置与实际运行配置一致。

　　⑤再次运行少量测试，观察原来为0%的函数是否开始产生覆盖数据。

　　这类问题在嵌入式项目中比较常见：分析针对一个Build配置完成，实际烧录的却是另一套可执行程序，最后就会出现测试已执行但覆盖数据对不上源码的情况。

　　3、检查动态数据是否完整回传

　　①确认测试运行结束后确实产生了新的覆盖数据。

　　②目标机测试时检查主机与目标设备之间的数据传输链路。

　　③程序发生复位、异常退出或被直接断电时，重新执行一次正常结束的测试。

　　④批量测试中只有部分用例缺失时，分别检查这些用例是否真正完成。

　　⑤重新导入动态结果，并确认报告生成时间已经更新。

　　结构覆盖依赖运行时采集信息，因此程序中途停止、采集数据没有正确返回，都会造成报告只统计到一部分执行路径。LDRA的动态分析本身就是通过执行插桩代码并分析输出数据完成覆盖统计。

　　4、区分“没有统计”和“确实没有覆盖”

　　①在覆盖报告中定位具体未执行语句和未命中分支。

　　②回到测试用例，确认是否存在能够触发这些路径的输入条件。

　　③防御性分支无法通过正常系统测试触发时，考虑增加针对性的单元测试。

　　④确认属于死代码或不可达代码时，不要为了提高百分比强行编写无意义测试。

　　⑤涉及认证项目时，对未覆盖代码保留明确分析结论和处理依据。

　　LDRA的结构覆盖分析本身就是用于发现测试尚未触达的代码。未覆盖区域可能意味着测试不足，也可能暴露死代码、停用代码或需求与实现之间的问题，因此需要继续分析原因，而不能只关注最终百分比。

　　三、怎样确认覆盖率结果已经可信

　　覆盖率恢复正常后，还要确认数字对应的是当前软件版本和完整测试集合。否则报告即使显示较高百分比，也可能只是旧数据或部分测试结果叠加出来的表象。

　　1、从报告反查几个关键函数

　　①选择几个本轮明确执行过的核心函数。

　　②在覆盖报告中查看【语句】和【分支】命中情况。

　　③再选一个刻意没有执行的分支，确认报告仍显示未覆盖。

　　④比较函数级、文件级和系统级统计是否能够相互对应。

　　⑤重新运行新增测试后，检查覆盖率变化是否符合预期。

　　2、代码变化后重新建立覆盖基线

　　①修改源代码后重新完成插桩和测试，不继续直接使用旧覆盖结果。

　　②新增分支、错误处理或防御性代码时，同步检查测试是否需要补充。

　　③保存本次正式版本使用的源码、测试集合和覆盖报告。

　　④回归测试时重点观察新增未覆盖区域，而不是只比较总百分比。

　　LDRA工具能够利用结构覆盖报告定位未测试代码，并通过回归测试持续观察代码变化对覆盖结果的影响。

　　总结

　　“Testbed怎么设置代码覆盖率，Testbed代码覆盖率统计不完整如何排查”的重点，是保证覆盖数据能够真实反映当前版本的软件实际执行情况。覆盖率数字本身只是结果，更有价值的是借助未覆盖区域判断测试是否充分、代码是否存在不可达路径，以及验证范围是否与项目目标一致。希望本文对大家使用LDRA Testbed进行结构覆盖分析有所帮助，如果在覆盖率采集、目标机测试或未覆盖代码分析方面还有疑问，欢迎联系咨询。