在LDRA Testbed中做单元测试时，测试驱动主要由TBrun生成，用来给被测函数传入数据、调用函数并收集实际输出。配置没对上时，常见表现是驱动生成失败、编译不过，或者程序刚运行就停在初始化阶段。

　　处理“Testbed测试驱动怎么配置Testbed测试驱动初始化失败怎么排查”，先确认测试跑在主机、目标板还是仿真器上。环境选错后，再反复修改测试数据，通常也解决不了问题。

　　一、Testbed测试驱动怎么配置

　　TBrun会分析被测单元的参数、全局变量、返回值、数据类型和外部调用，再自动生成测试驱动与测试框架。生成后的驱动可以运行在主机、目标硬件或仿真环境中。

　　1、先确定测试运行环境

　　项目刚开始配置时，建议先在主机环境跑通一条简单用例。主机测试正常后，再切到交叉编译器和目标板，问题更容易定位。

　　①打开Testbed项目并进入TBrun。

　　②选择需要测试的源文件和函数。

　　③进入【配置（Configure）】。

　　④打开【驱动构建与执行选项（Driver Build&Execution Options）】。

　　⑤选择主机、目标机或仿真器对应的构建方式。

　　⑥保存后重新生成测试驱动。

　　TBrun默认配置更接近主机到主机的测试场景。改成主机到目标机后，编译器、下载方式、执行命令和结果回传路径都要跟着调整，不能只换一个目标名称。

　　2、配置编译器和构建参数

　　①选择与实际项目一致的编译器。

　　②填写编译器、链接器和相关工具路径。

　　③补充头文件搜索目录。

　　④添加项目使用的宏定义和编译选项。

　　⑤检查库文件及链接顺序。

　　⑥先执行一次驱动编译。

　　这里最好直接参考原工程的真实构建参数。项目使用ARM交叉编译器，测试驱动却按桌面编译器处理，数据类型、关键字和头文件都可能对不上。

　　也别一次复制整条构建命令。先保留必要的包含目录、宏和库，能编译以后再逐项补回其他选项，排查会轻松不少。

　　3、设置驱动生成布局

　　TBrun的驱动布局文件控制驱动声明、测试初始化、输出函数和结果文件处理。C项目通常使用cshlayout.dat，C++项目可根据普通C++、MFC或STL环境选择相应布局文件。

　　①打开【配置】→【驱动生成与布局选项】。

　　②进入【S&H Generation】页面。

　　③检查当前布局文件。

　　④C项目选择对应C布局。

　　⑤C++项目根据所用库选择C++布局。

　　⑥保存后重新生成驱动。

　　普通C++项目误用了STL或MFC专用布局，未必马上报错，但生成代码可能多出不适用的声明。这个地方别凭文件名猜，和项目实际环境对应起来更稳。

　　4、设置输入、全局变量和桩函数

　　①在测试序列中填写函数输入值。

　　②为使用到的全局变量设置初始值。

　　③检查指针是否分配了有效对象或缓冲区。

　　④将测试范围外的函数设为桩函数。

　　⑤为桩函数填写返回值和输出参数。

　　⑥设置预期输出后保存测试用例。

　　TBrun能够自动识别被测单元的接口，并支持为测试范围外的函数和变量生成桩。测试数据还可以保存在测试用例文件中，后续直接用于回归测试。

　　指针只填一个地址值通常不够。它指向的内存、数组长度以及结构体成员也得准备好，不然驱动可能生成成功，一运行就在初始化阶段退出。

　　5、配置主机与目标机的数据回传

　　主机测试时，TBrun会分别生成测试序列和测试框架结果文件。目标环境只有一条输出通道时，可以通过【主机/目标选项（Host/Target Options）】把结果合并到.top文件，再由TBrun拆分处理。

　　①打开【配置】→【主机/目标选项】。

　　②选择目标数据文件模式。

　　③设置目标端结果输出路径。

　　④确认目录具有写入权限。

　　⑤配置文件传回主机的方式。

　　⑥运行简单用例验证结果能否返回。

　　目标程序明明执行了，TBrun却一直等不到结果，很多时候不是被测函数卡住，而是输出文件没有生成或没有传回来。

