LoadRunner是一款由 Micro Focus 公司开发的商业性能测试工具，旨在帮助用户评估计算机系统、应用程序或其他系统组件在特定条件下的性能表现。LoadRunner的主要功能包括负载模拟、性能监控、分析和报告等。许多互联网公司都选择使用LoadRunner来进行产品的性能测试工作，因为它支持广泛的协议和平台，并提供了全面的性能测试解决方案。

其核心特点包括：

负载模拟： LoadRunner能够模拟成千上万个同时访问系统的虚拟用户，以模拟真实的负载情况。
支持多种协议： LoadRunner支持各种常见的网络协议和技术，包括HTTP、HTTPS、Web Services、JDBC、LDAP、SMTP等，因此适用于不同类型的应用程序。
性能监控： LoadRunner可以实时监控系统的性能指标，如响应时间、吞吐量、资源利用率等，以便及时发现问题并进行调整。
脚本录制与回放： LoadRunner提供了脚本录制功能，可以录制用户操作并将其转换为性能测试脚本，然后进行回放以模拟用户行为。
灵活性和可定制性： LoadRunner提供了丰富的脚本编辑和定制选项，用户可以根据需要对测试进行灵活地配置和调整。
强大的分析和报告： LoadRunner提供了强大的分析工具和报告功能，可以帮助用户深入了解性能测试结果，并提供可视化的报告以便于分享和决策。

总的来说，LoadRunner是一款功能强大、灵活性高的性能测试工具，被广泛认可为业界的权威性能测试解决方案之一。

LoadRunner的安装&介绍

注意：LoadRunner只能在windows操作系统上运行，MAC操作系统不支持，如果你使用MAC操作系统，需要在MAC操作系统上安装一个虚拟机，再装上windows操作系统之后安装loadrunner，比较费事

一、下载安装包

提前下载安装文件：

二、安装loadrunner

双击HP_LoadRunner_12.02_Community_Edition_T7177-15059.exe，弹出安装界面。

一路安装，继续勾选图中三项并安装：

整个安装过程比较慢，耐心等待。

安装完成后，界面出现三个图标，如图：

如果遇到VUG（Virtual User Generator，虚拟用户生成器）无法录制脚本的问题，有几种常见的解决方法：

完全退出浏览器：在录制脚本之前，确保将浏览器完全退出。有时候浏览器的进程可能仍然在后台运行，这可能导致录制不到脚本的问题。
使用Fiddler + VUG：可以借助 Fiddler（网络调试工具）结合 VUG 来录制脚本。通过在 Fiddler 中捕获网络流量，并将其转发到 VUG 中进行处理，可以解决一些无法直接录制的问题。这种方法通常比较有效。
使用VUG自带的Firefox浏览器：LoadRunner（包括其中的 VUG）提供了一个特殊版本的 Firefox 浏览器，该浏览器已经配置好以确保能够与 VUG 协同工作。你可以尝试使用此浏览器来录制脚本，以解决录制问题。

为什么选择LoadRunner？

选择LoadRunner作为性能测试工具有以下几个主要原因：

强大的录制功能：LoadRunner提供了强大的录制功能，能够捕获用户与应用程序之间的交互，并将其转换为可执行的测试脚本。这使得测试人员能够轻松地模拟用户行为，从而进行性能测试。
模拟各种场景：LoadRunner支持模拟各种复杂的场景，包括多种协议、不同的用户行为模式、各种负载条件等。这使得测试人员能够更加真实地模拟实际生产环境中的情况，从而全面评估系统的性能表现。
详细的测试报告：LoadRunner生成的测试报告非常详细，包含了各种性能指标、图表和分析结果。这些报告能够帮助测试人员全面了解系统的性能表现，发现潜在的性能问题，并提供优化建议。

除此之外，LoadRunner还具有丰富的功能和灵活性，能够适应各种复杂的性能测试需求，是业界公认的领先性能测试工具之一。

Loadrunner的基本概念

功能：

LoadRunner是一种功能强大的自动负载测试工具，适用于多种软件体系架构。它提供了丰富的功能，可以帮助用户评估系统的性能表现。LoadRunner可以测量用户关注的各种性能指标，包括响应时间、吞吐量、并发用户数量以及性能计数器等，从而全面地评估系统在不同负载条件下的性能表现。通过模拟各种场景和负载条件，LoadRunner可以帮助用户发现潜在的性能瓶颈，并提供详尽的测试报告和分析结果，以指导系统性能的优化工作。LoadRunner的强大录制功能使得用户可以轻松地录制测试脚本，快速建立测试场景，从而提高测试效率。总的来说，LoadRunner作为一款领先的性能测试工具，为用户提供了全面而可靠的性能评估解决方案。

原理：

LoadRunner启动后，在系统任务栏中会有一个Agent进程运行。该Agent进程的作用是监视各种协议的客户端与服务器端之间的通信过程。LoadRunner利用一套C语言函数来录制测试脚本，因此只要LoadRunner支持的协议，就能够完整地录制通信过程，避免出现无法录制的情况。录制完成后，LoadRunner会使用这些脚本模拟用户行为，向服务器端发送请求，并接收服务器的响应。LoadRunner并不关心服务器内部的处理过程，它主要通过模拟上千万用户的并发负载以及实时性能监测的方式，来确认和查找系统中的性能问题，并提供性能优化建议，以加速应用系统的发布周期。

LoadRunner主要包括三个前台功能组件：

VuGen（虚拟用户脚本生成器）、Controller（测试控制器）和Analysis（结果分析器）。此外，系统还自动调用后台功能组件LG（负载生成器）和Proxy（用户代理）来完成性能测试工作。

VuGen：VuGen是用于录制和编写虚拟用户脚本的工具。通过录制或手动编写脚本，可以模拟用户在应用程序中的行为和操作。这些脚本描述了用户与应用程序之间的交互过程，包括发送请求、接收响应和处理数据等步骤。
Controller：Controller是性能测试的中心控制器，用于管理、监控和执行性能测试。在Controller中，可以指定性能测试方案、配置测试场景、分配虚拟用户、启动测试并监控测试执行过程。它还负责收集测试数据和监控系统性能指标，以便进行实时分析和调整。
Analysis：Analysis用于对性能测试过程中收集到的各种性能数据进行计算、汇总和分析。通过Analysis，可以生成各种图表和报告，展示系统在不同负载条件下的性能表现，帮助测试人员深入了解系统的性能特征和瓶颈，并提供优化建议。

此外，还有后台组件：

LG（Load Generator）：负载生成器，用于模拟多用户并发访问被测试系统。它执行从Controller指定的虚拟用户脚本，并生成负载以模拟实际用户的行为，从而评估系统的性能表现。
Proxy：用户代理，支持VuGen录制和回放过程。它在录制过程中拦截和记录HTTP/HTTPS通信，以便生成虚拟用户脚本。在回放过程中，将虚拟用户脚本发送到被测试系统，并捕获响应数据以供分析使用。

LoadRunner主要包括的三大组件之间的关系：

在LoadRunner的工作流程中，首先使用VuGen录制脚本，然后将脚本放置在Controller设计的测试场景中进行运行。在测试运行过程中，Controller会收集监控数据，并将这些数据传输到Analysis中进行分析和报告生成。

