TESSY

TESSY进行软件单元测试时，数组参数是比较容易出现配置问题的数据类型。与普通变量不同，数组不仅需要关注元素值，还需要保证数组长度、下标范围以及内存分配方式和被测函数定义一致。实际测试过程中，经常会遇到测试数据无法导入、数组元素对应错误、测试程序运行异常等情况，这些问题多数和测试接口解析、数组维度设置以及测试数据格式有关。处理数组测试时，需要先确认函数接口定义，再根据数组类型配置对应测试数据。

TESSY进行单元测试时，需要根据被测软件实际使用的编译器、目标平台以及编译参数生成对应测试环境。如果编译器配置不匹配，常见表现包括测试驱动生成失败、源文件无法编译、链接错误或者测试程序无法运行。实际项目中，很多问题并不是TESSY测试用例本身造成，而是编译器路径、目标架构、宏定义以及链接参数没有和原工程保持一致。因此，配置编译器选项时，需要让TESSY测试环境尽量接近正式开发环境。

在TESSY进行单元测试时，函数返回值可以直接作为测试对象的输出结果参与判定。TESSY怎么设置函数返回值检查，TESSY函数返回值与预期结果不一致如何定位，重点是先确认测试接口已经正确识别返回值，再为不同测试用例填写对应的预期结果。出现失败后，则需要结合输入数据、实际返回值和函数执行路径判断差异究竟来自测试数据还是被测代码。TESSY会在执行后比较预期值和实际值，并据此给出测试结果。

在单元测试规模逐渐扩大并接入持续集成环境之后，TESSY的批量执行应该如何配置，以及批量执行途中停止时又该如何定位，便成了经常需要处理的问题。批量执行并不只是同时选中多个测试对象去运行，它还涉及测试范围的确定、环境配置、目标连接、报告输出以及异常停止策略等多个方面。当运行过程在中途停下来时，也需要先判断究竟是因为测试失败触发了终止条件，还是某个测试对象超时，又或者是编译、下载、调试器连接或目标机通信这些环节出现了问题。

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

TESSY在单元测试和集成测试中，会把测试输入、预期值和实际执行结果分别管理，并根据预期值与实际值的比较结果判断测试通过或失败。处理“TESSY怎么管理测试用例预期值，TESSY预期值修改后测试结果没有更新如何处理”时，需要区分测试规格发生变化与已有测试结果发生变化。修改预期值只是更新了测试定义，已有结果不会因此自动变成一次新的测试执行结果。

在TESSY进行C/C++单元测试时，普通数值参数可以直接填写输入值，而指针参数还涉及指针指向的内存对象、对象长度以及数据传递方向。特别是数组指针、结构体指针和多级指针，如果只给指针本身配置数据，却没有正确建立目标对象，测试驱动可能无法按照预期初始化或读取数据。处理“TESSY怎么配置指针参数测试数据，TESSY指针参数测试结果异常如何排查”时，应把指针地址和指针指向的数据分开检查，再结合被测函数实际访问的内存范围判断结果是否合理。TESSY会通过动态对象表示指针实际指向的测试数据区域。

TESSY测试用例如何复制，以及测试用例复制后出现数据失效应当怎样处理，在相似函数的复用测试、模块版本升级和软件变体测试中经常遇到。复制测试用例并不仅仅是增加一条名称相同的记录，输入值、期望结果、测试步骤、接口元素以及用户代码之间存在着相互关联。一旦目标测试对象的参数、返回值或全局变量与原始对象不同，复制过来的数据就可能显示为未定义、只读或者无法执行。处理这类问题时，需要先判断是普通复制没有生效，还是接口发生变化之后需要进行数据复用。

如果只是盯着这一轮测试是通过还是失败，那TESSY历史结果的对比和回归差异的定位能看到的东西其实很少。回归测试真正要去解决的问题，是在代码、测试数据、桩函数、编译环境甚至目标平台发生过变动以后，确认原来已经跑通的那些功能有没有被意外碰坏。所以动手做历史结果对比之前，一定得先把用来比较的基准给找稳了，再一茬一茬地把差异拆开来细看，不能一瞧见Fail就急急忙忙判断代码里头出了毛病。

在嵌入式软件单元测试中，TESSY桩函数的返回值怎么模拟、调用顺序又该怎么校验，是实际项目里常常碰到的两个问题。很多被测函数并不是完全独立运行的，它在执行时总会去调用一些外部的函数，比如底层驱动、通信接口、诊断接口或者存储接口等等，如果让这些外部函数直接参与测试，结果就很容易被硬件环境、通信状态甚至其他模块干扰，所以需要先用桩函数把外部依赖替换掉。桩函数的重点，并不是随便写上一个空函数就算完事，而是要能模拟返回值、输出参数、调用次数还有调用的先后次序，这样得出来的测试结果才有真正的价值。

TESSY进行单元测试时，可以通过导入CSV文件批量管理测试数据，减少手动输入测试值的工作量。CSV测试数据通常用于保存函数输入参数、期望输出结果以及边界条件等内容，适合测试用例数量较多的场景。实际使用过程中，测试数据导入后出现参数顺序错误、变量匹配异常或者测试结果不符合预期的情况比较常见，这类问题通常和CSV字段定义、测试对象接口变化以及TESSY数据映射设置有关，需要结合测试函数定义逐项检查。

TESSY进行单元测试和组件测试时，可以通过结构覆盖结果判断测试数据实际执行了哪些代码路径。分支覆盖率不足往往说明某些判断结果、异常路径或边界场景还没有被现有测试触发，但也可能与条件编译、代码变体或不可达代码有关。围绕“TESSY怎么查看分支覆盖率，TESSY分支覆盖率不足时如何查找未覆盖路径”，重点是从覆盖率数字继续定位到具体分支，再判断真正缺少的是测试数据还是覆盖依据。

在TESSY进行单元测试时，测试对象除了函数参数和返回值，还可能依赖全局变量、静态全局变量或静态局部变量。此类变量如果初始状态不确定，很容易导致同一测试用例在不同执行顺序下得到不同结果。因此，进行“TESSY怎么设置全局变量初始值，TESSY全局变量初始值没有生效如何检查”时，既要确认测试数据已经正确传入，也要区分测试开始前的初始化与源代码运行后的再次赋值。

TESSY接口编辑器主要用于整理测试对象的输入、输出、返回值、全局变量和外部函数调用。模块分析完成后，TESSY会尝试自动判断接口元素的传递方向，但自动分析的结果不一定能完全符合测试的意图。在正式设计测试数据之前，应当先对接口定义进行检查，否则一旦参数方向、数组范围或指针目标的识别出现错误，后续的测试用例也会跟着错位。

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

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

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

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

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

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