LoadRunner测试SQL语句性能

LoadRunner测试SQL语句性能（精选4篇）

篇1：LoadRunner测试SQL语句性能

loadRunner性能测试 1.什么是性能测试

软件的功能：对一个软件基本功能能够实现，比如：银行卡能够正常转账成功（用户数=1）软件的性能：要求软件性能更好，一般关注多用户的使用情况，软件的响应时间。响应时间例子：登录一个软件，点击“登录”按钮时，多久能够显示成功登录的页面。

性能问题: 1． 每秒平均浏览量：2200次/秒

浏览量（PV，Page View）：即页面访问量或点击量，用户每次刷新即被计算一次 购票申请：20万张/秒以上

自身设计浏览量100万次/小时 浏览量280次/秒

2.响应时间的358原则：

3秒之内，客户比较满意 5秒之内，客户可以接受 8秒之内，客户可以忍受 大于8秒，无法忍受

3.一般进行性能测试之前，要对系统尤其是数据库进行备份

负载测试是一种

正常 的测试（在正常测试的指标下测出最大的负载量）

指标或者某种资源达到某种指标，比如响应时间达到多少，比如CPU负载100%等

压力测试和负载测试二者的区别：

负载测试强调系统在正常工作情况下的性能指标

压力测试的目的是发现在什么条件下系统的性能变得不可接受，发现应用程序性能下降的拐点

影响系统性能的主要因素

（1）硬件： CPU,内存，硬盘，网卡及其他网络设备【最好解决】（2）操作系统（3）网络

（4）中间件（又叫应用服务器），web服务器（5）数据库服务器（6）客户端

（7）变成语言，程序实现方式，算法【最难解决】

客户端=服务端（Web服务器）=应用服务器=数据库服务器

性能测试主要关心两个部分：web服务器和应用服务器。客户端向服务器发送请求

服务器端向客户端返回应答（响应response）

性能测试的常用术语： 并发（Concurrency）：所有用户在同一时刻（一个时间点，可以精确到毫秒级）做同一件事情或操作，一般针对同一类型的业务

例如：在信用卡审批业务中，一定数目的用户在同一时刻对已经完成的审批业务进行提交 做并发的测试就称为“并发测试”。【发测试不包含睡眠时间】 在线（OnLine）：多用户在一段时间内对系统执行操作【包含睡眠时间】

并发测试与在线测试对系统的压力不同，一般来讲并发测试的压力和在线测试的压力的比值是10:1。例如：200用户并发测试相当于2000用户在线测试。

并发测试一定是多用户。

请求响应时间

指从客户端发送一个请求开始计时，到客户端接到从服务器端返回的响应结果计时结束。在一些工具中，请求响应时间通常被称为TTLB 即“Time to Last Byte”，意思是从开始发送第一个请求开始，到客户端收到最后一个字节的响应为止所耗费的时间。请求响应时间的单位一般为“秒”或者“毫秒”

再复杂的响应时间都可以分为3段：请求的响应时间=客户端的响应时间+网络的响应时间+服务器的响应时间

一般测试放在内网里，带宽，网络不会成为瓶颈。只用分析客户端的响应问题和服务器的响应问题。一般客户端的响应很少有问题，一般只分析服务器响应问题即可。

事务响应时间：用户完成某个具体事务（如跨行取款事务）所需要的时间。事务可能包含多个请求。比如点击“登录”按钮，到登录进页面。

事务的响应时间和请求响应时间的区别？

一个事务包含一个或多个请求（一般，一个请求指的是一个http请求）。

点击率：

每秒钟用户向web服务器提交的http请求数。---点击率越大，对服务器的压力也越大

---注意：点击不是指鼠标的一次“单击”操作。因为在一次“单击”操作中，客户端可能向服务器发出多个HTTP请求（比如跳转页面需要更新展示图片等）。

点击量的计算：假如单击“登录”按钮，请求一个页面登录后的欢迎页面中包含3个图片，则每个图片都需要重新发送一个http请求，所以，单击鼠标一次产生的http请求总数为4=1（登录请求）+3（图片请求）点击率=点击量/时间

吞吐量：

用户在任意给定一秒从服务器端获得的全部数据量，单位是字节 吞吐量/传输时间=吞吐率

吞吐率很重要，反应了服务器的处理速度和性能，也是衡量网络性能的重要指标。TPS（事务数/秒）

在性能测试过程中，要监控服务器系统的各项资源情况，比如：CPU，内存，磁盘及网络等情况。

吞吐率和点击率的区别：

吞吐率：指服务器每秒处理的数据量。反应了服务器的处理能力，吞吐率越大，服务器处理能力越强。

点击率：客户端每秒向服务器发送请求的数量。反应了服务器的压力，点击率越大，服务器的压力越大

吞吐率受点击率影响，也受服务器性能的限制。

完美的吞吐率是：在带宽充足的情况下，吞吐率随着点击率的增加而增加。

资源利用率

指对不同的资源系统的使用程度，包括web服务器，操作系统，数据库服务器，网络，硬件，是测试和分析瓶颈的主要参数

-如：服务器cpu利用率，磁盘利用率等

