随着对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的坚定拥护者们，有任何意见，我非常欢迎理性的讨论。