关于组建Test Lab的几点想法

上午有位同事向我“推销”他的test lab构想，出发点是想提高公司设备的有效利用率。那么就需要征求测试部门的同事们贡献出手上空闲的测试机资源，以组建test lab。想法真的非常不错，很多大公司如微软等，都搭建了非常高效的test lab，虽然其具体实现细节个人无从知晓，但其效果确实从微软工程师所著的书中得到了说明。
目前所在公司的状况是，每个Tester手上都有多台测试机器，少则一两台，多则四五台，似乎目前也运行的很好，那么首先分析一下这种状况和组建Test lab后各自的优缺点：

	Per Tester分布式资源分配	Test Lab集中式资源分配
优点	² 较强的自主性：多个测试设备资源在一个人的掌控范围之内，自主性非常强	² 能有效克服Per Tester分布式资源分配的所述缺点
缺点	² 设备资源的重复购买：哪些部门有哪些设备，很多时候这些信息在部门之间是不共享的。在信息共享不及时的情况下，有时候可能会存在设备资源的重复购买。 ² 时间成本的无形浪费：某个时候在部门之间寻找所需要的设备资源的时候，需要做到多人间的沟通和交流，以确定当前设备资源的状态，而这些都需要时间。 ² 较大的资产管理难度：当存在资源调配的时候，及时的跟踪资源的变更，需要耗费必要的人力和物力，无形中加大部门经理和IT管理员的工作量。 ² 闲置率高：所有的测试设备在一个时间点上都能用到吗？这种概率好像比较小，但是也有另一种声音存在：我的测试机器还是不够用，出于某一种测试环境的需要，机器越多越好。 ² 工作环境舒适性较差：试想当你周围放着一圈的测试机器时，风扇的嘈杂声，大量的辐射充斥在你的周围。	² 专门的物理存放空间：将设备资源集中一个地方进行存放，需要一个单独的物理空间区域，在有限的工作空间资源下，可行性受到严重制约。 ² 底层架构的支撑：为了能使Tester高效、快捷、有效的使用lab，势必需要搭建底层的管理架构，如设备资源使用的check in/check out，实现便捷的Remote功能，所有的这些需要一定人力物力进行技术支持。 ² 物理主机上资源的管理：每个Tester，每个team都有自身所独有的文件资源，有些资源是非常庞大的，如果将这些资源统一存放在服务器上集中管理，显然是不现实的，因为这会导致服务器成本的增加，且使用起来，都需要从服务器拷贝资源，及其不方便。所以对本地的资源文件的高效管理也需要经过精心设计和管控

通过上述内容的表述，似乎各有利弊，撇开技术层面的细节，单纯分析一下组建Test Lab所要关注的几点问题：
1. ROI（投资回报利率）
让同为测试工程的同事们和各部门的老板乐意地贡献出自己拥有的测试机器来组建公共的Test Lab，这需要有效的数据和证明来说服大家。至少要让大家看到这件事情是值得做的，很自然就想到了ROI
ROI = (Test Lab组建后所带来的收益 – 前期组建和后期维护所需要的总成本) / (现有模式状态下的收益 – 现有状态下的维护成本)
如果上述ROI>1，那么这件事情至少出发点是可以去做的。其实上述内容只是代表了一个公式，真正分子上的数据收集需要划分更多更细的Item，或许参考同行的数据会来的更加有效和实际。

2. 有效的执行力
东西是好的，但要有人去用才行。人，有一定的惰性，所以想让测试工程师们从现有习惯的模式中走出来，不但要让大家看到其推行项目的优点、亮点，更需要上层领导的有效命令。本人曾经领导过几个项目，虽然做出来的东西很好，也很有用，但是经过一段时间，大家仿佛又回到了以前的思维和行为模式中了（有时候我发现自己也同样如此）。习惯其实是靠培养的，所以如果领导能不定时的进行一些命令干预，在一定的时间过后，大家或许就习惯了这样东西的存在，也体会到了其中的优越之处，那么后期遇到相应的问题需要解决，就自然而然会使用它了。
如果缺少有效的执行力，再好的项目也会失败，那么对于项目的领导者和推行者自身势必会有一定的打击。

3. 风险的规避
任何项目的开展都会存在风险，罗列出所有的风险，进行有效的规避预防是至关重要的。

似乎困难重重，或许你会说，如果什么事情在做之前都考虑那么多，那项目还做它干嘛！不，其实很多时候事情是一步一步做起来的，上述所讨论更多的是从大方向需要进行把控的几点内容。那到底该怎样开展这个项目呢？或许就像我那位同事所说的一样：
第一步，搭建一个微型Test Lab以满足自己的需要
第二步，说服某一部门Leader或Manager进行Test Lab扩容并推广到该部门使用
第三步，在实践的过程中学习和总结经验
最终，实现全公司的推广和运行！
路漫漫，其修远兮，汝&吾将上下而求索！