测试设备一旦开始运转，真正让人头疼的往往不是某一次的结果，而是这些结果散落在日志、报表、脚本平台，还有人工记录的各种地方，testbed结果看板怎么搭建，还有看板上冒出来的指标异常该怎么去解释，核心都是要把测试的状态、执行的结果、设备被谁占着、异常到底是什么原因引起的，还有责任最后有没有闭环，这所有的东西，都给放到同一个观察视角里，让项目经理、测试人员，还有做开发的，都能一眼就看得懂当前的风险在哪里。

　　一、testbed结果看板要怎么搭建

　　在动手去搭testbed的结果看板时，先别一上来，就急着去往上头堆一大堆的图表，一个看板，它得能回答三件事：设备现在是不是可用的、测试是不是都已经跑完了、跑出来的那个结果，它到底可不可信，先把这三样信息给打穿了，后面再去做趋势的分析，才会有它的意义。

　　1、要先把数据的来源给确定好

　　进到测试平台，或者是数据平台管数据源的地方，去把自动化测试跑出来的结果、设备当前的状态、任务排队的队列、缺陷的系统，还有版本的信息，都一股脑儿地给接进来，那些字段里头，至少也得把设备的编号、项目的名字、测试的是哪个版本、总的用例有多少、跑过了几条、失败了几条、被阻塞的有几条、执行花了多长的时间，还有谁是负责人，这些都给包进来。

　　2、去把核心要看的几个指标给设好

　　在配置看板的时候，去把通过率、失败率、执行的完成率、设备被用起来的占比、任务在队列里等了多久、失败的用例有多少条、被阻塞的用例又有多少条，这些指标给建立起来，刚开头的时候，不要一下子就放上去太多的指标，先把项目上每天都会去瞅一眼的那些内容，给保留好。

　　3、去照着项目，还有设备的维度来分组

　　这个看板，它得能支持按照项目、版本、设备的编号，还有测试的类型，去一层层地往下筛，就比如说，编号是TB01的设备正忙着跑回归测试，而TB02呢，还在那揪着缺陷做复现，这两套设备跑出来的数据，是不能给搅和到一块儿去瞅的，要不然的话，那个通过率上上下下的变化，你就非常难去解释清楚了。

　　4、去把异常的标记给建起来

　　在告警的规则里头，去设好几个门槛的数值，就比方说，通过率一下子掉到了某个数以下、连着失败的次数实在是太多了、设备离线的时间超过了你给它定好的那个钟点、又或者是任务一直停在“正在运行”的状态，老半天都不动弹，这些情况，一旦被触发了，就得在看板的上面，去显示出红色的状态、这件事该归谁管，还有它最近一次被更新，是在什么时候。

　　二、看板上指标的异常，该怎么去解释

　　testbed看板上的指标不对劲了，可不能只是在上头，简简单单地标一句“测试给跑失败了”，或者是“设备出了毛病”，在去解释它之前，是要先去判断一下，这个异常，它到底是从代码那边来的、是被测试用例给坑了、是环境闹的、是设备自己的事，还是说，只是在往外采集数据的时候，出了点岔子，只有把原因给分得清清楚楚了，后面再去动手处理的时候，才不会一下子就跑偏了。

　　1、通过率往下掉了

　　当通过率突然之间往下掉了，这时候，要先去瞅一眼，是不是在背后，偷偷地切换了测试的版本、分支，或者是把测试的范围给动过了，要是因为新加进来了一批高风险的用例，那通过率看着是下来了，这可不一定就代表着，质量真的在变差；可要是测试的范围压根儿就没变，那就要去追着查，那些跑失败的用例，它们是不是都集中在某一个模块里头。

　　2、失败的用例，猛得多了起来

　　当失败的用例，在数量上很显眼地变多了，那就要照着报错的类型，去把它给分着组来看，通信超时、断言失败了、设备压根儿就没给回应、脚本直接就开始报错，这几种情况，它们代表着的，可是完全不一样的问题，通信超时了，那多半是要去查网络、查总线，还有查设备的状态；只有断言失败了，才更有可能是指向，功能上的逻辑，是真的出了毛病。

　　3、执行的完成率，有点偏低

