在静态分析、动态测试、单元测试，还有回归测试扎堆执行的时候，有一类问题是挺常见的，就是testbed的执行队列要从哪里去看，还有，一旦队列给堵住了，又该先从哪里下手去查，这testbed一旦接上了批量跑的任务，或者是接进了流水线，那队列的状态，就会直接影响到测试的效率，还有报告能不能按时出得来，拿LDRA Testbed这类工具来打个比方，它可以把测试的执行、覆盖率的结果，还有需求的追踪，结合到一块儿去，生成审计要用的材料，而动态测试呢，还有可能牵扯到，在宿主机和真实目标机这两种环境底下，去执行，再把覆盖到的数据给收回来。

　　一、testbed执行队列要怎么查看

　　要去看testbed的执行队列，得从任务排队的那个入口、任务当前正在跑的状态，还有最后报告有没有被顺顺当当地输出来，这么三个地方，合在一块儿去看，可不能光去瞅一眼界面上，是不是显示着“正在运行中”，还得再去确认一下，任务它是不是真的已经被启动起来了、是不是卡在了那里，等着分配资源、又或者，其实是已经跑过了，只是那份报告，还迟迟没有生出来。

　　1、先去看一眼任务列表里的状态

　　进到管测试执行，或者是管批处理的那个界面里去，去瞅瞅当前的任务，是正排着队等着呢、是正在那跑着呢、是已经跑完了、是跑失败了，还是被人给取消掉了，排在队列里的，就说明它还在那等着，分给它执行用的资源；正在运行的，是说它已经被执行的那套东西给接管过去了；已经完成的，那也只是在说，流程它自己走完了，还得再去看一眼，报告里面的内容，到底是不是全乎的，要是瞧见有好些个任务，在队列那个状态里，待了老长的时间，那就要把眼睛，给放到执行器、许可证，还有环境的占用，这些事情上去了。

　　2、去把具体某一条任务的详情给点开

　　去点开那一条单独的任务，去瞅瞅它是几点几分被提交上来的、是谁提交的、跑的是哪一套用例、要对准的目标环境是哪一个、编译时候用的是个什么配置、日志会打在哪个路径底下，还有输出结果，会被搁到哪一个目录里头，有不少队列上的毛病，你光看表面，好像是“压根儿就没跑”，可实际上呢，是前头的编译就已经败下阵来了、脚本里头的参数给写岔了、又或者是目标机器，压根儿就没连上，这任务啊，它就没能真的进到测试的那一步里头去。

　　3、去检查一下报告，到底生没生成出来

　　等到执行的那一步，显示已经走完了以后，要去看一眼，覆盖率的报告、测试结果的那份报告，还有日志，这几样东西，是不是都一块儿给生出来了，LDRA这一套工具链，它本身就特别地看重，要把测试的结果、覆盖率，还有需求的追踪，这好几样东西的产出，给关联到一起去，所以，在排查队列的时候，也得去确认一下，这一整条结果串起来的链子，它到底是不是完完整整的。

　　二、队列被堵住了，要先查些什么

　　当testbed的队列被堵住了的时候，可先别一上来，就火急火燎地去把任务给删了，然后重跑，得照着资源、许可证、环境、脚本，还有数据，这么几条线索，去一条一条地排着查，先要把那个堵住的点给揪出来，然后才能去决定，是要去释放点资源出来、把服务给重启一下，还是去把配置给改对了。

　　1、要先去检查一下执行用的那些资源

　　去瞅一眼，那些负责执行的机器、代理的服务、跑任务的执行器，还有目标板，这些东西，是不是都还好好地待在线上，要是那个执行器都离线了，那后头的任务，就会一直那么干排着队，在嵌入式的项目里头，还得去瞅瞅仿真器、调试器、串口、网口，还有目标板的电源，这些是不是都好好的，当宿主机和目标板之间的那条线断开了的时候，动态的测试，是很容易就会被卡在那里的。

　　2、去检查一下许可证，是不是都被占满了

　　测试的这些工具，它一般来说，是会受到许可证有多少个席位的限制的，要是那些席位，都已经被别的用户，或者是别的任务给占得满满当当了，那新提交上去的任务，就只能老老实实地，排在后头等着，可以去找管事的，让人家去许可证的管理器里头，去确认一下，还有没有能用的空位、那些模块的权限是不是都开了、还有没有被借走的状态，可别光在客户端这边，看着软件好像还能打开，要知道，执行的模块，还有出报告的模块，它们也是有可能是，各占了各的授权的。