它是分析系统性能指标进而改善性能的主要依据，因此是web性能测试工作的重点。

性能测试的策略（即方法）：重点测试方法：基准测试，并发测试，综合场景测试，疲劳强度测试，极限测试，递增测试

基准测试：一般做的是单用户测试（Benchmark Testing）

----指测试环境确定以后，对业务模型中涉及的重要业务做单独的测试。

----目的是获取单用户执行时的各项性能指标，为多用户并发和综合场景等性能测试分析提供参考依据。

并发测试：就是多用户的并发测试某个测试点。并发测试对系统要求比较严格，因为要模拟一个瞬间压力。并且要忽略系统的睡眠时间（思考时间）。

递增测试：

A）指每隔一定时间段（如5秒，10秒）加载不同数目的虚拟用户执行测试点操作，对测试点进行递增用户压力加载测试。原因：所有用户（5000）共同登陆可能会导致系统压力过大，进而影响到后面关心的测试点（buy）的性能，导致关心的测试点结果不准确，所以采取递增，分散一下前面的压力，使系统关心的测试点能够正常的测试。（这里是递增着登陆）B）测试一个测试点（如：购票），先测试单用户，再测试20用户，40用户等情况，有利于分析，也称为递增测试。（这里是递增着全套测试）

综合场景测试【重难点】：

通过对系统结构和功能的分析，对用户的分布和使用频率的分析，来构造系统综合场景的测试模型，模拟不同用户执行不同操作。

如10%的用户执行浏览首页，50%的用户执行查询订单，40%的用户执行订购机票，最大限度地模拟系统的真实场景，使用户预知系统投入使用后的性能水平。没特别指明的话，一般都是指在线的。

Login不适合放在综合场景中运行。

综合场景：号称能最真实的模拟实际的生产环境。如测试时间为50分钟，则综合场景中的每个脚本都是在循环执行。所以综合场景中不宜加入login测试点，因为不能真实模拟实际的生产环境。

疲劳强度测试：是一种特殊的强度测试（压力测试）。指在一定的压力下（如：相同的用户数）长时间（疲劳）对系统进行测试，并监控服务器的各项资源情况。如：7x24小时,24小时（如移动电信银行的服务器）。测试其服务器的稳定性：指长时间的运行过程中，系统的各项资源及时间等指标表现是否正常。

内存泄露：系统的服务器内存都被占用，而没有释放。导致系统没有可用内存。

内存泄露测试：通过LR监控时查看具体的几项指标，或者通过其它的专门内存泄露检测工具测试。

数据容量测试：查看系统服务器能否实现大数量下使用情况，系统的各项资源表现情况。如：200G，或者3个T。

极限测试：也叫“摸高测试”，测试系统的极限，如系统最大能承受的用户数，吞吐量等。

虚拟用户：Virtual Users 控制台：Controller 分析工具：Analysis

LoadRunner的三大组件：

虚拟用户脚本生成器（Virtual User Generator）---Creat/Edit Scripts【Generator：生成器】 压力调度控制台（Controller）---Run Load Tests 压力结果分析器（Analysis）---Analyze Test Results

QTP（功能自动化的工具）和LR（性能测试工具）的区别： QTP关心的是功能方面，LR关心的是性能方面。

QTP关心界面的控件属性（对象，对象的属性，属性值等）等，LR关心的是客户端和服务器之间往来的数据包。

LR的工作原理：

录制时，LR记录客户端和服务器二者之间的所有对话（数据包），形成脚本，回放时，LR模拟真实的客户端，向服务器发送请求。并验证服务器的响应。

LR是怎么记录下数据包的：（1）基于局域网的广播原理。【这种用的很少】（2）基于一种嗅探原理sniffer。【目前在用的方式】

虚拟用户脚本生成器：是用来生成脚本的

LR的常用术语：

虚拟用户（Virtual User 【简称VU】）：在场景中，loadRUnner用VU代替实际用户。Vuser模拟实际用户执行操作。一个场景可以包含几十，几百甚至几千个Vuser。（每个虚拟用户是一个进程或者线程，一般用的是线程）

Vuser脚本（Virtual User Script）：用于描述VU在场景中执行的操作。（记录的客户端发送的请求。）

事物（Transaction）：为度量服务器的性能，需要定义事务。事务表示要度量的最终用户业务流程或操作。

为何要定义事务：因为脚本中将关心的操作（如购票）定义为一个事务，则结果报告中（analysis）就会返回事务的响应时间。不关心的操作就不需要定义成事务。

场景（Scenario）：场景是一种文件，用于根据性能要求定义在每一个测试回话运行期间发生的事件。模拟真实环境中，用户运行的情况。【将脚本放到控制台去运行（包括设置各种参数）】

综合场景：将不同的脚本，至少3个放到控制台去共同运行一段时间。具体定义见PPT。

测试注意：

----设置IE（清楚浏览器缓存）：进入工具Internet选项常规设置每次访问此页面时检查

----LR中修改参数：进入ControllerRunTime SettingTnternet Protocol Proxy，选择No Proxy。

Jojo /bean

LR基本测试流程：

