在测试项目里面，去设置testbed这种设备的预约，还有当预约的时间撞了车，发生了冲突以后要怎么去协调，这件事说到底，其实就是在管一种挺稀缺的资源，不少团队里，像台架、仿真的环境、硬件的板卡、传感器，还有总线这些设备，数量都是很有限的，要是光靠着在群里面发消息，临时去约个时间，就很容易闹出两个人抢同一台设备、测试用的版本对不上、问题刚复现到一半就被人给打断了，这一类的情况，想让预约这件事真正落了地，关键就是要把设备的状态、能用的时间段、该由谁来负责，还有冲突了该怎么处理，这些规矩都给提前定得明明白白的。

　　一、testbed设备预约要怎么设置

　　在做testbed设备预约设置的时候，要先把设备这些资源都给建得清清楚楚的，然后再让项目里的人，照着定好的规矩去提交预约，可不要只是建一个笼笼统统的、就叫“测试台架”的东西，要不然到了后面，就很难搞清楚，到底占用的，是哪一套硬件了。

　　1、要先去建一份设备资源的清单

　　在用来管预约的平台，或者是管项目的系统里面，进到管资源的那块儿，去把新的资源给加上，把testbed的名字、设备的编号、它是归哪个项目管的、硬件的版本、软件的版本、什么时候能用、还有谁对它负责，这些信息，全都给录进去，要是手里有好几套差不多的台架，那就得用编号去把它们给区分开，就比如TB01、TB02、TB03这样的，省得到了要预约的时候，手一滑给选错了。

　　2、去把能预约的时间段给划出来

　　进到设备资源的详细页里面，找到管可用时间，或者是预约日历的地方，去把工作日、留着做维护的时段，还有压根儿就不能约的时段，都给它设好，比如，每天晚上那个钟点，都需要去跑自动的回归测试，那就要把这一段时间给锁起来；设备在校准、升级、还有送去维修的这些日子里，也得提前就给它标成是不能用的状态。

　　3、把预约要不要审批的规矩给定下来

　　一般在测试环境比较吃紧的时候，是会更推荐去把审批这一关给打开的，可以在预约设置的那一栏里，定好普通的预约，就交给管这台设备的人去批一下；要是碰上那种跨了项目来占用的，又或者是连着占用的时间，超过了大家事先说好的那个时长，那就要由项目经理来点头确认了，这么做，就能防止某一个人，把设备给长期地占着，结果把别人要干的活，全给耽误了。

　　4、去把预约要填的信息给写好

　　在提交预约的时候，要把项目的名字、这次测试是想干什么、用的是哪个版本、打算从什么时候开始、到什么时候结束、联系人是谁，还有，是不是非得自己一个人独占这台设备，这些都给填清楚了，要是事情还牵扯到要给硬件刷写程序、要把环境给重置一下，或者是用到了什么特殊的工装，那也得在备注里头给写明白了，这样也方便前后两个要用设备的人，去做交接。

　　二、预约发生冲突了以后要怎么去协调

　　当testbed的预约，真的发生了冲突以后，可不要光去盯着，是谁第一个在群里发的消息，一种会更合理的法子，是先去看看那些活儿的轻重缓急、交付的日子是卡在哪一天、这台设备跟任务它到底匹不匹配，还有，有没有别的什么法子，能绕开这台设备。

　　1、要先把撞车的原因给找出来

　　预约会撞到一起，一般跑不出这么几种情况：有两个人，约了完全一样的那个时间段；前头的那个测试，跑超时了，到现在还没把设备给让出来；设备临时出了故障，趴窝了；再就是，项目上突然插进来一个，特别着急的活，在开始动手协调以前，要先把到底是什么原因起的冲突，给当面锣对面鼓地说清楚，不然的话，场面就很容易变成，就是在那儿单纯地抢东西了。

　　2、照着活儿的重要程度，重新排一下队

　　可以照着客户那边等着要交付、版本要赶着往外发布、某个缺陷必须得马上复现出来、系统要做回归验证、再到平日的那些调试，这么个先后的次序，去判断到底谁的事情更火烧眉毛一些，就比如，有那么一个问题，它要是解决不掉，就会影响到当天把测试的版本给交上去，或者是客户那边的验收，那它就可以被排到前面，先去用这台设备；而那种普普通通的调试任务呢，就可以把它给挪到一个空着的时间段里去。

　　3、去把那些可以同时做的事情，给拆分开

　　有些测试，它其实并不是从头到尾，都得把testbed给霸占着的，是可以先把环境的准备、脚本的检查、数据的分析，还有日志的整理，这些零碎的活，先给放到本地的电脑上，或者是仿真的环境里去做完，只把那些真正离不开这台设备的步骤，给塞进预约的那个时间窗口里头，这么做，就能让设备干等着的时间，变少很多。

　　4、要让那个能拍板的人，来把调整以后的结果给确认下来

　　等冲突协调完，有了个结果以后，得由管着这台设备的人，或者是项目经理，到预约的系统里面，去把占用的时段给改过来，然后再去通知到跟这件事有关的人，可别只是在聊天的窗口里，拿嘴说一句时间改了，就不管了，要不然的话，在系统的日历上，那边还明晃晃地显示着冲突，下一轮要用设备的人，看到了还是会被带偏的。

　　三、预约的记录要怎么留下来

　　testbed的预约记录，是要能被留下来，撑得住往后的追溯的，尤其是当碰上了测试跑失败了、设备表现得不对劲、或者是版本跟预想的不一样，这些情况的时候，得能顺着记录查出来，是谁、在什么时间、拿着什么版本，在这台设备上都干了些什么。

　　1、要把预约和实际使用的记录，都给留下来

　　每一次的预约，都得把是谁申请的、是谁批准的、占了多长的时间、测了些什么东西，还有最后到底是几点几分，才把设备给腾出来的，这些都给保留好，要是实际用它的时间，跟当初约好的时间对不上，那就要赶紧去更新一下，这么做的目的，是免得后面在统计设备到底被用了多久的时候，拿到的数字是不准的。

　　2、去把环境发生了哪些变更，也给记下来

　　在用的过程当中，要是动手刷了新的固件、替换了上面的板卡、调整了总线的配置，或者是把测试的脚本给改动过了，这些都是要写进交接的记录里，交代得明明白白的，这样，等下一位要接手用的人，一上来先去看一眼，现在这套环境是个什么状态，就能省下好多，再从头去排查一遍的力气。

　　3、去把异常的，还有恢复的动作，也给记下来

　　设备出了毛病、通信怎么都连不上了、电源好像有点问题、日志文件缺了一块、测试跑到一半就断了，这些事情，统统都要写进异常的那份记录里面去，等它恢复了以后，也要去讲明白，自己到底是用了什么法子去处理的，就比如是，把设备给重启了一下、把版本给退回到了前一个、把配置给重置了，又或者是，换了一根新的线束。

　　总结

　　testbed设备的预约，到底要怎么去把它给设置好，还有，当预约的时间起了冲突以后，又要怎么去处理它，这里面很关键的一点，就是要去把设备的资源、能用的时段、审批的那些规矩，还有用完之后留下的记录，这几样东西都给管起来，预约的设置，要细致到能把设备的编号，还有它当前版本的状态都给对上；冲突的协调，则是要按照任务本身的优先级，还有是不是有别的替代方案，去灵活地处理，等调整出了结果，还要记得把它给写回到预约的系统里面去，把这些事情全都给做到位了以后，testbed就不光光是一台，被人临时拿来用一下的设备了，而是会变成，在整个项目的测试过程里头，那种可以被提前规划好、事后也都能追溯得起来的，大家一起共享的资源。