持续集成实践问题（一）提交前功能测试运行太慢

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

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

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

 

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

 

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

 

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

 

1. 是不是有单元测试？

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

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

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

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

 

 

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

 

 

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

 

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

 

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