VuGen（虚拟用户脚本生成器）：VuGen用于录制、编辑和调试虚拟用户脚本。测试人员使用VuGen录制用户操作并生成脚本，然后将这些脚本保存下来，准备在性能测试中使用。
Controller（测试控制器）：Controller是性能测试的管理和监控中心。在Controller中，测试人员设计测试场景，配置虚拟用户数量、负载参数等，然后将预先录制好的脚本分配到场景中的虚拟用户中。一旦场景准备就绪，测试人员就可以启动测试并监控测试过程中的各项性能指标。
Analysis（结果分析器）：Analysis用于对性能测试结果进行分析和报告生成。测试人员在测试完成后，可以将收集到的性能数据导入到Analysis中进行分析。这些数据包括虚拟用户的响应时间、吞吐量、错误率等指标。通过Analysis生成的报告可以帮助测试人员评估系统的性能表现，发现潜在的性能问题，并提出优化建议。

重要概念

在使用LoadRunner之前，我们需要先了解以下几个重要概念：

场景（Scenario）：场景指的是在每一个测试过程中发生的事件或操作序列。它描述了被测试系统的特定使用情况和负载条件，包括用户的行为、并发用户数量等。一个场景可以由一个或多个虚拟用户组成。
虚拟用户（Vusers）：虚拟用户是LoadRunner用于模拟对应用程序产生压力的用户实体。LoadRunner使用多线程或多进程技术来模拟多个虚拟用户，每个虚拟用户都可以执行一系列的操作，并产生相应的负载。
脚本（Vuser Script）：脚本用来描述虚拟用户在场景中执行的动作和操作。它包含了虚拟用户在测试过程中的行为步骤、请求和响应的处理逻辑等内容。脚本通常由LoadRunner的脚本编辑器（VuGen）生成或编辑。
事务（Transactions）：事务代表了用户的某个业务过程，例如登录、搜索、结账等。在性能测试中，需要对这些业务过程的性能进行衡量和监控，以便评估系统的性能表现和稳定性。
集合点（Rendezvous）：在多用户并发测试中，每个用户执行事务脚本的先后顺序是不确定的。为了模拟真实的并发场景并评估系统的承载能力，可以在测试脚本中插入集合点。集合点指示所有用户在该点停顿，直到达到指定条件（默认是所有用户都到达），然后同时发出下一步请求，从而实现并发执行。

Loadrunner的性能测试过程

LoadRunner的性能测试过程可以分为以下几个主要步骤：

制定性能测试计划： 在这一阶段，团队需要分析应用程序，确定测试的目标，并计划如何执行测试。这包括确定测试的范围、目标用户数量、测试环境的配置等。
开发测试脚本： 使用LoadRunner的Virtual User Generator（VuGen）组件开发测试脚本。测试脚本描述了每个虚拟用户在测试中执行的活动，包括用户的行为、参数化、事务定义和检查点设置等。
设计运行场景： 在Controller中设计运行场景，定义要使用的虚拟用户数量、负载模型和测试持续时间等。运行场景描述了在测试活动中发生的各种事件，并包括一系列Load Generator机器和测试脚本的列表。
运行、监视测试： 一切配置就绪后，开始运行测试。在测试运行过程中，需要监视各个服务器的运行情况，包括数据库服务器、Web服务器等，以确保系统正常运行且能够处理预期的负载。
分析测试结果： 在测试运行结束后，使用Analysis组件来分析收集到的性能数据。LoadRunner提供了各种图表和报告，用于分析测试结果，评估系统的性能表现，并发现潜在的性能问题。最终，我们会得出结论，并提出性能优化的建议。

LoadRunner使用了三个主要功能模块来覆盖性能测试的整个流程：

Virtual User Generator（VuGen）：用于开发和编辑测试脚本。
Controller：用于设计运行场景，并执行测试。
Analysis：用于分析和评估测试结果，生成报告。

开发测试脚本

我们下面直接以Loadrunner安装时附带的样例程序Web Tours进行讲解。

了解Web Tours网站

如何启动

双击：

如何访问

成功访问到：

脚本录制

这个窗口别关，关了服务器就无法访问了：

接下来，双击VUG：

创建脚本文件

首先，新建一个脚本文件：

配合我们现在使用的Web Tours，选择HTTP协议：

录制脚本文件

输入用户名及密码：

现在我们选择停止录制：

这个窗口可以直接关掉：

录制好的脚本：

编译脚本文件

运行脚本文件

下面有很多日志，我们来仔细看看：

可以证明脚本的执行顺序：

vuser_init（虚拟用户初始化）： 在此阶段，虚拟用户初始化执行了一些准备工作，例如加载运行时设置文件。
Action（操作）： 在此阶段，虚拟用户执行了一系列操作。首先，通过web_url函数发送了一个GET请求，获取了页面上的一些资源（如图片）。接着，使用web_submit_form函数提交了一个登录表单，并且成功登录。然后，再次使用web_submit_form函数提交了另一个表单。在这些操作中，虚拟用户检测到了一些非资源的链接和一些资源已经在缓存中，因此没有重复下载。
vuser_end（虚拟用户结束）： 在此阶段，虚拟用户执行一些结束工作，如释放资源等。
Vuser Terminated（虚拟用户终止）： 虚拟用户执行完所有操作后被终止。

脚本加强

为什么要进行脚本的加强？

对脚本进行加强的主要目的是使其能够更准确地模拟用户行为，并且能够收集和报告相关的性能指标，以便于对应用程序的性能进行评估和分析。录制的脚本可能会忽略一些关键的性能指标，导致无法全面地评估应用程序的性能。通过对脚本进行加强，可以更全面地测试和评估应用程序的性能，从而确保应用程序在生产环境中能够达到预期的性能要求。

插入事务

当录制完一个基本的用户脚本后，在正式使用前我们还需要完善测试脚本，增强脚本的灵活性。一般情况下，我们通过以下方法来完善测试脚本：

事务（Transaction）：为了衡量服务器的性能，我们需要定义事务。比如：我们在脚本中有一个数据查询操作，为了衡量服务器执行查询操作的性能，我们把这个操作定义为一个事务，这样在运行测试脚本时，LoadRunner运行到该事务的开始点时，LoadRunner就会开始计时，直到运行到该事务的结束点，计时结束。这个事务的运行时间在结果中会有反映。插入事务操作可以在录制过程中进行，也可以在录制结束后进行。LoadRunner可以在脚本中插入不限数量的事务。

如何插入事务：通过菜单设计---在脚本中插入---开始事务、结束事务来进行事务的添加。事务的状态默认情况下是 LR_AUTO。一般情况下，我们也不需要修改，除非在手工编写代码时，有可能需要手动设置事务的状态。可以通过步骤导航器来查看步骤的参数选项。

其实不用搜索，这里就有：

注意，开始事务和结束事务必须成对出现！

开始事务函数里面的“login”是事务名称，开始事务和结束事务对应的事务名称要求一致！

以上述为例，在实际生成的脚本中含有打开首页、注册、退出登录等多项操作。而我们实际需要关注的是注册这一个事务的性能，那么就需要在注册前后来加入事务。

除了事务，我们还可以通过参数化、添加逻辑、错误处理等方式来完善测试脚本，以更好地模拟真实用户的行为，并评估应用程序的性能。

插入集合点

在LoadRunner中，为了实现并发这种目的，通过集合点实现。

