性能测试-loadrunner+jmeter

目录

基本概念

性能工具jemeter代码调试

loadrunner实战代码笔记

使用Loadrunner的步骤

1.插入事务transaction

2.参数化-账户密码参数化

设置集合点和并发lr_rendezvous()

定时器

设置等待时间thinktime

断言检查点

联机多机压测：

性能指标分析结果

---

基本概念

一、什么是性能：

性能：是用来描述产品除功能外的所具有的速度，效率和能力的综合能力评价。

二、什么是性能测试：

性能测试：对产品或是物品的性能进行定性或是定量的量测过程。

什么时候可以开始执行性能测试?
  功能测试通过;一般需要进行性能测试的系统，都是用户量比较大、业务使用比较频繁、比较重要的功能模块。

三、性能测试内容：

性能测试通过包括以下四个维度。

A：性能测试（PerFormance Test）：表示在给定的基准环境下，目标系统响应客户服务的最快速度或最好表现。

（如:在没有负重的情况下，你跑100米需要花多长时间？）

B：负载测试（Loading  Test）：表示在目标系统正常服务的前提下，目标系统所能承担的最大服务负荷数量（即最大并发数量），最终克分析因系统性能瓶颈。

（如:在负重50公斤，100公斤……等情况下，你跑100米需要花多少时间?）

C：压力测试（Stress  Test）：是一种破坏性测试，它故意让软件在比较少的资源环境下运行，如低内存、小硬盘、慢CPU上运行，考验程序直至程序无法运行，从而发现软件缺陷。用一句形象的话来比喻，就是让软件在饥饿状态上运行。

D：稳定性测试（Stability  Testing）:表示在给定的负载（负荷）的情况下，有外界或内部非正常的干扰，系统所能够提供稳定服务的能力。所

（如:在你负重50公斤的长跑时，不时的会刮风、下雨、有的时候还会出现坡灯情况，在这些正常非正常的条件下，我们都得跑步，但是你还能跑多长的时间？）

四、衡量性能的专业名词解释：

请求访问数量（VU或是Request Thread）：即向服务器发送请求的虚拟用户数量；

场景（Scenario）：性能测试过程中为了模拟真实用户的业务处理过程的一系列动作的集合；

事务（Transactions）:一般是指要做的或所做的事情，在关系数据库一个事务可以是一条SQL语句，一组SQL语句或整个程序。

事务应该具有4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为ACID特性；

事务平均响应时间（Average Transsction Response Time）：即在各种负载压力情况下，系统的响应时间，也就是从客户端交易发起，到服务器端交易应答返回所需要的时间(这其中包括网络传输时间和服务器处理时间)，每一事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向；

每秒处理事务（Transsction per Second）:每秒系统处理事务（通过、失败以及停止）的数量。通过这项目指标可以确定系统在任何给定的时间段里事务处理能力；

吞吐率（Throughput）：即应用系统在单位时间内完成的交易量，也就是在单位时间内，应用系统针对不同的负载压力，所能完成的交易数量；

系统负载（Load）：即系统所能容忍的最大用户并发数量，也就是在正常的响应时间中，系统能够支持的最多的客户端的数量；（TIPS：关于 用户并发量：个人的观点是，应用系统所能支持最大的在线用户量。）

CPU利用率(CPU usage)：CPU利用率分为用户态，系统态和空闲态，分别表示CPU处于用户态执行的时间，系统内核执行的时间，和空闲系统进程执行的时间，平时所说的CPU利用率是指：CPU执行非系统空闲进程的时间/CPU的总执行时间。

最佳用户数：系统的最佳状态，即系统在当前资源配置下（服务器资源，客户端资源，网络资源）所能处理的最大用户事务数量；对系统资料的占用率，系统的处理能力，用户等待的响应时间都处于最优的配置下。

最大用户数：依据系统当前的配置（包括硬件配置，网络资源），所能容纳的最大用户数量，超过这个额定的用户，系统的处理能力可能就要达到一个瓶颈了。
作者：胡溪玥
链接：https://www.jianshu.com/p/fcd83e913947
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

性能工具jemeter代码调试

loadrunner实战代码笔记

使用Loadrunner的步骤

制定性能测试计划—>开发测试脚本—>设计测试场景—>执行测试场景—>监控测试场景—>分析测试结果

1.插入事务transaction

  由于LR是以事务为单位统计性能指标所以插入事务把功能分为若干部分可以对不同的事务分别作统计。
    单击某个功能起始前的空白处右键鼠标–> insert–> start transaction–> 命名–> OK。系统自动在脚本语句中插入如下语句:
    lr_start_transaction(“登录”);
  插入事务结束点：
    单击某个功能结束后的空白处右键鼠标–> insert–> end transaction–> 命名（与起始点的名字一致）–>OK。系统自动在脚本语句中插入如下语句:
    lr_end_transaction(“登录”,LR_AUTO);

