Testbed单元测试避坑：从覆盖率87%到可信报告实战

简介：《Testbed工具手册—单元测试方法V1.0.doc》面向使用C/C++ LDRA Testbed开展白盒测试与单元测试的开发、测试人员，重点解决测试环境配置、用例构建及覆盖率分析中的操作落地问题。压缩包共1个doc文件，约2.01MB，目录按简介、版本说明、单元测试步骤、问题解决及覆盖率与回归报告编排，便于按章节查阅。正文从选择待测文件与头文件路径、宏添加讲起，逐步覆盖分析项选择、测试序列创建、全局变量赋值、输入输出变量创建、入参指针或数组映射、桩函数返回值设置，以及用例运行、覆盖率查看和报告保存；后段还整理测试失败、软件崩溃等常见问题的排查方法，并说明覆盖率报告与回归报告的查看方式。已有6123人学习，适合需要掌握Testbed单元测试流程、补齐白盒测试实操细节的读者作为工具型参考。

1. 覆盖率卡在 87% 上不去：一个把单元测试拖成两周的坑

用例全部 PASS，回归报告里 Fails 一列是 0，可覆盖率报告里 MC/DC 就是卡在 87% 不动——这是我在做 testbed 单元测试时被拖得最久的一类现象，也是最容易被误判成「被测代码写错了」的坑。白盒测试做到交付前，最怕的不是用例跑不过，而是跑过了却拿不出可信的覆盖率证据：报告上显示 100%，重跑一遍掉回 82%，谁也说不清哪个数是真的，最后只能加班重来。这类故障适合两类人看：一类是第一次接手存量工程、要在规定时间里交出语句、分支、MC/DC 三级覆盖率的人；另一类是刚装完工具、点下 start analysis 就被一屏「未声明标识符」挡在门外的新手。下面按我实际踩过的顺序，把分析配置、用例搭建、指针映射、报告核对这四段拆开讲，每段都给能照着点的菜单路径和能照着抄的配置。

2. 分析阶段就翻车：头文件路径和宏没配好，一屏「未声明标识符」

最典型的一幕是这样的：File / Select File 选完待测的 c 文件，信心满满点 start analysis，几秒钟后日志区刷出一片红色，满屏 undefined identifier、cannot open include file，函数列表里连目标函数都没出现。很多人第一反应是「代码是不是有语法错」，跑回 IDE 编译一遍，工程好好的，于是开始怀疑工具装坏了。其实绝大多数情况跟代码无关，是 Testbed 在用自己的预处理器重走一遍编译流程，而它拿到的头文件搜索路径和宏定义跟你 IDE 里的那份完全是两套东西。

Testbed 做静态分析时不读 Keil、IAR、CMake 的工程文件，它只认 static options 里那份配置。工程换了目录、换了分支、别人把公共头文件挪了位置，这份配置就悄悄失效了。所以分析跑不过这件事，定位顺序永远是「先查路径，再查宏，最后查类型」，别一上来就动代码。

2.1 头文件路径：Search Options 和手工编辑 dat 是同一件事

触发条件很固定：选完文件直接分析，报找不到头文件或者大量标识符未声明。根因是搜索路径列表为空，或者只加了顶层目录、没包含子目录。工具按顺序在给定目录里找 include，找不到就当成未声明，后面所有依赖该头文件的类型、宏、函数原型全部连带报错，一条错误能衍生出几十条。

图形化的配法是这样：点 configure / static options，第一次配置时点标记的按钮新建一个 dat 文件，存放位置按自己习惯来，建议跟工程放一起方便随代码走；建好后点弹框中间的 Search Options，点「…」按钮选头文件目录；如果下级子目录多，勾上 Add Subdirectories as search paths，再点 Add search path，最后确定。子目录层级深的工程如果不勾这一项，你会看到明明目录选对了还是报找不到。

更省事的做法是直接编辑那个 dat 文件，点右侧的 Edit，按行写路径，行首用 1 表示这条语句有效、0 表示注释掉：