　　完成率比较低，一个比较常见的原因，是任务还排在后头等着呢、设备一直被别人给霸占着、环境在做初始化的时候就已经败下阵来了，又或者是，脚本它自己，卡死在了那里，这时候，要先去看一眼，那些任务，它们是真的已经被启动了没有，然后再去看看设备的心跳，还有日志更新的时间，可别把那些压根儿就没来得及去跑的用例，直接就给当成是失败的用例，去往外头解释。

　　4、设备的利用率，看着不大正常

　　要是利用率太高了，那这背后藏着的，就是排队堵车的风险，还有大家抢资源的事，可能要变得越来越重了；可要是利用率太低了，那就有可能是，预约的规则定得不大合理、设备出了故障，到现在都还没被修好，又或者是，任务它根本就没有被，好好地给派发下去，利用率这一个指标，是要把它跟预约的记录，搁在一块儿，对照着去读的，要是就单把它一个的百分比，给孤零零地拿出来看，那是很容易，就判断错了的。

　　三、testbed结果的看板，要怎么去持续地维护它

　　等着把testbed结果的看板给搭好了以后，还得要接着去对它做持续的校准，一个看板，它可不是一次性地把配置给做完了，就能扔在那里不去管了，在测试的流程、设备的数量、脚本的结构，还有版本发布的节奏，这些东西发生了变化以后，那些指标统计的口径，也得跟着去同步地更新才行。

　　1、去把指标的口径给固定下来

　　像通过率、失败率、阻塞率，还有完成率，这些个指标，都得要把它到底是拿什么公式算出来的，给讲得明明白白的，就比如说，那些被阻塞住的用例，到底要不要给算进失败的那一拨里头去，把用例重新跑通了以后，新跑出来的结果，是不是要去把原来那个失败的状态给盖掉，像这样的口径，全都要统一掉，要不然的话，同一串数字，搁在不同的团队眼里头，它所代表的意思，是会跟着变的。

　　2、去把异常的说明给留下来

　　每一次，在看板上发现有指标的异常以后，都要跑进异常记录的那一栏里去，把发生的时间、它波及到了多大的范围、初步判断是什么原因引起的、该由谁来管这件事，还有当前处理到哪一步了，都给交代明白，可别只是在开会的那么一会儿功夫里，拿着嘴去说一说便过去了，要不然，等再过上几天，再回过头去瞅那张趋势图的时候，就没人能再去解释得清楚，当时那一阵波动，到底是怎么一回事了。

　　3、去定期地把那些没用的数据给清一清

　　那些已经报废了的设备、早就过了期的版本、调试专用的那些用例，还有用来试跑测试脚本时产生的数据，这些东西，是应该去给它们单独地打上个标记，或者是干脆就从统计的范围里，给拿出去的，要不然的话，沉淀下来的历史趋势，就会被这些脏东西，给硬生生地拽偏了方向，到了项目要复盘的时候，也是很容易，就顺着它们，得出来一个跑偏了的判断。

　　4、得让看板，真的去帮着项目做决定

　　看板这东西，它可不是为了摆在那里，让画面瞅着有多好看，才去搭起来的，它的用处，是得让项目上的人，知道眼下最该优先去处理些什么，在每天站会的时候，是可以就只去瞅那么一眼异常的指标、被堵住动不了的任务，还有那些反反复复老是在失败的高频用例，把大伙儿讨论的焦点，从“到底有没有在跑”，给慢慢地挪到“到底是哪一个地方，在影响着最后的交付”这上面来。

　　总结

　　testbed结果的看板，要怎么去把它给搭起来，还有，当看板上的指标冒出来异常了，又该怎么去解释它，这里面很关键的一点，就是得先把设备、任务、版本、用例，还有缺陷，这些个数据，全给串到一块儿去，然后再拿少数几个，最核心的指标，去把整个项目当前的状态，给呈现在大家眼前，等到指标出现了异常以后，也要去照着版本的变化、测试的范围、设备的状态、脚本的报错，还有那些真实的缺陷，这么一项一项地，去给它做出解释，一个看板，它之所以能一直持续地在那儿发挥作用，靠的，是清清楚楚的数据口径、异常发生以后留下来的那些记录，还有定期去做的维护，而绝不是只靠着，一个劲地往上面去堆图表的数量。