1. 初识TESSY：你的嵌入式软件测试“瑞士军刀”

如果你正在开发嵌入式软件，尤其是汽车电子、工业控制这类对可靠性要求极高的领域，那么“测试”这两个字的分量，你一定深有体会。代码写完了，怎么确保它真的能按预期工作？怎么保证一个函数的修改不会“牵一发而动全身”，导致其他模块崩溃？过去，我见过太多团队依赖“人肉测试”——开发人员自己点点按钮，看看输出，或者写一些临时的小程序来验证。这种方法效率低、覆盖不全，而且难以重复，每次代码改动都提心吊胆。直到我接触了TESSY，才真正把嵌入式软件的单元测试和集成测试带入了自动化、工程化的轨道。

TESSY（Test Environment for Software Systems）是一款专门针对C/C++嵌入式软件的测试工具，你可以把它理解为你代码的“专业体检医生”。它最大的魅力在于，不需要你修改一行业务代码，就能自动生成测试驱动（Test Driver），帮你把一个个函数、一个个模块单独“拎出来”进行测试。无论是测试一个简单的加法函数，还是测试多个模块组合在一起的复杂交互逻辑，TESSY都能提供一套完整的IDE环境来设计用例、执行测试并生成详尽的报告。我刚开始用的时候，感觉就像给测试工作装上了“自动驾驶”，以前需要手动搭建的桩函数（Stub）、模拟的输入输出，现在大部分都能由工具自动完成，省下的时间可以更专注于设计更全面的测试场景。

那么，TESSY适合谁呢？如果你是嵌入式软件的新手测试工程师或开发者，正苦于不知如何系统性地开始单元测试；或者你是团队的技术负责人，希望引入规范的测试流程来提升代码质量、减少后期调试的“火警”时间，那么这篇指南就是为你准备的。我们将完全从零开始，手把手带你走通在TESSY 5.1中创建单元测试和集成测试工程的每一个步骤，并分享一些我实战中总结的“避坑”技巧。放心，整个过程不需要你事先是测试专家，我们会用最直白的语言和具体的操作截图，让你快速上手。

2. 环境准备与第一个TESSY工程

工欲善其事，必先利其器。在开始编写酷炫的测试用例之前，我们得先把“厨房”收拾好。这里说的环境，主要就是TESSY软件本身以及你的待测代码。TESSY 5.1的安装过程比较常规，跟着安装向导一步步走就行，记得选择适合你操作系统的版本。安装完成后，你可能会注意到TESSY对编译器的支持：它本身不负责编译你的源代码，而是需要调用你项目原本使用的编译器（比如GCC、Tasking、Green Hills等）来编译生成的测试代码。因此，确保你的电脑上已经安装了正确的编译器链，并且其路径已添加到系统环境变量中，这是后续一切顺利的前提。

好了，现在让我们双击打开TESSY 5.1的图标。第一次启动时，你可能会看到一个欢迎界面或一个空的工作区。别担心，我们从头创建一个全新的测试工程。在菜单栏找到 File -> New -> TESSY Project，或者在启动的欢迎界面上直接点击 New Project。这时，会弹出一个新建工程向导对话框。

这个对话框需要你填写几个关键信息：

• Project name：给你的测试工程起个名字，比如 MyFirst_UnitTest。建议名字能体现被测对象或项目，养成良好的管理习惯。
• Location：工程文件存放的路径。我习惯为测试工程单独建立一个目录，与源代码目录分开，这样结构清晰，不会弄混。
• Workspace：通常使用默认的工作空间即可。
• 最关键的一步：选择测试类型。这里你会看到两个选项：Unit Test 和 Component Test（在TESSY的语境里，Component Test通常就是指集成测试）。这是我们第一个重要的选择点：如果你要测试单个C/C++函数内部的逻辑，就选Unit Test；如果你要测试多个函数或模块组合在一起的外部接口行为，就选Component Test。 为了演示，我们先选择 Unit Test。