1 D:/work/ctrl_project/inc 1 D:/work/ctrl_project/inc/driver 1 D:/work/ctrl_project/lib/third_party/include 0 D:/work/ctrl_project/legacy/inc

这份文件本质上就是一份纯文本路径表，第一列是开关，后面是绝对路径，一行一个，没有引号也不需要分号。用 1 和 0 而不是删掉整行，好处是换分支或者临时切到旧版本时改一个字符就能切回来，不用重新翻目录。第四行那种被 0 注释掉的历史路径别急着删，很多工程在打回归包时会切回旧基线，留着能省一次回忆。

参数上有几个细节值得说清。路径一定写绝对路径，相对路径的基准目录是工具的工作目录，不是你的 c 文件所在目录，写相对路径十次有八次对不上。搜索顺序按文件里的行序生效，同名头文件存在于多个目录时，排在前面的先命中，这一点在多版本共存的项目里能解释「为什么本机对、同事机器错」的怪现象。改完 dat 必须重新 start analysis，配置是分析启动时读取的，改完不重跑等于没改。

常见误用我列三个：把 IDE 的工程文件当成配置来源，以为选完 c 文件工具就自动知道路径；把路径写到具体某个 .h 文件而不是目录；配置里混进中文路径或者空格路径且没做处理。前两个改一下就好，第三个在个别版本上会静默失败，表现为配置看起来对、分析就是找不到，换到纯英文无空格目录立刻正常。

2.2 宏没打开：整段条件编译被吃掉，分支数凭空少一半

头文件路径配好之后还有一个更隐蔽的坑：分析能跑通、函数也能列出来，但覆盖率报告里某个函数的分支数明显比源码少，有的函数干脆一个分支都没有。翻源码发现里面一大段逻辑包在#ifdef里，那个宏没打开，预处理阶段整段被删掉，Testbed 分析的是裁剪后的代码。分母变小，覆盖率看起来虚高，或者某个分支压根没进报告，你却在拼命设计用例去覆盖它。

宏的配置和头文件几乎一样：点 Macros，用 Find/Creat 按钮创建或打开一个 dat 文件，点 Edit Default 进入编辑，把需要开放的宏一行一个粘进去：

1 USE_HAL_DRIVER 1 BOARD_REV_B 1 ENABLE_DIAG_FRAME 0 DEBUG_TRACE

和头文件那份一样，1 是生效、0 是注释，区别在于这里每行是一个宏名，不写#define，也不写值。如果某个宏需要带值（比如缓冲区大小），按工具接受的写法补在宏名后面，不同版本对这个格式的宽容度不一样，最稳的办法是先只放宏名，需要带值的宏在头文件里给默认值。

这里有个经验：分析期用的宏和编译期用的宏必须对齐。你在 IDE 里编译时开着 BOARD_REV_B，分析时忘了开，工具看到的代码和你实际运行的代码就是两份，覆盖率数据再漂亮也不作数。我一般会把这两份 dat 放在同一目录、用同样的前缀命名，切换配置时两个一起改，避免只改一个。

失败时看什么？先看分析日志里的 warning，宏缺失有时只报 warning 不报 error，很容易被红色的 error 盖过去；再看覆盖率报告顶部的函数列表，如果某个本该存在的函数没出现在列表里，八成就是被条件编译裁掉了；最后可以打开 Generate Driver 生成的驱动源码，看里面的函数体是不是缺了你预期的那几行，这是最直接的证据。

2.3 自定义类型不被识别：Declaration Type 退回基本类型

第三个高频报错出现在指针映射环节，提示变量未声明，但那个变量明明在头文件里定义过，路径也配了。根因是工程里 typedef 出来的复合类型、带位域的结构体、被多层宏包装的类型别名，Testbed 的映射对话框解析不了，它生成的实体声明用了原始写法，编译驱动时就报未声明。