集合点是为了衡量在加重负载的情况下服务器的性能情况。在测试计划中，可能会要求系统能够承受1000人同时提交数据。在LoadRunner中，可以通过在提交数据操作前面加入集合点来实现这一需求。这样当虚拟用户运行到提交数据的集合点时，LoadRunner就会检查同时有多少用户运行到集合点。如果不到1000人，LoadRunner就会命令已经到集合点的用户在此等待。当在集合点等待的用户达到1000人时，LoadRunner会命令1000人同时去提交数据，从而达到测试计划中的需求。

注意：集合点经常和事务结合起来使用。集合点只能插入到Action部分，vuser_init和vuser_end中不能插入集合点。

具体的操作方法如下：在需要插入集合点的前面，通过菜单操作：菜单设计---在脚本中插入---集合点。

运行后在日志中也得以体现：

插入检查点

当进行压力测试时，为了检查Web服务器返回的网页是否正确、页面元素是否渲染正确，VuGen允许我们插入文本检查点。这些检查点可以验证网页上是否存在指定的文本，并测试在较大的压力测试环境中，被测的网站功能是否保持正确。

检查点的含义类似于单元测试中的断言功能，用于确认程序的正确性。

通过菜单---查看---快照，可以查看HTTP数据视图，选择要检查的文本，然后选择添加文本检查步骤，即可添加一个检查点。

然而，在进行回放时，可能会遇到错误提示。这可能是由于检查点验证失败导致的。常见的失败原因包括：

网页内容发生变化：如果在录制脚本时检查点验证的文本与回放时的实际网页内容不一致，检查点将失败。
动态生成的内容：如果网页上的文本是动态生成的，如时间戳或会话标识符等，那么每次回放时文本都会发生变化，导致检查点失败。
网络延迟或服务器响应时间过长：如果在检查点验证期间网络延迟或服务器响应时间过长，可能会导致检查点验证超时。

在遇到检查点失败时，需要检查网页内容是否发生变化，确认是否存在动态生成的内容，并评估网络延迟或服务器响应时间是否影响了检查点的验证。根据具体情况调整检查点设置或网站功能以解决问题。

参数化

在录制脚本过程中，如果用户填写并提交了一些数据，比如要增加数据库记录，这些操作都会被记录到脚本中。然而，当多个虚拟用户运行脚本时，它们都会提交相同的记录，这不符合实际的运行情况，并且有可能引起冲突。为了更真实地模拟实际环境，我们需要各种各样的输入。

参数化输入是一种有效的方法。通过使用参数，可以实现以下两个优点：

可以使脚本变得更简洁：通过将常量值替换为参数，可以减少脚本的长度和重复性。
可以使用不同的数值来测试脚本：在回放过程中，可以使用不同的参数值，而不只是针对一个特定的情况。

参数化的过程通常包含以下两个任务：

在脚本中用参数取代常量值。
设置参数的属性以及数据源。

需要注意的是，参数化仅适用于函数中的参数。不能将参数用于非函数参数的字符串。

举例来说，在注册的例子中，如果我们已经注册了一个名为test的用户，再次注册就会失败，因为用户名已经存在。这意味着当LoadRunner脚本再次运行时，注册步骤会失败。为了解决这个问题，可以找到对应的代码块，在用户名（例如username）中选中"test"字符串，然后右键点击并选择"使用参数替换"，然后就可以设置参数，使得在每次运行时可以使用不同的用户名。

选择文件类型，并且自定义文件名称及路径后点击“Create table”：

点击“close”，再点击OK：

密码也进行参数化：

为了方便观察，我们调整日志格式，并且Ctrl+S保存：

如果有多个用户名，需要修改：

参数的类型

日期/时间（DateTime）：用于表示日期和时间，在需要输入日期/时间的地方使用DateTime类型来替代。属性设置包括选择日期时间格式。
组名（Group Name）：在实际运行中，LoadRunner使用该虚拟用户所在的Vuser Group来代替。在VuGen中运行时，Group Name将会是None。
负载生成器名称（Load Generator Name）：在实际运行中，LoadRunner使用该虚拟用户所在负载生成器的机器名来代替。
迭代编号（Iteration Number）：在实际运行中，LoadRunner使用当前测试脚本循环的次数来代替。
随机数字（Random Number）：用于生成随机数，在属性设置中可以设置随机数的范围。
唯一编号（Unique Number）：用于生成唯一的数字，在属性设置中可以设置第一个数字以及递增的数字大小（每个Vuser的块大小）。注意，使用该参数类型时要注意可以接受的最大数，以避免脚本运行出错。
Vuser ID：用于表示虚拟用户的ID，在实际运行中，LoadRunner使用该虚拟用户的ID来代替。在VuGen中运行时，Vuser ID将会是-1。
文件（File）：需要在属性设置中编辑文件，并添加内容。
用户定义的函数（User Defined Function）：从用户开发的DLL文件提取数据。

每种参数类型都有不同的用途和属性设置，根据实际需要选择合适的参数类型来进行参数化。

打印日志

脚本加强中的一项重要技术是打印日志。在软件开发和测试过程中，日志是一种非常有用的工具，能够提供关于系统运行状态的详细信息。通过在脚本中添加日志信息，我们可以更好地跟踪脚本的执行过程、调试脚本中的问题以及记录关键信息。

首先，通过在脚本中适当的位置插入日志语句，我们可以实时地记录脚本的执行情况。这样做有助于我们了解脚本执行到哪一步，以及每一步的执行结果。如果脚本出现异常或错误，我们可以根据日志信息追踪问题所在，并快速定位和解决。

其次，日志还可以用于调试脚本中的问题。通过在关键步骤前后插入日志语句，我们可以输出变量的值、函数的返回结果，甚至是请求和响应的内容。这些详细的信息有助于我们深入分析脚本的执行过程，从而更加准确地定位和解决问题。

此外，日志还可以用于记录关键信息，如用户操作的详细步骤、重要事件的发生时间、错误信息等。这些日志记录可以作为后续分析、报告和审计的重要依据，有助于我们全面了解脚本的执行情况和系统的运行状态，以及及时发现和解决潜在问题。

综上所述，通过适当地添加日志信息，我们可以提高脚本的可读性、可维护性和调试性，从而提高脚本的质量和效率，以确保系统的稳定性和可靠性。

还有一个函数和它很相似：

插入函数

VuGen 中可以使用C 语言中比较标准的函数和数据类型，语法和C语言相同。下面简单介绍一下比较常用的函数和数据类型。

控制脚本流程：在脚本页面，通过右键-插入-新建步骤可以查看函数列表。在VuGen中，您可以直接使用C语言中常见的控制流程语句，如if、else、for、while等，来控制脚本的执行流程。
字符串函数：由于在VuGen脚本中使用最多的是字符串操作，因此字符串函数在脚本中非常频繁。一些常用的字符串函数包括：
- strcmp：用于比较两个字符串。
- strcat：用于连接两个字符串。
- strcpy：用于拷贝字符串。注意：在VuGen中，以char声明的字符串是只读的。如果试图给char类型的字符串赋值，虽然编译会通过，但在运行时会产生“Access Violation”的错误。解决这类问题的方法是将字符串声明为字符数组，如char[100]。
输出函数：输出函数在调试脚本时非常有用。其中，lr_output_message用于输出一条消息，您可以在执行过程中插入此函数以输出调试信息，方便排查问题。

当在LoadRunner中进行脚本编写时，除了常见的C标准函数外，还提供了许多LoadRunner特定的标准函数，这些函数用于执行各种性能测试任务，并且通常与LoadRunner的特性和功能紧密相关。

