搜索
Contents目录一.性能测试实施流程介绍二.性能测试脚本介绍三.性能测试监控介绍四.性能测试分析介绍五.性能测试测试报告介绍Contents目录一.性能测试实施流程介绍1.了解什么是性能测试2.性能测试流程3.性能测试常见类型4.常用性能测试工具分类1.性能测试里论:性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。性能是衡量在一个环境下运行一个或多个应用程序的效率主要的指标一般是响应时间，tps，交易成功率2.性能测试流程:3.性能测试常见类型：4.常用性能测试工具分类：.LoadrunnerLoadRunner是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周..JmeterJMeter是Apache组织的开放源代码项目，它是功能和性能测试的工具，100%的用java实现。这个工具相对于上面的LoadRunner来说，是比较轻量级的工具，便于安装且免费开源。不仅可以进行功能测试也可以进行性能测试，一般可以用来做接口测试。这款工具学习起来也非常的容易，只要用这个工具做过几次测试，就可以非常熟悉的运用了。Contents目录二.性能测试脚本介绍1.事务2.参数化3.断言4.关联5.集合点6.思考时间1.事务：用户自定义的一个标识，用来衡量不同的操作所花费的时间，事务时间反映的是一个操作过程的响应时间。2.参数化：参数化作为测试脚本中最基本的使用技巧，需要每个从事性能测试的小伙伴都能熟练掌握。在测试工具中，每一个模拟用户都是一个线程，而在我们的仿真模型里，每一个用户都应该是一个真实的业务实体，每个用户代表的业务含义、他可以去处理的业务以及在处理业务的过程中可以操作的数据都应该是不同的，这样才可以更真实的表达现实世界中系统使用的负载模型。为了达到这个目的，将测试工具的每一个线程和仿真模型中的每一个用户及操作对应起来，就需要使用到参数化的脚本处理。说的有些太严肃了，简单举个例子，比如我们要测试用户注册的功能，注册的用户名是不允许重复的。我们录制完的脚本都是hardcode，直接进行并发测试的话，无疑所有模拟用户的线程在注册的时候输入的都是相同的用户名和密码，这样肯定是会有很多错误请求无法达到服务端，也就不能产生我们预期的负载压力。这时候，针对用户名就需要我们使用参数化的技巧来实现，每个注册的用户每次注册都使用不同的用户名来填写注册信息。3.断言:jmeter中有个元件叫做断言（Assertion），它的作用和loadrunner中的检查点类似；用于检查测试中得到的响应数据等是否符合预期，用以保证性能测试过程中的数据交互与预期一致。使用断言的目的：在request的返回层面增加一层判断机制；因为request成功了，并不代表结果一定正确。3.1.断言与beanshell组合使用.首先存储一个接口的响应结果.变量存储好后，再需要断言的接口后面添加BeanShell断言，使用Failrue来标识断言失败，FailureMessage标示断言失败的原因，4.关联（correlation）：在脚本回放过程中，客户端发出请求，通过关联函数所定义的左右边界值（也就是关联规则），在服务器所响应的内容中查找，得到相应的值，已变量的形式替换录制时的静态值，从而向服务器发出正确的请求，这种动态获得服务器响应内容的方法被称作关联。5.集合点：集合点用以同步虚拟用户，以便恰好在同一时刻执行任务。在测试计划中，可能会要求系统能够承受1000人同时提交数据，在LoadRunner中可以通过在提交数据操作前面加入集合点，这样当虚拟用户运行到提交数据的集合点时，LoadRunner就会检查同时有多少用户运行到集合点，如果不到1000人，LoadRunner就会命令已经到集合点的用户在此等待，当在集合点等待的用户达到1000人时，LoadRunner命令1000人同时去提交数据，从而达到测试计划中的需求。•jmeter也是，NumberofSimulatedUserstoGroupby的意思是分批执行请求。当线程数到达设置的数量后，才开始发送请求。•例如设置为5，如果启动的线程数到了4是不发送请求的，之后当再启动一个线程，线程数为5的时候才开始发送请求。•这样就相当于设置了集合点。只有达到我们想要的并发线程数的时候才开始并发。•如果我们的并发线程数为10，那我们就可以设置线程组的线程数为10，加个SynchronizingTimer，设置为10就可以。•Timout的意思是等待请求多久后，不管线程数有没有到达设置的并发数量都开始运行测试。6.思考时间：用户自定义的一个标识，用来衡量不同的操作所花费的时间，事务时间反映的是一个操作过程的响应时间。Pacing：请求和请求之间的间隔先明确一些概念：1）定时器是在每个sampler（采样器）之前执行的，而不是之后；是的，你没有看错，不管这个定时器的位置放在sampler之后，还是之下，它都在sampler之前得到执行。2）定时器是有作用域的；当执行一个sampler之前时，所有当前作用域内的定时器都会被执行；3）如果希望定时器仅应用于其中一个sampler，则把该定时器作为子节点加入；4）如果希望在sampler执行完之后再等待，则可使用TestAction；一、固定定时器（ConstantTimer）毫无疑问，这是最重要的定时器。需要注意的是，固定定时器的延时不会计入单个sampler的响应时间，但会计入事务控制器的时间。如下图，固定定时器的时长设为300毫秒。定时器时长并不计入java请求的响应时间，但被计入“事务控制器”的总时间如果你坚持看到这里，并且对loadrunner的thinktime和pacing这两个概念还有记忆的话，我们可以有答案了：对于“java请求”这个sampler来说，定时器相当于loadrunner中的pacing；对于“事务控制器”来说，定时器相当于loadrunner中的thinktime。我们通常说的响应时间，应该大部分情况下是针对某一个具体的sampler（http请求），而不是针对一组sampler组合的事务Contents目录三.性能测试运行及监控介绍1.性能测试脚本的运行2.性能测试资源的监控1.性能测试脚本的运行：1.1.性能侧测试几种类型的设置：.基准测试的设置：.负载测试的设置：.混合场景的设置：稳定性场景的设置：1.2.脚本的运行有两种：1.2.1.第一种：.设置线程组页面.设置好的脚本放到压力发起机上.运行命令：.Jmeter-n-t/home/baseuser/ljd/zzt.jmx-l/home/baseuser/ljd/zzt.jtl-e-o/home/baseuser/ljd/wuliaoleixing.把收集到信息拉到本地电脑上-n表示以nogui方式运行测试计划-t表示测试计划，后面跟测试计划名称-l表示测试结果，后面跟测试结果文件名称1.2.2第二种：负载运行：由于jmeter是java写的，效率没loadrunner那么好，loadrunner是c语言写的.Jmeter是有一台主控机来控制很多的负载机，client主动去连server,server只要打开一个服务就行，脚本放在主控机上的，就是是这样的一个过程。Saver上必须先安装jmeter工具，然后改下配置文件。修改配置文件如下：在bin下面找到一个文件propertics•cdapache-jmeter-3.2/cdbin•./jmeter-server•假设，我的脚本里线程设置100，那么3台每台Saver就300.•Loadrunner可以每台机器单独设置，但jmeter不行•2、在控制机执行分布式命令•jmeter-n-ttestplan/comic.jmx-r-ltestResult/result1.jtl启动所有从机执行脚本2.性能测试资源的监控：2.1安装工具nmon:(我这边有下载的工具及安装步骤）2.2用nmon监控工具收集后台资源收集命令：./nmon_x86_64_centos6-f-s6-c30说明：-f以文件的形式输出，默认输出是机器名+日期.nmon的格式，也可以用-F指定输出的文件名，例如:-s是采样频率，隔多长时间收集一次，这里我指定的是6秒一次；-c是采样次数，一共要收集多少次，这里我指定的是30次。2.3用nmon分析工具形成图表形式的文档分析工具：Contents目录四.性能测试分析介绍1.操作系统性能监控分析（cpu，内存，磁盘io）2.jvm堆模型，gc垃圾收集监控分析3.tomca(中间件）监控分析4.针对错误提示信息的分析1.1.cpu:单线程死锁这个判断流程比较多，生产上基本不会有问题，1.2.查看cpu利用率比较高的线程实现：1.L1.3.cpu常用命令详解：uptime：满足什么会于运行对列：1.没有在等待i/o操作的结果2.没有主动进入等待状态（没有调用“wait”）3.没有被停止（等待终止）L1.3.cpu常用命令详解：top：L1.3.cpu常用命令详解：top：Lbuffer和cache的作用是缩短i/0系统的调用的时间，比如读写等，一般一个系统而言，如果cache的值越大，说明cache住的文件数多，如果频繁地访问文件都能被命中，很明显会比读取磁盘调用快，磁盘的io必定会减小。cache的命中率是关键，如果频繁访问的文件不能被命中，对cache而言是个比较大的资源浪费，此时应考虑dropcache并且提升对应的cache命中率。命令：Free-msyncEcho3/proc/sys/vm/drop_cachesL1.2.内存：•内存使用率：内存使用率=（1-空闲内存/总内存大小）*100%•或内存使用率=（总内存-空闲内存-cached缓存-buffers缓存）/总内存•内存使用率：无性能压力：0%~50%、有一定性能压力：50%~70%、达到性能阀值：70%~80%、严重性能问题：80%~100%•内存使用率长时间处于95%以上-----P1级bug•内存使用率长时间处于90%以上-----P2级bug1.2.磁盘：•IO瓶颈往往是我们可能会忽略的地方（我们常会看top、free、netstat等等，但经常会忽略IO的负载情况），今天给大家详细分享一下如何确认一台服务器的IO负载是否到达了瓶颈，以及可能优化、定位的点。•先来看一台典型的IO密集型服务器的cpu统计图：可以看到，CPU总使用率不高，平均1.1%，max到5.6%，虽然大部分都耗在了iowait上，但才百分之五左右，应该还没到瓶颈吧？？？这里要特别注意：iowait≠IO负载，要看真实的IO负载情况，一般使用iostat–x命令$iostat–x1avg-cpu:%user%nice%system%iowait%steal%idle0.040.000.044.990.0094.92Device:rrqm/swrqm/sr/sw/srsec/swsec/savgrq-szavgqu-szawaitsvctm%utilsda0.0081.00104.004.0013760.00680.00133.702.0819.299.2599.90sda10.000.000.000.000.000.000.000.000.000.000.00sda20.000.000.000.000.000.000.000.000.000.000.00sda30.000.000.000.000.000.000.000.000.000.000.00sda40.000.000.000.00