为大型企业财务应用性能提速：深入浅出LoadRunner和JMeter性能测试工具

近年来，随着企业财务数字化转型的工作不断深化，企业采取建设财务一体化平台来覆盖财务域全业务流程，以及财务信息化系统大集中建设的技术趋势日渐明晰。

在此趋势影响下，财务数字化平台软件也从传统单一的专业财务系统，向具备处理“端到端”业务、更大数据量和更智能化的方向演进。因此，随着财务数字化平台的持续推广应用，一方面财务软件系统自身也变得更加复杂，另一方面过程中产生和积累的业务数据量也急剧增长。这些因素的不断叠加和变化，会对软件的性能带来持续的质变和量变影响。

与此同时，大型企业尤其是大型央企集团，几乎都设立了信息化专业公司，对企业信息化系统的交互、性能、安全等方面都提出了较高的专业化要求。其中，软件系统的性能，作为客户重点关注的指标，一般都会在系统上线运行前，通过专业的系统性能场景测试和优化，满足响应的性能指标要求后，才会允许发布上线。

工欲善其事，必先利其器。本篇文章将结合久其财务共享产品在大型企业的典型应用场景，对比介绍一下业界常用的两款老牌性能测试工具：LoadRunner和JMeter。

性能测试  

软件性能测试，是指通过模拟测试来验证软件是否满足既定的性能指标要求，同时发现系统中存在的性能瓶颈并进行优化。在软件性能测试过程中，通常采取交替进行负荷和强迫测试等方式，通过并发用户数、响应时间和吞吐量等主要指标，来考察软件性能的承载能力。对于一般用户而言，响应时间是评估和感知软件性能的重要指标。

基于软件性能测试的特殊性，采用人工模拟大规模的操作不现实，也相对困难。因此，一般都需要借助专业性能测试工具，通过工具模拟真实用户的行为，自动化实现大规模并发操作。

性能测试的主要过程简要来说，是通过执行预设好的场景化脚本，在一定时段内向应用系统发送大量的并发请求，模拟产生预设的用户并发操作负载，并对各项性能指标收集、记录和分析，最终形成相应的性能测试报告。

LoadRunner和JMeter是两款常用的老牌软件性能测试工具，前者是商用软件，后者则是开源软件。

LoadRunner是HP(Mercury)公司出品的一款测试工具，可适用于各种体系架构的性能测试，预测系统行为并评估系统性能。

JMeter是Apache组织基于Java开发的压力测试工具，用于对软件做压力测试，是一款开源、小巧、免安装的性能测试工具。

通常来说，性能测试工具需要具备以下三方面主要能力：

1. 脚本开发：指性能测试脚本的录制和编排，一般包括录制脚本、关联、参数化、检查点和集合点；

2. 场景设计：将开发好的性能测试脚本，按照业务场景进行配置和执行，向服务器产生负载；

3. 测试报表：在执行性能测试后，对监控数据收集分析计算后，生成测试结果图表。

本文着重从这三个方面来展开，结合久其云报账的业务场景实践，为小伙伴们细细分析。

一、脚本开发    

1.录制脚本

以久其财务共享产品的云报账业务性能测试为例，报账业务操作场景复杂，业务流程流转较长，随之而来的接口交互量大，大多数接口请求体复杂，直接以手工方式编写配置脚本困难，因此常以录制的方式生成脚本。

LoadRunner和JMeter均可支持录制脚本，常用的录制方式如下表所示：

LoadRunner：浏览器录制方式是其原生方式，但常用的LoadRunner11版本仅支持低版本IE浏览器，最新12版本虽支持谷歌Chrome浏览器，但对高版本浏览器的兼容性较差，因此通常选用代理录制方式，代理录制是通过启动代理服务器监听客户端与服务器间的请求信息与数据，生成脚本；

JMeter：支持使用badboy工具录制并导出.jmx文件，但badboy工具不是免费工具不可作为商业使用，且其对软件的兼容性要求较高，不推荐使用，因此也常使用代理方式录制脚本。

2.关联

