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

　　一、TESSY集成测试怎么做

　　集成测试真正难的地方，不是把更多源文件放进去，而是先把“这次要验证的交互边界”定清。TESSY的公开手册已经把component test单独拉出来说明，同时又保留了和单元测试相同的项目层级，所以更稳的做法，是先沿用原来的项目骨架，再把验证重点从单个函数切到模块之间的接口和调用链路上。

　　1、先把要参与联调的模块范围定清，只挑真正需要一起验证的接口链路，不要一开始就把整批源码全塞进同一轮集成测试。

　　2、继续沿用模块和测试对象这套结构去组织集成测试，不要另外搭一套平行目录。因为TESSY的component test management本身就是基于模块层级展开的。

　　3、在测试环境里把编译器、调试器、源文件和链接选项一次配顺，再开始执行集成测试。公开手册对TEE的定义就是用来统一这些公共执行条件。

　　4、执行后不要只看通过和失败，还要把覆盖一起看。TESSY明确支持单元和集成测试的覆盖分析，其中Call Pair Coverage还被用来支撑集成层面的调用关系检查。

　　二、TESSY集成测试与单元测试如何分工

　　单元测试和集成测试最怕边界不清。分工一乱，前面会重复设计用例，后面又很难解释为什么这条需求既在单元层测过，又在集成层再测一遍。TESSY的公开资料其实已经给了一个很清楚的分界线，也就是单元测试围绕test object展开，集成测试则更偏向多个对象和接口协同后的行为验证。

　　1、单元测试先把单个测试对象测透。公开手册明确写到，单元测试里的test object就是模块中的导出函数，所以这一层更适合把接口、边界值和异常输入先压实。

　　2、集成测试再去验证模块之间的调用链、数据传递和联动结果，不要把所有细节断言都堆到集成层。否则执行会很重，定位也会变慢。

　　3、需求链接两层都要做，但粒度不要一样。TESSY支持把需求挂到模块、测试对象和测试用例上，所以单元层更适合挂细粒度需求，集成层更适合挂跨模块行为和接口级需求。

　　4、不要把所有验证都硬塞进单元或集成测试。TESSY的发布说明已经补了外部测试和评审的任务元素，就是为了覆盖那些不适合靠普通单元或集成测试验证的需求。

　　三、TESSY测试链路怎么收口

　　很多项目不是不会做测试，而是最后收不住。前面单元测试有结果，后面集成测试也跑了，真到复盘时却说不清哪条需求已经被计划覆盖，哪条需求又真正被执行覆盖。TESSY手册对这一点写得很完整，需求可以链接到模块、测试对象和测试用例，执行后的结果又会回写到requirements coverage视图，所以更稳的办法，是从一开始就把计划、执行和报告放回同一棵项目树里。

　　1、先把需求链接挂到模块、测试对象和测试用例上，不要等测试跑完以后再人工补追溯。

　　2、再用测试运行结果去看execution coverage，因为TESSY明确区分了planning coverage和execution coverage，这两者不能混着解释。

　　3、结果汇总时优先生成Test Details、Test Overview、Planning Coverage和Execution Coverage这几类报告，这样单元层和集成层的证据会更容易放到一起看。

　　4、最后把覆盖、需求链接和失败项都收回项目结构里统一复核，不要把单元测试和集成测试拆成两套互不相认的结果库。

　　总结

　　TESSY集成测试怎么做，TESSY集成测试与单元测试如何分工，真正关键的不是多建几层目录，而是先把验证边界、需求链接和覆盖口径定清。单元测试先把单个测试对象测透，集成测试再去验证接口链路和协同行为，最后再用同一套需求覆盖和报告把两层结果收回到同一棵项目树里，这样测试链路才会真正贯通。