持续集成实践问题(一)提交前功能测试运行太慢
来源:互联网 发布:超图软件中标 编辑:程序博客网 时间:2024/05/02 01:15
一个多月前,收到一封来信,咨询一个持续集成的问题。内容是这样的:
“我们目前的项目,用Selenium Grid跑一遍完整的测试,用10台服务器分布式跑,已经需要超过1个小时,本地根本无法跑过。这样的话,让开发人员在本地run完所有的test再提交,已经不可能了。你们是否碰到过类似的情况?是如何解决的?”
很多人可能都在团队中实践了敏捷方法或精益方法,尽管有些团队会感到一些收效,但是达到满意效果的可能并不占多数。抛开公司文化因素等软性因素以外,从技术层面上讲,对某一实践的认识可能程度也会有很大的影响。
我们的目的是快速地高质量的交付软件价值。如果“本地测试时间”已经成为生产环节中的瓶颈(也就是出现了浪费现象),就要解决它。
从理论上说,“在本地上运行所有的测试以后再提交”从出发点来看,根本没有问题,尤其是在项目初期。然而,代码库是会一天一天长大的,对于周期比较长的项目来说,就需要重新考虑这一理论实践背后的思想啦。
Selenium测试算是一种功能测试,这种测试会占用很多的机器资源。所以,可以问自己一些问题,来找到答案。
1. 是不是有单元测试?
(1) 如果有,单元测试覆盖率是否达到了合理范围?
(a) 如果达到了,那么完全可以让这些功能测试跑在持续集成的环境中。
(b) 如果没达到,应该加强单元测试,直到达到合理覆盖率为止。
(2) 如果没有,可以选择重要的功能测试集在本地跑,同时补上单元测试。
单元测试在Thoughtworks的团队中是不可缺少的代码。如果没有单元测试,大家可能都不知道怎么写代码。
2. 为什么功能测试跑得慢?是否可以再优化一下?如果优化所需时间太长的话,是否可以增加到20台机器?
机器成本比人的成本少得多。一台8core/16GB的刀片服务器才一万多元RMB,那就是8台机器。应用到上面所说的功能测试上,提高测试速度至少30%以上。多么可观的数字啊。
只要理解思想,并保证实施不变味,如何做好持续集成并不是一个问题。
- 持续集成实践问题(一)提交前功能测试运行太慢
- 持续集成-Docker 与 DaoCloud 的实践(一)
- 持续集成(一)
- SoapUI实践:自动化测试、压力测试、持续集成
- 持续集成CI(一)
- 持续集成: 实践指南
- 持续集成最佳实践
- 持续集成实践
- PHP持续集成实践
- 解决MyEclipse运行太慢
- 解决MyEclipse运行太慢
- 解决MyEclipse运行太慢
- 电脑运行太慢怎么办
- 解决MyEclipse运行太慢
- 版本控制、缺陷管理和持续集成结合实践报告(一)
- 持续集成C++ 实践记(一) 实现定时更新、编译、发送报告
- 持续集成学习笔记-入门篇(4)持续集成自动化(一):所谓“关键”问题
- TOMCAT启动太慢问题
- Android入门第三篇之RelativeLayout、FrameLayout
- curl模拟登陆
- c#图片随机验证码的实现
- 简单有效统计web 页pv、uv的方法
- JavaScript 库作用及对比介绍
- 持续集成实践问题(一)提交前功能测试运行太慢
- UCHOME中配置邮件
- 怎样去理解去耦电容
- Java实例教程(2)Hello World应用程序
- 090904项目进展:强制终止线程
- JavaScript密码强度判断
- HDU 1106 排序
- 为DataList添加分页
- 人工智能的应用