在用Tessy做函数测试时，覆盖率往往是一项比较敏感的指标。很多工程项目的情况是：用例已经写了不少，函数也能执行，但覆盖率始终停留在一个不上不下的区间，不论怎么调整，某些语句或分支就是触发不到。表面看像是工具没识别到路径，实际排查后常常会发现，限制覆盖率提升的不是Tessy，而是测试场景与代码路径之间存在断层。这种断层不一定明显，但只要没有找准，覆盖率就会一直卡住。

一、场景覆盖不完整，让代码“看得见却走不到”

覆盖率上不去，最直观的原因往往是场景范围不够。函数虽然能跑，但触发条件太单一，很多分支自然没有机会被执行。

1、输入范围过于集中

同一类输入重复出现，函数内部只有固定判断路径被触发，其他分支一直处于未进入状态。

2、边界条件被忽略

比如最小值、最大值、阈值附近的变化，这些往往是函数内部条件切换的关键点，但用例中没有体现。

3、异常场景缺失

真实系统里可能发生的错误状态、未初始化状态、干扰数据，在测试里却完全没有模拟。

只要这些场景不补上，覆盖率常常会卡在某一截，怎么跑都突破不了。

二、依赖函数的行为太“理想化”，导致部分分支永远不会触发

函数逻辑很多时候依赖下层模块的反馈，而测试工程常会把这些依赖函数简化，使得实际流程缺少变化，从而影响覆盖率。

1、返回值过于单一

例如依赖函数永远返回“成功”，导致失败路径从不触发，相关代码也无法覆盖。

2、缺少输入相关的动态变化

真实设备会根据输入不同返回不同结果，但替代函数却始终给“标准答案”，使得内部条件永远单向。

3、状态类函数没有模拟真实变化

比如读取寄存器值、查询设备状态等。如果这些信息在测试中从不变化，逻辑自然没有机会进入另一条路径。

覆盖率想提高，依赖行为必须更贴近真实系统，否则很多分支只能停留在“理论存在”。

三、宏定义与编译配置使部分分支在测试工程中被直接屏蔽

嵌入式项⽬中，大量分支通过宏控制不同硬件型号、模式或协议功能。一旦宏定义不一致，测试工程可能根本没有编译那些你想覆盖的代码部分。

1、条件编译屏蔽了部分逻辑

测试工程缺少某个宏，使一整段逻辑完全被排除，覆盖率自然无法触及。

2、优化等级差异导致变量行为不同

某些边界逻辑在不同优化设置下表现不同，测试工程未必能还原真实行为。

3、引用的头文件非工程主版本

某些宏定义在产品主头文件内，而测试工程引用的是另一份，导致判断条件被替换。

覆盖率卡住时，检查宏与头文件往往能发现意外的屏蔽条件。

四、路径结构不一致，让测试工程加载了错误代码

覆盖率不只是函数执行是否到达，而是Tessy解析到的“那一份代码”是否是正确的。路径不一致，会让覆盖率看起来异常。

1、加载的是旧版驱动

项目内保留历史文件时，测试工程很可能引用了不该加载的版本。

2、文件优先级顺序错误

同名文件在不同目录存在，路径优先级不一致会导致Tessy使用另一套实现。

3、工程目录与真实工程脱节

主工程更新了结构，但测试工程没有同步，覆盖率自然无法对应到正确的文件。

路径问题通常不报错，但覆盖率会明显“卡住”，是最容易忽略却影响最大的部分之一。

TESSY授权经销商—思杰马克丁软件

官网：https://www.tessy.net.cn/
电话：18015636924
邮箱：ritchie.jin@makeding.com

总结

覆盖率上不去，通常不是工具识别问题，而是场景、依赖、宏定义或路径与真实工程之间存在差异。输入不够多样、依赖行为缺乏变化、部分逻辑被条件编译屏蔽、工程路径引用了错误文件，这些都可能让某些分支永远触发不到。只要把这些因素逐项对齐，让测试工程尽量还原真实应用环境，覆盖率就会逐渐抬升，逻辑层面的验证也会更完整、更可靠。