解决思路不是去改工程代码，而是在映射对话框里把类型退回到基本类型。建实体时 New Name 随便起，类型通常会自动生成，如果这个自动生成的类型有问题，就在 Declaration Type 处填指针或数组元素的基本类型，比如unsigned char；Array Bounds 处填数组脚标大小，需要按数组用时填真实长度，纯指针可以留空或填 1；Initial Value 处填初值。

提示：Declaration Type 退回基本类型只影响测试驱动里的实体声明，不改动被测代码。有人为了让它认识类型去改头文件里 typedef 的写法，那是在污染被测代码，后面回归全乱。

3. 用例建不起来：从 select analysis 到 Create New Test Case 的四个断点

分析通了之后，卡点会从日志区转移到单元测试界面上：函数列表是灰的、右键 Create New Test Case 之后一直转圈、用例建出来了但入参填了不生效。这一段的坑比第一段更碎，因为它涉及工具里两套变量的概念——函数形参和全局变量，以及两处赋值入口。搞不清这两组关系，就会出现「明明填了值，函数里读到还是 0」的玄学现场。

我的处理原则是先保证分析完整，再动手建用例，最后才调指针和桩。顺序反了，一个用例的问题会混进另一个用例的现象里，排查成本翻倍。

3.1 分析项只勾一半，单元测试界面进不去

现象是点进单元测试界面，右侧函数列表空的，或者目标函数在但显示为不可用；点了 UnitTest only 按钮也一样。根因是 select analysis 里的分析项没勾全，只做了静态分析的一部分，没生成动态分析需要的数据，单元测试界面拿不到可操作的函数信息。

标准动作是：在 select analysis 界面勾上前四项，点 start analysis，等分析完成，再点标记的按钮进入单元测试界面。手册里只写了「选择前四项」，不同版本文字表述略有差异，认准前四行的顺序即可。如果跳过这一步直接点 UnitTest only，工具默认会补做前四项分析，效果一样，但它把分析和单元测试揉在一次执行里，出问题时日志混在一起，你分不清是分析挂了还是用例挂了。我一般宁可多等一次分析，把两类问题隔开。

判断是否真的做完了，看两个地方：单元测试界面左侧的序列区能不能新建序列；覆盖率报告里的函数列表数量跟源码里的函数数量是否对得上。对不上就回退到分析这一步，别在用例上继续折腾。

3.2 Input parameter applied through local 与 Input global：赋错地方等于没赋

这是建用例阶段最容易翻车的一处。界面右下角会自动生成一批变量，Use 列有两种常见的取值：Input parameter applied through local 是函数的入参，只能在这一行赋值或者做映射；Input global 是函数体里直接引用的全局变量，既可以在右下角赋值，也可以转到用例的 Code Inserts 里赋。

为什么会赋了不生效？最常见的是把全局变量当成入参填在了 Input parameter 那一行，工具照样接受，值也存了，但驱动代码里根本没把这个值传给任何地方，函数运行时读到的还是全局变量自己的初值。反过来也成立：入参填到 Input global 里，函数形参拿不到。

还有一种更绕的情况：右下角自动生成了某条 Input global，同时你又在 Code Inserts / Initialisation Code 里给同一个全局变量赋了值，两条赋值都生效，谁后执行谁说话，结果取决于工具生成的驱动代码顺序——这就是我说过的玄学现场。正确做法是二选一：如果打算用 Code Inserts 赋值，先把右下角自动生成的那条 Input global 右键 remove 掉，再写初始化代码。

/* 用例级 Initialisation Code：每个用例执行前注入，给全局变量一个确定值 */ g_link_state = 0; /* 链路状态，被测函数据此走不同分支 */ g_retry_cnt = 3; /* 重试次数，影响循环体内分支 */ memset(g_rx_buf, 0, sizeof(g_rx_buf)); /* 接收缓冲区清零，避免上一用例残留 */