点击 Finish，TESSY就会为你创建一个空的单元测试工程框架。此时，你的IDE界面应该分为几个主要区域：左侧是工程浏览器（Project Explorer），可以看到刚创建的工程结构；中间是主要的编辑和视图区域；右侧可能有一些属性视图。工程创建好后，它还是“空壳”，我们需要告诉TESSY：你要测试的源代码在哪里？这就是接下来的“导入源代码”步骤。

在工程浏览器里，右键点击你的工程名，选择 Properties，或者从菜单栏的 Project 进入属性设置。我们需要找到 C/C++ General -> Paths and Symbols 相关的设置项（不同TESSY版本路径可能略有差异，但关键词是Paths）。在这里，你要添加两类路径：

1. Include paths (-I)：你源代码所依赖的所有头文件（.h）的目录。这通常包括你自己项目的头文件目录，以及使用的第三方库的头文件目录。
2. Source paths：你的C/C++源文件（.c, .cpp）所在的目录。

添加完成后，TESSY就能在后续分析你的代码了。你可以尝试点击菜单栏的 Analysis -> Analyze，让TESSY解析一下你的工程。如果路径设置正确，它应该能成功识别出你的源代码文件，并在工程浏览器中显示出来。如果报错，最常见的原因就是头文件路径没设对，或者编译器没配好，回头检查一下这两项。环境搭建就像盖房子的地基，这一步稳了，后面添砖加瓦才会顺利。

3. 深入单元测试：从单个函数开始验证

现在，我们的“厨房”已经就绪，可以开始烹饪第一道测试“菜肴”了。假设我们有一个非常简单的被测函数，它位于 calculator.c 文件中：

// calculator.h
#ifndef CALCULATOR_H
#define CALCULATOR_H

int add(int a, int b);
int subtract(int a, int b);

#endif

// calculator.c
#include "calculator.h"

int add(int a, int b) {
    return a + b;
}

int subtract(int a, int b) {
    return a - b;
}

我们的目标是测试 add 这个函数。在TESSY中，测试不是直接写在源文件里，而是通过创建“测试模块（Test Module）”来组织的。在工程浏览器中，右键点击你的工程，选择 New -> Test Module。系统会提示你命名这个测试模块，比如 Test_AddFunction，并且再次确认测试类型为 Unit。创建完成后，你会看到工程里多了一个 .tsm 文件，这就是你的测试模块文件。

双击打开这个 .tsm 文件，TESSY会打开一个专用的测试用例设计视图。这个视图通常分为几个部分：被测对象（Test Object）选择区、测试用例（Test Cases）设计表、变量与期望值设置区等。首先，我们需要指定要测试哪个函数。在“Test Object”区域，你可以浏览或搜索你的工程，找到 calculator.c 文件下的 add 函数，把它拖拽到测试对象区域。TESSY会自动分析这个函数的原型：int add(int a, int b)。

接下来就是设计测试用例的核心了。我们的目标是验证这个函数在各种输入下的输出是否正确。在测试用例设计表中，每一行代表一个测试用例。我们需要为参数 a 和 b 指定具体的输入值，并为函数的返回值（通常被TESSY自动命名为一个类似 RETURN 的变量）指定期望值（Expected Value）。

例如，我们可以设计以下几个用例：

1. 正常值测试：a=5, b=3，期望返回值是8。
2. 边界值测试：a=0, b=0，期望返回值是0。
3. 负数测试：a=-5, b=10，期望返回值是5。
4. 最大值测试：测试接近整数范围边界的情况（需根据int的范围设计）。

在设计表里，你直接在各用例行的 a、b 列输入测试值，在 RETURN 的期望值列输入 8、0、5 等。TESSY的强大之处在于，它不仅能处理简单的输入输出，还能让你设置“桩函数（Stub）”。什么是桩函数？假设 add 函数内部调用了另一个函数 log_operation 来记录日志，但这个日志函数依赖于硬件或复杂的系统。在单元测试时，我们并不想真正执行这个日志函数，只想让它返回一个我们预设的值或什么都不做。这时，你就可以为 log_operation 设置一个桩，指定它被调用时的返回值或行为，从而将被测函数 add 完美地隔离出来进行测试。在TESSY中，你可以在测试对象的设置里，找到对该函数的调用，并将其替换（Redirect）为一个桩实现。