以下是一些常见的LoadRunner标准函数：

lr_start_transaction和lr_end_transaction：这对函数用于开始和结束一个事务，用于衡量一组操作的性能，例如用户登录、搜索、结账等。
web_url和web_submit_form：这两个函数用于模拟用户在Web应用程序中的页面请求，web_url用于访问URL，而web_submit_form用于提交表单。
lr_think_time：用于模拟用户在操作之间的思考时间，以更真实地模拟用户行为模式。
lr_eval_string：用于在运行时评估字符串表达式，通常用于参数化脚本中的值。
lr_save_string和lr_eval_string：这对函数用于在脚本执行期间保存和检索字符串值，可用于动态提取服务器响应中的数据并在后续请求中使用。
lr_error_message：用于输出错误消息，方便调试和定位脚本中的问题。
web_reg_find：用于在服务器响应中查找特定的文本，以进行文本检查，用于验证页面是否正确加载。
web_add_header：用于添加自定义HTTP标头，以满足特定的测试需求，例如添加授权标头或自定义标头。

以上是一些LoadRunner中常见的标准函数，可以根据测试需求选择适当的函数来完成各种性能测试任务。这些函数使得LoadRunner成为一个强大而灵活的性能测试工具，能够满足各种复杂的测试场景和需求。

创建运行场景

在LoadRunner中，一个运行场景描述了在测试活动中可能发生的各种事件和操作。它包括了一组Load Generator机器列表、测试脚本列表以及大量的虚拟用户和虚拟用户组。

具体来说，一个运行场景包含以下几个要素：

Load Generator机器列表：指定了用于模拟用户行为和生成负载的Load Generator机器的列表。这些机器负责发送请求到被测系统，并模拟用户的行为。
测试脚本列表：包含了要在测试中执行的测试脚本。这些脚本定义了用户的操作流程、负载模式和性能测试目标。
虚拟用户和虚拟用户组：虚拟用户是由测试脚本定义的模拟用户，它们模拟真实用户在被测系统中的行为。虚拟用户组则是一组具有相似行为的虚拟用户的集合，可以根据需要配置不同数量的虚拟用户组，以模拟不同的用户群体和负载条件。

创建和管理运行场景通常通过LoadRunner中的Controller来完成。在Controller中，我们可以指定Load Generator机器、加载测试脚本、配置虚拟用户组以及设置测试参数等。一旦设置好了运行场景，我们就可以启动测试并监控测试过程中的性能表现。通过运行场景，我们可以模拟真实的用户行为、生成负载并评估被测系统的性能表现。

Controller打开方式

方式一——通过VUG打开：

但是我们应该根据需求修改，Controller有一个Bug，可能不会生成右边的图表：

而我们按照第一种方式可以显示图表：

方式二——双击直接打开

如果没有弹出窗口：

弹出一个框，选择场景类型：

左边展示着VUG新建的所有脚本文件，可以按需求添加到右边。

我们不修改，选择手动场景，点击OK。

通过Contrllor设置运行场景

在LoadRunner中，创建新场景时需要选择一种场景类型。

下面对两种主要类型进行简要说明：

手动场景：
- 说明：手动场景需要完全手动设置场景参数和配置。
- 百分比模式分配Vuser：在手动场景中，可以选择使用百分比模式来在不同的脚本之间分配虚拟用户。这意味着我们需要定义要使用的虚拟用户总数，并为每个脚本分配要运行的虚拟用户的百分比。如果不选择百分比模式，则虚拟用户将按数量分配给每个脚本。
面向目标的场景：
- 说明：面向目标的场景是根据测试计划中定义的性能测试目标自动创建的。我们只需定义我们的测试目标，LoadRunner将根据这些目标自动生成场景。
- 特点：该场景类型适用于在测试计划中明确定义了性能测试目标的情况。LoadRunner将根据我们提供的目标信息，自动为我们创建一个符合目标要求的场景，简化了场景设置的过程。

选择适合我们需求的场景类型可以根据我们的测试目标和需求来确定。如果我们希望对场景进行详细的手动配置，可以选择手动场景；如果我们已经明确了测试目标并希望根据目标自动生成场景，可以选择面向目标的场景。

当然，后者较为死板，所以我们重点放在第一种手动创建场景上。

选择场景类型为手动场景

在手动场景设置页面中，我们可以对场景进行详细的配置和调整。

在性能测试领域，通常有两种关键的角色：施压机器（Load Generators）和被压机器（SUT，System Under Test）。

施压机器（Load Generators）：

施压机器是指用于模拟大量用户并发访问系统的计算机或服务器。这些机器通过运行性能测试工具（如LoadRunner、JMeter等）来模拟多个用户同时对系统发出请求，以测试系统在不同负载下的性能表现。
施压机器会生成大量的网络流量和请求，以模拟真实用户的行为。它们通常会在测试期间不断向被压机器发送请求，并记录系统的性能指标和响应时间等数据。

被压机器（System Under Test，SUT）：

被压机器是指要进行性能测试的目标系统或应用程序。这可能是一个Web服务器、数据库服务器、应用程序服务器等。
被压机器接收来自施压机器的请求，并对其进行处理。其性能表现会受到施加的负载的影响，从而帮助测试人员评估系统在不同负载条件下的性能、稳定性和可靠性。

在性能测试过程中，施压机器和被压机器协同工作，通过模拟真实用户行为和对系统进行压力测试，以确保系统在生产环境中能够满足用户的需求并保持稳定的性能。

Load Generator（负载发生器）：
- 负载发生器是执行场景的机器，通常默认为本机。如果我们在其他计算机上安装了LoadRunner代理，则可以将其添加为负载发生器，从而进行调用。
- 添加负载发生器后，执行“连接”操作以确保状态为“就绪”。如果状态显示为“Failed”，表示该负载发生器无法连接，请检查连接原因。
Vuser组模式：
- 在场景菜单中，我们可以将场景设置为Vuser组模式或百分比模式。在Vuser组模式下，可以根据Vuser数目设置每个脚本的执行方式。
百分比模式：
- 在百分比模式下，用户数目在全局计划中进行设置，然后按照百分比进行分配。
全局计划设置：
- 全局计划设置非常重要，也是三种场景类型的主要区别。它包括初始化、启动Vuser、持续时间和停止Vuser等选项。
  - 初始化：指定每个Vuser在何时进行初始化。通常选择在每个Vuser运行之前初始化。
  - 启动Vuser：指定Vuser何时启动。一般会选择按阶梯逐步启动，以减轻服务器压力。
  - 持续时间：指定场景的总执行时间。选择“完成前一直运行”表示所有虚拟用户只运行一遍脚本就停止。
  - 停止Vuser：指定Vuser的停止策略。
设置结果文件保存路径：
- 通过菜单中的“结果”->“结果设置”，我们可以设置结果文件的保存路径。建议在每次场景运行前重新设置路径。
运行时设置：
- 包括日志和思考时间设置，这些会影响测试结果。关闭日志和思考时间可以提高TPS。
影响性能和TPS统计的设置项：
- 注意日志、思考时间以及自动事务选项等设置项，它们都会影响性能测试结果和TPS统计。

通过以上设置，我们可以更加灵活地调整场景，确保测试的准确性和可靠性，并获取到我们所需的性能指标。

选择场景类型为面向目标的场景

场景目标的主要设置页面如下：