制定性能测试计划（部分）创建测试脚本编译，运行测试脚本【VUG】创建场景运行，监控场景，收集数据【Con 控制台】生成测试报告，分析测试结果【analysis】

最好用英文命名

小技巧： 弹出结果

日志文件

Transaction 事务

将一个操作设置成事务的目的：获取操作的响应时间（在analysis报告里）

在带宽充足的情况下，完美的吞吐率应该随着点击率的升高而升高。反过来，当服务器压力过大服务器处理能力不足时，吞吐率会随着点击率的增高而保持恒定或者降低，那么点击率也会受到相应影响而变慢。

即吞吐率和点击率是相互影响的。

脚本生成器可以模拟1个用户，多用户一定要用控制台来实现。（控制台就是来生成管理多用户的。）

基准测试是单用户测试，可用脚本生成器（生成的调试结果是没有响应时间的），但是也还是需要控制台。因为结果要写到报告里。（结果生成器analysis得出单用户测试的结果，比如响应时间等等）

疲劳测试和综合场景测试的区别就是时间的长短，疲劳测试运行的时间会长一些。

只要业务逻辑不变（操作不变），则不需要重新调试脚本，回归测试中可以直接利用原来脚本。

调试脚本时请频繁保存副本，因为LR回退键效果不是很好。

脚本必须现在脚本生成器进行运行，执行通过将脚本放入控制台，在控制台执行完毕后生成结果报告

总的吞吐率

服务水平等级协议

报告中事务响应时间的标准方差值：越趋近于0，说明系统越稳定（每一项事务的响应时间非常相似）

90percent：表示90%的事务都可以在该响应时间内完成。代表一个大多数情况。

HTTP状态码： 200表示成功

4XX表示客户端的失败 5XX表示服务器的失败

当场景设定的duration时间结束时，所有的虚拟用户需要运行完当前的transaction以及action再结束。

基准测试执行方法

单用户执行脚本操作1分钟 单用户执行脚本操作5次

B/S脚本必须要有登陆，有退出（否则假退出其实链接还没断开，会影响测试结果）

Replay log：脚本执行日志 Recording log：录制时的日志

Generation log：所有客户端和服务器二者之间的对话

快捷键：

ctrl+G

Go to Line 跳到某一行

跳到对应的日志

基准测试：单用户测试。3.4 1.7 1.8 1.6 为了规避第一次测试的不准确性，则有两种测试方法：（1）设置循环5次（N次）

Run-time Setting 循环5次，或者持续运行1分钟。（取平均值）Run logic：循环次数----设置为5 Pacing：两次循环之间的步长值（时间间隔）----随机值2-4秒 Think time：ignore（忽略思考时间），因为对结果没什么影响

Pacing：步长值，为了更真实的模拟环境（断开连接，释放资源），一般选随机值

基准测试单用户对服务器压力不大，一般可以ignore think time。

监控资源：监控服务器的资源

客户端的资源：自己随时把握一下，不要成为测试的瓶颈即可。

（2）持续运行1分钟

当duration和run_time setting中循环（run logic）都有值的话，duration的优先级比较高【二者循环的位置都为action】 Run logic：循环次数----设置为1

Pacing：步长值，为了更真实的模拟环境（断开连接，释放资源），一般选随机值 基准测试单用户对服务器压力不大，一般可以ignore think time。监控资源：监控服务器的资源

客户端的资源：自己随时把握一下，不要成为测试的瓶颈即可。

并发测试执行方法： 脚本添加集合点

在控制台设置并发策略

注意：refresh中有两个选择，看情况使用。

脚本和控制台的run-time setting都设置的话，哪个优先级高？控制台的优先级高！脚本中的run-time setting 何时使用？运行脚本的时候使用

并发测试有两个步骤：

1）脚本中加并发点（即集合点）

2）在控制台设置：5个虚拟用户（VU），可以设置递增（不设也可），设置并发策略。

Run-time Setting---忽略休息时间，因为需要瞬间压力。

篇2：LoadRunner测试SQL语句性能

LoadRunner压力测试+Windows计数器，这种方法主要是找出大概的性能问题是在哪台服务器，主要是哪个资源紧张。

 ANTS Profiler+SQL Server Profiler，这两个工具的完美搭配可以准确的定位性能是出在哪个函数，哪个SQL语句上。

如果性能问题是出在程序上，那么就要根据业务对程序中的函数进行调整，可能是函数中的写法有问题，算法有问题，这种调整如果不能解决问题的话，那么 就要从架构上进行考虑，我们是不是应该使用这种技术，有没有替代的方案来实现同样的业务功能？举个简单的例子，假设经过跟踪发现，一个负责生成图表的函数 存在性能问题，尤其是在压力测试情况下性能问题尤为严重。原来的图表生成是完全基于GDI+在Web服务器上根据数据进行复杂的绘图，然后将绘出的图片保 存在磁盘上，然后在HTML中添加Img标签来引用图片的地址。现在使用GDI+会消耗大量内存和CPU，而算法上也没有太大的问题，那么这种情况下我们 就需要考虑修改架构，不使用GDI+ 绘图的方式，或者是使用异步绘图的方式。既然绘图会消耗大量的服务器资源，那么一种解决办法就是将绘图的操作从服务器转移到客户端。使用 SilverLight技术，在用户打开网页是只是下载了一个SilverLight文件，该文件负责调用Web服务器的Web服务，将绘图所需的数据获 取下来，然后在客户端绘图展现出来。这样服务器只提供WebService的数据访问接口，不需要做绘图操作。