这段代码写在 Modify Existing Test Case / Code Inserts / Initialisation Code 弹出的编辑框里，每个用例独立保存。三行的作用分别是：给状态机一个确定的起始状态，让用例可复现；把循环次数钉死，确保循环体里每个分支都能被走到；清空缓冲区，避免上一个用例写入的数据漏到下一个用例，这是回归报告里出现「单独跑能过、连着跑就 FAIL」的主要原因。参数上唯一要注意的是类型匹配，sizeof计算的是驱动里声明的那份实体，如果实体是在映射对话框里手工建的，长度要跟 Array Bounds 填的值一致。

3.3 IO 变量的正确建法：Assign 和 Compare Write 别选反

右下角空白处右键，Create IO Variable In Test Case，弹框里四个字段：Name 填变量名，Type 填类型，Use 下拉选 Input Global 或 Output Global，Regression Analysis 选 Assign 或 Compare Write，Value 填输入值或预期输出值。

这四者的对应关系不能错：Input Global 配 Assign，表示「执行前把这个值赋进去」；Output Global 配 Compare Write，表示「执行后拿实际值跟这里的值比」。选反了不会报错，但结果没有意义——输入选 Compare Write，它会拿函数执行前那个初始值去比你填的预期值；输出选 Assign，它只把值写进去不做比较，回归报告里这条输出永远显示通过，你以为校验了，其实一个字都没验。

判断有没有配错，最快的办法是跑完一个用例看回归报告的输入输出明细：如果某条 Output Global 在明细里只有实际值、没有预期值对比，就是选成了 Assign。

4. 指针和数组入参映射：报「变量未声明」和数组越界的根因

指针入参是 Testbed 单元测试里绕不开的一关。被测函数写成int parse_frame(unsigned char *buf, unsigned int len, frame_t *out)这种形式，你在 Value 里直接填个字符串或者填个 0，跑起来不是读到空就是直接崩。原因很朴素：指针在测试驱动里是一个地址，工具得先有一个真实存在的实体让它指，你得告诉它这个地址指向谁、有多大、初值是什么。

这一步报的错通常有两类：一类是「变量未声明」，来自类型解析；一类是运行期越界或者读到脏数据，来自长度和初值没配对。两类错的排查路径不一样，别混在一起看。

4.1 Point to global Entity 与 Assign to global 的区别

在指针或数组那一行的 Value 处右键，会看到 Point to global Entity 和 Assign to global 两个入口。名字很像，语义不同：前者让指针指向一个新建的实体，驱动里生成的是地址赋值；后者把实体内容赋过去，偏向值拷贝。判断用哪个，看被测函数对这个参数是读还是写。只读的入参，两者都能用，我一般用 Point，驱动代码更短；函数内部要往里写的出参，用 Point 更稳，写回的内容能留在同一个实体上，方便后续用 Output Global 校验。

点进去之后会弹一个对话框，New Name 栏可以任意填，类型一般会自动生成。如果生成的类型不被识别，就按第 2 章说的退回基本类型，同时把 Array Bounds 和 Initial Value 补齐。这里有个连锁关系：Array Bounds 填 16，驱动里就声明成长度 16 的数组，你后续在 IO 变量里校验这个数组时，预期值也得按 16 个元素给，长度不一致会导致比较逻辑只比前面几个元素，剩下的没比也不报错。

映射完还得赋值。赋值有两个入口：右下角该变量的 Value 列，或者 Code Inserts 里的初始化代码。同样二选一，别两边都写。用 Value 列赋值适合固定的小数据；用初始化代码适合要按字节构造的报文，可读性好得多。

4.2 Create User Global 手工建实体，用 &变量名 指回去

有时候映射对话框里新建的实体不合意，比如需要在多个用例之间共享同一个缓冲区，或者需要精确控制实体名以便在报告里辨认。这时候走手工路线：点菜单栏 Global variables / Create User Global，弹出的对话框和方法一里那个基本一样，区别是没有任何默认类型，全部要手填。