虚拟用户目标（Virtual Users Goal）：

如果我们想要了解系统在多少用户同时访问下的性能情况，建议设置虚拟用户目标。这个目标指定了同时运行的虚拟用户数量，以便我们评估系统在不同负载下的表现。

每秒点击次数：

如果我们希望测试Web服务器的真实性能，可以选择设置目标类型为每秒点击次数（Hits per Second）、每分钟页面数（Pages per Minute）或每秒事务数（Transactions per Second）。这些类型的目标需要指定一个虚拟用户的最小值和最大值范围。
Controller会尝试以最少的虚拟用户数量来达到所定义的目标。如果最小用户数无法达到目标，Controller会逐步增加用户数，直到达到最大用户数。如果即使使用了最大用户数目标仍未实现，就需要增加最大用户数，然后重新执行场景。

事务响应时间：

事务响应时间（Transactions Response Time）是评估系统性能的关键指标之一。以下是对事务响应时间的详细说明：

如果想知道在多少用户并发访问网站时，事务的响应时间达到性能指标说明书中规定响应时间的最大值，我们推荐使用Transactions Response Time 类型。在这种类型下，需要指定需要测试的事务名称、虚拟用户数量的最小值和最大值，以及预先定义好的事务的响应时间。

在场景运行中，如果我们使用了最多的虚拟用户，但仍未达到定义的最大响应时间，这说明Web服务器仍然有能力接受定义的最大虚拟用户数量。如果在使用了部分虚拟用户时就达到了定义的最大响应时间，或者LoadRunner提示即将超过最大响应时间，则需要重新设计或修补应用程序，并可能需要升级Web服务器的软硬件。

如果我们定义的目标是Pages per Minute、Hits/Transactions per Second，Controller会首先根据最小用户数除以定义的目标，得到一个值，然后确定每个用户应该达到的hits/transactions或pages per minute。然后Controller开始按以下策略加载用户：

如果选择自动加载虚拟用户，LoadRunner会首先加载50个用户。如果定义的最大用户数小于50，LoadRunner会一次性加载所有虚拟用户。
如果选择在场景运行一段时间后达到目标，LoadRunner会尝试在定义的时间段内达到目标，根据时间限制和计算出的每个用户的hits、transactions或pages确定第一批加载的用户数量。
如果选择按照一定的阶段达到目标，LoadRunner会计算每个用户应该达到的数字，然后确定第一批加载的用户数量。

在每加载一批用户后，LoadRunner会检查是否达到了这批用户的目标。如果未达到，则会重新计算每个用户应该达到的目标数字，并重新调整下一批加载用户的数量。默认情况下，LoadRunner每两分钟加载一批用户。

如果Controller加载了最大数量的用户仍未达到预定目标，则LoadRunner会重新计算每个用户的目标，并同时运行最大数量的用户，以尝试达到预定目标。

如果出现以下情况，Pages per Minute、Hits/Transactions per Second类型的场景会置于“Failed”状态：

Controller使用了指定的最大数量的用户，并且两次都没有达到目标。
所有的用户运行都失败。
没有足够的Load Generators机器可用。
Controller增加了几批用户后，pages per minute或hits/transactions per second没有增加。
Controller加载第一批用户后，定义的目标没有被捕捉到。

##分析以及监控运行场景

在运行过程中，我们可以监视各个服务器的运行情况，例如DataBase Server、Web Server等。我们可以通过添加性能计数器来实现监视。实际中更多的会使用第三方工具，例如nmon来监控Linux等系统。以下是在Windows服务器上的示例：

在运行页面，选择系统资源图中的Windows资源。
点击右键，选择“添加度量”。
添加要监控的服务器。
然后，我们可以查看各个计数器的值，通过这些值可以分析系统的瓶颈在哪里。

分析实时监视图表

在分析实时监视图表时，我们可以关注以下几个关键点：

事务响应时间是否在可接受的时间内？ 我们可以通过“事务响应时间”图表来判断每个事务完成所需的时间。这可以帮助我们确定是否有任何事务的响应时间超出了预期的可接受时间范围。通过观察这些图表，我们可以识别出哪些事务花费的时间最长，以及是否有任何事务的响应时间超出了预定的可接受时间。
网络带宽是否足够？ 通过“吞吐量”图表，我们可以观察在场景运行期间每秒从Web服务器接收到的数据量。将这个值与网络带宽进行比较，可以确定当前的网络带宽是否是系统的瓶颈。如果“吞吐量”图表显示的曲线随着用户数量的增加而呈现相对平缓的趋势，而不是增长趋势，那么这可能意味着当前的网络速度无法满足系统当前的流量需求。
TPS值：通过“每秒事务数”图表，我们可以实时监测系统每秒处理的事务数量。这个值对于评估系统的性能非常重要。通过观察TPS值的变化，我们可以了解系统的负载情况以及系统是否能够处理当前的事务负载。

通过对这些实时监视图表的分析，我们可以及时发现系统性能方面的问题，并采取相应的措施来优化系统的性能。

运行场景

在Controller中的运行场景界面，通常分为几个主要区域，其中包括：

虚拟用户状态区（Virtual User Status）：
- 我们可以在这个区域看到当前正在运行的虚拟用户的状态和活动情况。
- 每个虚拟用户通常显示其当前的状态，如“运行中”、“等待中”、“完成”等。
- 通过这个区域，我们可以实时监视虚拟用户的运行情况，及时发现问题并进行调整。
日志消息区（Log Messages）：
- 在这个区域，我们可以查看测试运行过程中生成的日志消息。
- 日志消息可能包括关于测试步骤的信息、警告、错误信息以及其他与测试相关的事件。
- 通过查看日志消息，我们可以了解测试执行过程中的各种情况，帮助定位和解决问题。
运行时间区（Run Time）：
- 这个区域显示了当前测试场景的运行时间。
- 我们可以随时查看测试已经运行了多长时间，以便掌握测试的进展情况。
图表区（Graphs）：
- 这个区域显示了一系列图表，用于实时监视系统的性能指标和性能趋势。
- 图表可以包括吞吐量、响应时间、错误率、CPU 使用率等性能指标，帮助我们全面了解系统在不同负载下的表现。
- 这里可以调整图表显示个数：
活动虚拟用户列表（Active Virtual User List）：
- 这个区域显示了当前正在活动的虚拟用户的详细信息，如虚拟用户的编号、IP地址、运行时间等。
- 我们可以通过这个区域查看每个虚拟用户的活动状态和运行情况，以及它们的资源占用情况。
活动事务列表（Active Transaction List）：
- 这个区域显示了当前正在执行的事务的详细信息，如事务的名称、启动时间、结束时间、执行时间等。
- 我们可以通过这个区域了解每个事务的执行情况，包括事务的响应时间、成功率等指标。

通过以上六种区域，我们可以全面监控和管理测试场景的执行过程，及时发现问题并做出调整，确保测试的顺利进行和准确评估系统的性能表现。

虚拟用户状态区（Virtual User Status）

虚拟用户状态区（Virtual User Status）包含多种状态，具体包括：

