性能测试学习Word下载.docx

1、压力测试：通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，并或得系统能提供的最大服务级别。压力测试是逐步增加负载，使系统某些资源达到饱和甚至失效的测试。其他的性能测试有配置测试、并发测试、容量测试、可靠性测试、失败测试等等。2工具2.1工具简介Loadrunner主要由VuGen、Controller和Analysis3个部分构成。VuGen是Loadrunner用于开发Vuser脚本的主要工具，VuGen不仅能够录制脚本，还可以运行脚本。录制脚本是VuGen会生成各种函数，来定义在录制会话过程中执行的操作。VuGen将这些函数插入到VuGen编辑器中

2、，以创建基础Vuser脚本。Loadrunner通过Controller模拟一个多用户并行工作的环境来对应用程序进行负载测试。Analysis提供了丰富的图标帮助用户从各个角度对数据进行有效分析，也可以将多个图标合并起来进行分析2.2工具安装Loadrunner安装简单，方便，next到完成，安装完成后需要注意的是license。lm70.dll（license的支持文件），mlr5lprg.dll（保存license的文件）将这两个文件复制并粘贴到LR8.1安装目录下的bin文件夹下（C:E:Program FilesMercuryLoadRunnerbin），然后将老的license添加到

3、loadrunner就可以了。2.3工具卸载Loadrunner安装后若想卸载安装别的版本，建议卸载完后一定要删除本地关于loadrunner的文件，删除缓存文件，删除注册表里MI的文件。只有这样彻底卸载后，安装别的版方能正常使用。3创建脚本VuGen提供了多种协议，方便用户模拟系统的Vuser技术，暂时我学习的是web（Http/html）协议的录制。创建脚本的步骤：脚本录制、脚本优化、脚本执行3.1脚本录制脚本录制时，选择正确的协议，在录制前对recording options 进行适当的设置，能够去掉冗余的不必要的脚本信息。但是在录制的过程中出现了录制打不开浏览器，主要考虑的解决方法有：

4、a） 当有多个浏览器时，需要将IE置为默认浏览器。在Run-time Settings中设置Browser Emulation的User-Agent值为IE。由于IE的第三方插件的影响，需要在IE的工具-Internet选项-高级中，将“启用第三方浏览器扩展”的选中去掉。b） 若是a方法还是录制打不开浏览器，那么就极有可能是浏览器不兼容的问题，可以重新安装一个高版本或者低版本的浏览器。例如Loadrunner9.1不支持IE7以上的浏览器。c） 若是a/b方法都解决不了该问题，那么建议在自己电脑上安装一个虚拟机，虚拟机上装一个windows2003或者linux系统，然后安装loadrunne

5、r，一般这样就可以正常录制了。3.2脚本优化 脚本优化，我主要考虑的是插入事务、检查点、关联，对数据进行参数化等操作，事务的插入主要在脚本录制的时候完成，这里我重点讲解数据的参数化和检查点的插入。 脚本数据的参数化，需要注意的是：数据分配方法和数据更新方式。 插入检查点总是会遇到检查点插入后不执行检查操作，或者执行检查点总是报错的情况。这里我主要解决的方法是：a） 在run time Settings -Preferences-Enabel Image and Text Check复选框选中，就会执行检查操作b） 利用lr_convert_string_encoding函数将需要检查的文字转换

6、成服务器返回的文本字符，lr_output_message函数输出对应文本字符，执行检查的时候就能找到对应的文字信息，即综合转换后就是鍒犻櫎。如：Action（）lr_convert_string_encoding（综合,gb2312utf-8tmp）;lr_output_message（=%s,lr_eval_string（tmp）; return 0; 关联也是比较重要的，主要是服务返回的session ID不一致的问题，我们可以采用自动关联，也可以采用脚本对比设置关联，或者手动关联。3.3脚本执行在测试执行之前，需要对runtime Settings进行设置，一般可以考虑迭代的次数，忽略

7、思考时间，日志的输出等等。脚本执行前最好先对脚本进行编译，编译没有问题后再运行脚本，这是一个好的习惯，对错误的定位分析也会更好一些的4场景设置4.1场景基本设置测试场景的设置是否正确对测试结果有很大的影响。因为当测试出现异常时，我们要对场景设置进行分析。一般我们选择的加压方式是一次加载、逐级加载，高低突变加载、随机加载用得比较的少。一次加载：一次性加载某个数量的用户，在预定的时间段内持续运行。4.2企业微博实例展示本次主要对企业微博进行测试，主要采用了基准测试和逐级加压的方式来测定系统的性能指标在设置场景之前，我们需要对性能指标、测试环境进行了解，初步判断系统的承受能力和加压的程度。性能指标：

8、响应时间=5s、TPS：无、CPU=99.8%测试环境：硬件环境软件环境应用服务器1台 2个物理CPU 2core 4G 物理内存 4G 虚拟内存 30G IP: 192.168.17.81 数据库服务器IBM，X3850CPU：8颗，24cores内存：48G，硬盘：250G 192.168.17.141操作系统：linux应用软件：Mysql压力机2颗Pentium Dual-core CPU E6600 3.06GHz硬盘 ：300G1.96GB192.168.19.49 Windows xpIE7测试场景设置：检测项检测方法性能要求结果数据测试结果平均事务响应时间TPS成功率基准测试_

