简介本资源是一份聚焦嵌入式软件质量保障的权威白皮书面向汽车电子、医疗设备及工业控制等安全关键领域的开发工程师与测试人员系统解答单元测试为何必要、如何科学开展及如何借助Tessy工具落地实践。内容涵盖单元测试在IEC 61508、ISO 26262、IEC 62304等国际标准中的合规要求详解分类树方法CTM构建测试用例的四步流程并以Tessy实操案例贯穿单元接口定义、初始用例设计、自动化执行与回归验证全过程。资源为单文件PDF大小1.87MB结构清晰、图文结合含前言、标准对照、方法论详解、工具应用示例与总结共4大模块便于快速查阅与工程复用。目前已有4873人学习下载是理解高可靠性嵌入式单元测试体系与Tessy实战路径的精炼参考材料。1. 单元测试不是“写完代码再补的流程”而是嵌入开发节奏的质量锚点你有没有遇到过这样的情况一个 C 函数在集成环境里偶尔崩溃但单步调试时又一切正常或者某次小修逻辑后原本通过的模块突然在客户现场报错回溯发现是上游某个被调用函数的边界处理被悄悄改坏了这类问题背后往往不是代码写得不够快而是单元测试没在正确的时间、以正确的粒度、用正确的工具卡住质量出口。Tessy 不是另一个要学的新工具它是把“函数级可验证性”真正落地到嵌入式开发流水线里的工程化接口——它强制你定义输入怎么进、输出怎么出、异常怎么返把黑盒逻辑变成白纸黑字的契约。这份方案面向两类人一是正在做嵌入式毕设/课设的学生需要一份能答辩、能跑通、能体现工程思维的完整单元测试实践二是刚接手遗留 C 项目、被“改一处崩三处”折磨过的开发者需要一套可复现、可回归、不依赖整机环境的验证路径。它不讲抽象理论只拆解“从函数源码到覆盖率报告”的每一步动作、每个配置陷阱、每次失败日志该看哪一行。2. 总体架构设计三层隔离结构与四个核心交付物的职责划分Tessy 的工程价值不在它能点几下鼠标跑出个绿条而在于它用三层结构把“测试意图→测试执行→测试证据”彻底解耦。这三层不是概念分层而是物理隔离测试规范层Specification定义“测什么”测试实现层Implementation解决“怎么测”测试运行层Execution确保“测得稳”。这种分离让测试用例能脱离具体硬件存在也让回归测试真正成为可能——哪怕目标芯片停产只要源码还在Tessy 就能生成新的测试镜像。下面按实际交付顺序展开每一步都对应一个可打包、可提交、可答辩的产出物。2.1 测试规范层用分类树方法生成可追溯的测试用例集分类树方法Classification Tree Method, CTM不是花哨的数学游戏而是把模糊的“这个函数要测全”翻译成精确的“必须覆盖 7 种输入组合3 类边界值”的工程语言。它的核心是两步识别测试相关维度Classifications和构建组合表Combination Table。以白皮书中那个带 bug 的范围判断函数为例// range_check.c bool in_range(int start, int length, int value) { return (value start) (value (start length)); }它的测试维度绝不止value一个变量。CTM 要求你系统梳理输入维度 1start的取值类型→ 正数 / 零 / 负数 / 溢出临界值如 INT_MAX-10输入维度 2length的取值类型→ 正数 / 零 / 负数 / 溢出临界值输入维度 3value的取值类型→ 小于start/ 等于start/ 在(start, startlength)内 / 等于startlength/ 大于startlength隐含维度整数溢出行为→ 当start length溢出时函数是否仍返回合理结果提示CTM 不要求穷举所有组合那会爆炸而是用“正交表”或“边界值分析”选取最具缺陷检出率的子集。Tessy 内置的 CTM 编辑器支持拖拽生成组合表但关键在人工定义维度——漏掉“负数 length”这一类就永远测不出startlength溢出导致的未定义行为。生成的组合表最终导出为.ctm文件这是第一份交付物可版本控制的测试契约。它不包含任何代码只有结构化描述评审时导师一眼就能看出覆盖是否合理。2.2 测试实现层Tessy 自动生成驱动桩但接口适配必须手写Tessy 的自动化能力集中在“胶水代码”生成上但它绝不替你决定“如何模拟真实环境”。对上面的in_range()函数Tessy 会自动生成test_in_range.c主测试函数调用被测函数并断言结果stub_*.c占位桩文件如stub_printf.c防止链接失败test_data.h存放测试数据的头文件但以下三处必须人工介入否则测试就是空中楼阁输入数据初始化逻辑Tessy 只生成test_data.h中的数组但start,length,value的具体值需根据 CTM 组合表手动填入。例如当 CTM 要求测试startINT_MAX, length10时你必须确认该平台int是否为 32 位并在test_data.h中写#define START_VAL_0 2147483638 // INT_MAX - 10 #define LENGTH_VAL_0 10 #define VALUE_VAL_0 2147483647 // INT_MAX桩函数行为定制若被测函数调用了HAL_GPIO_WritePin()Tessy 生成的stub_HAL_GPIO_WritePin.c默认什么都不做。但你要验证“当 GPIO 写失败时函数是否返回错误码”就必须修改桩函数// stub_HAL_GPIO_WritePin.c uint8_t stub_gpio_write_result HAL_OK; // 全局控制返回值 HAL_StatusTypeDef HAL_GPIO_WritePin(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin, GPIO_PinState PinState) { if (stub_gpio_write_result ! HAL_OK) { return stub_gpio_write_result; } // 正常模拟逻辑... return HAL_OK; }这样测试用例就能通过stub_gpio_write_result HAL_ERROR主动触发异常分支。断言策略选择Tessy 支持TEST_ASSERT_EQUAL,TEST_ASSERT_TRUE等但对in_range()这种布尔函数不能只写TEST_ASSERT_TRUE(result)。必须结合 CTM 的预期结果列写成// 根据 CTM 第3行start5, length2, value7 → 期望 false TEST_ASSERT_FALSE(in_range(5, 2, 7));否则测试通过只是运气好不是逻辑正确。这三处手工工作构成第二份交付物可执行的测试实现包含.c/.h文件及修改说明。它证明你理解了被测函数与环境的交互本质而非盲目点击生成。2.3 测试运行层交叉编译链与目标环境的精准对齐Tessy 本身不编译代码它生成的测试工程需接入真实的编译链。这里最容易翻车的是ABI应用二进制接口不一致。例如你的产品代码用 ARM GCC 10.3 编译而 Tessy 默认调用系统 PATH 下的 GCC可能是 12.1会导致结构体内存布局差异如__attribute__((packed))处理不同浮点 ABI 模式不匹配-mfloat-abihardvssoftfp库函数符号解析失败memcpy实现版本冲突解决方案是强制 Tessy 使用项目指定的工具链在 Tessy 的Project Settings → Compiler中取消勾选 “Use system compiler”手动填写完整路径/opt/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-gcc在Additional Compiler Flags中粘贴产品工程的全部 CFLAGS尤其注意-mcpu,-march,-mfpu注意Tessy 的 “Test Execution” 配置页中“Target System” 必须与实际硬件匹配。若测试 STM32F4选ARM Cortex-M4若测试 RISC-V MCU则必须选RISC-V 32-bit并指定riscv32-elf-gcc。选错会导致生成的.elf文件无法在 OpenOCD 中加载。运行成功后Tessy 会生成.trfTest Result File和.html报告。这是第三份交付物带时间戳的原始测试证据。.trf文件可被其他工具解析.html报告则直接展示每条用例的输入、输出、执行时间、覆盖率色块——答辩时打开就能看到“第7条用例因整数溢出失败”比口头解释有力十倍。2.4 四个交付物的协同关系从需求到证据的闭环这四份交付物不是孤立文件而是环环相扣的证据链交付物文件名示例作用评审关注点测试契约range_check.ctm定义“应该测什么”来源是需求规格书维度是否覆盖安全关键场景如溢出、负值测试实现test_in_range.c,stub_*.c实现“怎么测”含人工适配逻辑桩函数是否模拟了真实故障模式断言是否与 CTM 严格对应测试证据test_report_20240520.html记录“测得怎样”含覆盖率和失败详情MC/DC 覆盖率是否 ≥ 90%失败用例是否有明确根因回归套件regression_suite.zip封装“下次怎么快速重测”含全部源码配置是否能在新环境一键导入并执行学生交毕设时把这四个文件夹打包附上一份《测试覆盖说明文档》200 字内解释 CTM 维度选择理由导师立刻能判断你是否真做过测试而非仅截图绿条。3. 关键模块实现Tessy 配置与 C 代码的双向映射细节Tessy 的强大在于它把测试工程变成了“可编程的配置项”但配置项背后是扎实的 C 语言机制。下面以三个高频模块为例说明配置如何落地为可验证的代码行为。3.1 接口自动识别Tessy 如何从 .c 文件提取函数签名Tessy 的 “Import Unit” 功能不是简单解析函数名而是执行一次轻量级预处理Preprocessing来捕获宏定义影响。例如若你的函数声明在头文件中被条件编译包裹// range_check.h #ifdef UNIT_TESTING #define RANGE_CHECK_API static #else #define RANGE_CHECK_API extern #endif RANGE_CHECK_API bool in_range(int start, int length, int value);Tessy 在导入时会自动定义UNIT_TESTING宏确保识别到static修饰的函数。但如果你的函数在.c文件中定义且未在头文件声明即无原型Tessy 会报错“Function not declared”。此时必须手动在test_in_range.c顶部添加// 必须添加否则 Tessy 无法生成正确调用 extern bool in_range(int start, int length, int value);提示Tessy 的 “Interface Editor” 页面显示的参数列表直接决定后续测试数据的输入框数量。如果它把int* buffer识别为“指针类型”而非“数组”你就无法在 GUI 中为buffer[0],buffer[1]单独赋值——必须在函数声明中显式写出数组大小void process_data(int buffer[10])。3.2 数据驱动测试如何用 CSV 文件批量注入测试用例Tessy 支持从 CSV 导入测试数据但这不是简单的“复制粘贴”。CSV 的列名必须与函数参数名完全一致区分大小写且需遵循 Tessy 的数据类型映射规则CSV 列名Tessy 解析为示例值注意事项startint32_t5,-10,2147483647超出int32_t范围会截断lengthuint32_t0,10,4294967295若 C 函数声明为int length需在 Tessy 的 Interface Editor 中手动将length类型改为int32_tvalueint32_t7,2147483647,-2147483648负数必须带负号-0会被解析为0expected_resultbooltrue,false不能写1/0否则 Tessy 视为整数而非布尔生成的 CSV 示例start,length,value,expected_result 5,2,7,false -10,5,-8,true 2147483647,1,2147483647,true导入后Tessy 会为每一行生成一个独立测试用例并在.c文件中展开为// 自动生成的 test_in_range.c 片段 void test_in_range_case_0(void) { bool result in_range(5, 2, 7); TEST_ASSERT_FALSE(result); // 对应 expected_resultfalse } void test_in_range_case_1(void) { bool result in_range(-10, 5, -8); TEST_ASSERT_TRUE(result); }这种映射让测试用例管理从“改代码”变为“改表格”极大降低维护成本。3.3 覆盖率分析MC/DC 覆盖率的底层实现原理Tessy 报告中的 “MC/DC Coverage” 不是魔法它依赖编译器插桩Instrumentation。当你启用 “Coverage Analysis” 时Tessy 会在编译前修改源码在每个判定表达式的分支点插入计数器// 原始代码 if ((value start) (value (start length))) { ... } // Tessy 插桩后简化示意 int __tessy_cond_0 (value start); __tessy_counter_0; int __tessy_cond_1 (value (start length)); __tessy_counter_1; if (__tessy_cond_0 __tessy_cond_1) { ... }这些计数器变量在测试结束后被读出Tessy 通过分析__tessy_cond_0和__tessy_cond_1的真假组合出现次数判断是否满足 MC/DC 要求每个条件独立影响判定结果value start为假时整个if必须为假每个条件的所有可能取值都被执行过注意MC/DC 覆盖率要求高但并非所有函数都需要。Tessy 允许你右键函数 → “Exclude from Coverage”对纯数据搬运函数如memcpy包装跳过插桩避免报告失真。4. 常见问题排查Tessy 工程中 4 个最易翻车的硬核坑点新手在 Tessy 上栽跟头往往不是不会点按钮而是不了解底层机制。以下是我在多个嵌入式项目中踩过的、最痛的四个坑按“现象→原因→解决”给出可立即操作的方案。4.1 现象测试用例全部通过但覆盖率报告显示“0%”原因覆盖率插桩未生效。常见于两种情况编译器优化等级过高-O2或-O3导致插桩代码被编译器优化掉Tessy 的 “Coverage Instrumentation” 选项未在Project Settings → Coverage中勾选或勾选后未重新生成测试工程。解决在Project Settings → Compiler → Optimization中将优化等级设为-O0无优化进入Project Settings → Coverage确保 “Enable coverage instrumentation” 打钩并点击 “Apply”最关键一步右键项目 → “Rebuild Test Environment”强制 Tessy 重新生成所有插桩代码。仅 Clean Build 不够4.2 现象测试执行时程序卡死在main()串口无任何输出原因Tessy 生成的测试工程默认使用main()作为入口但你的原始工程可能有自定义启动文件如startup_stm32f4xx.s或SystemInit()初始化而 Tessy 的test_main.c未调用它们导致时钟、中断等未配置printf等函数无法工作。解决打开 Tessy 生成的test_main.c找到int main(void)函数在RUN_TEST()调用前手动添加初始化代码int main(void) { // 添加你的硬件初始化 SystemInit(); // 芯片系统时钟初始化 HAL_Init(); // HAL 库初始化 MX_GPIO_Init(); // 外设初始化根据你的 CubeMX 生成 RUN_TEST(); return 0; }将SystemInit()等函数的声明头文件如stm32f4xx_hal.h添加到test_main.c顶部。4.3 现象调用外部函数如HAL_Delay()时链接失败提示undefined reference原因Tessy 的测试工程默认只链接被测函数及其直接依赖而HAL_Delay()依赖HAL_GetTick()后者又依赖 SysTick 中断服务函数形成依赖链。Tessy 不会自动解析这种间接依赖。解决在 Tessy 的Project Settings → Linker中点击 “Add Library”添加你的 HAL 库.a文件如STM32F4xx_HAL_Driver/Lib/libstm32f4xx_hal.a更推荐的做法用桩函数替代。在stub_HAL_Delay.c中写volatile uint32_t mock_tick 0; uint32_t HAL_GetTick(void) { return mock_tick; } void HAL_Delay(uint32_t Delay) { mock_tick Delay; }这样既避免链接复杂库又能精确控制延时行为。4.4 现象在 Windows 上生成的测试工程Linux 主机编译时报错No rule to make target all原因Tessy 的跨平台工程生成器在 Windows 上默认生成 Makefile 时路径分隔符用反斜杠\而 Linux 的make只认正斜杠/同时Windows 生成的 Makefile 可能调用cmd.exe而非sh。解决在 Tessy 的Project Settings → Build中将 “Build Tool” 从 “Default” 改为 “Custom”在 “Custom Build Command” 中填写make -f Makefile.linux手动创建Makefile.linux内容为标准 GNU Make 语法所有路径用/且第一行指定 shellSHELL : /bin/bash CC : arm-none-eabi-gcc CFLAGS : -mcpucortex-m4 -mfloat-abihard -mfpufpv4 ... # 后续规则...这样即可在 Linux 上稳定构建。5. 验收与答辩用三张表、一次演示、一个习惯征服评审老师答辩不是背诵 PPT而是用证据链证明你真的把单元测试“做进去了”而不是“贴在PPT上”。我带过的十几个嵌入式毕设项目凡是顺利通过的都做了同一件事把验收过程本身做成可演示的标准化动作。下面这套方法学生能照着做从业者能直接用。5.1 三张表让评审老师 3 分钟看懂你的测试深度不要堆砌文字描述用三张精炼表格直击要害。每张表控制在半页 A4 内答辩时投影出来老师扫一眼就明白你的工作量和专业度。表 1CTM 维度覆盖表证明你没漏关键场景测试维度取值类别选取依据是否覆盖安全关键点start正数 / 零 / 负数 /INT_MAX-10IEC 61508 SIL2 要求覆盖极端值是INT_MAX-10触发溢出length正数 / 零 / 负数ISO 26262 ASIL-B 要求验证非法输入是负数 length 导致逻辑反转valuestart/start/in range/startlength/startlength边界值分析法BVA是startlength暴露原 bug表 2测试用例执行表证明你真跑通了用例 ID输入start, length, value预期结果实际结果覆盖率贡献TC-001(5, 2, 7)falsefalse✅ MC/DC 条件1独立影响TC-002(-10, 5, -8)truetrue✅ MC/DC 条件2独立影响TC-003(2147483647, 1, 2147483647)truetrue✅ 溢出场景覆盖TC-004(10, -5, 12)falsefalse✅ 非法 length 覆盖表 3覆盖率对比表证明你比“只测正常流”强覆盖率类型本方案仅测“正常输入”基线提升幅度语句覆盖率Line100%62%38%分支覆盖率Branch100%55%45%MC/DC 覆盖率92.3%0%92.3%注基线数据来自对同一函数仅用 (1,1,1)、(5,2,6) 两个用例测试的结果提示表 3 的“基线”不是虚构的是你自己用最简测试跑出来的。答辩时老师问“为什么要做这么多用例”你就打开这个表指着数字说“因为少测这 4 个边界就会漏掉 3 个严重缺陷”。5.2 一次演示5 分钟现场重现“从 bug 到修复”的完整闭环答辩时别只放静态截图。准备一个 5 分钟的现场演示步骤如下Step 11 分钟打开 Tessy加载原始工程运行全部测试——展示“TC-001 失败”控制台输出Expected false, was trueStep 21 分钟打开range_check.c定位到return (value start) (value (start length));指出value (start length)时应返回false但当前逻辑返回trueStep 32 分钟修改代码为return (value start) (value (start length)) (value ! (start length));保存Step 41 分钟在 Tessy 中点击 “Rebuild Run”展示 TC-001 变绿且 MC/DC 覆盖率从 92.3% 升至 95.1%。这个演示的价值在于它把“单元测试提高质量”从口号变成可触摸的动作。老师看到你 2 分钟就定位并修复了一个隐蔽 bug自然相信你掌握了方法论。5.3 一个习惯每次提交代码前强制运行回归套件最后一点也是我带项目时最坚持的习惯把 Tessy 回归测试变成 Git 提交的强制门禁。具体做法在项目根目录放一个run_regression.sh脚本#!/bin/bash echo Running Tessy regression suite... /opt/tessy-4.5/tessy_cli --project ./tessy_project.tsp --run-all --export-html ./report.html if [ $? -ne 0 ]; then echo Regression failed! Check report.html exit 1 fi echo All tests passed.在 Git 的pre-commit钩子中调用它# .git/hooks/pre-commit ./run_regression.sh这样任何同学想提交代码都必须先通过全部单元测试。久而久之团队里没人再问“这个函数测没测”因为答案永远是“没过回归就提不了”。从那以后我每次带新项目都强制走一遍这个回归门禁流程——不是为了卡进度而是让“质量”从一句口号变成每次敲git commit时键盘上实实在在的触感。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/29 4:00:11 · 阅读 1.2k 嵌入式C单元测试实战：Tessy+CTM实现MC/DC覆盖率闭环
简介本资源是一份聚焦嵌入式软件质量保障的权威白皮书面向汽车电子、医疗设备及工业控制等安全关键领域的开发工程师与测试人员系统解答单元测试为何必要、如何科学开展及如何借助Tessy工具落地实践。内容涵盖单元测试在IEC 61508、ISO 26262、IEC 62304等国际标准中的合规要求详解分类树方法CTM构建测试用例的四步流程并以Tessy实操案例贯穿单元接口定义、初始用例设计、自动化执行与回归验证全过程。资源为单文件PDF大小1.87MB结构清晰、图文结合含前言、标准对照、方法论详解、工具应用示例与总结共4大模块便于快速查阅与工程复用。目前已有4873人学习下载是理解高可靠性嵌入式单元测试体系与Tessy实战路径的精炼参考材料。1. 单元测试不是“写完代码再补的流程”而是嵌入开发节奏的质量锚点你有没有遇到过这样的情况一个 C 函数在集成环境里偶尔崩溃但单步调试时又一切正常或者某次小修逻辑后原本通过的模块突然在客户现场报错回溯发现是上游某个被调用函数的边界处理被悄悄改坏了这类问题背后往往不是代码写得不够快而是单元测试没在正确的时间、以正确的粒度、用正确的工具卡住质量出口。Tessy 不是另一个要学的新工具它是把“函数级可验证性”真正落地到嵌入式开发流水线里的工程化接口——它强制你定义输入怎么进、输出怎么出、异常怎么返把黑盒逻辑变成白纸黑字的契约。这份方案面向两类人一是正在做嵌入式毕设/课设的学生需要一份能答辩、能跑通、能体现工程思维的完整单元测试实践二是刚接手遗留 C 项目、被“改一处崩三处”折磨过的开发者需要一套可复现、可回归、不依赖整机环境的验证路径。它不讲抽象理论只拆解“从函数源码到覆盖率报告”的每一步动作、每个配置陷阱、每次失败日志该看哪一行。2. 总体架构设计三层隔离结构与四个核心交付物的职责划分Tessy 的工程价值不在它能点几下鼠标跑出个绿条而在于它用三层结构把“测试意图→测试执行→测试证据”彻底解耦。这三层不是概念分层而是物理隔离测试规范层Specification定义“测什么”测试实现层Implementation解决“怎么测”测试运行层Execution确保“测得稳”。这种分离让测试用例能脱离具体硬件存在也让回归测试真正成为可能——哪怕目标芯片停产只要源码还在Tessy 就能生成新的测试镜像。下面按实际交付顺序展开每一步都对应一个可打包、可提交、可答辩的产出物。2.1 测试规范层用分类树方法生成可追溯的测试用例集分类树方法Classification Tree Method, CTM不是花哨的数学游戏而是把模糊的“这个函数要测全”翻译成精确的“必须覆盖 7 种输入组合3 类边界值”的工程语言。它的核心是两步识别测试相关维度Classifications和构建组合表Combination Table。以白皮书中那个带 bug 的范围判断函数为例// range_check.c bool in_range(int start, int length, int value) { return (value start) (value (start length)); }它的测试维度绝不止value一个变量。CTM 要求你系统梳理输入维度 1start的取值类型→ 正数 / 零 / 负数 / 溢出临界值如 INT_MAX-10输入维度 2length的取值类型→ 正数 / 零 / 负数 / 溢出临界值输入维度 3value的取值类型→ 小于start/ 等于start/ 在(start, startlength)内 / 等于startlength/ 大于startlength隐含维度整数溢出行为→ 当start length溢出时函数是否仍返回合理结果提示CTM 不要求穷举所有组合那会爆炸而是用“正交表”或“边界值分析”选取最具缺陷检出率的子集。Tessy 内置的 CTM 编辑器支持拖拽生成组合表但关键在人工定义维度——漏掉“负数 length”这一类就永远测不出startlength溢出导致的未定义行为。生成的组合表最终导出为.ctm文件这是第一份交付物可版本控制的测试契约。它不包含任何代码只有结构化描述评审时导师一眼就能看出覆盖是否合理。2.2 测试实现层Tessy 自动生成驱动桩但接口适配必须手写Tessy 的自动化能力集中在“胶水代码”生成上但它绝不替你决定“如何模拟真实环境”。对上面的in_range()函数Tessy 会自动生成test_in_range.c主测试函数调用被测函数并断言结果stub_*.c占位桩文件如stub_printf.c防止链接失败test_data.h存放测试数据的头文件但以下三处必须人工介入否则测试就是空中楼阁输入数据初始化逻辑Tessy 只生成test_data.h中的数组但start,length,value的具体值需根据 CTM 组合表手动填入。例如当 CTM 要求测试startINT_MAX, length10时你必须确认该平台int是否为 32 位并在test_data.h中写#define START_VAL_0 2147483638 // INT_MAX - 10 #define LENGTH_VAL_0 10 #define VALUE_VAL_0 2147483647 // INT_MAX桩函数行为定制若被测函数调用了HAL_GPIO_WritePin()Tessy 生成的stub_HAL_GPIO_WritePin.c默认什么都不做。但你要验证“当 GPIO 写失败时函数是否返回错误码”就必须修改桩函数// stub_HAL_GPIO_WritePin.c uint8_t stub_gpio_write_result HAL_OK; // 全局控制返回值 HAL_StatusTypeDef HAL_GPIO_WritePin(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin, GPIO_PinState PinState) { if (stub_gpio_write_result ! HAL_OK) { return stub_gpio_write_result; } // 正常模拟逻辑... return HAL_OK; }这样测试用例就能通过stub_gpio_write_result HAL_ERROR主动触发异常分支。断言策略选择Tessy 支持TEST_ASSERT_EQUAL,TEST_ASSERT_TRUE等但对in_range()这种布尔函数不能只写TEST_ASSERT_TRUE(result)。必须结合 CTM 的预期结果列写成// 根据 CTM 第3行start5, length2, value7 → 期望 false TEST_ASSERT_FALSE(in_range(5, 2, 7));否则测试通过只是运气好不是逻辑正确。这三处手工工作构成第二份交付物可执行的测试实现包含.c/.h文件及修改说明。它证明你理解了被测函数与环境的交互本质而非盲目点击生成。2.3 测试运行层交叉编译链与目标环境的精准对齐Tessy 本身不编译代码它生成的测试工程需接入真实的编译链。这里最容易翻车的是ABI应用二进制接口不一致。例如你的产品代码用 ARM GCC 10.3 编译而 Tessy 默认调用系统 PATH 下的 GCC可能是 12.1会导致结构体内存布局差异如__attribute__((packed))处理不同浮点 ABI 模式不匹配-mfloat-abihardvssoftfp库函数符号解析失败memcpy实现版本冲突解决方案是强制 Tessy 使用项目指定的工具链在 Tessy 的Project Settings → Compiler中取消勾选 “Use system compiler”手动填写完整路径/opt/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-gcc在Additional Compiler Flags中粘贴产品工程的全部 CFLAGS尤其注意-mcpu,-march,-mfpu注意Tessy 的 “Test Execution” 配置页中“Target System” 必须与实际硬件匹配。若测试 STM32F4选ARM Cortex-M4若测试 RISC-V MCU则必须选RISC-V 32-bit并指定riscv32-elf-gcc。选错会导致生成的.elf文件无法在 OpenOCD 中加载。运行成功后Tessy 会生成.trfTest Result File和.html报告。这是第三份交付物带时间戳的原始测试证据。.trf文件可被其他工具解析.html报告则直接展示每条用例的输入、输出、执行时间、覆盖率色块——答辩时打开就能看到“第7条用例因整数溢出失败”比口头解释有力十倍。2.4 四个交付物的协同关系从需求到证据的闭环这四份交付物不是孤立文件而是环环相扣的证据链交付物文件名示例作用评审关注点测试契约range_check.ctm定义“应该测什么”来源是需求规格书维度是否覆盖安全关键场景如溢出、负值测试实现test_in_range.c,stub_*.c实现“怎么测”含人工适配逻辑桩函数是否模拟了真实故障模式断言是否与 CTM 严格对应测试证据test_report_20240520.html记录“测得怎样”含覆盖率和失败详情MC/DC 覆盖率是否 ≥ 90%失败用例是否有明确根因回归套件regression_suite.zip封装“下次怎么快速重测”含全部源码配置是否能在新环境一键导入并执行学生交毕设时把这四个文件夹打包附上一份《测试覆盖说明文档》200 字内解释 CTM 维度选择理由导师立刻能判断你是否真做过测试而非仅截图绿条。3. 关键模块实现Tessy 配置与 C 代码的双向映射细节Tessy 的强大在于它把测试工程变成了“可编程的配置项”但配置项背后是扎实的 C 语言机制。下面以三个高频模块为例说明配置如何落地为可验证的代码行为。3.1 接口自动识别Tessy 如何从 .c 文件提取函数签名Tessy 的 “Import Unit” 功能不是简单解析函数名而是执行一次轻量级预处理Preprocessing来捕获宏定义影响。例如若你的函数声明在头文件中被条件编译包裹// range_check.h #ifdef UNIT_TESTING #define RANGE_CHECK_API static #else #define RANGE_CHECK_API extern #endif RANGE_CHECK_API bool in_range(int start, int length, int value);Tessy 在导入时会自动定义UNIT_TESTING宏确保识别到static修饰的函数。但如果你的函数在.c文件中定义且未在头文件声明即无原型Tessy 会报错“Function not declared”。此时必须手动在test_in_range.c顶部添加// 必须添加否则 Tessy 无法生成正确调用 extern bool in_range(int start, int length, int value);提示Tessy 的 “Interface Editor” 页面显示的参数列表直接决定后续测试数据的输入框数量。如果它把int* buffer识别为“指针类型”而非“数组”你就无法在 GUI 中为buffer[0],buffer[1]单独赋值——必须在函数声明中显式写出数组大小void process_data(int buffer[10])。3.2 数据驱动测试如何用 CSV 文件批量注入测试用例Tessy 支持从 CSV 导入测试数据但这不是简单的“复制粘贴”。CSV 的列名必须与函数参数名完全一致区分大小写且需遵循 Tessy 的数据类型映射规则CSV 列名Tessy 解析为示例值注意事项startint32_t5,-10,2147483647超出int32_t范围会截断lengthuint32_t0,10,4294967295若 C 函数声明为int length需在 Tessy 的 Interface Editor 中手动将length类型改为int32_tvalueint32_t7,2147483647,-2147483648负数必须带负号-0会被解析为0expected_resultbooltrue,false不能写1/0否则 Tessy 视为整数而非布尔生成的 CSV 示例start,length,value,expected_result 5,2,7,false -10,5,-8,true 2147483647,1,2147483647,true导入后Tessy 会为每一行生成一个独立测试用例并在.c文件中展开为// 自动生成的 test_in_range.c 片段 void test_in_range_case_0(void) { bool result in_range(5, 2, 7); TEST_ASSERT_FALSE(result); // 对应 expected_resultfalse } void test_in_range_case_1(void) { bool result in_range(-10, 5, -8); TEST_ASSERT_TRUE(result); }这种映射让测试用例管理从“改代码”变为“改表格”极大降低维护成本。3.3 覆盖率分析MC/DC 覆盖率的底层实现原理Tessy 报告中的 “MC/DC Coverage” 不是魔法它依赖编译器插桩Instrumentation。当你启用 “Coverage Analysis” 时Tessy 会在编译前修改源码在每个判定表达式的分支点插入计数器// 原始代码 if ((value start) (value (start length))) { ... } // Tessy 插桩后简化示意 int __tessy_cond_0 (value start); __tessy_counter_0; int __tessy_cond_1 (value (start length)); __tessy_counter_1; if (__tessy_cond_0 __tessy_cond_1) { ... }这些计数器变量在测试结束后被读出Tessy 通过分析__tessy_cond_0和__tessy_cond_1的真假组合出现次数判断是否满足 MC/DC 要求每个条件独立影响判定结果value start为假时整个if必须为假每个条件的所有可能取值都被执行过注意MC/DC 覆盖率要求高但并非所有函数都需要。Tessy 允许你右键函数 → “Exclude from Coverage”对纯数据搬运函数如memcpy包装跳过插桩避免报告失真。4. 常见问题排查Tessy 工程中 4 个最易翻车的硬核坑点新手在 Tessy 上栽跟头往往不是不会点按钮而是不了解底层机制。以下是我在多个嵌入式项目中踩过的、最痛的四个坑按“现象→原因→解决”给出可立即操作的方案。4.1 现象测试用例全部通过但覆盖率报告显示“0%”原因覆盖率插桩未生效。常见于两种情况编译器优化等级过高-O2或-O3导致插桩代码被编译器优化掉Tessy 的 “Coverage Instrumentation” 选项未在Project Settings → Coverage中勾选或勾选后未重新生成测试工程。解决在Project Settings → Compiler → Optimization中将优化等级设为-O0无优化进入Project Settings → Coverage确保 “Enable coverage instrumentation” 打钩并点击 “Apply”最关键一步右键项目 → “Rebuild Test Environment”强制 Tessy 重新生成所有插桩代码。仅 Clean Build 不够4.2 现象测试执行时程序卡死在main()串口无任何输出原因Tessy 生成的测试工程默认使用main()作为入口但你的原始工程可能有自定义启动文件如startup_stm32f4xx.s或SystemInit()初始化而 Tessy 的test_main.c未调用它们导致时钟、中断等未配置printf等函数无法工作。解决打开 Tessy 生成的test_main.c找到int main(void)函数在RUN_TEST()调用前手动添加初始化代码int main(void) { // 添加你的硬件初始化 SystemInit(); // 芯片系统时钟初始化 HAL_Init(); // HAL 库初始化 MX_GPIO_Init(); // 外设初始化根据你的 CubeMX 生成 RUN_TEST(); return 0; }将SystemInit()等函数的声明头文件如stm32f4xx_hal.h添加到test_main.c顶部。4.3 现象调用外部函数如HAL_Delay()时链接失败提示undefined reference原因Tessy 的测试工程默认只链接被测函数及其直接依赖而HAL_Delay()依赖HAL_GetTick()后者又依赖 SysTick 中断服务函数形成依赖链。Tessy 不会自动解析这种间接依赖。解决在 Tessy 的Project Settings → Linker中点击 “Add Library”添加你的 HAL 库.a文件如STM32F4xx_HAL_Driver/Lib/libstm32f4xx_hal.a更推荐的做法用桩函数替代。在stub_HAL_Delay.c中写volatile uint32_t mock_tick 0; uint32_t HAL_GetTick(void) { return mock_tick; } void HAL_Delay(uint32_t Delay) { mock_tick Delay; }这样既避免链接复杂库又能精确控制延时行为。4.4 现象在 Windows 上生成的测试工程Linux 主机编译时报错No rule to make target all原因Tessy 的跨平台工程生成器在 Windows 上默认生成 Makefile 时路径分隔符用反斜杠\而 Linux 的make只认正斜杠/同时Windows 生成的 Makefile 可能调用cmd.exe而非sh。解决在 Tessy 的Project Settings → Build中将 “Build Tool” 从 “Default” 改为 “Custom”在 “Custom Build Command” 中填写make -f Makefile.linux手动创建Makefile.linux内容为标准 GNU Make 语法所有路径用/且第一行指定 shellSHELL : /bin/bash CC : arm-none-eabi-gcc CFLAGS : -mcpucortex-m4 -mfloat-abihard -mfpufpv4 ... # 后续规则...这样即可在 Linux 上稳定构建。5. 验收与答辩用三张表、一次演示、一个习惯征服评审老师答辩不是背诵 PPT而是用证据链证明你真的把单元测试“做进去了”而不是“贴在PPT上”。我带过的十几个嵌入式毕设项目凡是顺利通过的都做了同一件事把验收过程本身做成可演示的标准化动作。下面这套方法学生能照着做从业者能直接用。5.1 三张表让评审老师 3 分钟看懂你的测试深度不要堆砌文字描述用三张精炼表格直击要害。每张表控制在半页 A4 内答辩时投影出来老师扫一眼就明白你的工作量和专业度。表 1CTM 维度覆盖表证明你没漏关键场景测试维度取值类别选取依据是否覆盖安全关键点start正数 / 零 / 负数 /INT_MAX-10IEC 61508 SIL2 要求覆盖极端值是INT_MAX-10触发溢出length正数 / 零 / 负数ISO 26262 ASIL-B 要求验证非法输入是负数 length 导致逻辑反转valuestart/start/in range/startlength/startlength边界值分析法BVA是startlength暴露原 bug表 2测试用例执行表证明你真跑通了用例 ID输入start, length, value预期结果实际结果覆盖率贡献TC-001(5, 2, 7)falsefalse✅ MC/DC 条件1独立影响TC-002(-10, 5, -8)truetrue✅ MC/DC 条件2独立影响TC-003(2147483647, 1, 2147483647)truetrue✅ 溢出场景覆盖TC-004(10, -5, 12)falsefalse✅ 非法 length 覆盖表 3覆盖率对比表证明你比“只测正常流”强覆盖率类型本方案仅测“正常输入”基线提升幅度语句覆盖率Line100%62%38%分支覆盖率Branch100%55%45%MC/DC 覆盖率92.3%0%92.3%注基线数据来自对同一函数仅用 (1,1,1)、(5,2,6) 两个用例测试的结果提示表 3 的“基线”不是虚构的是你自己用最简测试跑出来的。答辩时老师问“为什么要做这么多用例”你就打开这个表指着数字说“因为少测这 4 个边界就会漏掉 3 个严重缺陷”。5.2 一次演示5 分钟现场重现“从 bug 到修复”的完整闭环答辩时别只放静态截图。准备一个 5 分钟的现场演示步骤如下Step 11 分钟打开 Tessy加载原始工程运行全部测试——展示“TC-001 失败”控制台输出Expected false, was trueStep 21 分钟打开range_check.c定位到return (value start) (value (start length));指出value (start length)时应返回false但当前逻辑返回trueStep 32 分钟修改代码为return (value start) (value (start length)) (value ! (start length));保存Step 41 分钟在 Tessy 中点击 “Rebuild Run”展示 TC-001 变绿且 MC/DC 覆盖率从 92.3% 升至 95.1%。这个演示的价值在于它把“单元测试提高质量”从口号变成可触摸的动作。老师看到你 2 分钟就定位并修复了一个隐蔽 bug自然相信你掌握了方法论。5.3 一个习惯每次提交代码前强制运行回归套件最后一点也是我带项目时最坚持的习惯把 Tessy 回归测试变成 Git 提交的强制门禁。具体做法在项目根目录放一个run_regression.sh脚本#!/bin/bash echo Running Tessy regression suite... /opt/tessy-4.5/tessy_cli --project ./tessy_project.tsp --run-all --export-html ./report.html if [ $? -ne 0 ]; then echo Regression failed! Check report.html exit 1 fi echo All tests passed.在 Git 的pre-commit钩子中调用它# .git/hooks/pre-commit ./run_regression.sh这样任何同学想提交代码都必须先通过全部单元测试。久而久之团队里没人再问“这个函数测没测”因为答案永远是“没过回归就提不了”。从那以后我每次带新项目都强制走一遍这个回归门禁流程——不是为了卡进度而是让“质量”从一句口号变成每次敲git commit时键盘上实实在在的触感。希望帮到你。本文还有配套的精品资源点击获取