Down：表示虚拟用户当前处于停止状态，无法执行任何操作或任务。这通常是因为虚拟用户会话已经结束或者被手动停止，导致虚拟用户无法执行任何任务。在 Down 状态下，虚拟用户将不再参与场景的执行，并且不会再生成任何活动或者日志。
Pending。这个状态表示虚拟用户处于等待状态，等待系统分配资源或者等待前置条件满足后才能开始执行任务。通常，当虚拟用户数量超过系统当前能够支持的上限时，一部分虚拟用户可能会进入Pending状态，直到有可用资源或者满足条件时才会转变为其他状态，比如Ready或者Run。 Pending状态的虚拟用户不会执行任务，直到系统能够分配资源或者满足前置条件为止。
Init：示虚拟用户正在初始化过程中，准备开始执行测试脚本之前的准备工作。在这个阶段，虚拟用户会执行必要的初始化操作，包括加载脚本、设置参数、建立连接等。一旦初始化完成，虚拟用户就会进入就绪状态（Ready），准备开始执行脚本。
Ready：示虚拟用户已经完成初始化，准备好执行测试脚本，但尚未开始执行。一旦虚拟用户进入到这个状态，它就已经准备好执行测试脚本，只等待控制器发出开始执行的命令。
Run：表示虚拟用户正在执行测试脚本，与服务器进行交互，并模拟用户行为。在这个状态下，虚拟用户会按照脚本中定义的操作进行请求和响应，与被测应用程序进行交互。
Rendez：

表示虚拟用户处于同步等待状态，等待其他虚拟用户达到同步点再继续执行。这种状态通常用于模拟多个用户同时执行某个操作的情况，其中一个用户需要等待其他用户执行完特定操作后才能继续进行。
Passed：

表示虚拟用户已经成功完成了其任务，执行测试脚本的全部步骤，并且没有出现错误或异常。当虚拟用户达到此状态时，表示其任务顺利完成，测试结果正常。
Failed：表示虚拟用户在执行过程中遇到了无法处理的严重错误，导致测试任务失败。当虚拟用户处于此状态时，通常需要进行错误分析和排查，以确定问题的根源并采取相应的修复措施。
Error：表示虚拟用户在执行过程中遇到了错误，可能是网络连接问题、脚本错误、服务器响应异常等。与“Failed”状态不同的是，此状态下的错误通常不会导致整个测试任务的失败，但仍需要关注和处理以确保测试的准确性和稳定性。
Gradual Exiting：表示虚拟用户正在逐渐退出执行状态，准备停止执行测试脚本。这种状态可能在测试任务结束或者手动停止虚拟用户时出现，表示虚拟用户正在逐步完成当前的任务并最终退出执行状态。
Stopped：表示虚拟用户正在逐渐退出执行状态，准备停止执行测试脚本。这种状态可能在测试任务结束或者手动停止虚拟用户时出现，表示虚拟用户正在逐步完成当前的任务并最终退出执行状态。

这些状态可以帮助我们实时监控虚拟用户的运行情况，及时发现问题并采取相应的措施进行调整和处理，确保测试的顺利进行。

运行起来之后观察：

你会发现左侧的性能指标区分为蓝色的字和黑色的字，蓝色的字代表检测到的数据，黑色的代表没有检测到。

添加电脑监控指标：

想要监控黑色的字怎么办？需要手动添加。左击想要添加的性能，右击一个空白图表：

施压机器和被压机器都是本机，写上localhost：

可以把不想要的删除：

Running状态：在场景运行开始时，所有虚拟用户都需要经历初始化并启动，因此初始时Running状态的虚拟用户数量为0。随着场景的进行，虚拟用户逐渐完成初始化并开始执行测试脚本，导致Running状态的虚拟用户数量逐渐增加。由于我们一开始设置了3个虚拟用户，因此Running状态的虚拟用户数量的最高点为3。
Finished状态：初始时，所有虚拟用户都处于未完成状态，因此Finished状态的虚拟用户数量为0。随着场景的进行，一些虚拟用户完成了其任务并成功执行了测试脚本，导致Finished状态的虚拟用户数量逐渐增加。这表示已经完成了测试任务的虚拟用户数量。
Error状态：因为场景运行时没有出现错误，所以Error是0；

我们只插入了一个事务，但是这里显示4个事务？

这是因为在Controller中，VUG中的一个代码文件就是一个事务，再加上我们添加的一个事务，一共是4个事务。

许多部分趋势和走势极其相似。

刚开始需要建立连接，紧接着才会断开连接，所以new connection数据刚开始比较高lConnection shutdown数据刚开始为0，因为需要先建立连接。

趋势基本稳定。

这种的就不太正常，需要你去着重分析到底发生了什么。

通过Analysis进行测试报告解读

如果运行结束之后没有自动打开 Analysis，你需要先设置这两个地方：

接下来它就会自动打开窗口：

我们可以合并图表观察：

合并吞吐量和每秒点击数量：

为什么吞吐量和每秒点击数量的趋势是一样的？

吞吐量和每秒点击数量的趋势通常是相关的，因为它们之间存在着密切的关联关系。当每秒点击数量增加时，即表示系统接收到HTTP的请求量增加了，这意味着系统需要处理更多的请求。这种情况下，系统的吞吐量也会相应地增加，因为吞吐量是衡量系统在单位时间内能够处理的请求数量。因此，当每秒点击数量增加时，吞吐量通常也会增加，反之亦然。这种相关性反映了系统处理能力和负载之间的密切关系。

我们可以新建一个表来观察：

合并后发现两者几乎重合：

通过上述图表，我们可以做一些简单的项目的性能分析：
如果点击率上升，但是吞吐量没有反应/吞吐量数据没有变化？

从这句话我们可以剖析出：我们虽然对系统不断请求，但是请求和服务之间没有数据交互。

服务无响应： 可能是因为服务出现了故障或性能问题，导致无法及时响应请求。这可能是由于服务器过载、软件错误、网络问题或其他原因引起的。
请求未到达服务器： 虽然点击率上升，但实际发送到服务器的请求数量并没有增加，这可能是由于网络问题、防火墙设置、负载均衡器故障等原因导致请求未能成功到达服务器。
服务响应延迟： 即使请求已经到达服务器，但由于服务端处理能力不足或处理速度较慢，导致无法及时响应请求，从而使吞吐量没有相应变化。
服务器限制请求量： 可能是服务器端对请求数量进行了限制或设置了阈值，一旦达到该阈值，服务器将不再响应或处理请求，这可能是为了保护服务器免受过载或拒绝服务攻击等问题的影响。
其他问题： 还可能存在其他问题，如网络拥塞、软件配置错误、硬件故障等，这些问题也可能导致点击率上升但吞吐量未发生变化。

事务摘要

事务摘要是性能测试结果分析中的重要组成部分，它提供了整个测试期间各个事务的综合情况，包括通过（Pass）和失败（Fail）等信息。通过对事务摘要的综合分析，我们可以对系统的整体性能进行初步评估，并快速了解系统是否正常运行。

成功与失败比例分析：
- 分析通过（Pass）和失败（Fail）事务的比例，评估系统在测试期间的整体稳定性和可靠性。
- 如果通过事务比例较高，可能表示系统在测试条件下表现良好，可以考虑进行更深入的性能分析。相反，如果失败事务比例较高，则需要进一步分析失败原因，并采取相应措施解决问题。
事务执行时间分析：
- 对通过和失败事务的执行时间进行分析，了解事务的平均响应时间、最大响应时间和最小响应时间。
- 如果存在执行时间较长的事务，可能表示系统中存在性能瓶颈或者出现了异常情况，需要进一步定位和解决。
关键事务分析：
- 针对关键业务场景中的事务进行重点关注，分析关键事务的执行情况，包括通过率、响应时间等指标。
- 通过重点关注关键事务，可以更全面地评估系统在高负载条件下的性能表现，并及时发现可能存在的问题。
趋势分析：
- 对事务通过率和执行时间随时间的变化趋势进行分析，了解系统性能在测试过程中的变化情况。
- 通过趋势分析，可以发现系统性能的波动情况，及时调整测试策略或者系统配置，确保系统在各种条件下都能保持稳定的性能。