.net上的优化我暂时不表，今天主要讲数据库的优化。使用ANTS Profiler+SQL Server Profiler我们可以精确定位某个业务操作对应的数据库脚本或者存储过程。ANTS Profiler告诉我们一个方法在调用的时候花了10秒的时间，那么我们就可以使用VS打开源代码，找到该放入，然后找到对应调用的存储过程，这里也许 一个方法里面调用了多个数据层方法，调用了多个存储过程。将调用的这些存储过程记下了，然后在SQL Server Provider的跟踪文件里面去找调用该存储过程花费的Duration。

据的时间

一般企业应用或小型应用中数据库服务器和Web服务器要不是就在同一个机房，同一个局域网，或者干脆是同一台机器，这种情况下网络传输速度是很快 的，所以我们不考虑网络传送上面的时间。那么就得出：的存储过程的Duration)

代码中的时间得到了，SQL Server中的时间（也就是Duration字段）得到了，那么就可以判断出打开该页面各个服务器所花费的时间，从而找到我们要优化的方向，是存储过程 还是C#代码。如果是存储过程，那么通过查询SQL Server Profiler中内容可以找到具体是哪一个存储过程消耗的时间最长。

“射人先射马，擒贼先擒王。”多个存储过程被调用，如果性能出在数据库服务器上，那么进行性能优化时首先要调优的是最大Duration最大的存储 过程，另外还有就是Reads很大的存储过程。如果Duration很大但是Reads和Writes都不算特别大，那么有可能是以下原因：

1.这个存储过程相关的资源正在被其他事务占用，也就是说该存储过程被阻塞所以才花了那么多时间。这种情况只需要把该存储过程提出，多执行几 次，看是不是仍然Duration很大但Reads不大。

2.存储过程本身很复杂，里面的T-SQL语句就是五六百行，编译出的执行计划也是一堆，里面进行了大量的逻辑判断、大量函数的调用，这种情 况下进行调优就比较痛苦了。实际上这次我调优的这个项目就是如此，抓取出来的存储过程尽是复杂的逻辑，少则两三百行代码，多则五六百行，里面还有大量的用 户定义函数的调用。对于这种存储过程，我接下来会专门写篇博客介绍下我们这个项目是如何调优的。

3.程序读取的数据不多，但是需要对数据进行大量的运算。哈希联接、聚合函数、DISTINCT、UNION等都是比较耗CPU的。如果是这 种情况那就看能不能建立索引或者改写法进行调优。

前面说的是Duration大而Reads小的情况，当然更常见的情况是Duration和Reads都很大。那么我们就将主要精力集中在如何减小 Reads上。造成Reads很多的原因大概有以下几种：

1.没有建立相应的索引。对表t1进行查询，条件是where c2=abc返回c1,c2,c3三个字段，那么这种情况下如果没有对c2建立非聚集索引（c1是主键，建立了聚集索引），那么这个查询将会进行“聚集索 引扫描”，本来可能只查出几条记录的，结果要把表的所有记录都扫描一篇，自然Reads就高了。解决办法就是建立相应的索引，比如这里只需要对c2字段建 立非聚集索引，然后将c3字段作为包行列就行了。如果只是最c2字段建立非聚集索引，那么前面说到的查找在进行了“非聚集索引查找”后还会进行“键查找” 来找到c3列的值，所以要建立的正确的索引才行。

2.不符合SARG原则。查询如果不符合SARG原则，那么即使建立了索引也没法使用。SARG就是查询参数的意思，具体怎么写才符合 SARG，大家可以百度，已经有很多相关文章了，我就不累述。

3.涉及的业务数据量大。也就是说即使建立了正确的索引，查询也符合SARG使用到了该索引，但是由于涉及的数据量太大了，所以Reads仍 然很大。这种情况就不能再从索引和查询入手，而只能从数据库的设计入手。是否能够增加适当的冗余字段，对数据库进行反范式化，或者如果数据的实时性要

求不 高的话则可以建立中间汇总表，使用SQL作业来维护这个中间汇总表，查询的时候只查询该中间汇总表即可。或者是否可以建立索引视图或者计算列，然后在计算 列中建立索引的方式进行一个预运算，减小实际查询时涉及的数据量。

4.使用了不当的视图。如果对视图的定义很复杂，涉及的表很多，在查询的时候使用了该视图，但是实际上只用到了视图中的一张或两张表，对视图 的查询会造成系统根据视图定义查询其他与该查询不相关的表。所以在使用视图的时候一定要知道视图的定义，不用贪图一时的方便而随便使用视图。

