VectorCAST与TRACE32自动化测试平台集成实录提到嵌入式软件的自动化测试VectorCAST和Lauterbach TRACE32这两个名字在行业里基本绕不开。VectorCAST负责测试用例的生成、执行和覆盖率统计TRACE32负责目标机调试和运行控制。很多人一开始会觉得这两个工具各干各的——VectorCAST在主机上编译跑测试TRACE32在调试器上连目标板两者没什么交集。但真正做过嵌入式单元测试和集成测试的人会发现当被测代码需要跑在真实处理器上、依赖特定外设寄存器、或者涉及中断和时序逻辑时单纯靠VectorCAST的宿主模式Host Execution根本不够用。这时候把VectorCAST的执行后端切到TRACE32让测试用例通过调试器下载到目标板上去跑就成了一个非常刚需的用法。这篇文章我从自己实际搭建这套平台的经验出发把VectorCAST集成TRACE32的完整思路、配置步骤、脚本写法以及踩过的坑一次性讲清楚。内容面向的是有嵌入式测试基础、想把回归测试真正跑在目标硬件上的团队也适合那些刚接手VectorCAST、正在纠结怎么和调试器对接的测试开发工程师。1. 为什么要把VectorCAST和TRACE32绑在一起先说一个很现实的问题VectorCAST默认的测试执行方式是在主机上把被测代码和测试桩stub编译成可执行文件然后直接在PC上跑。这种方式速度快、反馈及时做纯逻辑层面的单元测试完全够用。但一旦被测代码涉及到以下任何一种情况宿主模式就会出问题代码里直接操作了特定寄存器地址比如*(volatile uint32_t *)0x40021000 0x01;这种写法在主机上跑轻则读不到正确值重则直接段错误。代码依赖启动文件、中断向量表或者底层的BSP初始化逻辑这些在主机编译环境下根本不存在。被测函数内部有临界区保护、关中断、等待标志位之类的操作纯软件模拟无法还原真实的时序。你需要在真实的总线速率、Flash等待周期、RAM时序下验证时序相关的逻辑。这个时候用TRACE32作为VectorCAST的执行后端把测试用例和被测代码交叉编译后下载到目标板上运行就成了一种标准的“目标机测试”Target Execution方案。VectorCAST负责生成测试驱动、测试用例数据和覆盖率分析TRACE32负责把可执行文件加载到目标硬件、控制CPU运行、在测试结束后把结果回传给主机。1.1 两个工具分别解决什么问题VectorCAST在这套方案里的角色是测试用例的“生产工厂”。它根据你选的函数或者代码单元自动生成测试驱动Test Driver把被测函数的入口参数、全局变量、返回值这些全部做成可编辑的用例数据。它还支持打桩Stubbing把被测函数依赖的下游函数替换成可控的桩函数这样就能隔离测试单独验证某一个函数的逻辑。TRACE32在这套方案里的角色是目标机的“遥控器”。它通过JTAG、SWD、ETM等调试接口连接目标处理器的调试端口能控制CPU的启动、暂停、单步、断点还能读写内存和外设寄存器甚至在不打断CPU运行的情况下实时采集指令流和数据流通过ETM和TPIU。在VectorCAST的集成场景里TRACE32主要承担两件事把编译产物下载到目标板以及执行运行控制。两者配合后测试流程变成VectorCAST编译出带测试驱动的目标文件调用TRACE32的脚本接口把文件下载到目标板然后TRACE32启动CPU运行测试程序测试程序把结果写到约定好的内存区域或者通过串口/UART输出VectorCAST再把这些结果读回来做判定和覆盖率统计。1.2 不做集成时有多痛苦在没做集成之前我们的团队是另外一个工作方式白天在VectorCAST里做用例设计晚上手动开TRACE32把编译好的可执行文件拖到目标板上然后人工操作脚本跑一轮测试再把日志拷回来。做过的人都知道这中间有大量手工重复劳动每次代码改了都要重新编译、重新下载、重新跑漏一步测试结果就不可信。覆盖率数据经常因为跑的不是最新版本而作废回归测试又得从头来。有时候晚上挂机跑测试第二天发现昨晚根本就没跑起来因为TRACE32连接目标板的时候出了个小问题而人不在现场。测试过程和结果分散在多个工具里想要一份统一的测试报告得手动整理半天。这套流程最大的问题是不可重复、不可审计。你没法保证每次测试用的都是同一套环境配置也没法在代码提交后自动触发一轮全量回归。集成之后的好处是一键化改动代码、提交、自动编译、自动下载、自动执行、自动生成报告全程不需要人介入。1.3 集成后的完整工作流从用户视角看集成之后的工作流大概是这样的开发人员提交代码到版本库CI流水线检测到变更触发VectorCAST回归测试任务。VectorCAST根据工程配置交叉编译被测代码和测试驱动生成目标平台上可执行的文件通常是.elf格式。VectorCAST调用TRACE32的自动化接口启动调试会话。TRACE32执行启动脚本完成目标板初始化、连接调试器加载可执行文件。加载完成后TRACE32复位CPU并启动测试程序运行。测试程序运行完毕结果写入预定位置TRACE32暂停CPU并通知VectorCAST。VectorCAST采集测试结果和覆盖率数据生成HTML或XML格式的测试报告。报告和日志回传到CI服务器失败用例自动关联到对应的代码变更。这套流程跑通之后原来需要人工干预的环节全部自动化了。团队能实时拿到目标机测试结果而且由于TRACE32支持多核调试和目标板群控一些并行测试场景也能覆盖到。2. 搭建集成环境版本、硬件与License集成环境搭得好不好直接决定后面每一步是否顺利。这里的“环境”包含软件版本、调试硬件和许可证三个维度任何一个环节不匹配都可能导致集成失败。2.1 版本选型与适配矩阵第一步就是确认VectorCAST和TRACE32之间的版本兼容关系。VectorCAST从早期的8.x版本开始支持通过Lauterbach TRACE32作为执行目标但不同版本的支持程度差异不小。比如老版本主要支持PowerPC、ARM7/ARM9这类经典内核新版本对ARM Cortex-M/R/A系列、RISC-V的支持就完善得多。我的经验是在选型前先查VectorCAST安装目录下自带的ReleaseNotes或者Lauterbach提供的VectorCAST Integration Guide里面会有一张官方测试过的版本组合表。一般来说VectorCAST 2021以后的版本配合TRACE32 2020以后的版本是一个比较稳的组合。TRACE32软件本身版本迭代很快但Lauterbach对向下的兼容性做得还不错新版本软件通常能兼容旧的调试探针固件只是有些新特性会依赖新硬件。选版本时还要注意你用的IDE和编译器的版本。VectorCAST在集成TRACE32时本质上是在交叉编译环境之上做的一层测试框架所以它必须理解你的编译器。比如ARM编译器用armcc还是armclangGCC的版本是9还是12这些都会影响VectorCAST的编译选项和数据结构解析。如果编译器版本太新而VectorCAST版本太老可能会出现符号解析失败、结构体对齐方式识别错误等问题。2.2 调试探针与目标机连接调试硬件方面Lauterbach的调试器产品线比较丰富常见的几款是PowerDebug系列比较高端的型号支持多核调试、ETM追踪、超高速下载适合复杂SoC平台。µTrace系列内置跟踪存储适合需要实时追踪指令流的场景。Lauterbach Probe兼容第三方JTAG一些简化版的方案走标准JTAG/SWD接口。选型时主要看被测平台的调试接口类型和最高调试时钟频率。比如一个Cortex-M7主频跑在400MHz的目标板调试探针的SWD/JTAG时钟至少得支持几十MHz才能保证下载速度不至于慢到没法用。另外还要注意目标板的参考电压VTref探针必须能适配这个电压否则VREF检测不对连接会失败。连接这块有一个经常被忽略的点TRACE32对目标板的上电时序和复位信号要求比较高。如果目标板用的是双电源轨内核电压和IO电压上电有先后的要求而TRACE32探针在上电瞬间就去尝试连接调试端口可能会导致连接失败。我一般会在启动脚本里加一段延时等目标板完全稳定后再发起连接。2.3 License策略与权限模型VectorCAST的License一般有两种浮动LicenseFloating License和节点锁定LicenseNode-locked License。在集成测试自动化路径里我强烈建议用浮动License因为CI机器往往是一个共享的构建机池每次跑的构建机器不固定。如果用节点锁定LicenseCI任务一旦被调度到没有License的机器上就会失败。TRACE32这边的情况特殊一些它的License是跟调试探针绑定的。也就是说你买了PowerDebug探针里面就带了对应软件的License授权。所以TRACE32的License策略主要是看探针支持多少个核、支持哪些调试特性比如ETM追踪、多核调试这些。在VectorCAST集成TRACE32的时候只要探针本身功能完整就不需要额外再买License。但这里有一个细节VectorCAST调用TRACE32的方式是通过Lauterbach提供的COM接口也叫T32API或者命令行接口不管哪种方式都需要机器上安装完整的TRACE32软件包并且License要能正常识别探针。如果是在虚拟机或者docker容器里跑自动化探针USB驱动必须穿透到容器里这个略麻烦后面排查章节我会单独讲。另一种做法是把TRACE32跑在一台实体Windows机器上CI通过远程调用方式触发这样能绕开USB穿透问题。3. 核心配置与实操步骤环境准备好了接下来就是配置和实操。这一部分我按VectorCAST工程创建、TRACE32脚本编写、执行环境配置、命令行自动化四个层面来拆解每一步都附上我自己验证过的做法。3.1 新建VectorCAST工程并加载TRACE32配置打开VectorCAST之后新建工程时会让你选择“Execution Environment”这里面有两个大类一个是Host Execution也就是主机执行另一个是Target Execution下面是各种嵌入式目标平台选项其中就包括Lauterbach TRACE32。选好TRACE32之后还需要配置几个关键参数Lauterbach安装目录VectorCAST需要知道T32软件装在哪里默认是C:\T32但如果装在其他盘符需要手动指定。调试探针类型比如ARM内核选ARMRISC-V选RISCV有些SoC有专用的配置文件选对才能正常初始化。目标板配置文件TRACE32用.cmm脚本描述不同的目标板配置VectorCAST需要指定启动时加载的cmm脚本路径。调试接口一般选JTAG或者SWD取决于你的目标板硬件。下载文件格式一般选ELF或者AXFVectorCAST交叉编译出来的文件格式要跟这个配置一致。配置界面不复杂但有一个容易被忽略的选项是“Auto Start TRACE32”如果你勾选了它VectorCAST在跑测试的时候会自动拉起TRACE32图形界面。在CI自动化环境里这个选项应该关掉否则界面会卡住CI执行。后面用命令行启动TRACE32时我会加上-s参数让它静默运行。3.2 配置编译器和交叉编译选项VectorCAST要生成目标板上运行的测试程序必须得调用你的交叉编译器。在工程的“Build”配置里需要指定编译器的路径、前缀和关键编译选项。以ARM GCC为例常见配置是Compiler Prefix: arm-none-eabi- Compiler Path: C:/toolchains/arm-gnu-toolchain-12.2/bin Compile Options: -mcpucortex-m7 -mthumb -mfpufpv5-d16 -mfloat-abihard Link Options: -T link.ld -nostartfiles这里有几个关键点-nostartfiles未必是必须的取决于你的启动文件是不是也要一起编进来。如果VectorCAST生成的测试驱动需要替代原有的启动流程可能要去掉默认的启动文件让TRACE32通过仿真或者脚本方式完成CPU初始化。链接脚本.ld文件必须是针对目标板内存布局的。VectorCAST生成的测试程序要被TRACE32下载到目标板RAM里运行所以链接脚本的RAM起始地址、堆栈大小这些必须跟目标板实际匹配否则下载进去一跑就崩。浮点选项必须跟你的硬件一致。A/B硬浮点和软浮点编出来的调用约定不一样如果编译器选项配置错测试程序能编译但跑起来函数传参就出错。另外要注意的是VectorCAST在生成测试驱动时会给被测函数包一层封装。它会重新编译被测源文件同时加上它自己的用例数据结构和驱动逻辑。如果被测文件中引用了编译器内置函数或者特定平台的特性比如__attribute__((interrupt))这些声明必须能被VectorCAST的解析器识别否则会出现“无法解析的符号”之类的错误。3.3 配置TRACE32调试会话与脚本TRACE32的自动化能力核心在于它的Practice脚本语言文件后缀是.cmm。在VectorCAST集成场景下你至少需要两个脚本一个是环境初始化脚本负责配置调试探针、连接目标板另一个是加载并运行测试程序的脚本负责下载可执行文件、设置好运行环境并启动测试。下面是我常用的一个初始化脚本init.cmm以ARM Cortex-M平台为例; 初始化脚本示例 ; 配置调试探针类型为ARM接口为JTAG SYSTEM.RESET SYSTEM.CONFIG.INTERFACE JTAG ; 选择CPU类型这里以Cortex-M7为例 CPU STM32H743 ; 配置调试时钟 SYSTEM.CONFIG.CPU.CLOCK 20MHz ; 连接目标板 SYSTEM.UP ; 等目标板稳定 WAIT 100ms调试器脚本这块的核心逻辑是“先恢复环境再下载执行”。如果你之前跑过一次测试目标板可能停在某个断点或者异常状态如果不做复位而直接下载可能会遇到Flash被锁或者RAM被占用的问题所以先复位再连接是最稳妥的。加载执行的脚本也类似; 加载并运行测试程序 ; 复位CPU RESET ; 加载ELF文件 LOAD.ELF C:/build_output/test_program.elf ; 设置PC指针为入口地址 REGISTER PC program_start ; 启动CPU运行 GO这里面的关键问题是VectorCAST怎么知道测试程序跑完了呢一般有几种做法在工程配置里可以选基于串口输出测试程序在结束时通过UART打印特定关键字TRACE32脚本里监听串口输出并识别。基于内存标志位测试程序结束前在约定地址写一个特殊值TRACE32脚本通过轮询这个地址来判断。基于软件断点测试程序末尾放一条BKPT指令TRACE32执行到断点后自动暂停。这三种方式里内存标志位是我用得最多的因为它最稳定可靠、不依赖串口驱动是否初始化成功。做法是在链接脚本里预留一个4字节的变量区域比如0x2007FFF0测试程序结束时往这个地址写0xA5A5A5A5。TRACE32脚本里循环读取这个地址一旦读到约定值就认为测试结束。3.4 配置VectorCAST运行环境工程编译配置搞定之后还需要在VectorCAST的“Runtime”配置里设置执行相关的参数。这一步的核心选项包括执行后端选择Lauterbach TRACE32。T32脚本路径指定init.cmm和run.cmm这些脚本的位置。环境变量如果测试程序依赖某些外设映射地址这些信息要在这里声明。超时时间VectorCAST默认会等TRACE32的执行结果如果程序在目标板上卡住了这个地方要设一个超时否则CI任务会一直挂着。一般我设2分钟超过就判失败并自动重启目标板。另外还有一个很关键的配置项是“Coverage Collection Mode”。TRACE32集成模式下覆盖率数据有两种收集方式软件插桩VectorCAST在编译时给代码插入覆盖率探针这种方式不依赖TRACE32的硬件追踪功能。硬件追踪TRACE32通过ETM接口实时采集指令执行轨迹然后离线分析覆盖率。这种方式对CPU的ETM引脚和探针的追踪功能有要求。我用的多是软件插桩因为配置简单、结果稳定。硬件追踪覆盖率的好处是不改动代码但ETM缓冲区大小有限跑大型测试程序时可能会溢出导致覆盖率数据不全。对于一般的单元测试和集成测试软件插桩完全够用。3.5 级联启动与自动化回归配置文件全都准备好之后第一次完整的联调建议用VectorCAST的图形界面跑通确认各个环节没有问题然后再把命令行自动化加进来。图形界面跑通的意义在于出问题的时候你能直观地看到TRACE32的执行状态也能看到目标板的PC指针停在哪条指令上排查起来飞快。在图形界面下点击“Execute”按钮VectorCAST会依次执行编译测试程序。创建TRACE32的临时脚本。启动TRACE32。加载初始化脚本。加载并运行测试程序。等待测试结果。第一次跑通常会遇到一堆问题比如目标板连不上、脚本路径不对、链接脚本内存越界等。这些不用慌逐个排查即可。等到能在图形界面里跑通一轮测试后就可以尝试命令行方式了。3.6 命令行集成CI流水线必备CI环境下没法每次都点图形界面所以VectorCAST提供了完整的命令行接口。命令行模式下核心的调用方式是这样# 在工程目录下执行测试 clicast -p my_project.vcm -E environment_name -c -e -t # 参数说明 # -p 指定VectorCAST工程文件 # -E 指定要运行的环境 # -c 编译测试程序 # -e 执行测试 # -t 生成测试报告如果要在CI里跑完整回归一般还会加上-b参数做基线管理以及-R参数输出Result文件。一个典型的CI脚本片段长这样#!/bin/bash # 更新代码 git pull origin main # 清理上次的构建产物 rm -rf build_output # 执行VectorCAST测试 clicast -p mcu_test.vcm -E test_env -c -e -t -R test_results.xml # 解析测试结果 if grep -q FAILED test_results.xml; then echo Tests failed! exit 1 fi # 生成覆盖率报告 clicast -p mcu_test.vcm -E test_env -R coverage_report.xml -f purecov这里要注意的是clicast执行的时候同样会调用TRACE32所以CI机器上必须装好TRACE32软件、插好调试探针并且TRACE32的License能正常识别探针。如果CI机器和调试探针不在同一台机器上就需要用到后面说的远程调用方案。3.7 远程调用与集中管理有些团队的CI集群是分布式的构建机可能不带调试探针这时候有一个实用的做法把TRACE32单独部署在一台Windows机器上通过它提供远程调试服务。VectorCAST和Lauterbach在较新版本里都支持这种方式核心是使用TRACE32的T32API接口做远程控制。T32API是Lauterbach提供的一组C/C动态库接口通过TCP/IP网络就能控制远端的TRACE32实例。VectorCAST在目标配置里如果选了“Remote Lauterbach”模式就可以指定远端机器的IP和端口。远端机器上跑一个TRACE32的监听服务等待VectorCAST发过来的控制指令。这个方案的好处是调试资源可以集中管理多台CI构建机共享一套调试探针和台架成本和维护难度都降低了。缺点是需要额外的网络通信层调试的实时性会有微弱下降但对测试这种非实时场景来说影响可以忽略。4. 常见问题与排查技巧实录集成这套东西的过程中我踩过不少坑有些坑光看官方文档根本摸不到头绪最后是通过TRACE32的调试脚本一点点定位出来的。下面把高频问题整理成一个速查表再挑几个典型的详细说说排查思路。现象可能原因快速解决办法编译器报错找不到头文件交叉编译工具链的sysroot路径没配置在VectorCAST的Build配置里显示指定--sysrootTRACE32连接目标板失败目标板未上电或探针VTref电压不匹配检查目标板供电重新插拔探针核对VTref测试程序能下载但不运行复位向量错误或PC初始值不对检查链接脚本入口地址用TRACE32查看PC寄存器测试执行超时程序在硬件上卡死典型是外设等待超时用TRACE32暂停CPU查看PC指针落在哪个函数覆盖率始终为0覆盖率收集方式选错或探针插桩没生效确认编译时加了插桩选项确认覆盖率模式多次执行结果不一致目标板状态未复位干净残留断点或缓存在脚本里加SYSTEM.RESET清空CPU缓存下载速度极慢JTAG时钟配置过低或者探针连了高负载目标调高调试时钟频率检查是否存在线缆质量问题4.1 每次联调最气人的问题编译器配置和解析不一致VectorCAST本身有源码解析器它会去理解被测代码的语法结构。遇到一些特殊的编译器扩展语法比如TI编译器特有的#pragma、__interwork这样的关键字VectorCAST默认的解析器可能识别不了。我遇到过的一个典型场景是被测代码里用了__attribute__((section(.ccmram)))把变量放在特定RAM分区VectorCAST解析的时候直接把这个属性忽略了导致生成的测试驱动和实际变量地址对不上运行起来数据错乱。解决办法是在VectorCAST的源码解析设置里把不认识的编译器关键字配置成“忽略”或者“当作普通宏”。具体路径是Settings - Compiler Options - Predefined Macros把目标平台的特殊关键字加进去。4.2 TRACE32连接目标板不稳定连接不稳定是个比较烦人的问题尤其是在长时间跑回归测试的时候。测试跑到一半TRACE32突然断连整个CI任务就废了。我总结下来连接不稳定主要有以下原因USB线缆质量不好或者USB Hub供电不足导致探针和PC之间的通信偶发丢包。解决办法是换原装线、插到PC主板直出的USB口不要经过Hub。目标板电源纹波太大导致调试接口的电平不稳定。可以在探针上增加隔离措施或者检查目标板的电源设计确保调试接口附近有足够的去耦电容。调试时钟太高信号完整性问题。JTAG频率不是越高越好如果你发现跑高频时偶发错误往下调一两档频率往往就好了。另外还有一种情况是TRACE32连接时和目标板的“已有调试会话”冲突。如果你同时开了多个T32实例去连同一块目标板后面的连接会失败。在做自动化的时候我习惯在每个cmm脚本的开头先执行SYSTEM.RESET和SYSTEM.UP确保抢占到调试端口的所有权。4.3 测试程序跑飞或卡死的定位方法程序下载到目标板之后跑飞是最让人头疼的问题。因为VectorCAST绘制的测试结果界面是黑盒的你只知道测试超时失败了但不知道程序到底跑到了哪里。这时候千万不要急着改代码先用TRACE32手动把程序加载起来然后让它跑等超时后用TRACE32的暂停功能把CPU停下来直接查看PC寄存器指向的地址。我遇到过的几种典型情况PC指针停在未初始化区域比如RAM的空白区这通常是函数指针被错误地赋值或者Stack指针没配好函数调用返回到了错误位置。PC指针停在一个死循环里查看Call Stack能看出函数调用链往往能定位到是哪个驱动在轮询一个没有置位的中断标志。程序进入了HardFault异常。TRACE32会自动停在异常向量处观察CPU的异常寄存器对于Cortex-M是SCB-CFSR、HFSR能快速定位是总线错误、用法错误还是断言错误。这方面的排查经验是TRACE32不要只当下载工具用它的寄存器窗口、内存窗口、反汇编窗口在调试时价值巨大。VectorCAST集成模式下如果出了莫名其妙的问题先切到TRACE32界面手动复现一遍往往三分钟就能定位。4.4 覆盖率数据缺失和异常覆盖率是VectorCAST最核心的卖点但集成TRACE32后覆盖率数据异常的情况很常见。最常见的问题是跑完之后覆盖率报告显示0%或者某些函数的覆盖率是空的。排查的思路一般是这样先确认编译时是否启用了覆盖率插桩。VectorCAST的覆盖率插桩是通过编译器选项-fprofile-arcs和-ftest-coverage实现的GCC编译器下如果这些选项没被正确传递代码不会插入覆盖率探针自然就没有数据。确认TRACE32的脚本里有没有在测试开始时执行“覆盖率数据清零”操作。VectorCAST会在每个测试用例执行前清一次覆盖率计数如果没清前一个用例的数据会累计到下个用例上结果当然不对。最后注意目标板的RAM空间。覆盖率探针需要一段内存来计数如果这段内存被其他代码覆盖或者越界写坏了覆盖率数据会出现“坏块”。我遇到过目标板的DMA往RAM区域写数据把覆盖率计数区给冲了导致覆盖率结果一团乱。后来通过把覆盖率计数区放到带ECC保护的RAM分区才解决。4.5 CI环境下USB穿透和权限问题最后说一个docker场景下的坑。很多团队喜欢用docker来跑CI。如果在docker容器里跑VectorCAST而TRACE32探针是USB接口的那你必须把宿主机的USB设备穿透到容器里。docker的--device参数可以做到但还需要考虑容器里的用户权限。TRACE32探针驱动在Windows下不存在这个问题Linux下就必须处理udev规则否则容器里的TRACE32没有权限访问USB设备。如果不想折腾USB穿透另一个办法是把“执行TRACE32”这个动作放到宿主机上用docker容器只跑VectorCAST的编译部分然后通过SSH或者网络调用的方式触发宿主机上的TRACE32。这种解耦的方案虽然多了一层通信但稳定性和隔离性都更好。5. 关于这套平台我的几点体会集成这套平台做到后面我越来越觉得工具的集成不是目的让团队能把精力放在测试设计上才是目的。之前我们大量的时间耗在“跑测试”这个动作上编译、下载、记录、统计数据、整理报告。现在这些动作全部自动化了测试工程师把主要时间花在分析测试需求、设计测试用例、评估覆盖率盲区上这才是更有价值的工作。另外想说的是VectorCAST和TRACE32的集成方案虽然官方有文档但真正的难点永远在细节里。每个项目用的编译器不同、目标板不同、外设初始化流程不同这些差异都会导致配置上的微调。建议团队在起步阶段先选一个相对简单的模块做试点把整个流程跑通形成一套团队内部的步骤文档和脚本模板再逐步扩展到其他模块。不要一上来就想全量切换否则排查问题的成本会很高容易把团队劝退。如果你正在做的事情也是嵌入式软件测试相关的并且手头有Lauterbach的调试器强烈建议尝试一下这套方案。刚开始配置可能会觉得繁琐但只要跑通一次后面带来的效率提升是实实在在的。我始终觉得嵌入式软件的可测试性建设和测试自动化建设值得每个做高可靠产品的团队投入资源。