9、单用户发布在测试环境下执行单用户发布系统操作。设置思考时间为0，脚本迭代100次，结果响应时间为平均值。1.单用户系统发布响应时间3秒2.应用服务器和DB服务器CPU平均利用率753.事务成功率100%1.0310.714100%通过10用户并发发布在测试环境下初始加载10个用户并发，每隔0.5分钟加载10个并发用户，同时执行发布和发布操作。持续运行该脚本30分钟，设置思考时间为0S。1. 90%系统响应时间5秒6.4320.671不通过30用户并发发布在测试环境下初始加载30个用户并发，每隔1分钟加载20个并发用户，同时执行发布和发布操作。27.4660.64250用户并发发布在测试环境下初

10、始加载50个用户并发，每隔1分钟加载20个并发用户，同时执行发布和发布操作。持续运行该脚本30分钟，设置思考时间为0S 24.2560.862基准测试：测定单个用户多次迭代系统运行的性能。在设置的过程中，我考虑了单个用户的迭代次数，忽略了思考时间。逐级加载：有规律的逐渐增加用户，每几秒增加一些新用户，交错上升。这种方式容易发现性能的拐点，即性能的瓶颈的地方。本次测试是按照4分钟15个用户这样依次递增的加载，重点关注事务的响应时间、TPS、系统资源的利用率。场景设置好后，在运行的过程中事务的平均响应时间持续偏高，这个时候需要重新设置场景，添加网页细分页的监控，方便之后分析具体是哪个页面的加载的响

11、应时间比较的长。5结果分析5.1测试结果有效性判断在Controller执行的测试场景结束后，首先要做的是判断采集到的结果数据是否真实有效。判断测试结果是否有效，通常按下面的步骤进行：第一步：在整个测试场景的执行过程中，测试环境是否正常。如果在测试过程中出现过异常，那么这样得出的结果往往不准确，无须进行分析。例如，在测试执行过程中，测试机的CPU利用率经常达到100%、测试环境的网络不稳定、一些系统参数配置不正确等等，这样得出的测试结果没有必要进行分析，应该重新设置测试场景或调整测试环境，再次执行测试。第二步：测试场景的设置是否正确、合理。因此，当测试出现异常时，我们要对场景设置进行分析。一些

12、新手在使用Controller执行测试时，可能会同时在一台PC上加载全部虚拟用户例如同时加载1000个虚拟用户，如果客户端来不及处理，就会有很多虚拟用户因不能初始化而失败。失败的根本原因不是被测试的应用服务器不能处理，而是压力根本没有传输过去。正确的做法是增加更多的Generator或逐步加压，使测试场景运行起来。第三步：测试结果是否直接暴露出系统的一些问题。对测试场景的整个执行过程，没有必要对压力下系统运行正常的结果进行分析，因为这样的结果不能反映出系统的性能问题，应该进一步调整场景（比如增大压力）进行测试。在测试过程中使系统表现不正常的测试场景生成的结果则要进行深入分析。实际上，分析能够反

13、映性能问题的测试结果才是性能分析阶段的主要工作。5.2测试结果分析基本原则5.3性能测试分析流程这里主要讲解企业微博逐级加压的简单的分析过程：从分析Summary的事务执行情况入手从上图我们可以看到发布的平均事务响应时间是30.376S,且90%的用户的平均响应时间居然是56.951S，系统的处理能力极低！ 查看负载发生器和服务器的系统资源情况。从上表我们可以看出响应时间越来越长，但是CPU的使用率并没有呈现上升的趋势，这里我们就要分析是不是网络受限，数据库锁，队列等待等原因造成的查看虚拟用户与事务的详细执行情况。TPS与RunningVusers图组合可以得出，TPS随着用户数量的增加呈现下

14、降的趋势，当用户增长到80时，TPS急剧下降，在2.5的范围波动，这个时候就有可能出现了瓶颈，系统的处理能力下降，有可能是服务器开始出现瓶颈。随着测试时间和用户数量的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着时间和用户数量的变化，整体性能将会有下降的趋势第四步：查看错误发生情况。错误或者失败分析很重要，根据错误或失败的情况可以分析系统性能瓶颈等问题，但是因企业微博运行过程中未出现任何错误或者失败的情况，这里就不做分析。第五步：查看Web资源与细分网页。从Time to First Buffer Breakdown可以得出事务的响应时间过长与网络没有关系，但服务器的响应时间也对系统没有过大的影响，由此我们可以考虑可以能是系统的架构方面的影响了。从Page Component Breakdown（Over Time）图我们可以看到First buffer Time组件的响应时间已经达到了18.535S，这个页面组件一直呈上升趋势，且占了响应时间的最大部分。First buffer time大部分又是消耗在Server time上面，但是cpu的使用率却呈现的下降的趋势，初步确定是程序本身的原因。5.4企业微博测试结论 通过本次测试，TPS成功率达到了100%，但是企业微博的总体性能没有达到我们预期的指标，其中包括事务的平均响应时间、处理TPS交易等。