设计好用例后，就可以运行测试了。点击工具栏上的绿色运行按钮，TESSY会执行以下动作：自动生成一个测试驱动代码（包含main函数），编译这个驱动代码（调用你配置的编译器），链接你的被测源代码和必要的库，最后执行生成的可执行文件。运行结束后，测试结果视图会清晰地展示出来：每个用例是通过（Pass，绿色对勾）还是失败（Fail，红色叉号）。如果失败，它会显示期望值是多少，实际值是多少，一目了然。你还可以查看生成的详细报告，里面包含了每个步骤的执行情况。通过这样一个个函数的测试积累，你就能像拼图一样，逐步建立起对代码底层逻辑的绝对信心。

4. 进阶集成测试：验证模块间的交互

单元测试保证了每个“零件”的质量，但把零件组装成“部件”或“机器”后，还能正常工作吗？这就是集成测试要回答的问题。在嵌入式系统中，模块之间通过接口函数、全局变量、消息队列等方式通信，集成测试就是要验证这些交互是否符合设计预期。在TESSY中，我们通过创建 Component Test 类型的工程或测试模块来实现。

让我们升级一下场景。假设现在有两个模块：calculator.c（计算模块）和 validator.c（验证模块）。validator 模块提供一个函数 validate_input，用来检查输入是否在有效范围内，然后 calculator 模块的 complex_calc 函数会先调用 validate_input，验证通过后才进行计算。这种跨模块的调用，就是典型的集成测试点。

首先，我们像第二章一样，创建一个新的TESSY工程，但在选择类型时，这次我们选择 Component Test。工程创建后，同样需要正确导入 calculator.c、validator.c 以及它们的所有头文件路径。接着，创建一个新的测试模块，类型也选择 Component。

在组件测试模块中，测试对象不再是一个孤立的函数，而是一个或多个模块的接口。你可以将 complex_calc 函数添加为测试对象。TESSY在分析时，会发现它内部调用了来自 validator.c 的 validate_input 函数。与单元测试不同，在集成测试中，我们通常不希望把 validate_input 打成桩（Stub），因为我们就是想测试这两个模块连接在一起的真实行为。我们希望 validate_input 的真实代码被执行。

那么，如何测试不同的交互路径呢？关键在于控制 validate_input 的输入，从而驱动 complex_calc 走不同的逻辑分支。虽然我们直接测试的是 complex_calc，但我们需要为它的间接输入——即 validate_input 的返回值——设计场景。在TESSY中，你可以通过几种方式实现：

• 直接设置被调用函数的返回值：在测试用例中，你可以指定当 validate_input 被调用时，强制返回某个值（比如 0 表示成功，-1 表示失败）。这听起来像打桩，但在集成测试中，这更像是为了模拟下游模块的某种特定状态，以验证上游模块的应对逻辑。
• 通过设置全局变量或输入参数来影响被调用函数：更真实的方式是，通过给 complex_calc 传入不同的参数，这些参数最终会传递给 validate_input，从而触发其内部不同的判断逻辑，产生不同的返回值。这就需要你对函数调用链有清晰的理解。

例如，我们可以设计这样两个集成测试用例：

1. 用例A（验证成功路径）：设置 complex_calc 的输入参数为合法值（比如两个正数）。预期结果是 validate_input 被真实调用并返回成功码，然后 complex_calc 完成计算并返回正确结果。
2. 用例B（验证失败处理路径）：设置 complex_calc 的输入参数为非法值（比如一个超大的数）。预期结果是 validate_input 被真实调用并返回错误码，然后 complex_calc 应检测到这个错误，并返回一个特定的错误代码（而不是崩溃或输出无意义数据）。