2.参数化-账户密码参数化

设置集合点和并发lr_rendezvous()

定时器

设置等待时间lr_think_time

断言检查点

联机多机压测：见http://t.csdn.cn/HeY0i

1.负载机安装了loadrunner中完整的.net程序并安装 LOAD GENERATOR 并启动 LOADRUNNER AGENT PROCESS 进程，控制机安装loadrunner之后其中controller可以调度负载机实现集群压测

2.负载机和控制机都使用静态IP（不静态不允许打开IP wizard）保持在同一网段并且关闭防火墙，保持controller和各加压机之间通讯正常

3.回访-运行时设置-常规-其他，采用进程设置，与线程区别见LoadRunner中进程运行和线程运行区别 - Agoly - 博客园

4.使用管理员权限启动ip wizard，用于实现IP欺诈，添加IPhttp://t.csdn.cn/ldFaf

5.控制机的controller中新建场景选择手动场景-使用百分比，否则只能添加一个负载机IP

性能指标分析结果

1、事物响应时间和虚拟用户数关联：当随着用户数的增加，响应时间应该随着上下波动，但是如果事物相应时间有严重波动需要分析问题所在处

　　2、每秒错误数：如果在某个时间段内错误数量增加，那么需要观看此时间段的其他指标变化

　　3、平均事物响应时间：平均事物响应时间随着时间、用户数的波动而波动，如果在某个时间段响应时间变慢但是马上又变快了，说明可能是服务器处理能力强，也可能是处理能力差出现大量错误。如果没波动取平均响应时间，如果波动大取90percent time

　　4、每秒通过事务数：tps越高说明系统处理能力强，主要看走势图。如果出现平缓那么服务器可能出问题了，如果在某个时间段内 失败事物数增加，成功事物数减少说明系统瓶颈有问题

　　5、每秒点击数：

　　（1、和平均事物响应时间）：如果点击数减少，请求变少，但是响应时间却增加，或者是请求数量增加但是响应时间变少，可能是网络问题。

　　（2、和吞吐量）：如果点击数增多，流量肯定该增大，如果点击数增多，但是吞吐量减少等不正常，有可能是服务器处理能力降低造成的。

　　（3、每秒点击数和每秒事物数）：如果hps和tps的曲线出现平缓或者平坦，服务器响应时间增加，如果请求减少，而通过的事物数增加，或者请求数量增加而通过事物数减少那么服务器存在瓶颈

　　6、吞吐量：如果吞吐量比较平 那么宽带有瓶颈，吞吐量和tps图基本一致，如果平了说明网络瓶颈了。

　　7、每秒http响应数：一般都是和hps关联，如果客户端发送了n请求，但是http却不够，说明服务器无法应答

　　8、连接数（connection）：每个时间点打开的tcp/ip的连接数

　　9、每秒连接数（connection per second）：方便了解每秒对服务器产生的连接数，如果同时连接数越多，那么说明服务器的连接池越大，如果随着负载增加，而连接数停止时那么连接池已满，这时会反回504

1、TPS标准差/TPS Average>8%,或者<2%则系统存在性能瓶颈

2、当增大系统的压力(或增加并发用户数)时，吞吐率和TPS的变化曲线呈正比变化，则系统基本稳定

3、若压力增大时，吞吐率的曲线增加到一定程度后出现变化缓慢，甚至平坦，同时TPS也趋于平坦，查看系统资源使用，如果资源使用率比较高，则说明服务器硬件资源存在问题，需要拓展硬件或者优化应用。反之，则说明服务器硬件资源不存在问题，查看网络流量，估计网络带宽存在问题。

4、点击率/TPS曲线出现变化缓慢或者平坦,很可能是服务器响应时间增加，观察服务器资源使用情况，确定是否是服务器问题或者应用问题

1、Transation Sunmmary（事务综述）
对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。

2、Average Transaciton Response Time（事务平均响应时间）
“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。
例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。

3、Transactions per Second（每秒通过事务数/TPS）
“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。
将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。
例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。

4、Total Transactions per Second（每秒通过事务总数）
“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。

5、Transaction Performance Sunmmary（事务性能摘要）
“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。
重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。

6、Transaction Response Time Under Load（事务响应时间与负载）
“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。

7、Transaction Response Time(Percentile)（事务响应时间(百分比)）
“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。

8、Transaction Response Time(Distribution)（事务响应时间(分布)）
“事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。

Web Resources（Web资源分析）
Web资源分析是从服务器入手对Web服务器的性能分析。

1、Hits per Second（每秒点击次数）
“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。
通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。

2、Throughput（吞吐率）
“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。
可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
“吞吐率”图和“点击率”图的区别：
“吞吐率”图，是每秒服务器处理的HTTP申请数。
“点击率”图，是客户端每秒从服务器获得的总数据量。

3、HTTP Status Code Summary（HTTP状态代码概要）
“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数，该图按照代码分组。HTTP状态代码表示HTTP请求的状态。

