性能测试学习Word下载.docx

性能测试学习Word下载.docx

《性能测试学习Word下载.docx》由会员分享，可在线阅读，更多相关《性能测试学习Word下载.docx（14页珍藏版）》请在冰豆网上搜索。

压力测试：

通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，并或得系统能提供的最大服务级别。

压力测试是逐步增加负载，使系统某些资源达到饱和甚至失效的测试。

其他的性能测试有配置测试、并发测试、容量测试、可靠性测试、失败测试等等。

2工具

2.1工具简介

Loadrunner主要由VuGen、Controller和Analysis3个部分构成。

VuGen是Loadrunner用于开发Vuser脚本的主要工具，VuGen不仅能够录制脚本，还可以运行脚本。

录制脚本是VuGen会生成各种函数，来定义在录制会话过程中执行的操作。

VuGen将这些函数插入到VuGen编辑器中，以创建基础Vuser脚本。

Loadrunner通过Controller模拟一个多用户并行工作的环境来对应用程序进行负载测试。

Analysis提供了丰富的图标帮助用户从各个角度对数据进行有效分析，也可以将多个图标合并起来进行分析

2.2工具安装

Loadrunner安装简单，方便，next到完成，安装完成后需要注意的是license。

lm70.dll（license的支持文件），mlr5lprg.dll（保存license的文件）将这两个文件复制并粘贴到LR8.1安装目录下的bin文件夹下（C:

\E:

\ProgramFiles\Mercury\LoadRunner\bin），然后将老的license添加到loadrunner就可以了。

2.3工具卸载

Loadrunner安装后若想卸载安装别的版本，建议卸载完后一定要删除本地关于loadrunner的文件，删除缓存文件，删除注册表里MI的文件。

只有这样彻底卸载后，安装别的版方能正常使用。

3创建脚本

VuGen提供了多种协议，方便用户模拟系统的Vuser技术，暂时我学习的是web（Http/html）协议的录制。

创建脚本的步骤：

脚本录制、脚本优化、脚本执行

3.1脚本录制

脚本录制时，选择正确的协议，在录制前对recordingoptions进行适当的设置，能够去掉冗余的不必要的脚本信息。

但是在录制的过程中出现了录制打不开浏览器，主要考虑的解决方法有：

a）当有多个浏览器时，需要将IE置为默认浏览器。

在Run-timeSettings中设置BrowserEmulation的User-Agent值为IE。

由于IE的第三方插件的影响，需要在IE的工具-Internet选项…-高级中，将“启用第三方浏览器扩展”的选中去掉。

b）若是a方法还是录制打不开浏览器，那么就极有可能是浏览器不兼容的问题，可以重新安装一个高版本或者低版本的浏览器。

例如Loadrunner9.1不支持IE7以上的浏览器。

c）若是a/b方法都解决不了该问题，那么建议在自己电脑上安装一个虚拟机，虚拟机上装一个windows2003或者linux系统，然后安装loadrunner，一般这样就可以正常录制了。

3.2脚本优化

脚本优化，我主要考虑的是插入事务、检查点、关联，对数据进行参数化等操作，事务的插入主要在脚本录制的时候完成，这里我重点讲解数据的参数化和检查点的插入。

●脚本数据的参数化，需要注意的是：

数据分配方法和数据更新方式。

●插入检查点总是会遇到检查点插入后不执行检查操作，或者执行检查点总是报错的情况。

这里我主要解决的方法是：

a）在runtimeSettings->

Preferences->

EnabelImageandTextCheck复选框选中，就会执行检查操作

b）利用lr_convert_string_encoding函数将需要检查的文字转换成服务器返回的文本字符，lr_output_message函数输出对应文本字符，执行检查的时候就能找到对应的文字信息，即‘综合’转换后就是‘鍒犻櫎’。

如：

Action（）

{lr_convert_string_encoding（"

综合"

"

gb2312"

utf-8"

tmp"

）;

lr_output_message（"

====%s"

lr_eval_string（"

{tmp}"

））;

return0;

}

●关联也是比较重要的，主要是服务返回的sessionID不一致的问题，我们可以采用自动关联，也可以采用脚本对比设置关联，或者手动关联。

3.3脚本执行

在测试执行之前，需要对runtimeSettings进行设置，一般可以考虑迭代的次数，忽略思考时间，日志的输出等等。

脚本执行前最好先对脚本进行编译，编译没有问题后再运行脚本，这是一个好的习惯，对错误的定位分析也会更好一些的

4场景设置

4.1场景基本设置

测试场景的设置是否正确对测试结果有很大的影响。

因为当测试出现异常时，我们要对场景设置进行分析。

一般我们选择的加压方式是一次加载、逐级加载，高低突变加载、随机加载用得比较的少。

一次加载：

一次性加载某个数量的用户，在预定的时间段内持续运行。

4.2企业微博实例展示

本次主要对企业微博进行测试，主要采用了基准测试和逐级加压的方式来测定系统的性能指标

在设置场景之前，我们需要对性能指标、测试环境进行了解，初步判断系统的承受能力和加压的程度。

性能指标：

响应时间<

=5s、TPS：

无、CPU<

=75%、内存使用率:

要求无溢出（没明确指标）、事务成功率>

=99.8%

测试环境：

硬件环境

软件环境

应用服务器

1台

2个物理CPU2core4G

物理内存4G

虚拟内存30G

IP:

192.168.17.81

数据库服务器

IBM，X3850

CPU：

8颗，24cores

内存：

48G，硬盘：

250G

