LoadRunner和JMeter应用于资产管理系统性能测试的对比分析

李金萌

关键词：性能测试；性能测试工具；LoadRunner；JMeter

1 资产管理系统的介绍

随着现在信息化时代的快速发展，对计算机软件的要求也越来越高，特别是对于资产管理系统来说，如何提高资产管理系统的准确性、便捷性以及后期维护起来的困难性。对于资产系统来说，需要符合用户的需求、实际工作中的需要、对企业资产信息维护是迫切的，该系统就是基于这样的需求开发出来的资产管理系统，对于用户来说，减少手动分析数据的事情，对于管理人员来说，将其交给资产管理系统，可以提高工作质量和效率[1]。

2 LoadRunner 和JMeter 基于资产管理系统的不同

2.1 脚本添加

脚本的添加是性能测试最基本的内容，后面所有的操作基本上都是基于脚本的操作，然而LoadRunner和JMeter对于脚本添加来说，区别还是很大的。

对于LoadRunner来说，脚本的添加其实是录制脚本并回放，需要使用LoadRunner—Virtual User Gen?erator录制脚本并进行回放。脚本内容基本上是进行录制的，录制成功后对部分脚本内容进行代码的添加和修改，然而对于JMeter来说，是脚本添加和运行。对于JMeter的来说需要注意的是：JMeter中一个脚本即是一个测试计划，也是一个管理单元。然而在测试计划中，测试计划只有一個；测试计划中至少要有一个线程组；测试计划中至少要有一个取样器；测试计划中至少要有一个监听器。脚本中还需添加HTTPCookie 管理器、Sampler-HTTP 请求、Web 服务器、HTTP请求等元件。

针对脚本添加来说，LoadRunner使用性会比JMe?ter更加方便，对于初学者来说，LoadRunner更加容易接受，但对公司来说，使用各有千秋。

2.2 思考时间

思考时间是对于性能测试来说很关键的，也有另外一种说法叫休眠时间，从业务的角度来说，思考时间其实就是用户在进行某些操作时和下一个操作之间需要的间隔。对于交互式应用来说，用户在使用资产管理系统的时候，请求不是一直不断地点击发出的，而是用户在发出一个请求后，需要等待一段时间，才进行下一个请求发出[2]。因此，从性能测试实现的角度来说，要真实地模拟用户操作，就必须在测试脚本中让各个操作之间等待一段时间。

思考时间的设置，LoadRunner和JMeter都是需要手动添加的，针对于LoadRunner来说，就是需要在进行操作之前放置一个思考时间的函数——ThinkTime，具体思考时间可以根据实际需求进行填写，这样可以在两个操作的中间加一个缓冲时间，可以让下一个操作页面充分的加载。比如，当前操作因为网速等原因没有正常的显示，这个时候就可以使用到lr_think_time（）函数，括号里面写上具体的思考时间，例如：3秒。在回放的时候，如果想看到具体思考时间的回放结果，需要在Runtime Settings 中选择ThinkTime中选择：Replay think time as recorded，这样在回放脚本时，就可以查看日志中思考时间回放结果。如图1所示。

对于在JMeter脚本中，思考时间是用定时器来模拟实现的。主要有固定定时器和高斯随机定时器，两个都是可以选择的，其中，如果需要让线程按指定的时间停顿，这个时候就需要选择固定定时器（ConstantTimer） 。但如果需要让线程在请求前按随机时间停顿，那么可以使用高斯随机定时器（Gaussian RandomTimer） ，在设置过程中选择，偏差：设置的偏差值，是一个浮动范围，单位毫秒。固定延迟偏移：固定延迟时间[3]。比如：偏差设置1000毫秒，固定延迟偏移设置3000毫秒，如图2所示。

对于“事务控制器”来说，定时器相当于LoadRun?ner中的Think Time。对于思考时间来说，固定思考时间是一样的，但是在JMeter中的高斯随机定时器和固定思考时间不同，高斯随机定时器是让线程在请求前按随机时间停顿，在思考时间方面，JMeter 比Load?Runner更加灵活。

2.3 检查点

对于检查点来说，如果是针对添加成功等操作，需要设置检查点来进行验证。脚本回放成功，只是代表请求成功，并不能代表请求的业务成功。要判断业务是否成功，就需要在脚本中加入检查点[4]。

对于LoadRunner来说，检查点的原理是在回放脚本时搜索特定的文本、字符串或者服务器返回的文字、返回的code键值等设置检查点，从而验证请求业务的正确性。而对于JMeter来说，检查点主要是通过断言组件来实现的。