5.不正确的使用了用户定义函数。一个存储过程中几百行代码，出于编写方便，大量的调用了一个用户定义表值函数，而该函数是进行了复杂的查询 和运算才返回结果的。如果数次或者数十次的调用该用户定义表值函数，那么就会进行很多这种复杂的查询和运算，自然Reads也就很大了。解决办法是尽量减 少对这种复制函数的调用，比如一次调用后就将解决保存在表变量或临时表中，接下来再使用的话就使用该表变量或临时表即可。

篇3：LoadRunner测试SQL语句性能

目前对性能测试没有明确的定义,它主要是针对系统的性能指标制定性能测试方案,执行测试用例,得出测试结果来验证系统的性能指标是否满足既定值。性能指标里可能包括系统各个方面的能力,如系统并发处理能力,批量业务处理能力,数据库机制等。

性能测试包括负载测试、压力测试和容量测试。

压力测试(Stress Test)是通过不断向被测系统施加“压力”,测试系统在压力情况下的性能表现,是一种性能测试指数据在超负荷环境中运行,程序是否能够承担。

负载测试(Load Test)是为了检验系统在给定负载下是否能达到预期性能指标。

容量测试(Capability Test)是针对数据库而言,是在数据库中有较大数量的数据记录情况下对系统进行的测试,确定系统可处理同时在线的最大用户数。

2 Load Runner介绍

Load Runner是一种预测系统行为和性能的负载测试工具。通过模拟上千万用户实施并发负载及实时性能检测来确认和查找问题,能够对整个企业架构进行测试。通过使用Load Runner,企业能够最大限度的缩短测试时间,优化性能和加速应用系统的发布周期。Load Runner能支持广泛的协议和技术,功能比较强大,可以为特殊环境提供特殊的解决方案。Load Runner由下面三部分组成:Virtual User Generator用来录制脚本、编辑脚本;Controller用来布置测试场景、执行测试场景;Analysis用来对测试结果进行分析。

用Load Runner进行负载测试的流程通常由五个阶段组成:计划、脚本创建、场景定义、场景执行、监视执行和结果分析。

1)计划负载测试:定义性能测试要求,例如并发用户数量、业务流程和所需响应时间;

2)创建Vuser脚本:将最终用户活动捕获到自动脚本中;

3)定义场景:使用Load Runner Controller设置测试环境;

4)运行场景:通过Load Runner Controller驱动、管理测试;

5)监视场景:通过Load Runner Controller监控测试;

6)分析结果:使用Load Runner Analysis创建图和报告并评估性能。

3 Vu Gen脚本开发

Load Runner可以模拟一个数千用户同时使用客户端/服务器系统的环境。为执行此操作,Load Runner用“虚拟用户(Vuser)”代替实际用户。Vuser执行的操作是用Vuser脚本描述的。Load Runner提供各种帮助来开发Vuser脚本的工具。

Load Runner提供了多种Vuser技术,通过这些技术可以在使用不同类型的客户端/服务器体系结构时生成服务器负载。每种Vuser技术都适合于特定体系结构并产生特定的Vuser类型。例如,可以使用Web Vuser模拟用户操作Web浏览器、使用Tuxedo Vuser模拟Tuxedo客户端与Tuxedo应用程序服务器之间的通信、使用RTE Vuser操作终端仿真器。各种Vuser技术既可单独使用,又可一起使用,以创建有效的负载测试方案。

Vuser脚本的结构和内容因Vuser类型的不同而不同。例如,数据库Vuser脚本总是包含三部分,是在一段类似C语言并且包括对数据库服务器的SQL调用的代码中编写的。相反,GUI Vuser脚本只有一个部分,并且是用TSL(测试脚本语言)编写的。

开发Vuser脚本的过程开始于录制一个基本的脚本。Load Runner为您提供了大量录制Vuser脚本的工具。您可以通过将控制流结构和其他Load Runner API添加到脚本中来增强该基本脚本。然后配置运行时设置。运行时设置包括迭代、日志和计时信息,以及定义Vuser在执行Vuser脚本时的行为。要验证脚本是否能正确运行,请以单独模式运行该脚本。如果脚本运行正确,则将其合并到Load Runner方案中。录制业务流程时,Vu Gen生成一个由函数构成的Vuser脚本。函数中参数的值是录制期间使用的实际值。

每个Vuser脚本都至少包含三部分:vuser_init、一个或多个Actions及vuser_end。录制前和录制期间,可以选择脚本中Vu Gen要插入已录制函数的部分。下表显示了要在每一部分录制的内容以及执行每一部分的时间。

运行多次迭代的Vuser脚本时,只有脚本的Actions部分重复,而vuser_init和vuser_end部分将不重复。可以使用Vu Gen脚本编辑器来显示并编辑每个脚本部分的内容。但一次只能显示一个部分的内容。要显示某一部分,请在左窗格中突出显示该部分的名称。

在处理使用Java类的Vuser脚本时,可以将所有代码都置于Actions类中。Actions类包含三个方法:init、action和end。这些方法对应于脚本中使用其他协议开发的部分,您可以在init方法中插入初始化例程、在action方法中插入客户端操作,并在end方法中插入注销过程。

4 Controller测试方案设计

4.1 方案开始时间