　　二、Testbed测试驱动初始化失败怎么排查

　　初始化失败别急着改测试期望值。驱动还没真正调用被测函数时，输出值对不对根本不是当前问题。先看失败发生在驱动生成、编译、链接，还是运行阶段。

　　1、编译器环境没有对齐

　　①打开驱动构建日志。

　　②找到第一条编译错误。

　　③核对编译器可执行文件路径。

　　④补齐缺失的头文件和宏定义。

　　⑤检查语言标准及处理器选项。

　　⑥清理旧结果后重新构建。

　　如果日志里连续出现大量未知类型和未定义宏，别一条条补代码。往前翻，通常是某个公共头文件没找到，或者原工程的条件编译宏没有带进测试环境。

　　2、外部符号没有处理

　　驱动编译通过、链接阶段报未定义符号时，通常是被测函数调用了测试范围外的函数，或者引用了没有提供定义的全局变量。

　　①查看链接器报告的符号名称。

　　②判断该符号应加入真实源码还是创建桩。

　　③外部函数暂时无法运行时生成桩函数。

　　④外部变量补充定义和初始值。

　　⑤再次构建测试驱动。

　　并不是所有函数都适合打桩。底层硬件接口、日志输出可以隔离，真正属于当前测试范围的业务函数如果也全替换掉，测试结果就没多少参考价值了。

　　3、初始化数据与类型不匹配

　　①检查参数类型和填写格式。

　　②核对数组长度与实际缓冲区大小。

　　③查看结构体成员是否全部初始化。

　　④检查枚举值有没有超出范围。

　　⑤为指针准备可访问的目标对象。

　　⑥删除可疑测试数据后逐项恢复。

　　源码结构体改过以后，旧测试用例可能还保留原来的字段布局。界面里看着数值都在，生成驱动时却已经和新代码对不上。这种情况重新分析源文件、刷新接口，再修测试数据更干脆。

　　4、布局文件或自定义驱动代码异常

　　①恢复默认驱动布局文件。

　　②暂时移除自定义初始化代码。

　　③重新生成一份干净驱动。

　　④先运行最小测试序列。

　　⑤再逐段加回自定义内容。

　　驱动布局文件允许根据主机和目标环境修改初始化、声明与输出处理。改动范围很大时，一个缺失的声明或提前返回，就可能让整个初始化过程停下来。

　　5、目标板没有完成启动或结果回传

　　①单独运行目标端可执行文件。

　　②确认程序已下载到正确地址。

　　③检查串口、网络或文件通道。

　　④查看目标端是否发生复位或异常。

　　⑤核对结果文件名称和保存目录。

　　⑥将超时设置调到合理范围后重试。

　　主机能跑、目标板不能跑时，先比较两套环境的字节序、数据宽度、启动代码和运行库。TBrun支持在主机、目标板及仿真器上执行同一类测试，但目标环境仍要使用匹配的编译和通信配置。

　　三、怎样更快定位测试驱动问题

　　测试驱动配置项不少，最省时间的办法不是全改一遍，而是先把环境缩到最小。

　　1、建立一条最小测试链路

　　挑一个参数简单、没有硬件依赖的函数，只保留一条测试用例。它能完成生成、编译、执行和结果回传，说明基础链路没问题。

　　再逐步加入全局变量、指针、外部调用和目标板执行。加到哪一步失败，范围一下就缩小了。

　　2、保留可用配置和测试用例

　　编译器路径、布局文件、目标通信设置确认可用后，可以保存为项目配置。测试序列则保存在TCF中，用于后续重复执行和回归验证。

　　别在每台电脑上从头手填一遍。配置差一个宏、一个库路径，最后表现出来的错误可能完全不同。

　　总结

　　“Testbed测试驱动怎么配置Testbed测试驱动初始化失败怎么排查”涉及编译环境、驱动布局、测试数据和目标通信等多个环节。配置时让测试环境尽量贴近真实工程，并从简单函数逐步扩展，问题会更容易定位。希望本文对大家配置Testbed测试驱动和排查初始化异常有所帮助。