　　3、去检查一下，排在前头的任务，是不是还没完事

　　有些队列，它是非得照着排好的顺序，一个一个地去执行的，要是前头的那个任务，它自己被什么东西给绊住了，那跟在后头的那些，就全都会在那等着，要先去找出来，排在队伍最前头的，那个一直显示着“正在运行”的任务，然后去看看它的日志，是不是还在不停地往里头刷着新东西，要是那日志，老半天都一动不动了，那就有可能是，脚本陷进死循环里头了、测试的用例正卡在那等着往里输入东西、目标机器那边没反应了，又或者是，结果要往外写的那个路径，根本就写不进去。

　　4、去检查一下，那个工程，它到底还能不能编得过去

　　像LDRA Testbed这类的工具，它通常是要求，那些等着被分析的代码，怎么着也得能形成一个，可以被处理的、完整的程序，或者哪怕是部分的、能编过去的程序也行，因为头文件、宏定义，还有编译的选项，这几样东西要是缺了，那可是会连累到后头的分析的，在队列被堵住了的时候，就得先去确认一下，这个工程，在它原来那一套构建的环境里头，是不是还能正常地被编译出来，然后，再去查testbed里头，那些包含路径、宏定义，还有工具链的配置，是不是都还好好地对头。

　　三、队列堵住的问题，要怎么避免它反反复复地出现

　　等到队列好不容易被恢复过来了以后，还得去把闹出这次问题的原因，给好好地记下来，要不然的话，今天就靠着重启这么一下子，把它给对付过去了，可等明天，再换上一批新的用例，它就还是会在那里，接着给你卡住。

　　1、去建一份巡检队列的记录出来

　　每一次遇到队列被堵住，都得去记下来，被卡住的任务编号是多少、是谁提交上来的、跑的是哪一套用例集、当时用的是哪一台执行机、许可证那时候是个什么状态、目标板是不是还在线、日志尾巴上那几行，都写了些什么，还有最后，是拿什么法子去处理的，把这些都给攒下来以后，要是后面，又是那一台执行机，在那反反复复地出问题，那就能判断出来，这是它自己环境的毛病，也就不至于，会错怪到用例的头上去。

　　2、去把同时往队列里塞的任务数量，给管一管

　　可别把整个回归测试的那些任务，一股脑儿地，全都给同时提交到队列里头去，是可以照着模块来分一分、把优先级给标一标，再按它跑一遍要花掉多少时间，去分成一批一批的，再来提交，先把那些冒烟的测试，还有高风险的用例给跑通了，然后再去动那一整套完整的回归，这么做，就算是中间有哪一批任务，它不小心给卡住了，也不至于，把能用的执行资源，全给死死地霸占住。

　　3、去把执行环境的版本，都给固定下来

　　工具是哪一个版本的、编译器又是哪一版的、脚本的版本、目标板里头烧的固件，还有那些配置文件，这些东西，全都得放在一起去，统一地管起来，队列会被堵住，有好多时候，就是因为环境被人临时给动了那么一下，尤其是当脚本的路径、结果要往外放的目录它给的权限、还有连目标机器的那些个参数，被人给改过了以后，表面上看着，任务是还在那老老实实地排着队呢，可实际上，它已经根本就没法子，正常地被启动起来了。

　　总结

　　testbed的执行队列，到底该从哪儿去查看它，还有，当队列被堵住了以后，又该先抓着什么东西去查，实际动手去处理的这个先后顺序，就是先去看一眼任务当前是个什么状态，再去把那单条任务自己的日志，还有报告出来的东西，给打开来瞧瞧；等到发现堵住了，就要优先去查，执行用的资源、许可证、排在前头的任务、那个工程到底还能不能编得过去，还有目标机器那一头，环境是不是正常的，全都处理利索了以后，还要记得去把队列的记录给留好、把同时跑的任务数量给管住、再把执行环境的那一套版本，给它死死地固定下来，这么一来，testbed的队列，就不用只靠着临时去重启那么一下子，来勉勉强强地撑着了，到了后面，那些测试的报告，还有用来证明覆盖率的证据，再想往回追溯的时候，也会变得容易得多。