在TESSY中设计边界值测试，以及对遗漏的测试条件进行补充，不能仅仅将其理解为给输入参数填入最大值和最小值。真正容易被忽略的，往往是边界附近的相邻值、多个条件同时变化所形成的组合、无效输入，以及代码在内部经过换算后才产生的隐含边界。边界值的设计应当先分析接口定义，再检查分支条件和数据类型，最后才将测试数据录入TESSY。如果顺序颠倒，测试用例的数量可能并不少，但实际覆盖的条件却依然不完整。

在TESSY当中，测试对象的创建与识别不完整的排查，关键是要让TESSY拿到完整的待测源码和编译环境，再通过模块分析把可测试的函数识别出来。测试对象出现缺失的时候，问题往往不是出在测试用例上，而是源文件的范围、头文件的路径、宏定义、条件编译或者筛选规则，跟正式的工程没有对上。排查的时候，应当先去看一看分析日志，然后再去检查预处理之后的源码内容。

做单元测试的时候，TESSY里的MC/DC覆盖率该怎样去统计，那些没被覆盖到的空洞又要怎么补上，这是围绕着结构覆盖来展开的。TESSY这个工具是支持代码覆盖率分析的，覆盖率一般说的就是那些已经被测试执行到的代码项在全部代码项里占的比例，而MC/DC比起普通的语句覆盖和分支覆盖来，要求还要更细一些，它不光要求条件被跑到过，还得去证明每一个条件都能单独地去影响整个判定的结果。所以我们在TESSY里面去看MC/DC的时候，不能光去盯那个百分比是不是到了100%，还得去瞧一瞧有哪些判定没有被覆盖到，又有哪些条件没有表现出它的独立影响。

TESSY可以满足哪些标准的测试需求，TESSY生成单元测试报告，关键不是“把用例跑完”，而是把标准要求常见关注点拆成可执行的测试需求清单，再用TESSY把需求、用例、覆盖与结果组织起来，最终落到一份结构稳定的单元测试报告上。

TESSY集成测试怎么做，TESSY集成测试生成报告，落到项目里不是把用例跑完就结束，而是先把集成测试对象组合、依赖策略、执行口径搭稳，再把每次集成测试的结果、日志、配置与追溯信息沉淀成可复核的报告材料。很多集成测试返工，根因往往是组合范围没定清、真实依赖与替身混用、回归时条件变了却没人察觉。下面按可执行顺序说明。

TESSY单元测试怎么用，TESSY如何生成测试报告，这两个问题看似只是在问工具怎么点，但实操里会直接影响测试与单元测试能不能稳定复跑，报告口径能不能一次定死，回归时能不能把“同一套用例同一套结论”交给评审。下面先把TESSY单元测试从建工程到执行的关键动作讲清，再把测试报告的生成路径落到可操作的步骤上，最后补一段让报告更可追溯的闭环做法。

在TESSY里做C单元测试时，最容易失控的地方通常不是测试数据不会填，而是被测函数一旦依赖外部函数、底层驱动或同文件里的局部函数，测试边界就会立刻变糊。Razorcat官方对这件事说得很清楚，TESSY本身就提供stub function机制，用来替代缺失的外部函数；而且它不只支持普通stub，还支持Advanced Stubs、synthetic variables，以及把对象文件或库链接进测试驱动这几种不同层次的做法。也就是说，TESSY里的Stub不是补丁动作，而是隔离外部依赖的正式手段。

在TESSY里看代码覆盖率，先要把两件事分开。一件事是覆盖率怎么跑出来，另一件事是这次到底选哪种覆盖准则。Razorcat官方手册写得很清楚，覆盖率不是默认一直开着的，而是在执行测试时通过instrumentation选项启用；启用后，TESSY会为选定的覆盖类型插装代码，再把结果放到Coverage Viewer、代码高亮和各类coverage report里展示。也就是说，覆盖率统计的起点不是报表，而是测试执行设置。

在TESSY里做单元测试，真正容易乱掉的，通常不是不会点按钮，而是前面测试对象已经建好了，后面测试用例既没有形成稳定结构，命名也越写越散，结果一到回归、覆盖率复核和需求追踪阶段，就很难快速看清哪条用例对应哪一段行为。Razorcat官方对TESSY的定位很明确，它覆盖从项目建立、测试设计、执行，到结果分析和报告的完整流程，并且把测试组织、需求追踪、覆盖率和回归测试都放进了同一套环境里；同时，TESSY既支持在集成的CTE里系统化设计测试用例，也支持在Test Items视图里手工创建test cases和test steps。也就是说，TESSY的问题从来不只是“怎么建”，而是“怎么建得成体系”。

把TESSY接进CI，真正要解决的是两件事，第一件是让TESSY在无人值守环境里稳定跑起来，第二件是把结果变成CI能识别的通过与失败，并且能把报告自动归档。只要你把测试工程的可还原性、命令行执行链路、账号与许可、结果门禁这四块一次做实，后续不管你用Jenkins还是GitLab CI，流程都能长期复用。