192.168.17.141

操作系统：

linux

应用软件：

Mysql

压力机

2颗PentiumDual-coreCPUE66003.06GHz

硬盘：

300G

1.96GB

192.168.19.49

Windowsxp

IE7

测试场景设置：

检测项

检测方法

性能要求

结果数据

测试结果

平均事务响应时间

TPS

成功率

基准测试_单用户发布

在测试环境下执行单用户发布系统操作。

设置思考时间为0，脚本迭代100次，结果响应时间为平均值。

1.单用户系统发布响应时间≤3秒

2.应用服务器和DB服务器CPU平均利用率≤75％

3.事务成功率100%

1.031

0.714

100%

通过

10用户并发发布

在测试环境下初始加载10个用户并发，每隔0.5分钟加载10个并发用户，同时执行发布和发布操作。

持续运行该脚本30分钟，设置思考时间为0S。

1.90%系统响应时间≤5秒

6.432

0.671

不通过

30用户并发发布

在测试环境下初始加载30个用户并发，每隔1分钟加载20个并发用户，同时执行发布和发布操作。

27.466

0.642

50用户并发发布

在测试环境下初始加载50个用户并发，每隔1分钟加载20个并发用户，同时执行发布和发布操作。

持续运行该脚本30分钟，设置思考时间为0S

24.256

0.862

基准测试：

测定单个用户多次迭代系统运行的性能。

在设置的过程中，我考虑了单个用户的迭代次数，忽略了思考时间。

逐级加载：

有规律的逐渐增加用户，每几秒增加一些新用户，交错上升。

这种方式容易发现性能的拐点，即性能的瓶颈的地方。

本次测试是按照4分钟15个用户这样依次递增的加载，重点关注事务的响应时间、TPS、系统资源的利用率。

场景设置好后，在运行的过程中事务的平均响应时间持续偏高，这个时候需要重新设置场景，添加网页细分页的监控，方便之后分析具体是哪个页面的加载的响应时间比较的长。

5结果分析

5.1测试结果有效性判断

在Controller执行的测试场景结束后，首先要做的是判断采集到的结果数据是否真实有效。

判断测试结果是否有效，通常按下面的步骤进行：

第一步：

在整个测试场景的执行过程中，测试环境是否正常。

如果在测试过程中出现过异常，那么这样得出的结果往往不准确，无须进行分析。

例如，在测试执行过程中，测试机的CPU利用率经常达到100%、测试环境的网络不稳定、一些系统参数配置不正确等等，这样得出的测试结果没有必要进行分析，应该重新设置测试场景或调整测试环境，再次执行测试。

第二步：

测试场景的设置是否正确、合理。

因此，当测试出现异常时，我们要对场景设置进行分析。

一些新手在使用Controller执行测试时，可能会同时在一台PC上加载全部虚拟用户——例如同时加载1000个虚拟用户，如果客户端来不及处理，就会有很多虚拟用户因不能初始化而失败。

失败的根本原因不是被测试的应用服务器不能处理，而是压力根本没有传输过去。

正确的做法是增加更多的Generator或逐步加压，使测试场景运行起来。

第三步：

测试结果是否直接暴露出系统的一些问题。

对测试场景的整个执行过程，没有必要对压力下系统运行正常的结果进行分析，因为这样的结果不能反映出系统的性能问题，应该进一步调整场景（比如增大压力）进行测试。

在测试过程中使系统表现不正常的测试场景生成的结果则要进行深入分析。

实际上，分析能够反映性能问题的测试结果才是性能分析阶段的主要工作。

5.2测试结果分析基本原则

5.3性能测试分析流程

这里主要讲解企业微博逐级加压的简单的分析过程：

从分析Summary的事务执行情况入手

从上图我们可以看到发布的平均事务响应时间是30.376S,且90%的用户的平均响应时间居然是56.951S，系统的处理能力极低！

查看负载发生器和服务器的系统资源情况。

从上表我们可以看出响应时间越来越长，但是CPU的使用率并没有呈现上升的趋势，这里我们就要分析是不是网络受限，数据库锁，队列等待等原因造成的

查看虚拟用户与事务的详细执行情况。

TPS与RunningVusers图组合可以得出，TPS随着用户数量的增加呈现下降的趋势，当用户增长到80时，TPS急剧下降，在2.5的范围波动，这个时候就有可能出现了瓶颈，系统的处理能力下降，有可能是服务器开始出现瓶颈。

随着测试时间和用户数量的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着时间和用户数量的变化，整体性能将会有下降的趋势

第四步：

查看错误发生情况。

错误或者失败分析很重要，根据错误或失败的情况可以分析系统性能瓶颈等问题，但是因企业微博运行过程中未出现任何错误或者失败的情况，这里就不做分析。

第五步：

查看Web资源与细分网页。

从TimetoFirstBufferBreakdown可以得出事务的响应时间过长与网络没有关系，但服务器的响应时间也对系统没有过大的影响，由此我们可以考虑可以能是系统的架构方面的影响了。

从PageComponentBreakdown（OverTime）图我们可以看到FirstbufferTime组件的响应时间已经达到了18.535S，这个页面组件一直呈上升趋势，且占了响应时间的最大部分。

Firstbuffertime大部分又是消耗在Servertime上面，但是cpu的使用率却呈现的下降的趋势，初步确定是程序本身的原因。

5.4企业微博测试结论

通过本次测试，TPS成功率达到了100%，但是企业微博的总体性能没有达到我们预期的指标，其中包括事务的平均响应时间、处理TPS交易等。