测试 请教,如何缩短整体测试的运行时间?

ery · 2012年04月02日 · 最后由 nouse 回复于 2012年04月17日 · 4847 次阅读

目前,我们的项目所有测试跑完需要4 分钟左右。

共有 575 个 test 47 个集成测试 354 个功能测试 174 个单元测试

硬件配置 CPU 双核 2.4G 内存 8G

技术框架 UnitTest Spork FactoryGirl Fixtures Sqlite Ruby 1.9.3-p0 Rails 3.2.1

因为有 Spork,所以平时跑单个测试的时候,不觉得慢, 但是跑整体测试的时候,4 分钟时间,足以打乱我的编码节奏。 而且,我最近在重构,经常要全跑一遍。

所以想问问各位,有什么办法可以提高全体测试的运行时间

买高性能 CPU,Ivy bridge 马上就要出了

好话题,楼主如想获得更多,应该把你的想法说说,介绍更多背景。

你用的是 UnitTest,测试里有没有和外部数据库关联的步骤。比如导入数据库之类的。这方面有 load

#2 楼 @xds2000 我的每个测试的在开始的时候,都会用 FactoryGirl 创建 10 个左右的基础数据。我猜测这个地方目前是 test 速度的瓶颈。

#1 楼 @kgen 我相信升级硬件,效果肯定能立竿见影,但是烧钱啊,而且,团队中所有人都有这个问题,大家一起升级,太伤钱了。

#4 楼 @ery 对于新手来说,不测试是提高测试运行时间的不二选择。

测试的时候出去走走,抽根烟你会觉得时间过得很快

跑测试 内存 不需要多高,关键是 cpu

#4 楼 @ery 如果是台机,升级 CPU 不过千元,高频 i5 双核即可,测试不能并行。如果是笔记本,一台 i7 的 MBP 不到程序员一个月的工资,如果这真的消耗了大家很多时间,那么花钱升级绝对是省钱的行为。

@ery 看你的技术框架同时有 factory_girl 和 fixtures,factory_girl 可以代替 fixtures。不清楚是笔误还是你公用这两个。

大家都认为楼主机子太差,要不@ery 把主机配置放出来看看。

#7 楼 @vkill 觉得跑测试硬盘速度才是瓶颈,如果可以上 ssd,速度会有大幅度提升

测试之所以慢,抛去硬件原因,剩下的就是编写的方式了。 由于 require 的东西多,自然就慢。一些测试可以写成 isolate 的,速度会有大大提升,不过需要大量 stub。

rake -t 看看是不是 test:prepare 慢

方案 http://codecampo.com/topics/154#reply-1663

#9 楼 @xds2000 不是笔误,我们的确同时使用 factory_girl 和 fixtures。CPU 和内存的配置上面有,请问,你觉得我还需要说明那些主机配置? #8 楼 @kgen 我的机器是笔记本 ThinkPad SL410K 是台低端笔记本。我们是创业团队,资金匮乏,所以我想从软件方面优化。

#10 楼 @bluecoda +1 我也猜测 硬盘速度是瓶颈。我目前没发现 require 是负担。我依然把注意力放在 IO 操作上。

#11 楼 @Rei 谢谢你的方案,我尝试过啦,这个方法可以提高几秒钟。

@ery Oops,不用了,没细看。见谅。

既然大家都用,为什么不搞一个测试服务器 服务器的性能和 pc 性能相差很大,万把块钱的货,就不错了,而且跑了你就不用管了,本机应该 做什么还是做什么 而且你们好多人,环境是不一样的,最好的还是有一个统一的服务器,不然部署后再测试/部署会有很多麻烦

#13 楼 @ery 事实上,IO 的问题就是 require 的问题,每个测试都 require test_helper.rb 或者 require spec_helper.rb 就会变得很慢,因为这个文件里也有很多 require,尤其 require environment 特别慢。 如果仅仅 require 相关的那个文件,那就会快很多。当然就会少很多 helper 以及 rails 的支援。但是此时的测试更为独立,没有太多依赖的库。 建议试试看 require_relative 吧,不过这种方式测试代码都要重写。

#16 楼 @azhao 测试服务器?这个如何做 TDD?

@bluecoda require 同一个文件,不会重复加载的。 No matter how many times you require the same feature in your program, only the first time is significant. Ruby will not re-read a file a second time, this is the first fundamental difference from how load works.

#20 楼 @xds2000 诚然,但是你是否确定跑测试的时候,每个 test 文件都 require 一次呢?每次是否花时间呢? 另外,真的不推荐完全用 factory girl 代替 fixtures,会慢很多很多,这两者应处于共存的关系

@bluecoda 测试服务器是用来专门跑测试的,和 TDD 没有关系,不是按着 TDD 走就可以不测试了

专门的测试人员拿你程序来测,bug 仍然一堆堆,网站什么的,或还在开发阶段你只用本机没有问题 一但上线后,开发人员的本机环境不可能跟生产环境相同,很可能本机装了什么程序而生产机没有,部署后生产环境崩溃,影响很大。如果涉及到金额交易就很危险了

所以一般需要一个测试服务器,和生产环境同步,削弱一些这样的风险,同时也能承担楼主这种跑大量耗时的任务。像我以前做银行的时候,这方面管得就特别严。总之测试服务器是肯定得有的,没有,以后会很乱。

TDD 本来就只要跑你修改的部分影响的用例,只用影响比较大的重构才需要跑一次全部的用例。这个 guard 很好用。如果你意思是怎么只跑你修改部分影响的用例,那就是 guard 之类的工具了。

#20 楼 @xds2000 #21 楼 @bluecoda 想到个问题,Ruby 版本是多少

#23 楼 @Rei Ruby 1.9.3-p0 Rails 3.2.1

#22 楼 @azhao 我觉得在某些情况下,的确需要测试服务器,但是就目前而言,我希望从软件技术上进行改造,来提高测试速度。

#22 楼 @azhao 这就是为什么会有 ci 这个东西的原因,也是为什么会有 travis-ci,janky 之类的东西诞生。 但是,@ery 的需求是,想让他重构时跑测试的速度快一点,这一点是 dev 环境的东西,走 ci 环节并不会有太大帮助。 另外,如果想跑得稍微快一点,可以试试看 https://gist.github.com/1688857 这个 patch,但是有时候可能不太稳定,最好不要用到 production

autotest-rails 只跑受修改影响的测试 也许会快一些吧

上 SSD 了吗?

需要 登录 后方可回复, 如果你还没有账号请 注册新账号