TESSY工程中，批量运行多个测试对象、连续执行测试步骤，以及按时序调用组件函数，使用的配置方式各有区别。源代码更新后，如果函数名称、参数或全局变量发生变化，原有测试数据也可能暂时无法使用。处理这两类问题时，应先确认运行层级和接口状态，再调整执行安排或迁移数据。下面以TESSY 5.1的界面为例说明。

被测函数访问硬件或通信接口时，可以用桩函数提供可控结果。填好返回值后，测试仍走另一条分支，就需要检查配置和调用情况。本文围绕“TESSY怎么配置测试桩函数TESSY桩函数返回值无法按预期控制如何检查”，介绍普通桩和高级桩的设置及检查方法，操作采用TESSY英文界面。

TESSY代码插桩主要用于收集软件运行过程中的覆盖率数据，例如语句覆盖、分支覆盖以及MC/DC覆盖等。在汽车软件测试项目中，代码插桩通常会和单元测试结合使用，通过插入统计代码记录被测函数执行情况。实际使用时，插桩后的程序可能出现运行异常，例如测试程序启动失败、执行结果异常、目标环境运行不稳定等问题。这类情况通常和插桩配置、编译参数、内存空间以及目标平台限制有关，需要结合构建日志和运行环境逐项检查。

在TESSY中设计边界值测试，以及对遗漏的测试条件进行补充，不能仅仅将其理解为给输入参数填入最大值和最小值。真正容易被忽略的，往往是边界附近的相邻值、多个条件同时变化所形成的组合、无效输入，以及代码在内部经过换算后才产生的隐含边界。边界值的设计应当先分析接口定义，再检查分支条件和数据类型，最后才将测试数据录入TESSY。如果顺序颠倒，测试用例的数量可能并不少，但实际覆盖的条件却依然不完整。

在TESSY当中，测试对象的创建与识别不完整的排查，关键是要让TESSY拿到完整的待测源码和编译环境，再通过模块分析把可测试的函数识别出来。测试对象出现缺失的时候，问题往往不是出在测试用例上，而是源文件的范围、头文件的路径、宏定义、条件编译或者筛选规则，跟正式的工程没有对上。排查的时候，应当先去看一看分析日志，然后再去检查预处理之后的源码内容。

做单元测试的时候，TESSY里的MC/DC覆盖率该怎样去统计，那些没被覆盖到的空洞又要怎么补上，这是围绕着结构覆盖来展开的。TESSY这个工具是支持代码覆盖率分析的，覆盖率一般说的就是那些已经被测试执行到的代码项在全部代码项里占的比例，而MC/DC比起普通的语句覆盖和分支覆盖来，要求还要更细一些，它不光要求条件被跑到过，还得去证明每一个条件都能单独地去影响整个判定的结果。所以我们在TESSY里面去看MC/DC的时候，不能光去盯那个百分比是不是到了100%，还得去瞧一瞧有哪些判定没有被覆盖到，又有哪些条件没有表现出它的独立影响。

TESSY可以满足哪些标准的测试需求，TESSY生成单元测试报告，关键不是“把用例跑完”，而是把标准要求常见关注点拆成可执行的测试需求清单，再用TESSY把需求、用例、覆盖与结果组织起来，最终落到一份结构稳定的单元测试报告上。

TESSY集成测试怎么做，TESSY集成测试生成报告，落到项目里不是把用例跑完就结束，而是先把集成测试对象组合、依赖策略、执行口径搭稳，再把每次集成测试的结果、日志、配置与追溯信息沉淀成可复核的报告材料。很多集成测试返工，根因往往是组合范围没定清、真实依赖与替身混用、回归时条件变了却没人察觉。下面按可执行顺序说明。

TESSY单元测试怎么用，TESSY如何生成测试报告，这两个问题看似只是在问工具怎么点，但实操里会直接影响测试与单元测试能不能稳定复跑，报告口径能不能一次定死，回归时能不能把“同一套用例同一套结论”交给评审。下面先把TESSY单元测试从建工程到执行的关键动作讲清，再把测试报告的生成路径落到可操作的步骤上，最后补一段让报告更可追溯的闭环做法。

在TESSY里做C单元测试时，最容易失控的地方通常不是测试数据不会填，而是被测函数一旦依赖外部函数、底层驱动或同文件里的局部函数，测试边界就会立刻变糊。Razorcat官方对这件事说得很清楚，TESSY本身就提供stub function机制，用来替代缺失的外部函数；而且它不只支持普通stub，还支持Advanced Stubs、synthetic variables，以及把对象文件或库链接进测试驱动这几种不同层次的做法。也就是说，TESSY里的Stub不是补丁动作，而是隔离外部依赖的正式手段。