打开“延迟方案开始时间”对话框,可以在其中延迟方案的开始时间。按方案定义计划,定义整个方案的设置->“加压”选项卡->“持续时间”选项卡->“减压”选项卡->按组计划:定义各个组的设置。从左侧的框中,选择要计划的Vuser组->“开始时间”选项卡->“加压”选项卡->“持续时间”选项卡->“减压”选项卡。

4.2 计划方案,使用计划生成器,可以通过下列方式控制方案的执行

限制方案持续时间->在方案中逐渐运行Vuser->在方案中逐渐停止Vuser。要为方案设置计划选项,请执行下列操作:

1)选择“按方案计划”选项。

2)要确定方案开始的方式,请单击“加压”选项卡。选择下列选项之一:

a同时加载所有的Vuser:同时启动方案中的所有Vuser;

b启动X个Vuser,每X(时W分W秒):同时开始运行指定数目的Vuser,并在两次Vuser加压之间等待指定的时间。

注意:方案运行时,您可以在方案中添加Vuser组/脚本,然后启用它们。在逐渐加压模式下,如果在方案中的所有Vuser都加压之后添加Vuser组/脚本,则新的组/脚本将立即开始加载。

3)要指示Load Runner在开始加载Vuser之前对它们进行初始化,请选中“加压之前初始化所有的Vuser”。注意,Load Runner仅在Vuser全部达到“就绪”状态后才加载它们。

4)要设置方案的持续时间,请单击“持续时间”选项卡。

选择下列选项之一:

a运行直到完成;

b在加压完成之后运行X(时W分W秒):所有Vuser都已加压之后,再运行方案一段指定的时间;

c无限期运行。

5)要确定方案停止的方式,请单击“减压”选项卡。

选择下列选项之一:

a同时停止所有的Vuser:同时停止方案中的所有Vuser;

b停止X个Vuser,每=u(时W分W秒):在指定的时间段内停止一定数目的Vuser。

6)单击“确定”关闭计划生成器并保存设置。

4.3 控制器设置

使用联机监视器可以监视Vuser状态、错误、事务、系统资源、Web资源、网络延迟、防火墙服务器资源、Web服务器资源、Web应用程序服务器资源、数据库服务器资源、流媒体资源、ERP/CRM服务器资源、Java性能、应用程序部署和中间件性能监视器。要启动联机监视器,请执行下列操作:

1)启动方案。选择要运行的Vuser组,再单击“开始方案”按钮或选择“方案”->“启动”;

2)单击“运行”选项卡。“方案组”窗格下将显示默认图;

3)双击该图,使其最大化。再次执行该操作可以还原为平铺视图;

4)如果不显示图树,请选择“视图”>“显示可用图”。单击左窗格中的“+”号以展开图树。要隐藏图树视图,请选择“视图”>“隐藏可用图”,或者单击“可用图”列表右上角的X按钮。

5)从该树中选择图并将其拖入右窗格中。还可以在窗格之间拖动图。

5 Analysis测试结果分析

5.1 分析事务性能

分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图,可以确定在方案执行期间响应时间过长的事务。使用“平均事务响应时间”图,可以查看有问题的事务在方案运行期间每一秒钟的行为。

事务性能摘要图描述了方案执行期间每个事务的最短响应时间、平均响应时间和最长响应时间的摘要。在图1的示例中,保留事务在方案执行期间的平均响应时间为44.4秒。

平均事务响应时间图描述保留事务在整个方案运行期间的响应时间很长。在方案执行期间的第六分钟和第十三分钟,此事务的响应时间过长(大约55秒钟)。

为了确定问题并了解在该方案执行期间保留事务响应时间过长的原因,需要细分事务并分析每个页面组件的性能。要细分事务,请在平均事务响应时间图或事务性能摘要图中右键单击该事务,然后选择“<事务名>的网页细分”。

5.2 使用网页细分图

使用网页细分图,可以细分平均事务响应时间图或事务性能摘要图以查看事务中每个页面组件的下载时间。注意,只有在运行方案前启用了“网页细分”功能才可以实现这一点。网页细分图显示了保留事务中每个页面组件的下载时间明细。

如果组件下载的时间过长,应查看这是由哪些度量(DNS resolution time.connection time、time to first buffer、SSL handshakingtime、receive time和FTP authentication time)引起的。要查看方案运行期间发生问题的具体时刻,请选择“页面下载细分(随时间变化)图”。有关所显示度量的详细信息,可以参阅“页面下载时间细分图”。要确定问题是否与网络或服务器相关,请选择“第一次缓冲时间细分随时间变化”。

图4描述了服务器耗时比网络耗时长很多。如果服务器耗时过长,请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长,请使用“网络监视器”图确定导致性能瓶颈的网络问题。

5.3 使用自动关联

可以通过分析网页细分图或者使用自动关联功能确定造成服务器或网络瓶颈的原因。自动关联功能应用高级统计信息算法来确定哪些度量对事务的响应时间影响最大。平均事务响应时间图显示方案运行期间每个事务的平均响应时间。

图5描述在方案即将结束运行时Submit Data事务的响应时间相对较长。要将此事务与方案运行期间收集的所有度量关联,请右键单击Submit Data事务并选择“自动关联”。在打开的对话框中,选择要检查的时间段。

