JMeter与LoadRunner的比较
本来打算写一篇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的坚定拥护者们，有任何意见，我非常欢迎理性的讨论。
文章标题：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的坚定拥护者们，有任何意见，我非常欢迎理性的讨论。
