在测试台架这边，去安排固件的升级，还有升级完了以后，要是冒出来了兼容性方面的异常，又该拿什么去验证它，这件事，可不能光是盯着那个升级的按钮，看看它能不能点得下去就完了，一套测试的台架，它往往是连着控制器、各种板卡、仿真机、负责采集数据的模块、通信的设备，还有一整套自动化的脚本的，这固件稍微一动，跟在后头的驱动、模型、输入输出的映射关系、通信时候的时序，还有那些测试的用例，全都有可能被牵连到，所以，在安排升级的时候，要先去把涉及的范围给确认好，再去搞一轮小范围的验证，等确认了它已经稳下来了，然后，才能进到正式的台架里面去。

　　一、testbed固件升级要怎么安排

　　testbed固件的升级，是要照着版本、设备，还有用例会受到什么样的影响，这几点来排的，它不太适合在项目测试正赶到高峰期的时候，临时去处理，特别是那种硬件的在环台架、耐久性测试的台架，还有生产线下线检测的台架，在动手升级以前，是要把万一不行了，怎么往回退的条件，给讲在前头的。

　　1、要先把这次升级都涉及到哪些对象给理出来

　　去把这一次要动的控制器、输入输出的板卡、实时运行的机器、管通信的板卡、电源的模块、那些负载的设备，还有上位机里软件的版本，都给一项一项地列出来，可不要就只是在记录上写一句“台架固件升级”便算了，要具体到设备的型号、当前正跑着的固件版本、打算要升级到的那个目标版本、驱动的版本，还有它是对应着哪一个项目的。

　　2、去把版本之间能不能兼容的关系给查清楚

　　在给固件升级以前，要去翻一翻供应商那边给出来的发布说明，看一看你打算升上去的那个目标版本，它有没有要求，必须得配上特定的驱动、工具的版本，或者是某种格式的项目文件才行，就拿dSPACE的SCALEXIO固件兼容性说明来讲，那里头也提到了，在升完级以后，是要用固件的管理器去检查一下，看看所有的板卡，是不是都好好地、正确地被显示出来了，一旦出了异常，就需要去提供专门的系统报告，还有安装管理的诊断文件。

　　3、把备份和万一要往回退的方案都给准备好

　　在开始升级以前，要把当前的工程文件、各项参数的文件、输入输出的映射关系、板卡的配置、脚本的库、测试的序列，还有软件的安装包，全都给保存下来，那些能被导出来的配置，就要把它给导出来；实在导不出来的，那也要去截个图，或者是把存放的路径给记下来，在往回退的方案里面，要写得明明白白，这玩意儿到底能不能降级、到时候该由谁来动手操作、还有，需要留出多长的一段维护窗口。

　　4、要先在一套不是那么关键的台架上，去验一下

　　要是条件允许的话，最好是先在一台备用的台架上，或者是离线的环境里面，去把级给升了，把最基本的通信、模型的加载、信号的采集、故障的注入，还有那些自动化的脚本，都挨个地跑上一遍，可不要一上来，就把那套正产着、跑着生产测试的台架，直接给拿来当试验品，要不然一旦出了点什么岔子，是会把当前项目整个的节奏，都给连累到的。

　　二、升级完了以后，兼容性出了异常要怎么去验证

　　在升完级以后，兼容性上冒出来的异常，比较常见的几种样子，是设备怎么也识别不到了、通道上的读数开始飘了、模型跑着跑着就超时了、脚本那边开始报错了，还有CAN总线，或者是工业以太网的通信，变得不稳定了，在做验证的时候，可别光看着软件好像是能打开，就放过去了，得按着信号那条链，还有测试那条链，一层一层地去确认才行。

　　1、去验证一下设备，是不是都被认出来了

　　去把固件的管理工具，或者是管设备的那个界面给打开，去检查一下，所有的板卡、通道，还有模块，是不是都好好地在线，它们的型号、序列号、插在哪个槽位上、还有固件的版本，这些东西，都要跟升级的记录，能一丝不差地对得上，哪怕只是少了一块板卡，又或者是板卡插的槽位顺序变了，这些，都有可能会引到后面，通道的映射关系发生错位。