单击“关联选项”选项卡,选择要将哪些图的数据与Submit Data事务关联,然

后单击“确定”。在图7中,Analysis显示与Submit Data事务关联最为紧密的五个度量:平均事务响应时间、每秒点击数、Windows资源、Web Logic(JMX)、SQL Server。

此关联示例描述下面的数据库和Web服务器度量对Submit Data事务的影响最大:Number of Deadlocks/sec(SQL Server)、JVMHeap Size Current(Web Logic Server)、Pending Request Current Count(Web Logic Server)、Waiting For Connection Current Count(Web Logic Server)和Private Bytes(Process_Total)(SQL Server)。使用相应的服务器图,可以查看上面每一个服务器度量的数据并查明导致系统中出现瓶颈的问题。

图8描述Web Logic(JMX)应用程序服务器度量JVMHeap Size Current Private Bytes(Process_Total)随着运行的Vuser数量的增加而增加。因此,图8描述这两种度量会导致Web Logic(JMX)应用程序服务器的性能降,从而影响Submit Data事务的响应时间。

5.4 比较方案结果

每次对系统进行细微调整并解决其他性能瓶颈时,都应再次运行相同的负载测试以验证问题是否得到了解决并确认未造成新的性能瓶颈。执行几次负载测试后,可以将初始结果与最终结果进行比较。下图显示了方案的初始负载测试与最终负载测试之间的比较。

第一个负载测试描述在执行任何负载测试前应用程序处于初始状态时的性能。从图9中,可以看到当Vuser为50人时,响应时间大约是90秒,这说明应用程序出现了严重的性能问题。使用Analysis过程,可以确定缩短事务响应时间所需的体系结构更改。对这些站点体系结构进行更改后,在上次执行的负载测试中,具有相同数量用户的相同业务进程的事务响应时间少于10秒。

6 Load Runner的不足之处

Load Runner作为性能测试工具能够发现测试系统中的瓶颈,但在实际的性能测试中它仍然存在着以下的问题。

1)价格昂贵

作为商业的自动化测试工具,其价格和他的功能成正比,功能的强大也使得它价格很高。

2)缺少对自身稳定性的检验

Load Runner使用压力测试计算测试时间时,大概只有Load Runner的产品设计和开发人员才知道测试时间是如何计算的。一个性能测试工具在实施性能测试时,作为一把标尺,但其自身的稳定性又由谁来检验呢。

摘要：性能测试用来测试软件在集成系统中的运行性能的,它是相对于功能测试,并在功能测试基础上对系统进行的全面的测试。而LoadRunner正是一款能够预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题,LoadRunner能够对整个企业架构进行测试。

关键词：性能测试,LoadRunner

参考文献

[1]段念.软件性能测试过程详解与案例剖析.清华大学出版社,2006.

篇4：LoadRunner测试SQL语句性能

关键词：煤矿,安全监控系统,稳定性测试,并发测试

0 引言

煤矿安全监控系统主要通过各种传感器采集瓦斯、O2、温度等实时值, 并由分站进行处理并上传至上位机, 上位机对采集数据进行处理分析, 实现超限报警、实时数据显示、历史数据查询等功能, 对避免或降低瓦斯爆炸等事故发生具有十分重要的意义[1]。然而实际环境中经常会因为网络故障或监控主机问题而导致数据传输不完整, 直接影响了调度人员的安全监测决策[2], 因此必须对煤矿安全监控系统进行性能测试。

目前国内主要以自主开发的模拟工具对煤矿安全监控系统进行性能测试, 或直接在现场用户环境中进行工业性试验 (人工测试) 。自主开发的模拟工具只实现了数据的随机变化, 模拟数据需人工添加, 无法实现大数据量测试[3]、模拟用户周期性日常操作的稳定性测试;工业性试验无法测试系统的极限运行情况, 且测试出现问题会影响现场。LoadRunner是一种系统行为和性能的负载测试工具, 可模拟用户的操作行为并对系统实时性能进行监测[4]。本文提出了一种基于LoadRunner的煤矿安全监控系统性能测试方法, 详细介绍了系统测试流程。

1 测试计划

1.1 测试前期调查

煤矿安全监控系统的性能测试需求调研主要从并发测试和稳定性测试2个方面进行。并发测试操作需考虑一些主要数据查询功能的显示性能, 如多用户同时打开页面的响应时间小于等于5s, 能同时支持50个用户登录系统, 并能进行报警信息查看等。在进行多用户并发测试前, 需要确认单个页面打开的响应时间在5s以内。稳定性测试依据AQ 6201—2006《煤矿安全监控系统通用技术要求》中4.12的要求:系统平均无故障工作时间应不小于800h。测试持续时间可选取34d。

1.2 测试准备工作

1.2.1 测试用例设计

根据测试需求调研的结果设计测试用例, 见表1。本文以测试用例P-1—P-5和L-2为例, 介绍并发测试和稳定性测试的实施方法。

1.2.2 测试环境部署

