您的位置:首页 > 其它

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

2009-09-04 21:34 375 查看
一个多月前,收到一封来信,咨询一个持续集成的问题。内容是这样的:

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

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



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



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



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



1. 是不是有单元测试?

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

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

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

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





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





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



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



只要理解思想,并保证实施不变味,如何做好持续集成并不是一个问题。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: