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

　　一、TESSY集成测试怎么组织

　　在组织集成测试时，一开始就把所有模块一股脑全扔进去测，是不太稳妥的，因为这样做了以后，一旦测出毛病，想回头去找原因非常吃力。比较靠谱的做法，是先挑那些接口关系简单、对外依赖也少的模块开始测，然后再慢慢扩大范围，逐步把控制逻辑、状态机、通信处理这类多个模块配合的场景也包进来。这样能更好地握住测试范围，分析结果时也不会乱成一团。

　　1、先确定集成范围

　　先通过【测试范围】说明本轮集成哪些模块、哪些接口、哪些输入输出，以及哪些外部依赖暂时不进入真实测试环境。

　　这一步的关键，就是把范围交代得清清楚楚。假如你这一轮只是想去验证上层控制模块和状态处理模块之间的配合是否正常，那就先不要急着把硬件驱动或者真实的通信环境也牵扯进来，要不然等到用例失败了，你连问题是出在业务逻辑本身还是被底下的依赖拖累的，都不容易分清楚。

　　2、按接口关系设计用例

　　集成测试的用例，一定要紧紧贴着模块相互之间的配合来设计。不要想着只是把原来单元测试的那些用例简单搬过来就能应付，单元用例关注的是一个函数内部的走向，而集成用例要盯的是上层模块调用下层模块之后，下层返回的值有没有被正确处置；某个状态一发生变化，关联的模块是不是及时拿到了对应的数据；遇到异常的返回值时，整个系统有没有拐进预想中的那条分支，这些才是集成测试真正该抓住的核心。

　　3、控制前置状态和执行顺序

　　可以通过【初始化脚本】固定测试前的变量、状态标志、计数器和必要的环境条件。

　　有不少集成测试场景是离不开前置状态的，比如初始化流程到底跑完了没有，通信那一块是不是处在有效期，某个故障标志有没有被正确置位，如果这些条件没有被锁死，那么同一条用例可能今天跑得通，明天又莫名其妙挂掉，测出来的结果变得飘忽不定，后面再去分析问题就会非常棘手。

　　二、TESSY依赖模块替换怎么处理

　　处理依赖模块替换这件事，真正的用意是要让被测模块在一个能被我们牢牢掌握的环境里运行，而不是图省心一下子把真实环境全扔掉。嵌入式软件这一块，经常跟着驱动、通信、存储、操作系统服务这类外部依赖，假如把它们统统接上真实的模块，那测试环境会变得过于复杂；可如果把它们全部替换掉，测出来的结果又可能跟实际情况隔得太远，所以替换的范围必须经过一番挑选。

　　1、先判断哪些依赖需要替换

　　像硬件驱动、EEPROM的读写、CAN通信、传感器采样这些依赖，因为它们太容易被硬件上的波动给干扰到，一般在集成测试里更适合把它们换成桩模块。反过来，那些跟被测模块逻辑扣得非常紧，版本也相对稳定的业务模块，则可以先考虑做真实的集成，这样我们既能稳稳握住测试环境，又不至于让测试结论离真实软件的状态太远。

　　2、替换模块要保持接口一致

　　处理【桩函数】时，要保证函数名、参数、返回值和调用语义与真实模块一致。

　　具体来说，真实的接口会返回成功、失败、超时，或者是某个特定的错误码，那么你写的桩函数也得能把这些情况挨个模拟出来。要是图省事，把桩函数写得永远只固定返回成功，用例倒是很容易全部变绿，可是那些异常的处理路径根本就没被锻炼过，等到后面真的接上了真实模块，藏下头的毛病还是会一个接一个冒出来。

　　3、替换逻辑要支持场景变化

　　做依赖模块替换的时候，最忌讳的就是把结果钉死在一个地方不动。拿通信模块来说，你可以安排它模拟接收成功、校验没过、或者根本没有数据进来等多种情形；存储模块也可以用同样的思路，分别去模仿读取顺畅、数据已经损坏、写入失败这些状况。只有让不同的外部场景在桩函数里轮番上演，你才能正经去检查被测模块在面对各种外部条件时，处理得是不是都还在谱上，这也跟集成测试原本的目的正好合上了拍。

　　三、TESSY集成测试证据怎么整理

　　等集成测试跑完以后，证据的整理也是一件轻慢不得的事。不少项目到最后只留下几张用例通过的截图，可是对于测试到底圈了多大的范围、依赖关系是怎么替换的、实际的覆盖结果又长什么样，却没人去说清楚，等到后面评审的时候，想证明这次测试是扎实有效的，就会变得很吃力。测试证据这一摊，至少得能讲明白：我到底测了哪些东西，是怎么测的，哪些依赖被换掉了，跑出来的结果有没有够到当初的期望。

　　1、保留测试配置说明

　　整理【测试配置说明】时，要写清楚本轮测试使用了哪些真实模块，哪些模块被替换，替换模块模拟了哪些返回场景。

　　这样一份说明，到了评审那里就能派上用场，它可以帮评审人员看明白测试环境和真实运行环境之间到底存在多大的距离。万一有某个关键依赖被你给换掉了，可是既没交代替换的原因，也没说明桩模块模拟的范围有多宽，那么这份测试结论拿出来，就很容易遭到别人的质疑。

　　2、关注接口结果和覆盖情况

　　看测试报告的时候，视线不能只死死地咬住那个通过率，你还得去留意，接口之间的调用是不是照着设想的样子发生了，那些关键的分支和异常路径是不是真被踩到了。如果一眼扫过去，覆盖率数字好像还不低，可仔细一瞧，依赖模块从头到尾就只给你返回同一种结果，那这种集成测试的实际价值，终究还是要打个折扣的。

　　3、问题关闭要对应回归结果

　　要是集成测试过程中揪出了接口参数搞错、状态切换不对劲，或者对依赖返回值的处理欠妥当这类问题，那在关门的时候，就不能只扔出一句“已修复”就不管了，还要把修改的记录和回归测试的结果一起保留下来，让人能翻出来是哪一个用例重新跑过了，又是在哪个版本上走完了验证。

　　总结

　　总的说起来，TESSY集成测试要怎么去组织，依赖模块的替换又要怎么去处理，这里面最要紧的就是先把集成的边界画得一清二楚，再把依赖的替换做得既能牢牢控制住，也让人信得过。组织测试的时候，要围绕着模块间的接口和调用关系去铺排用例；处理依赖模块的时候，既要保证接口不走样，也要把正常的、异常的、边界上的各种情景都轮番覆盖到。等到最后，再把测试的配置、测试报告和问题关闭的记录都归置整齐，让TESSY产出的测试结果能够实实在在地撑起项目的验证，而不是只停留在“用例跑过了”这么薄的一层上头。