填写步骤跟前面一致，Declaration Type、Array Bounds、Initial Value 三项按实际需要给。建好之后回到需要映射的指针那里，在 Value 处直接填&变量名；如果是数组，填变量名[n]，n 是你要传的起始下标。这个写法本质上是把驱动代码里那一行赋值手写出来，所以格式必须严格，多一个空格都可能解析失败。

/* 驱动里最终生成的效果，理解了这个就知道 Value 该填什么 */ unsigned char g_buf[64] = {0}; /* Create User Global 手工建的实体 */ frame_t g_out; /* 输出结构体实体，同样手工建 */ /* 被测函数调用处，对应 Value 列填的内容 */ ret = parse_frame(&g_buf[0], 32, &g_out);

看懂这段生成效果，映射这件事就没有神秘感了：&g_buf[0]对应在 buf 的 Value 处填g_buf[0]或者用映射对话框指过去，32是 len 这个普通入参直接在 Input parameter 行赋值，&g_out对应 out 的映射。第三行那个实体建好之后，再建一条 Output Global 指向 g_out 的字段做 Compare Write，就能校验函数写回来的内容。

失败时看什么？打开 Generate Driver 生成的驱动源码，找到调用被测函数那一行，看三个实参长什么样。指针实参如果是个未初始化的局部变量，说明映射没生效；如果是(unsigned char*)0，说明 Value 被填成了 0。这一步比看报错快得多，驱动源码是整件事的黑匣子。

4.3 桩函数返回值不生效：Set Return Value on Exit 的时机

被测函数里调用了别的模块，打桩是常规操作。在界面标记处双击能看到函数中调用到的函数列表，右键选中某个函数，点 Set Return Value on Exit，在弹框的 Value 处设值，这就让它在返回时给出指定值，而不是执行真实实现。

不生效的情况我遇到三种。第一种是设了返回值但函数体还是被执行了，导致真实逻辑里的副作用把结果覆盖掉，这通常是桩没打到位，回去确认这个函数在列表里是不是真的被标记成了桩。第二种是同一个函数在多个用例里设了不同的返回值，用 Resequence This Test Case 单独跑某个用例时，只应用当前用例的设置，前面用例的设置不会累积，这是符合预期的，但很容易被误解成「设置丢了」。第三种是把指针出参的期望值也塞进桩返回值里，两者是不同机制：返回值对应函数返回类型，指针出参的内容要靠 Output Global 的 Compare Write 校验。

注意：一个用例里只让桩返回一个值。想覆盖「成功」和「失败」两个分支，就建两个用例，各自设置桩值。在一个用例里指望桩返回两个不同结果，只会得到后设置的那个。

5. 常见问题与避坑：Suspend 输出、假 100% 覆盖、回归 FAIL 的现场记录

这一章是我自己的踩坑台账，四条都是反复出现、每次都让人怀疑工具的。写法统一成「现象 → 原因 → 解决」，方便对着现场一条条比。

5.1 输出变量 Value 是 Suspend，回归报告 Suspends 一列不为 0

现象：用例跑完 Status 是 PASS，但右下角某个输出变量的 Value 显示 suspend，回归报告里 Suspends 一列出现百分比。

原因：这条输出变量是自动生成的，Regression Analysis 没有配成 Compare Write，也没有给预期值，工具不知道拿什么去比，只能标记成待定。另一种情况是你把它 remove 掉了，但被测代码确实会写这个变量，报告里就少了这项校验。

解决：确认这个输出该不该校验。该校验就把 Regression Analysis 改成 Compare Write，Value 填预期值；不该校验就明确 remove，并在心里记一笔「这里没验」。交付前 Suspends 必须是 0，因为一个 suspend 就意味着一处输出没人看，覆盖率再高也缺一块证据。

5.2 覆盖率显示 100%，重跑掉到 80% 多

现象：一轮用例跑完，报告里语句、分支、MC/DC 全是 100%，为了确认又跑了一遍，数字掉下来了，谁也不知道哪个是真的。