测试环境由传感器、监控分站、传输接口、监控主机、监控备机、服务器 (普通PC) 、客户端等构成, 如图1所示。考虑实际情况接入3台真实的分站, 其中1台分站上接满真实的传感器, 利用自动化功能测试工具QTP (QuickTest Professional) 添加剩余的分站和分站下未实装的传感器数据, 最后利用自动化性能测试工具LoadRunner模拟用户并发测试和用户查询数据, 使用数据变化模拟工具模拟未实装的传感器数据变化及报警, 进行稳定性测试。测试环境网络为局域网, 煤矿安全监控系统程序为C/S (Client/Server) 架构, 部署在监控主机和监控备机上, 数据变化模拟工具和QTP运行在监控主机上, LoadRunner部署在客户端PC上。

1.2.3 大数据量准备

系统性能测试的前提为数据库中存有约运行1a的数据量, 可通过使用现场数据备份后再恢复的方法来实现。

测试用例L-2中的2个通道分别接入36台和28台分站 (共64台分站) , 每台分站接入全部的传感器。系统是在.NET框架上使用C#语言开发, 选用QTP录制添加分站和传感器数据的过程, 然后进行参数化, 迭代多次反复运行脚本, 达到添加数据的目的[5]。

2 测试脚本创建

以并发测试用例P-1为例, 使用LoadRunner11.0创建测试脚本, 即录制单个用户的操作:打开HP Virtual User Generator, 选用协议为Microsoft.NET, 录制用户登录系统后选择所有的测点, 查询时间条件选择1个月跨度, 点击查询历史报警数据。录制时, 在查询历史报警数据动作前添加1个集合点、1个事务开始点, 查询结果全部显示完后点击插入事务结束点。

录制完成后, 回放脚本确认回放成功后, 出现部分类名重复报错的情况, 需要把报错处的类名更改为程序中真实的类名, 另对登录用户名及对应密码进行参数化[6], 再次确认参数化成功后, 将脚本保存至测试客户端上, 命名为HisAlarm。

3 场景创建

选择场景方式:以并发测试用例P-1为例, 打开LoadRunner Controller, 场景类型选择Manual Scenario类型, 虚拟用户数量选择20。测试P-2—P-5时只要修改虚拟用户数量即可。

选择脚本:脚本选择HisAlarm, 在Scenario Schedule下的Global Schedule中, 每秒运行5个用户, 共运行20个用户。

设置迭代:Run-time Settings下的Run Logic中Number of Iterations选择1。

4 场景运行和监控

4.1 场景一

执行并发测试用例P-1。使用LoadRunner Controller中的Run运行和监控场景, 需要记录历史报警页面打开的响应时间、服务器的资源使用情况。通过人工查看煤矿安全监控系统主机页面中的数据来确认监控性能, 如历史报警和故障统计。通过LoadRunner性能监视器实时监控服务器的资源使用情况。

4.2 场景二

执行稳定性测试用例L-2。系统中有2个通道, 其中1个通道下有3台真实的分站, 且其中1台分站上接满32个真实的传感器, 其他分站为未实装的分站。通过数据变化模拟工具实现分站下未实装的传感器数据定时随机变化, 启动模拟程序, 设置传感器数据的变化规则, 实现每隔10min产生2条报警和故障;另外添加类似场景一的测试, 同时由LoadRunner运行10个用户查询1d内的所有历史报警, 迭代间隔时间设置为1h。

一般并发测试完成后再进行稳定性测试, 因此场景二在测试的最后阶段进行。

5 测试结果分析

场景一 (并发测试-报警统计) 测试结果见表2。可以看出随着并发用户数增加, 打开页面响应时间加长, 手工测试单个用户打开页面响应时间在5s之内, 自动化测试20个用户并发操作的响应时间在5s以上, 不满足响应时间小于等于5s的性能要求。即使服务器的CPU利用率在可接受范围内 (80%以下) , 并发测试仍不能通过, 需要进一步优化程序后再次测试。

场景二运行开始3d内, 监控主机主界面打开后无法查询通信数据, 程序修改后再次测试, 系统运行34d, 系统最大巡检周期不大于30s, 报警功能正常, 服务器资源占用率在正常范围内。稳定性测试通过。

6 结语

基于LoadRunner的煤矿安全监控系统性能测试方法可实现大数据量下模拟用户日常操作的稳定性测试和多用户并发测试, 提高了测试效率和准确性, 为系统性能优化提供了依据。

参考文献

[1]孙继平.煤矿自动化与信息化技术回顾与展望[J].工矿自动化, 2010, 36 (6) :26-30.

[2]贺耀宜.煤矿远程安全监测监管一体化平台创新设计[J].工矿自动化, 2013, 39 (11) :1-4.

[3]李昆霖.浅析性能测试[J].科技信息, 2012 (9) :456-457.

[4]张海梅, 薛亚敏, 张静.Flex3.0系统的性能测试过程解析[J].计算机光盘软件与应用, 2012 (10) :23-24.

[5]CRISPIN L, GREGORY J.敏捷软件测试:测试人员与敏捷团队的实践指南[M].孙伟峰, 崔康, 译.北京:清华大学出版社, 2010:188-216.