平均事务响应时间

平均事务响应时间图是性能测试结果分析中的重要指标之一，它显示了在测试场景运行期间每一秒内事务执行所用的平均时间。通过这个图表，我们可以分析应用系统在不同时间段内的性能表现，以及了解系统在负载变化下的响应情况。

性能走向分析：
- 通过观察平均事务响应时间随时间变化的曲线，可以了解系统的性能走向。通常情况下，随着负载的增加，平均响应时间会逐渐上升，反映了系统在高负载下的性能压力。
最大、最小和平均响应时间：
- 平均事务响应时间图表通常还会统计出测试期间每个事务的最大、最小和平均响应时间。通过对这些数据的分析，可以了解系统在不同时间段内事务执行时间的波动情况，以及评估系统的稳定性和一致性。
识别性能问题：
- 当平均事务响应时间呈现出明显的上升趋势或出现拐点时，可能表示系统性能存在问题或者出现了瓶颈。这时需要进一步分析具体的事务或系统组件，找出性能问题的原因，并采取相应的优化措施。
排队等待分析：
- 当平均响应时间快速上升时，可能意味着系统出现了排队等待的情况，即有大量事务在等待系统资源。这时需要进一步分析系统中的瓶颈点，例如数据库负载过高或者网络带宽不足，以便及时优化系统性能。

通过对平均事务响应时间图的分析，可以全面了解系统在测试期间的性能表现，及时发现并解决潜在的性能问题，确保系统能够在不同负载下保持稳定和高效的运行。

每秒通过事务数分析图(Transactions per Second)

每秒通过事务数分析图（Transactions per Second，TPS）是评估系统性能的重要指标之一。该图显示了在测试场景运行的每一秒中，每个事务通过、失败以及停止的数量，反映了系统在不同时间段内的事务处理能力和负载情况。

实时事务负载分析：
- TPS图展示了系统在每一秒钟内处理的事务数量，包括通过、失败和停止的事务。通过观察TPS的变化趋势，可以直观地了解系统在测试过程中的实时事务负载情况，以及系统在不同负载下的表现。
性能变化趋势分析：
- 通过分析TPS图的变化趋势，可以发现系统性能在不同时间段内的变化趋势。如果TPS值呈现出逐渐上升、稳定或者下降的趋势，可以推断系统的性能在相应时间段内是增强、稳定还是下降的。
与响应时间的对比分析：
- 将TPS图与平均事务响应时间图进行对比分析，可以帮助了解系统在不同负载下的性能表现。如果TPS持续增加而平均响应时间保持稳定或下降，可能表示系统的吞吐量提高了，性能表现良好。相反，如果TPS增加而平均响应时间上升，可能表示系统的负载已经超出了其承载能力，需要进一步优化系统以提高性能。
发现性能瓶颈：
- 当TPS曲线达到峰值时突然下降，或者出现了频繁的波动，可能表示系统出现了性能瓶颈或者其他问题。此时需要进一步分析系统中的瓶颈点，并采取相应的措施进行优化，以提高系统的性能和稳定性。

通过对每秒通过事务数分析图的观察和分析，可以帮助我们全面了解系统在测试期间的事务处理能力和性能表现，及时发现并解决潜在的性能问题，确保系统能够在高负载下保持稳定和高效的运行。

负载下的事务响应

“负载下的事务响应”图是一种综合性的图表，结合了“正在运行的虚拟用户”图和“平均事务响应时间”图的数据，用于展示系统在不同负载下的事务响应情况。

综合性分析：
- “负载下的事务响应”图综合考虑了系统的负载水平（通过正在运行的虚拟用户数目）和事务的响应时间。通过综合分析这两个因素，可以更全面地了解系统在不同负载下的性能表现。
事务响应随负载变化：
- 图表展示了系统在不同负载水平下的平均事务响应时间。通过观察图表的变化，可以了解系统的响应时间是如何随着负载的增加而变化的。一般来说，随着负载的增加，系统的平均事务响应时间可能会逐渐增加，但也可能存在负载增加而响应时间不变或者减少的情况。
负载与性能关系分析：
- 通过“负载下的事务响应”图，可以清晰地看出系统在不同负载下的性能变化趋势。当负载较小时，系统可能表现出较低的响应时间；而当负载增加时，响应时间可能会逐渐增加，直至达到系统的承载极限。
扩展应用系统的参考：
- 该图表提供了扩展应用系统时的重要参考数据。通过分析不同负载下的事务响应情况，可以帮助我们评估系统的性能瓶颈和极限，为系统的扩展提供合理的参考依据。
分析渐变负载场景：
- 对于具有渐变负载的测试场景，该图表尤为重要。通过观察事务响应随负载变化的情况，可以更好地了解系统在不同负载模式下的性能表现，为系统的优化和调整提供数据支持。

综合来看，“负载下的事务响应”图提供了系统在不同负载下的综合性性能数据，有助于深入分析系统的性能特征，发现潜在的问题和瓶颈，并为系统的优化和扩展提供重要参考。

事务响应时间（百分比）

“事务响应时间（百分比）”图提供了在给定事务响应时间范围内能够执行的事务百分比的分析。

分析事务响应时间分布：
- 该图表显示了事务响应时间的百分比分布情况。横轴表示事务的响应时间范围，纵轴表示在该时间范围内执行的事务百分比。通过观察图表，可以了解系统中事务响应时间的分布情况，以及在不同时间范围内执行的事务比例。
性能指标分析：
- 事务响应时间是评估系统性能的重要指标之一。通过分析事务响应时间的百分比分布，可以确定系统在不同响应时间范围内的性能表现。通常情况下，我们希望大多数事务能够在较短的时间内完成，因此关注响应时间分布的高峰值和尾部延迟情况是很重要的。
识别性能异常：
- 通过观察图表中的分布情况，可以识别系统中可能存在的性能异常。例如，如果图表中存在一个或多个响应时间较长的尾部延迟区域，可能表明系统在某些情况下性能不佳，需要进一步优化和调整。
优化决策支持：
- 事务响应时间（百分比）图为系统性能优化提供了重要的数据支持。通过分析事务响应时间的分布情况，可以确定哪些事务可能受到影响，以及可能需要重点优化的方面。这些信息可以帮助我们做出合理的优化决策，提升系统的整体性能。
性能趋势评估：
- 通过定期绘制事务响应时间（百分比）图，可以跟踪系统性能的变化趋势。如果图表中的某些区域出现变化，可能表明系统性能有所改善或恶化。这有助于及时发现问题并采取相应的措施进行调整和优化。

综合来看，“事务响应时间（百分比）”图通过对事务响应时间分布的分析，提供了全面的性能评估和优化决策支持，帮助我们深入了解系统性能特征，并发现潜在的性能问题。

点击率/吞吐率

点击率（Throughput）和吞吐率（Transactions per Second，TPS）是评估系统性能的重要指标，它们之间存在着密切的关联。

