测试一个温度判断函数，可能还要调用传感器读取、故障查询和告警输出接口。如果把这些模块一起编进来，用例结果就会受硬件状态和其他模块影响；全部替换成固定返回值，又可能漏掉读取失败、数据无效等分支。TESSY提供普通桩和高级桩来控制这些依赖。配置前应先确定测试边界，再逐项安排依赖行为。

　　一、TESSY如何处理函数间的依赖关系

　　TESSY分析源文件后，会在测试接口中列出识别到的调用和变量。下面以英文界面为例，具体菜单文字可能随版本略有不同。

　　1、从接口列表梳理依赖

　　①完成模块分析，选择被测函数，进入【TIE】，查看【External Functions】、【Local Functions】。

　　②同时检查【External Variables】和【Global Variables】，记录影响函数执行的状态。

　　外部函数不等于所有需要隔离的函数。同一模块中的辅助函数，也可能访问硬件或共享状态；反过来，一个无副作用的计算函数，可能适合保留真实实现。

　　2、决定哪些调用保留真实实现

　　①根据测试目标，确定当前要验证的是单个函数逻辑，还是多个函数协作。

　　②对保留的实现，将相应源文件、对象文件或库纳入测试构建，并核对编译配置。

　　保留真实实现后，报告中的结果就包含了它的行为。测试说明中应写清边界，避免将包含其他模块的结果当作完全隔离的单元测试结论。

　　3、用普通桩替换外部调用

　　①在【TIE】中右键目标函数，选择【Create Stub】；仅针对当前被测对象时，选择带当前对象范围的对应选项。

　　②切换到【TDE】，在【Stub Functions】中选择该函数，填写替代行为。

　　③对有返回值的函数，确保各条有效执行路径都返回约定值；通过指针输出数据的接口，还要提供相应写入行为。

　　普通桩适合需要自行组织逻辑的情况。例如，读取接口既返回状态码，又通过指针给出数据，桩就应按接口约定处理两部分，不能只返回“成功”。

　　4、用高级桩将依赖行为放进测试数据

　　①在【TIE】中右键依赖函数，选择【Create Advanced Stub】。

　　②展开参数和返回值，检查其数据方向。

　　③在【TDE】中填写桩返回的数据，以及需要检查的调用参数期望值。

　　④同一测试中调用多次时，对支持的标量项目设置逐次取值，或使用普通桩描述调用序列。

　　高级桩的数据方向以被测对象为参照：桩返回给被测对象的值通常作为IN提供；被测对象传给桩、需要核验的参数通常作为OUT检查。不要照搬函数形参的输入、输出习惯。

　　二、TESSY被测函数依赖外部模块时如何隔离测试

　　函数替换只是其中一部分。全局状态、指针目标和构建时使用的真实实现，也可能让隔离失效。

　　1、让外部变量有定义，也有明确初值

　　①在【TIE】中核对相关外部变量由谁定义，确保测试驱动与链接库不会重复提供同一符号。

　　②根据用途，在【Passing】中选择IN、OUT或INOUT，并在【TDE】中填写初值和期望值。

　　③每个独立用例开始前，恢复影响执行的状态；需要跨步骤保留的状态则单独说明。

　　“未定义符号”属于构建问题；变量已经存在但值不正确，则属于测试状态问题。把变量设成IRRELEVANT，只会将其移出相应数据处理，不能代替必要的初始化。

　　2、检查指针目标和多次调用

　　①为被测对象及桩需要访问的指针准备有效目标，核对数组容量、结构体内容和有效期。

　　②对既返回状态又写入缓冲区的接口，分别设置状态码和输出内容。

　　③多次调用需要不同复杂数据时，检查高级桩是否支持当前类型；不支持时，在普通桩中按调用序号处理，必要时通过合成变量提供数据。

　　例如，第一次读取失败、第二次读取成功，需要分别安排两次调用。每次都返回成功，无法验证重试分支；每次都失败，也无法验证恢复后的处理。

　　3、确认运行时确实使用了预期的桩

　　①检查桩设置作用于整个模块还是当前测试对象，以及是否存在局部覆盖。

　　②查看测试构建日志和生成的驱动，确认没有同时链接真实函数与替代定义。

　　③对比调用记录、参数实际值及覆盖结果，判断代码是否走到了预期位置。

　　④若依赖没有按预期出现，核查条件编译、宏、内联及函数指针调用，确认分析配置与目标构建一致。

　　桩没有被调用，可能只是前面的条件已经返回。此时应从输入和执行路径查起，而不是先修改桩。标准库和编译器系统函数也不宜随意替换，以免影响测试驱动自身。

　　三、TESSY隔离后怎样验证错误处理分支

　　以“读取失败后停止本次控制，并报告故障”为例，测试不仅要安排读取失败，还要检查被测函数有没有做出正确反应。

　　①将读取接口配置为桩，在当前用例中提供约定的失败状态，并初始化相关全局变量。

　　②为故障上报接口安排参数核验，检查故障编号及上下文是否符合要求。

　　③检查被测函数返回值、状态变化，以及失败后是否仍错误地使用了读取数据。

　　④再增加正常读取和恢复场景，确认函数不会在所有情况下都进入故障处理。

　　这几种场景可以共用桩机制，但输入和期望结果应分别来自接口与软件需求。桩负责制造条件，不应把被测函数的判断逻辑重新实现一遍，否则双方犯下同样的错误时，用例也可能通过。

　　隔离测试通过后，仍需在集成层面确认真实模块的接口和协作。桩能够控制返回值，不能据此证明真实传感器、驱动或通信模块具备相同行为。

　　总结

　　处理TESSY依赖时，先划清测试边界，再决定保留真实实现、使用普通桩还是高级桩。返回值、指针数据和全局状态都需要安排，测试结果才容易解释。用例失败后，也应区分构建、桩配置和业务执行路径的问题。希望这些方法能帮助大家把外部条件控制清楚，让正常、异常及恢复场景都有可核验的结果。后续开展TESSY测试如有相关需求，欢迎联系我们交流。