理解LoadRunner，基于此工具进行后端性能测试的详细过程（上）

1、LoadRunner 的基本原理

后端性能测试工具通过虚拟用户脚本生成器生成基于协议的虚拟用户脚本，然后根据性能测试场景设计的要求，通过压力控制器控制协调各个压力产生器以并发的方式执行虚拟用户脚本，并且在测试执行过程中，通过系统监控器手机各种性能指标以及系统资源占用率，最后通过测试结果分析器展示结果数据。

在 LoadRunner 中，Virtual UserGenerator 对应的是虚拟用户脚本生成器，Controller 对应的是压力控制器和系统监控器，Load Generator 对应的就是压力产生器，Analysis 对应的是测试结果分析器。

以下我们把 LoadRunner 每个模块类比手工操作放大理解工作过程：

1）首先，我们需要一批测试机器，每台测试机器雇佣一个测试人员；
2）然后，一个调度员来统一控制，比如 “1-10 号测试人员开始执行登录操作，10-20 号测试人员 5 分钟之后执行搜索操作”，同时调度员还会要求每个测试人员记录操作花费的时间；
3）测试完成后，调度员会要求性能工程师分析测试中记录的数据。
4）通过类比：

测试调度员以及完成数据记录的部分就是 Controller；

大量的测试机器以及操作这些机器的人就是 Load Generator；

操作这些机器的人的行为就是 Virtual User Generator 产生的虚拟用户脚本；

对测试数据的分析就是 Analysis 模块；

2、LoadRunner 的主要模块
1）Virtual User Generator
用于生成模拟用户行为的测试脚本，生成的手段主要是基于协议的录制，也就是由性能测试脚本开发人员在通过 GUI 执行业务操作的同时，录制客户端和服务器之间的通信协议，并最终转化为代码化的 LoadRunner 的虚拟用户脚本。
这样转化得到的虚拟脚本还需要经历数据参数化（Parameterization）、关联建立（Correlation），以及运行时设置（Run Time Settings）等操作，然后才能用于性能测试场景中。

2）LoadRunner Controller
Controller 相当于性能测试执行的控制管理中心，负责控制 Load Generator 产生测试负载，以执行预先设定好的性能测试场景；同时，还负责收集各类监控数据。
在实际执行性能测试时，Controller 是和性能工程师打交道最多的模块，性能工程师会在 Controller 的 UI 界面上完成性能测试场景的设计、运行时的实时监控、测试负载的开始与结束等操作。

3）LoadRunner Analysis
Analysis 是 LoadRUnner 中一个清大的分析插件。不仅能图形化展示测试过程中收集的数据，还能对国歌指标做关联分析，找出他们的因果关系。它最根本的目的就是：分析出系统可能的性能瓶颈点以及潜在的性能问题。

3、如何基于 LoadRunner 性能测试？

从宏观角度讲，可以分为五个阶段：

性能需求收集及负载计划制定
录制并增强虚拟用户脚本
创建并定义性能测试场景
执行性能测试场景
分析测试报告

我觉得在性能测试中获取这些测试需求和测试结果分析与性能问题定位是比较难得两个点。而类似于性能测试脚本开发、场景设计等偏向于机械性地重复工作。

这 5 个阶段，按照先后顺序及各个模块作用排序如下：

4、性能需求收集及负载计划制定

其实无论什么类型测试，第一步都要根据测试目的明确测试具体需求。常需要包括以下内容：

系统整体的并发用户数比如，高峰时段会有 10 万用户同时在线；

并发用户业务操作的分布情况比如，20%的用户做登录操作，30%用户做订单操作，其他50%用户做搜索；

单一业务操作的用户行为模式比如，两个操作之间的典型停留时间，完成统一业务的不同操作路径等；

并发用户高峰期的时间分布规律比如，早上8点有大量用户登录，晚上 6 点后用户主键退出；

达到最高峰负载的时间长度比如，并发用户从0到10万花费的总时间。等等~~

前面说获取测试需求是比较难做的，因为绝大多数情况下没人会明确告诉你具体的性能需求。好比功能测试，如果需求不明确可以求助产品经理。

而性能测试产品通常无法准确告诉各个业务所占的百分比，也无法说出准确的用户行为模型。往往只能获取一些定性描述，然后自己去计算或根据过往经验得到具体定量需求。

测试目的不同，采用方法也不同，如何获取明确性能需求？这里提供测试需求的思考方式：

在性能测试指标中提到的体检例子，比如产品经理对体检的性能要求是“每天支持完成 8000 个体检”，这个需求看似具体，但还可以细化在很多方面。

首先，要明确这里的“每天”是否指的是 24 小时这取决于产品本身的属性。比如，产品是为单一时区的用户提供服务，还是要面向全球所有时区的用户。那么，根据体检中心的属性，可以确定“每天”一定是指 8 小时的工作时间。因为，体检中心是在一个确定的时区，并且不会 24 小时营业。

**然后，你明确了这个 8 小时后，那么原始需求是不是可以转化为“每小时支持完成 1000 个体检”？**若照这个套路设计后续的性能测试，会发现即使测试顺利完成，且各项性能指标都达标，可一旦上线后，系统还是很有可能被压垮。因为实际情况是，验血往往需要空腹，所以上午往往是体检中心的高峰时段，体检者会在上午集中涌入体检中心。也就是说，这 8000 个体检并不是平均分布在 8 小时内完成的，而是有明显的高峰时段。

最后，你可以采用 80/20 原则对高峰时段的用户负载进行建模比如 80% 的体检（6400 个）是发生在上午 20% 的时间（96 分钟）里。为了使模型更接近真实的情况，还应该分析历史数据，然后对该模型做进一步的修正。

另外，在得到了负载模型后，往往还会在此基础上加入一定的负载冗余，比如在峰值的基础上再额外放大 20%，以增强系统上线后稳定运行的信心。

完成了性能测试需求分析后，就已经明确了要开发哪些性能测试脚本。接着就要看开发性能测试脚本的步骤，以及相关的技术细节。

文章来源：网络 版权归原作者所有
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系小编，我们将立即处理