所谓关联，是将服务器提供动态变化的值存放在变量参数中，当需要使用该变量时，自动从服务器响应的信息中获取该值，并在之后的接口交互的使用过程中自动替换。

例如久其云报账服务每次登录系统后，都会响应返回token值，响应的token值要在后续请求中作为身份认证的令牌发送到服务端，如果发送的token值不正确，则无法正常进行后续的操作。

再例如新建单据后生成的单据ID，即每次创建单据ID值都不同，但在后续保存、提交单据中都需要使用单据ID，如果不对单据ID做关联，后续请求中服务端会判断其ID不正确从而不能正确响应，导致脚本运行不正确。

关联的主要实现步骤包括：

在关联方式上，LoadRunner和JMeter略有不同。

LoadRunner：关联方式是以左右边界值来获取动态数据，支持事前和事后两种方式:

JMeter：关联方式主要是事后关联，可通过Json提取器、正则表达提取器或边界提取器等后置处理器，按照规则提取需要关联的动态值。相比于LoadRunner可以自动替换脚本中的动态值，JMeter需要以手工编辑.jmx文件方式，来进行动态数据替换。

3.参数化

参数化，是指对录制脚本中的常量进行参数化处理，包括参数名和参数取值。

录制脚本过程，所有录入和提交的数据会生成到脚本中，并以常量的方式记录，在每次回放或运行脚本时，都会将该常量数据提交到服务器。

但在实际系统运行时，有一些数据不适合作为常量，例如在模拟并发登录场景时，录制脚本中的登录用户名和密码，如果使用常量则会引发冲突，通常需要根据一份模拟用户清单来动态改变。此时，参数名是用户名、密码，参数取值则是模拟用户清单数据。

LoadRunner：通过参数列表创建参数，对常量做批量的参数化设置，并在脚本中替换参数；

JMeter：通过在线程组中添加配置元件“CSV数据文件设置”，导入参数化的数据，并定义参数名，再替换脚本中的参数。

4.检查点

通常判断脚本是否执行成功是根据服务器返回的状态来确定的，如果服务器返回的HTTP状态为200 OK ，那么LoadRunner和JMeter就认为脚本正确运行了，并且是运行通过的。

但这并不表示系统运行正常，例如登录云报账服务时，登录成功、登录失败（如密码错误）返回的HTTP状态都是200 OK。如果是登录失败，后续的脚本继续运行也无法正确响应请求了，其结果会影响测试结果分析。

因此，需要增加检查点，协助验证请求是否是“成功”的响应返回。

LoadRunner：使用函数进行，在需要检查响应结果的请求脚本前，增加web_reg_find函数设置检查的文本，

JMeter：专有的断言-响应断言，在需要检查响应结果的请求脚本中，增加响应断言并设置断言存在的文本。

5.集合点

集合点是用于同步用户操作，实现在同一时刻执行同一事务或请求的绝对并发机制。

集合点的实现方式是在一定时间范围，将一定数量的虚拟用户阻挡在一个操作行为前等待，当达到虚拟用户量条件或等待超时时，释放全部等待的虚拟用户，从而实现一定数量的虚拟用户并发执行下一步事务或请求的目的。

例如，当我们需要关注单据保存或提交操作，在一定数量用户绝对并发的效率时，可在单据保存事务前设置集合点。在压测时，虚拟用户数达到指定并发数时释放，实现绝对并发。

LoadRunner：在需要并发的事务或请求前，添加Rendezvous函数，在场景执行时设置具体并发的虚拟用户数和等待时间。

JMeter：在需要并发的HTTP请求中，添加定时器-同步定时器，设置模拟用户组数量和超时时间。

性能测试中，场景是用来模拟大量用户操作的技术手段，性能脚本是场景设置的数据来源，通过配置和执行场景向服务器产生高负载。场景的设计和执行是整个性能测试活动的核心，只有合理的设计测试场景才能获得有价值的测试数据，为接下来的确认性能瓶颈、系统调优打下基础。