执行这些测试，你就是在验证模块间的“合约”是否被正确遵守。集成测试常常能发现一些单元测试发现不了的问题，比如：模块A认为模块B返回的错误码是-1，但模块B实际定义的是-100；或者模块A传递了一个指针，但模块B内部修改了指针所指内存的大小，造成了越界。这些问题只有在把它们集成在一起运行时才会暴露。TESSY的组件测试提供了强大的跟踪和调试能力，当测试失败时，你可以查看函数调用栈，精确地定位是哪个模块、哪个接口出的问题。

5. 测试数据管理与自动化实践

当你测试的函数越来越多，用例数量会急剧增长。管理好这些测试数据和用例，是维持测试工程可持续性的关键。在TESSY中，除了直接在图形界面设计用例外，它还支持从外部文件导入测试数据，比如CSV或XML格式。这对于参数化测试特别有用。想象一下，你要测试一个复杂的算法，有上百组输入输出组合。手动在表格里一行行输入不仅容易出错，效率也低。你可以用Excel或脚本生成一个CSV文件，第一列是输入a，第二列是输入b，第三列是期望值。然后在TESSY的测试模块中，使用“导入”功能，将这些数据一次性加载进来，自动生成对应的测试用例。下次算法调整，你只需要更新这个CSV文件，重新导入，测试用例就全部更新了，维护成本大大降低。

另一个提升效率的方向是自动化。我们不可能每次代码有改动，都手动打开TESSY点一下“运行”。TESSY通常支持命令行接口（CLI）。这意味着你可以将测试执行集成到你的持续集成（CI）流水线中，比如Jenkins或GitLab CI。你可以编写一个脚本，大致步骤如下：

1. 调用TESSY命令行工具，加载你的测试工程（.tpr 文件）。
2. 指定要运行的测试模块。
3. 执行测试。
4. 将测试结果输出为指定格式的报告（如JUnit XML格式）。
5. 根据测试结果（是否有失败用例）决定CI流水线是成功还是失败。

这样，每当开发人员提交一次代码，CI服务器就会自动拉取最新代码，运行全套TESSY测试。如果任何测试用例失败，CI会立即标记这次构建为失败，并通知相关人员。这种“早发现，早治疗”的机制，能将缺陷扼杀在摇篮里，避免其流入后续阶段造成更大的修复成本。我在项目中搭建了这套流程后，团队对代码修改的信心明显增强了，因为知道有一个自动化的“安全网”在背后兜着。

最后，分享几个我踩过的“坑”和总结的实用技巧：

• 头文件依赖是万恶之源：环境配置问题，80%出在头文件路径和宏定义上。务必确保测试环境中的路径和宏与真实编译环境一致。可以尝试先用编译器命令行编译通过你的源代码，再把参数搬到TESSY里。
• 善用“分析”功能：在添加测试对象前后，多使用 Analysis 功能。它能提前发现语法问题、找不到符号等问题，比运行时才报错要好得多。
• 从简单到复杂：不要一开始就测试最复杂的函数。从一个最简单的、没有外部依赖的函数开始，走通整个“创建工程-添加对象-设计用例-执行”的流程，建立信心和熟悉度。
• 测试用例命名要有意义：不要用“TestCase1”这种名字。用“Add_PositiveNumbers”、“Validate_Input_OutOfRange”这样的名字，一眼就能看出测试的意图，报告也更容易读。
• 定期审查和清理测试用例：随着代码重构，一些函数可能被删除或修改，对应的测试用例会失效。定期检查测试工程，保持其与源代码的同步。

测试不是一项写完代码后才进行的“附加任务”，而是驱动设计、保证质量的必要环节。TESSY这样的专业工具，正是为了将这项必要任务变得高效、规范且可重复。希望这篇指南能帮你顺利起步，在嵌入式软件质量保障的道路上走得更稳、更远。如果在实际操作中遇到具体问题，多查阅TESSY官方手册，那里面包含了每个功能和选项最详细的说明。