在嵌入式软件单元测试这一块，把测试从主机搬到真实的硬件上去跑，TESSY目标板上怎么执行、执行后的日志又该怎么去看，是绕不开的实际问题。TESSY是支持在不同目标系统上跑C和C++的嵌入式软件测试的，从测试设计、执行，到结果分析和报告管理这一整套流程它都能覆盖，在目标板上跑的时候，工具会把测试的输入传到目标系统那边，去运行被测的函数，然后再把实际的输出取回来，跟预期结果做一次比对。

　　一、TESSY目标板上怎么执行测试

　　要在目标板上去执行测试，这件事的重点可不光是让用例简单地跑起来就完事了，它是要让整个测试程序放到真实的MCU、真实的编译器，还有真实的运行条件底下去跑的。和单纯在主机上做测试比起来，目标板上的测试更容易把内存、编译器、启动初始化、硬件依赖这些层面的毛病给抖出来，所以在动手执行之前，得先把基础的环境都确认好才行。

　　1、确认目标环境

　　执行之前，一定得先确认好目标板的型号、编译器的版本、链接脚本、启动代码、调试器，还有通信接口这些东西。在主机环境里能跑通的用例，可不代表到了目标板上也一定能顺顺当当地通过，因为目标板是会受到存储空间、字节对齐的方式、初始化的先后顺序，还有底层驱动的状态这些因素影响的。

　　2、配置执行环境

　　在【Target Configuration】中维护编译、链接、下载和运行相关设置，确认TESSY能调用项目对应的工具链。

　　这一步，要重点去检查头文件的路径、宏定义、库文件、链接参数，还有目标连接的方式。很多执行失败的情况，倒不是测试用例本身有什么毛病，而是测试工程和真实项目的配置没对上，比如少了启动文件、链接的地址写错了，或者是调试器的参数没有配好，这些都会导致跑不起来。

　　3、生成测试程序

　　TESSY会围着被测函数生成一个测试驱动，然后再跟被测代码一起，构建出一套能在目标环境底下跑的测试程序。在做构建的时候，得多留意编译的告警、链接时报出来的错误、还没定义过的符号，还有桩函数的配置。要是被测的代码依赖了硬件的寄存器、外部的变量，或者是底层的接口，那就得提前把这些桩函数和初始化的条件都给处理好。

　　4、下载并执行测试

　　通过【Build】→【Download】→【Execute】完成构建、下载和运行。

　　执行的时候，要保证目标板供电稳稳当当的，调试器的连接也一直正常，程序能够顺利地进到测试的入口里面去。头一次跑的时候，不太建议一口气就把所有的用例全推上去，完全可以先挑几个简单点的用例，确认一下通路是不是正常，然后再一批一批地去跑，免得等大片大片失败了，回头才发现原来是目标连接的环节出了问题。

　　二、TESSY目标板执行日志怎么查看

　　目标板执行日志，主要就是拿来判断问题到底是出在构建、下载、运行，还是最后结果回传的哪个阶段上。翻看日志的时候，不能只看一个通过或者失败的标记，还得去瞧中间过程里面有没有冒出编译告警、链接出错、目标没响应、通信超时，或者是异常的复位这些信息。

　　1、查看构建日志

　　查看构建日志，重点要去看编译的命令、宏定义、头文件的路径、链接的参数，还有报出来的那些错误提示。比较常见的问题，无非是头文件找不着了、类型定义没对上、缺了库文件、链接段溢出了，或者是有些符号还没被定义过，碰上这种事，应该先去翻一下项目原始的工程配置，照着它来排查。

　　2、查看执行日志

　　在【Execution Log】中查看下载状态、目标连接状态、用例执行顺序、运行错误和结果回传信息。

　　要是日志里面出现了目标没响应、程序异常停掉了、等待超时这类提示，那就得重点去查一查调试器的连接、目标板的复位状态、时钟的初始化、看门狗，还有通信的通道。在目标板上执行失败，不一定就代表函数的逻辑写错了，也有可能是运行的那套环境压根儿还没准备好。

　　3、查看测试结果

　　看测试结果的时候，得把输入值、预期的输出、实际的输出，还有判定的条件这几样东西合到一块儿去打量。假如某一条用例失败了，你就要去关心一下是哪个变量不对、边界值是不是越了、桩函数的返回值是什么，还有容差是怎么设的。因为目标板上可能会跟主机那边存在浮点精度的差异、定时的差异，或者受到硬件状态的影响，所以不能一瞅见失败的标记就急着下结论。

　　4、导出测试报告

　　通过【Test Report】整理执行结果、覆盖率、日志信息和异常说明。

　　TESSY对测试执行、结果分析，还有报告的输出都是支持的，这些报告就可以当作后面去做评审和问题复查的证据来用。对于ASPICE或者ISO 26262这类项目来说，报告里面最好是能把测试的环境、执行的时间、通过和失败的状态、关键的日志，还有问题的说明都给体现出来。

　　三、目标板执行异常怎么排查

　　目标板上的测试要是失败了，可千万别一上来就急着去改测试用例，更稳当的法子，是先按阶段去把问题的位置给判断出来，免得把工具链、硬件环境和代码逻辑这几样东西搅和到一起去瞎猜。

　　1、区分失败阶段

　　如果是构建的阶段失败了，那就重点去盯着编译器、链接脚本和库文件；要是下载的时候失败了，就要去看看供电是不是正常、调试器有没有连好，还有接口是不是通的；如果是运行的时候失败了，那就要把眼睛放在启动代码、看门狗、中断，还有内存访问上头；而结果异常呢，则要回过头去查输入的数据、桩函数，还有预期的输出。

　　2、缩小测试范围

　　排查的时候，可以先挑一个最最简单的用例去跑，等到确认了目标板的通路是正常的，然后再慢慢地去加用例的数量，把复杂度也一点点地提上去。对于那种会牵涉到全局变量、静态变量，或者是硬件状态的代码，要特别留意用例之间是不是会互相影响，如果觉得有必要，完全可以在每条用例跑之前，先把初始状态恢复干净。

　　3、保留异常证据

　　但凡在目标板执行的时候碰到了异常，就一定要把构建的日志、执行的日志、测试报告、调试器输出，还有关键的截图都给留住。往后回过头来看的时候，有了这些东西，才好去判断当时的问题到底是配置出错、硬件环境不对劲，还是被测代码本身藏着缺陷。

　　总结

　　TESSY在目标板上的测试执行和日志查看，关键就是要让目标环境的配置、测试程序的构建、下载执行、结果回传，还有日志的分析，这几个环节能串成一个闭环。在执行之前，要把目标板、工具链和调试接口都给核对好；执行的过程中，要一路盯着构建、下载和运行的状态；等到执行完了，再结合日志、测试结果和报告去判断问题出在了哪里。这样走下来，目标板的测试才不只是随便跑上一次，而是能够沉淀出一套可以反复去查、去分析的测试证据。