首页 > OMD > TEST > > 正文

JMeter与LoadRunner的比较

发布人:zhoulujun@live.cn    点击:

JMeter和LoadRunner都可以很好的完成Critical Feature中列出的任务,而LR在Non-Critical Feature方面表现更出色。不过,JMeter在我希望的更灵活的功能方面大获全胜。

本来打算写一篇JMeter和LoadRunner的简单比较的文章,Google了一下,发现类似的文章已经有不少了,中文的英文的都有。大致阅读了几篇,发现其中一篇文章的总结和比较还是比较中肯的,因此直接把这篇文章的Link贴在这里,供大家参考(请注意,这篇文章是2006年的文章,有些内容有点过时了)。

文章标题:Shootout: Load Runner vs The Grinder vs Apache JMeter 
http://blackanvil.blogspot.com/2006/06/shootout-load-runner-vs-grinder-vs.html

随着对JMeter使用的深入,我越来越倾向于在自己的工作中使用JMeter工具,并且也不遗余力的向我认识的测试工程师推荐这个工具,但很多工程师在初步使用过这个工具后,会向我抱怨JMeter有太多不能做的事情,但在我看来,JMeter确实有不能做的事情,不过,对于Web应用的测试,JMeter是足够强大了。很多人会把JMeter和自己正在使用的LoadRunner进行比较,然后说“还是LoadRunner好用”——关于这一点,我觉得首先要明确“好用”的定义。接下来,我以自己的工作为例,说明一下JMeter是如何适应我的工作内容的。

我测试的主要项目都是基于Web的应用,从性能测试的角度来说,我希望性能测试工具具有这样的一些特点:
Critical Features:
1,支持HTTP/HTTPS协议,能够发送HTTP/HTTPS request;
2,支持用户场景(借用了LR中的词汇),能够以某种比例在不同的业务上分布用户数量;
3,支持事务;
4,支持参数化和关联(还是借用LR中的词汇);
5,能够获得和汇总请求响应时间等数据,能够提供响应时间汇总、事务/请求处理成功率等数据报表;

Non-Critical Features:
1,能够以漂亮的图表展示出结果数据;
2,能够提供漂亮的用户界面(GUI);
3,能够提供良好的录制功能和调试环境;

另外,从我所测试的产品,和我个人的角度来说,我还希望工具具有以下功能:
1,能够灵活的扩展,例如,我的应用的后端(bakcend)和前端的通讯使用的是RPC方式,则我希望工具能够通过我已有的API直接对后端产生负载,进行负载测试;
2,可以使用命令行方式,采用批处理模式运行(不需要GUI),运行后的结果能够通过Email等发送给我,或是直接integration到一个可发布的web页面上;
3,收集得到的数据能够很容易的进行再处理(例如,以XML格式存储raw data);
4,工具本身具有很好的可信度,可以通过查看代码等方式,了解当意外发生时是工具本身的问题或是应用的问题。

大体上,JMeter和LoadRunner都可以很好的完成Critical Feature中列出的任务,而LR在Non-Critical Feature方面表现更出色。不过,JMeter在我希望的更灵活的功能方面大获全胜。

JMeter的另一个最大的优势,自然是在cost方面,LR的价格是有目共睹的,而JMeter,接近0的获得成本对于资金不那么宽裕的公司来说,实在是难得。

我得承认,在对JMeter和LoadRunner进行比较的时候,我很明显的偏向了JMeter:)在本文中,我不打算以一个独立第三方的面目出现,你可以把本文的观点看作是对JMeter的推介或是认可,目的只是为了消除一些人认为“JMeter是玩具”的观点,实际上,JMeter现在确实是我的性能测试中的主要工具,而LoadRunner已经不再出现在我的性能测试工具列表中了。

希望这篇文章不会开罪LoadRunner的坚定拥护者们,有任何意见,我非常欢迎理性的讨论。