点击率（Throughput）：
- 点击率指的是系统在单位时间内处理的请求或事务数量。它是衡量系统处理能力的重要指标之一。通过观察点击率的变化，可以了解系统在不同负载下的处理能力。通常情况下，我们希望点击率越高越好，因为这意味着系统能够更有效地处理用户请求，提供更好的用户体验。
吞吐率（Transactions per Second，TPS）：
- 吞吐率指的是系统在单位时间内完成的事务数量。与点击率类似，吞吐率也是评估系统性能的关键指标之一。它反映了系统处理事务的速度和效率。在性能测试中，通过监测吞吐率的变化，可以了解系统在不同负载下的处理能力，帮助评估系统的性能表现和稳定性。
点击率和吞吐率的关系：
- 点击率和吞吐率通常是相互关联的，它们反映了系统处理能力的不同方面。在正常情况下，随着负载的增加，系统的点击率和吞吐率通常会同时增加，因为系统需要处理更多的请求和事务。然而，当系统达到容量上限或出现瓶颈时，点击率和吞吐率可能会停止增长或开始下降。
拐点的意义：
- 拐点是指点击率或吞吐率图中的曲线突然发生变化的点。拐点的出现可能意味着系统资源已经耗尽或出现了性能瓶颈，导致系统无法继续处理更多的请求或事务。当出现拐点时，系统可能会出现性能下降或不稳定的情况，需要进一步分析和解决问题。
性能问题的诊断：
- 点击率和吞吐率的变化可以帮助诊断系统性能问题。如果点击率或吞吐率突然下降，可能表明系统出现了性能问题，需要进一步分析原因。可能的原因包括资源耗尽、网络问题、软件配置错误等。通过分析点击率和吞吐率的变化趋势，可以及时发现并解决系统性能问题，保障系统的稳定运行和良好性能。

网页诊断

网页诊断是对网站页面内容的评估，旨在确定是否有任何因素影响了事务响应时间。通过网页诊断，可以深入分析导致网页响应缓慢或链接中断等问题的元素。以下是网页诊断的四种细分方式：

下载时间细分：
- 这种方式根据下载过程的时间细分各个阶段，包括DNS解析时间、建立连接时间、首次缓冲时间和接收时间等。通过分析这些细分时间，可以确定系统中的瓶颈和性能问题所在。
组件细分（随时间变化）：
- 将网页的组件按时间顺序进行细分，例如图片、脚本、样式表等，分析每个组件的下载时间和加载情况。这有助于识别影响网页性能的具体元素，从而采取针对性的优化措施。
下载时间（随时间变化）：
- 通过时间轴展示整个页面下载过程中各个组件的加载时间，帮助查找下载速度较慢或延迟的元素。这有助于发现导致页面加载缓慢的具体原因。
第一次缓冲时间（随时间变化）：
- 这指的是页面首次开始呈现内容的时间点，通常指的是浏览器首次渲染页面的时间。该指标可以反映出网页加载的快慢和用户体验的流畅度。

在网页诊断中，以下是常见的时间指标及其含义：

DNS Resolution（DNS解析时间）：浏览器向Web服务器发送请求时，需要先将域名解析为IP地址的过程所花费的时间。较小的DNS解析时间表示DNS服务器运行良好。
Connection（连接时间）：浏览器和Web服务器之间建立连接所需的时间。较小的连接时间表明网络情况良好且Web服务器能够及时响应请求。
First buffer（首次缓冲时间）：从建立连接后，Web服务器发送第一个数据包到浏览器成功接收第一个字节之间的时间。这反映了Web服务器的延迟和网络反应时间。
Receive（接收时间）：从浏览器成功接收到第一个字节到下载完成的时间段。该时间可以判断网络的质量和下载速度。

除此之外，还有其他重要的时间指标，如SSL Handshaking（SSL握手时间）、Client Time（客户端延迟时间）、Error Time（错误处理时间）和Ftp Authentication（FTP身份验证时间），它们也是评估网页性能和系统质量的关键参数。

SSL Handshaking（SSL握手时间）：指在建立安全套接字层（SSL）连接时所花费的时间。SSL握手协议用于确保通信安全，较长的SSL握手时间可能会导致网站加载速度变慢。
Client Time（客户端延迟时间）：指客户端浏览器发送请求后到服务器响应前所花费的时间。客户端延迟时间反映了客户端设备的性能和网络连接的质量。
Error Time（错误处理时间）：指从发送HTTP请求到Web服务器发送回HTTP错误信息所经过的时间。较长的错误处理时间可能表明服务器或网络出现了故障或延迟。
FTP Authentication（FTP身份验证时间）：指在客户端发送FTP请求后，服务器开始处理客户端命令之前所花费的时间。FTP身份验证时间反映了服务器处理请求的效率和安全性。

其他分析

交易成功率曲线

交易成功率曲线显示了在测试期间每秒成功完成的事务数量与总事务数量之间的比率。这个曲线可以帮助我们了解系统在不同负载下的事务成功率，以及系统在处理高负载时是否能够保持稳定的性能。

CPU使用率曲线

CPU使用率曲线显示了在测试期间服务器的CPU利用率随时间的变化情况。通过观察CPU使用率曲线，我们可以了解系统在不同负载下的CPU负荷情况，帮助评估系统的性能表现和资源利用率。

内存使用率曲线

内存使用率曲线显示了在测试期间服务器的内存利用率随时间的变化情况。通过观察内存使用率曲线，我们可以了解系统在不同负载下的内存消耗情况，以及系统是否存在内存泄漏或内存不足的问题。

网络带宽曲线

网络带宽曲线显示了在测试期间服务器的网络带宽利用率随时间的变化情况。通过观察网络带宽曲线，我们可以了解系统在不同负载下的网络通信情况，以及系统是否存在网络瓶颈或带宽不足的问题。

性能测试报告的编写

性能测试报告一般会包括如下部分：

1. 测试目标：

指标要求：明确本次性能测试的目标和预期达到的性能指标，如事务处理量（TPS）、平均响应时间（ART）、交易成功率、并发用户数等。

2. 测试概要描述：

系统结构：简要描述被测试系统的架构和组成部分。
测试时间：记录测试开始和结束的日期和时间。
测试地点和测试人员：指明测试所在的地点以及参与测试的人员。
工具和环境：列出用于测试的工具和测试环境的配置情况。
测试过程简介：概述测试过程中采取的方法和步骤。

3. 测试结果和分析：

测试场景：说明所选取的测试场景，包括负载模型、业务流程等。
测试结果：呈现性能测试的具体结果数据，如每秒事务处理量、响应时间分布、系统吞吐量等。
结果分析：对测试结果进行分析解读，发现性能瓶颈和优势，并指出可能的原因。

4. 测试结论：

遗留问题：记录在测试过程中发现的尚未解决的问题或存在的风险。
缺陷列表：列出测试中发现的系统缺陷或性能问题。
测试结论：总结性能测试的整体结果，评估系统的性能是否符合预期，并提出改进建议。

5. 建议和结果限制：

建议：提供针对性能改进的建议或优化措施。
测试结果的限制：说明测试结果的局限性，如测试环境与真实生产环境的差异等。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/小丑西瓜9/article/detail/502405

测试开发（9）性能测试工具——LoadRunner（一）：LoadRunner的安装&介绍、基本概念、开发测试脚本、创建运行场景、通过Analysis进行测试报告解读、性能测试报告的编写_性能测试loadrunner

LoadRunner简介