原因：workfiles 里残留着上一轮的覆盖率数据，新数据叠在旧数据上，或者你用 Resequence This Test Case 单独跑了某个用例，报告中间一列只反映当前或最后一个单独执行的用例，右侧一列才是所有执行过的用例的汇总，看错列就会得出错误结论。

解决：点菜单栏 Source / Delete LDRA Testbed workfiles，在弹框里选中清除项后确定，把历史数据清干净，然后按全量方式重新跑一遍用例，再看覆盖率。看报告时注意颜色语义：绿色或黑色表示已覆盖，蓝色表示未覆盖；中间列和右侧列的口径不同，交付前只看右侧汇总列。这一步别省，清 workfiles 再重跑，是我每次交报告前的固定动作。

5.3 回归报告里出现 FAIL，Fails 不为 0

现象：某个用例 Status 是 FAIL，Fails 一列不是 0，单独跑这个用例又过了。

原因：按概率排，第一是预期值填错，尤其是数组和结构体，长度或字段顺序对不上；第二是指针映射指向的实体没初始化，上一次运行残留的数据被当成本次输入；第三是桩返回值跟真实实现不一致，函数走了另一条分支；第四是用例之间全局变量没重置，上一个用例改过的值漏到下一个。

解决：翻到回归报告下方，那里有每个用例的描述、输入输出、桩函数明细，逐字段对比实际值和预期值。连着跑失败、单独跑通过，几乎可以锁定是全局变量没重置，把公共全局变量的赋值统一挪到每个用例的 Initialisation Code 里，别指望工具的默认行为。改完重跑，确认 Status 全 PASS 且 Fails 为 0 再往下走。

5.4 报告导出漏文件，回归时找不回用例

现象：过两周要复跑，发现只剩一份覆盖率报告，用例序列和回归报告都没了，只能重建。

原因：三个导出入口分散在不同菜单，容易只存一个。而且默认目录常常是工具的工作目录，不是工程目录，重装或者换机器就丢。

解决：固定一套导出动作，三份文件同目录、同前缀保存：Sequence / Export Test Cases（TCF）导出用例序列，Results / Dynamic Coverage Analysis Report 导出覆盖率报告，Results / Regression Report 导出回归报告。TCF 是后面复跑和追溯用例的唯一凭据，比报告更重要。序列命名也有讲究，一般直接用待测函数名，回归时一眼就能定位到是哪个函数的用例集。

6. 快速定位：把分析、用例、覆盖率、回归四段拆开验

排查这类问题，最有效的习惯是别把四段揉在一起看，按「分析 → 用例 → 覆盖率 → 回归」的顺序逐段确认，每段只问一个问题：这段的产物对不对。

这张表我贴在显示器边上用了很久。它的价值不在于覆盖所有情况，而在于把「满屏报错」压缩成「先看哪一段」，避免在用例上折腾半天，最后发现是宏没打开。四段里任何一段没验证过，后面的数据都不可信，这是白盒测试里最朴素的因果链。

另外一个自查习惯：每次新建序列之前，先只跑一个最简单的用例，把 Generate Driver、Build Driver、Execute Driver、Process Regression Driver Output 四步分开点，而不是一键 Run Test Case Driver。分步点的意义在于错误会停在它发生的那一步——驱动没生成是映射问题，编译失败是类型问题，执行崩了是入参或桩的问题，回归比对不过才是预期值的问题。一键跑完只给你一个红色结果，分步点能直接告诉你红在哪。

从那以后我每次开新工程，都强制走一遍「路径 dat、宏 dat、前四项分析、单用例分步跑」这四步，哪怕工程看起来一切正常。血泪经验是：省下的那十分钟，通常会在交付前夜以十倍的代价还回来。这份手册里的原始步骤我按自己的踩坑顺序做了标注，配套的 dat 配置样例和用例导出命名约定一起整理在资源里，对着走一遍能少踩几个已经有人踩过的坑。希望帮到你。

本文还有配套的精品资源，点击获取