一个多月前，收到一封来信，咨询一个持续集成的问题。内容是这样的：

　　“我们目前的项目，用Selenium Grid跑一遍完整的测试，用10台服务器分布式跑，已经需要超过1个小时，本地根本无法跑过。这样的话，让开发人员在本地run完所有的test再提交，已经不可能了。你们是否碰到过类似的情况？是如何解决的？”

　　很多人可能都在团队中实践了敏捷方法或精益方法，尽管有些团队会感到一些收效，但是达到满意效果的可能并不占多数。抛开公司文化因素等软性因素以外，从技术层面上讲，对某一实践的认识可能程度也会有很大的影响。

　　我们的目的是快速地高质量的交付软件价值。如果“本地测试时间”已经成为生产环节中的瓶颈（也就是出现了浪费现象），就要解决它。

　　从理论上说，“在本地上运行所有的测试以后再提交”从出发点来看，根本没有问题，尤其是在项目初期。然而，代码库是会一天一天长大的，对于周期比较长的项目来说，就需要重新考虑这一理论实践背后的思想啦。

　　Selenium测试算是一种功能测试，这种测试会占用很多的机器资源。所以，可以问自己一些问题，来找到答案。

　　1. 是不是有单元测试？

　　(1) 如果有，单元测试覆盖率是否达到了合理范围？

　　(a) 如果达到了，那么完全可以让这些功能测试跑在持续集成的环境中。

　　(b) 如果没达到，应该加强单元测试，直到达到合理覆盖率为止。

　　(2) 如果没有，可以选择重要的功能测试集在本地跑，同时补上单元测试。

　　单元测试在Thoughtworks的团队中是不可缺少的代码。如果没有单元测试，大家可能都不知道怎么写代码。

　　2. 为什么功能测试跑得慢？是否可以再优化一下？如果优化所需时间太长的话，是否可以增加到20台机器？

　　机器成本比人的成本少得多。一台8core/16GB的刀片服务器才一万多元RMB，那就是8台机器。应用到上面所说的功能测试上，提高测试速度至少30%以上。多么可观的数字啊。

　　只要理解思想，并保证实施不变味，如何做好持续集成并不是一个问题。

　　（以上言论仅代表作者的个人观点，不代表51Testing观点）