对于LoadRunner来说，检查点的设置主要是使用函数--web_reg_find函数。在设置检查点时，需要注意的是必须将web_reg_find函数放到该操作前面，否则该检查点的结果就会出错。例如：服务器返回的值是 OK，在 脚 本 中 添 加 web_reg_find“（ Text=OK”，LAST） ;，运行成功后可以再回放结果中查看检查点设置是否成功。

断言组件通过获取服务器响应数据，然后根据断言规则去匹配这些响应数据；匹配到是正常现象，此时看不到任何提醒，如果匹配不到，即出现了异常情况，此时JMeter就会断定这个请求失败，那么在查看结果树中看到的请求名称就是红色字体。断言组件有多个，检查点可以运用响应断言元件来实现[5]。

断言添加成功后，进行断言结果的查看，需在测试计划中添加监听器-断言结果。对于请求，正常通过时在断言结果里面会打印一行请求的名称；如没有通过，在断言结果里有请求的名称，以及出现失败的原因。如果不同类型的断言，则显示的断言结果不同。

对于检查点来说，LoadRunner和JMeter是非常重要的元件，LoadRunner添加后只需运行后查看检查点即可，而对于JMeter，是添加监听器-断言结果，才可看到断言的结果。

2.4 参数化

性能测试工具通常会模拟多个用户对系统进行操作。比如现在对于新增资产登录，资产名称进行参数化。对于LoadRunner来说，对于资产名称进行参数，在回放的时候，可以对参数化里面的数据进行数据顺序选择，每次都进行更新[6]。在回放的结果中也可以看到参数的具体取值情况，如图3所示。

然而对于JMeter来说，创建CSV数据文件设置，文件的位置以及变量名称，文件是.dat文件，需要提前创建好的。设置好CSV数据文件设置，需要到对应的地方将值设置为${value}，这样整个过程才算是可以的。在查看结果树中，查看参数取值如图4所示。

对于LoadRunner和JMeter来说，参数化是同样重要，因为模拟用户登录，或者进行多条信息进行添加，这个时候使用参数化来说会更加便捷。

2.5 事务与集合点

事务（Transaction） ：为了衡量服务器的性能，需要定义事务。比如：在登录时，可以对登录操作设置成一个事务[7]。

在LoadRunner 中设置事务需要有开始事务和结束事务，而且事务的运行时间会在结果中显示[8]。在LoadRunner中，添加事务操作可以在录制过程中进行添加，也可以在录制结束后选择插入步骤进行添加。而且，LoadRunner 对于事务的数量是没有限制的。在JMeter中，事务是通过定时器-Synchronizing Timer实现的。

集合点是达到特定的用户数后再“一起”进行某个操作，比如“一起”进行登录，“一起”进行新增资产维修等[9]，其中，“一起”就是集合点设置的内涵所在。

对于LoadRunner 来说，集合点使用的函数是lr_rendezvous“（ login”），后面在分析器中需要对集合点策略进行设置，而在JMeter中，增加同步定时器元件就可以。

集合点的使用可以进行压力测试，这对于Load?Runner 和JMeter 来说都是很重要的，在使用方面，LoadRunner需要設置集合点策略，在LoadRunner中集合点策略的设置是在控制器中，比较容易遗漏。

3 小结

对于资产管理系统来说，性能测试可以使用不同的性能测试工具，只是在具体的使用方面不一样。对于LoadRunner 来说是三个组件，分别是Virtual UserGenerator、Controller、Analysis[10]，在使用方面来说，JMeter更方便些，不需要使用那么多的组件。对于脚本添加来说，初学者使用LoadRunner会更加方面，因为脚本是通过录制生成的；对于思考时间来说，JMeter除了固定式定时器来说，还有高斯定时器；对于检查点来说，LoadRunner 添加后只需要在运行后查看即可，然而对于JMeter来说，是需要进行添加监听器-断言结果，才可以看到断言的结果；对于参数化来说，两个工具基本上差不多；对于事务来说，LoadRunner需要添加开始事务和结束事务，而JMeter只需要添加定时器-Synchronizing Timer 即可；对于集合点来说，LoadRunner设置集合点时，需在控制器中设置集合点策略。

两个性能测试工具都有自己的特点，没有说哪个工具一定比另外一个工具强，公司在选择工具使用方面，不仅考虑使用方面，还要考虑费用方面的问题。但是不管使用哪个性能测试工具，都是为了提高测试的速度和质量。