　　2、去验证一下输入输出的映射关系

　　去把原先的那个项目文件给加载起来，然后去检查一下，那些模拟量的、数字量的、脉宽调制的、继电器的、CAN总线的、LIN总线的，还有以太网的，这些个通道，是不是还都能被正确地读出来、写进去，可以拿一组固定的输入值，去挨个地点检一下，就比如，给个电压、给个频率、给个开关量，或者是发一帧总线的报文，去看看实际采回来的值，跟自己心里预期的那个值，它俩是不是一样的。

　　3、去验证一下模型，还有它实时跑起来的表现

　　去跑一个平日里最常用的模型，然后去好好地观察一下，编译的过程、下载进去顺不顺利、启动正不正常、每一步花的时间、CPU的负载，还有那种任务超时的情况，要是在升级以前，这个模型是能稳稳当当地跑起来的，可升完了以后，就开始冒出来超时，或者是丢了步，那就要去检查一下实时的内核、驱动的版本、输入输出任务的周期，还有模型的接口，这些地方了。

　　4、去验证一下那些自动化的脚本

　　去把原来就有的，那些做冒烟测试的、做回归测试的，还有那些最关键的测试序列，都给拿出来，重新再跑上一遍，在跑的时候，重点要去看，脚本里面引用的接口名字、给设备起的别名、通道指向的路径、设好的等待时间，还有最后打出来的日志，这些东西，有没有悄悄地跟着变了，要是发现脚本跑失败了，可别一上来就直接去动手改测试的逻辑，要先去确认一下，是不是底层的那些接口，真的已经变了。

　　三、升级出现的异常要怎么去收口

　　在升级的过程里碰上的异常，是不能只靠着在现场临时拿脑子去记一记，就这么处理过去的，是得形成一套，后面能被拿来复查的记录才行的，要不然的话，等再过上几个礼拜，又碰到类似的问题，你就很难去判断，这到底是固件自己的毛病、是配置上的事、还是说，测试的脚本，在不知道的时候，已经被人给动手改过了。

　　1、要把升级前和升级后的对照记录，给留下来

　　去把升级以前，和升级以后，固件的版本、工具的版本、驱动的版本、项目文件的版本，还有测试跑出来的结果，全都给记下来，最后做出来的那张对比的表，是要能让人一眼就看出来，有哪些设备是升了级的，又有哪些设备，是待在原地没有动的。

　　2、要能把配置上的问题，和兼容性上的问题，给区分开

　　要是把配置重新导入了一遍以后，它就自己恢复了正常，那这多半就是配置在迁移的时候，出了点问题；可要是同一份配置，放在旧的版本底下是好好的，跑在新的版本上就变得不对劲了，那就要把它当成兼容性的问题去处理，把日志给保留下来，然后去联系供应商，让人家来确认一下。

　　3、去把允许放行的条件，给设好

　　在正式放行以前，至少也得是通过了设备的识别、输入输出通道的点检、模型的运行、总线的通信、那些最关键的测试序列，还有报告的生成，这几样检查才行的，要是还存在那种没解决的遗留问题，那就要去把它的影响范围，还有能避开的法子，都给写清楚了，可不能就只丢下一句“暂时还没什么影响”便完了。

　　总结

　　给testbed安排固件升级，是要从列出设备的清单、搞明白版本之间的兼容性、做好配置的备份、拿出往回退的方案，还有先去备用的台架上验一下，这些事情开始入手的，等升完级以后，去验证兼容性上的异常，也是要照着设备的识别、输入输出的映射、实时的模型、通信的链路，还有自动化的脚本，这么一层一层地去检查的，只要把记录给留全了，那么就算是后面再冒出来什么异常，你也能很快地就判断出来，这问题，到底是出在了固件上、驱动上、配置上，还是测试用例它自己身上。