4、HTTP Responses per Second（每秒HTTP响应数）
“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。

5、Pages Downloader per Second（每秒下载页面数）
“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser生成的负载量。
和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。但是吞吐量考虑的各个资源极其大小（例，每个GIF文件的大小、每个网页的大小）。而每秒下载页面数只考虑页面数。
注：要查看每秒下载页数图，必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。

6、Retries per Second（每秒重试次数）
“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。
在下列情况将重试服务器连接：
A、初始连接未经授权
B、要求代理服务器身份验证
C、服务器关闭了初始连接
D、初始连接无法连接到服务器
E、服务器最初无法解析负载生成器的IP地址

7、Retries Summary（重试次数概要）
“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数，它按照重试原因分组。将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。

8、Connections（连接数）
“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。
借助此图，可以知道何时需要添加其他连接。
例：当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。

9、Connections Per Second（每秒连接数）
“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。
理想情况下，很多HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。

10、SSLs Per Second（每秒SSL连接数）
“每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。当对安全服务器打开TCP/IP连接后，浏览器将打开SSL连接。

Web Page Breakdown（网页元素细分）
“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的
元素。

1、Web Page Breakdown（页面分解总图）
“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。
“页面分解”图可以按下面四种方式进行进一步细分：
1)、Download Time Breaddown（下载时间细分）
“下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。
2)、Component Breakdown(Over Time)（组件细分(随时间变化)）
“组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。
3)、Download Time Breakdown(Over Time)（下载时间细分(随时间变化)）
“下载时间细分(随时间变化)” 图显示选定网页的页面元素下载时间细分（随时间变化）情况，它非常清晰地显示了页面各个元素在压力测试过程中的下载情况。
“下载时间细分”图显示的是整个测试过程页面元素响应的时间统计分析结果，“下载时间细分(随时间变化)”显示的事场景运行过程中每一秒内页面元素响应时间的统计结果，两者分别从宏观和微观角度来分析页面元素的下载时间。
4)、Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）
“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一次缓冲之前的这段时间，场景或会话步骤运行的每一秒中每个网页组件的服务器时间和网络时间（以秒为单位）。可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。
First Buffer Time：是指客户端与服务器端建立连接后，从服务器发送第一个数据包开始计时，数据经过网络传送到客户端，到浏览器接收到第一个缓冲所用的时间。

2、Page Component Breakdown（页面组件细分）
“页面组件细分”图显示每个网页及其组件的平均下载时间（以秒为单位）。可以根据下载组件所用的平均秒数对图列进行排序，通过它有助于隔离有问题的组件。

3、Page Component Breakdown(Over Time)（页面组件分解(随时间变化)）
“页面组件分解(随时间变化)”图显示在方案运行期间的每一秒内每个网页及其组件的平均响应时间 （以秒为单位）。

4、Page Download Time Breakdown（页面下载时间细分）
“页面下载时间细分”图显示每个页面组件下载时间的细分，可以根据它确定在网页下载期间事务响应时间缓慢是由网络错误引起还是由服务器错误引起。
“页面下载时间细分”图根据DNS解析时间、连接时间、第一次缓冲时间、SSL握手时间、接收时间、FTP验证时间、客户端时间和错误时间来对每个组件的下载过程进行细分。

5、Page Download Time Breakdown(Over Time)（页面下载时间细分(随时间变化)）
“页面下载时间细分(随时间变化)”图显示方案运行期间，每一秒内每个页面组件下载时间的细分。使用此图可以确定网络或服务器在方案执行期间哪一时间点发生了问题。
“页面组件细分(随时间变化)”图和“页面下载时间细分(随时间变化)”图通常结合起来进行分析：首先确定有问题的组件，然后分析它们的下载过程，进而定位原因在哪里。

6、Time to First Buffer Breakdown（第一次缓冲时间细分）
“第一次缓冲时间细分”图显示成功收到从Web服务器返回的第一次缓冲之前的这一段时间内的每个页面组件的相关服务器/网路时间。如果组件的下载时间很长，则可以使用此图确定产生的问题与服务器有关还是与网络有关。
网络时间：定义为第一个HTTP请求那一刻开始，直到确认为止所经过的平均时间。
服务器时间：定义为从收到初始HTTP请求确认开始，直到成功收到来自Web服务器的一次缓冲为止所经过的平均时间。

7、Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）
“第一次缓冲时间细分(随时间变化)”图显示成功收到从Web服务器返回的第一个缓冲之前的这段时间内，场景运行的每一秒中每个网页组件的服务器时间和网络时间。可以使用此图确定场景运行期间服务器或网络出现问题的时间点。

8、Downloader Component Size(KB)（已下载组件大小）
“已下载组件大小”图显示每个已经下载的网页组建的大小。通过它可以直接看出哪些组件比较大并需要进一步进行优化以提高性能。