在单元测试的收尾阶段，TESSY测试文档到底该怎么去生成，它的格式又要怎么去调整，这是很多项目在准备交付评审时都会撞上的事情。实际工作中，不少团队在TESSY里已经把测试用例设计好了、桩函数也配过了、覆盖率也统计了、连执行结果都确认完了，可等到真要拿去给别人看的时候，才发现手头的测试文档要么内容不完整，要么格式乱糟糟的不统一，再要么就是测试报告跟项目的其他证据对不上号。TESSY的测试文档，并不是简单导出一份报告就能算完事的，它还得能把测试的对象、测试的环境、测试的用例、执行的结果、代码的覆盖率，还有缺陷的处理情况都给说明白，这样后面才能稳稳地撑住ASPICE、ISO 26262这些评审，或者企业内部的质量审查。

在嵌入式软件测试中，很多人都会碰到TESSY集成测试怎么去搭建，以及依赖模块替换又要怎样去处理这两个挺现实的问题。做单元测试的时候，大部分精力是放在单个函数上，看它自己的逻辑走得对不对，但一转到集成测试，事情就变了，你必须把好几个模块合到一起，去检查它们互相之间的接口调用是不是符合约定、数据是怎么传的、状态切换正不正常，还有当异常发生时，整个组合体还能不能稳稳地撑住。TESSY这个工具在管理测试用例、输入输出、覆盖率和报告方面确实能帮上忙，可真到了要动手设计集成测试那一步，我们首先得把测试的边界画清楚，把依赖关系理出来，再定好替换的策略，不能想着光靠工具自己去跑就能交差。

TESSY集成测试结果怎么看，TESSY集成测试报告如何解读，决定你能不能把一次集成测试的结论讲清楚。要把集成测试结果读对、把集成测试报告解读透，第一步是先把结果按测试范围与执行口径对齐，第二步是把失败用例按类型分桶并回到最小触发条件，第三步是把报告里的证据链拆出来，保证任何人拿到同一份报告都能复现同样的判断结论。

TESSY代码覆盖率怎么做，TESSY代码覆盖率统计口径如何统一，表面看是在做一次覆盖率统计，实际是在解决两类常见失真：一类是代码覆盖率数字好看但不可复现，同一套代码换台机器就变；另一类是团队各算各的口径，语句覆盖率、分支覆盖率、条件覆盖率混用，最后评审时只能解释不清。要把TESSY代码覆盖率做扎实，必须把覆盖采集的流程跑通，把统计口径在工程配置、过滤规则、报表输出三个层面统一起来。

TESSY测试自动化测试流程，TESSY测试自动化测试结果在嵌入式软件研发里，单元测试如果停留在手工点选和临时跑一遍，很容易在回归阶段被版本分支、改动频率和结果不可追溯拖慢节奏。把测试自动化做成可重复执行的测试流程，把输出做成可审计、可对比、可留痕的测试结果证据链，才能让TESSY测试真正服务于迭代交付与质量门槛。

在TESSY里测指针，最容易出错的地方不是界面不会点，而是把“指针本身”和“指针指向的目标对象”当成了一回事。Razorcat官方手册写得很清楚，TESSY的测试数据里有一类专门的Dynamic objects，用来表示通过指针访问的目标对象；同时，数组参数也可以被当成指针来处理，并且能在TDE里分配为NULL或具体数组目标。也就是说，测指针时真正要喂给TESSY的，不只是一个地址概念，而是“这个指针现在指向谁，这个目标对象里面有什么值”。

很多团队用TESSY时，单元测试能很快铺开，真正到了集成测试阶段却容易发散。常见问题不是工具不会用，而是项目树、测试对象、需求链接和覆盖口径没有先摆成一条线。Razorcat的公开资料已经说明，TESSY同时支持单元测试和集成测试，项目里本来就有模块、测试对象、测试运行、需求链接和覆盖分析这些管理抓手，所以更稳的做法不是把集成测试当成单元测试的加量版，而是按另一层验证目标去组织。

团队把单元测试跑起来之后，下一步通常会遇到两个现实问题：一是集成测试越做越乱，测试对象和依赖关系散在不同人手里，回归时很难一键跑全；二是单元用例明明已经验证过关键边界，到了集成阶段又从头再写一遍，重复劳动多、还容易漏。用TESSY把这两件事做顺，核心是先把测试组织结构固定下来，再把单元用例变成可迁移、可重映射、可持续回归的资产。TESSY本身强调覆盖单元与集成测试的动态测试流程，并提供测试组织与管理能力，这为统一口径提供了基础。

做单元测试时，外部依赖一多就会出现两类典型问题，一类是编译链接过不了，另一类是能跑但结果不稳定，今天过明天不过。TESSY的桩函数就是用来把这些外部函数调用替换成可控的替身，让你把注意力放在被测函数的逻辑本身，同时把输入输出和调用行为变成可验证的证据链。

做单元测试时，覆盖率不是为了把数字做高，而是为了证明测试确实触达了关键逻辑分支，能支撑评审与合规交付。TESSY采集覆盖率的难点通常在两处：一是编译口径与插桩执行口径不一致导致数据不稳定，二是覆盖率类型选得不匹配导致整改成本偏高。下面按采集流程、类型选择、结果固化三条线，把每一步怎么点、怎么配写清楚。