一般通过配置延时策略、运行时长、加压策略、并发用户量以及终止方式等策略，来进行压测场景设计，规划一次负载的上升和下降，实现单一场景下的高负载压力测试或稳定性测试。

在实际场景计划模式下，通过灵活增加策略来实现逐步增压的负载测试，可以观察不同负载下系统的事务响应时间、数据吞吐量等性能指标，以发现系统可能存在的性能瓶颈。

举几个场景设计的例子：

1.场景设置

1）LoadRunner

利用专用的软件应用Controller帮助我们设计场景、运行场景和监控收集数据。支持手动场景设计和面向目标的场景设计两种方式。

手动场景设计：即自定义模式的场景设计，可手动灵活设置各项指标；

面向目标场景设计：预先设定一个测试目标，如虚拟用户数量、事务响应时间等，根据这个目标自动构建测试场景。例如，期望用户5秒钟内登录到云报账系统，即可将目标最长事务响应时间指定为5秒，并查看可以处理的实际用户数。

相比于面向目标场景，手工场景在实际工作中应用更加广泛；

2）JMeter

JMeter的场景设计依赖于线程组的配置，也支持手动场景设计和面向目标的场景设计两种方式。

手动场景设计：可通过预设的普通线程组以及插件扩展的线程组可基本实现手动场景设计。

面向目标的场景设计：需要通过JMeter的插件管理（Plugins Manage），装载相应的插件进行扩展支持。

常用插件如jpgc - Standard Set插件，可对线程组进行扩展：

综合而言，LoadRunner的场景设计工具更专业，通过Controller场景设置就可以配置不同的性能测试需求场景，而JMeter则需通过安装插件实现，不如前者方便。

2.负载设计

在并发量很大的需求场景下，如上万并发量，受测试单机CPU和内存的限制，单机很难满足并发负载要求，为了提供更大的负载能力，需要使用分布式机制。

分布式机制是将压力机部署分布在多个测试机上，多台测试机同时产生负载，实现分布式执行压力测试的工作机制。

LoadRunner：在控制机上Controller的负载生成器（Load Generators）功能中添加负载机的ip，在压力机上安装并启动LoadRunner Agent，在场景设计时可以设置场景在哪一个压力机上执行，也可设置压力机上运行的用户数。

JMeter：通过修改控制机上的jmeter.properties配置文件实现，在remote_hosts中增加负载机的ip。

相对LoadRunner可以分配负载用户量，JMeter的分布式负载无法分配线程数，不如前者使用灵活，设置方式上LoadRunner也更加便捷。

报表是性能测试工具中至关重要的一环节，在执行性能测试后，对监控数据收集、分析、计算后生成测试结果图表，作为分析系统性能的重要依据。

LoadRunner：结果分析器十分强大，通过Analysis展示分析概要和各项指标的详细结果，如吞吐量、事务响应时间等，都可以在各页签下通过清晰的图表展示出来。

报告摘要：

吞吐量

事务响应时间

JMeter：最常用的结果分析报表是预设的聚合报告，包括事务响应时间、异常率和吞吐量等指标分析结果。

如想达到能和LoadRunner相媲美的丰富图表效果，仍需要通过第三方插件扩展来实现。常用插件如上文提到的jpgc - Standard Set插件，提供了结果分析的监听器：

监听动态TPS：jp@gc - Transactions per Second（分析吞吐量）

事务响应时间：jp@gc - Response Times Over Time

小结  

以上就是从脚本开发，场景设计和测试报表 三个方面，对LoadRunner和JMeter两款性能测试工具的基本对比和分析。

这两款工具都可以满足日常工作需要，都有各自的特点，小结如下：

针对两款工具的学习路线，建议先从LoadRunner入手，了解性能测试的概念和步骤，之后再深入学习JMeter，会更容易上手。

小贴士：LoadRunner安装后会附带HP的测试系统WebTours，结合LoadRunner的官方学习文档可高效的学习LoadRunner工具和性能测试步骤。

此外，从信创大环境来看，国产性能测试工具也在奋力追赶，像kylinPET和kylinTOP是最有能力替代国外性能测试工具的佼佼者。