网络压力测试怎么做(银行压力测试怎么做)

用loadrunner做简单网站的压力测试的方法使用LoadRunner 完成测试一般分为四个步骤：1、Vvitrual User Generator 创建脚本。创建脚本，选择协议，录制脚本， 编辑脚本，检查修改脚本是否有误。2、中央控制器（Controller）来调度虚拟用户。创建Scenario，选择脚本，设置机器虚拟用户数，设置Schedule，如果模拟多机测试，设置Ip Spoofer。3、运行脚本。分析scenario分析测试结果4、安装LoadRunner 中文版。LoadRunner 分为Windows 版本和Unix 版本。如果所有测试环境基于Windows 平台， 那么只要安装Windows 版本即可。本章讲解的安装过程就是LoadRunner7.8中文的Windows 版本的安装。5、使用LoadRunner进行负载/压力测试。6、录制基本的用户脚本。创建用户脚本需要用到VuGen。提示： 运行VuGen 最好在1024*768 的分辨率下， 否则有些工具栏会看不到。启动Visual User Generator 后， 通过菜单新建一个用户脚本， 选择系统通讯的协议。这里需要测试的是Web 应用，同时考虑到后台SQL数据库所以需要选择Web(HTTP/HTML)协议＋SQL SERVER协议，确定后， 进入主窗体。通过菜单来启动录制脚本的命令。7、在URL 中添入要测试的Web 站点地址。●测试http://lms.ah.sp.com.cn/lms-lmm/loginForm.do选择要把录制的脚本放到哪一个部分， 默认情况下是“Action”。这里简单说明一下：VuGen 中的脚本分为三部分：vuser_init、vuser_end 和Action。其中vuser_init 和vuser_end 都只能存在一个， 不能再分割， 而Action 还可以分成无数多个部分（ 通过点击New 按钮， 新建ActionXXX）。在录制需要登陆的系统时， 把登陆部分放到vuser_init 中， 把登陆后的操作部分放到Action 中， 把注销关闭登陆部分放到vuser_end 中。（ 如果需要在登陆操作设集合点， 那么登陆操作也要放到Action 中， 因为vuser_init 中不能添加集合点） 在其它情况下， 只要把操作部分放到Action 中即可。注意： 在重复执行测试脚本时，vuser_init 和vuser_end 中的内容只会执行一次， 重复执行的只是Action 中的部分。8、点“ 选项 ”按钮， 进入录制的设置窗体， 这里一般情况下不需要改动。●然后点“OK” 后，VuGen 开始录制脚本。在录制过程中， 不要使用浏览器的“ 后退” 功能，LoadRunner 支持不太好！ 录制过程中， 在屏幕上会有一个工具条出现。录制的过程和WinRunner 有些类似， 不再多介绍。录制完成后， 按下“ 结束录制” 按钮，VuGen 自动生成用户脚本， 退出录制过程。9、完善测试脚本。当录制完一个基本的用户脚本后， 在正式使用前还需要完善测试脚本， 增强脚本的灵活性。一般情况下， 通过以下几种方法来完善测试脚本。插入事务、插入结合点、插入注解、参数化输入。这里只举例介绍参数化如何设置，其它只作简单介绍。10、插入事务。事务（Transaction）： 为了衡量服务器的性能， 需要定义事务。比如： 在脚本中有一个数据查询操作， 为了衡量服务器执行查询操作的性能， 把这个操作定义为一个事务， 这样在运行测试脚本时，LoadRunner 运行到该事务的开始点时，LoadRunner 就会开始计时， 直到运行到该事务的结束点， 计时结束。这个事务的运行时间在结果中会有反映。插入事务操作可以在录制过程中进行， 也可以在录制结束后进行。LoadRunner 运行在脚本中插入不限数量的事务。具体的操作方法如下： 在需要定义事务的操作前面， 通过菜单或者工具栏插入。输入该事务的名称。注意： 事务的名称最好要有意义， 能够清楚的说明该事务完成的动作。插入事务的开始点后， 下面需要在需要定义事务的操作后面插入事务的“ 结束点”。同样可以通过菜单或者工具栏插入。默认情况下， 事务的名称列出最近的一个事务名称。一般情况下， 事务名称不用修改。事务的状态默认情况下是LR_AUTO。一般情况下， 也不需要修改， 除非在手工编写代码时， 有可能需要手动设置事务的状态。11、插入集合点。插入集合点是为了衡量在加重负载的情况下服务器的性能情况。在测试计划中， 可能会要求系统能够承受1000 人同时提交数据，在LoadRunner 中可以通过在提交数据操作前面加入集合点， 这样当虚拟用户运行到提交数据的集合点时，LoadRunner 就会检查同时有多少用户运行到集合点，如果不到1000 人，LoadRunner 就会命令已经到集合点的用户在此等待， 当在集合点等待的用户达到1000 人时，LoadRunner 命令1000 人同时去提交数据， 从而达到测试计划中的需求。注意： 集合点经常和事务结合起来使用。集合点只能插入到Action 部分，vuser_init 和vuser_end 中不能插入集合点。具体的操作方法如下： 在需要插入集合点的前面， 通过菜单或者工具栏操作输入该集合点的名称。注意： 集合点的名称最好要有意义， 能够清楚的说明该集合点完成的动作。12、插入注释。注释的作用就不多说了， 不过插入注释最好是在录制过程中。具体的操作方法如下： 在需要插入注释的前面， 通过菜单或者工具栏操作。13、参数化输入。如果用户在录制脚本过程中， 填写提交了一些数据， 比如要增加数据库记录。这些操作都被记录到了脚本中。当多个虚拟用户运行脚本时， 都会提交相同的记录， 这样不符合实际的运行情况， 而且有可能引起冲突。为了更加真实的模拟实际环境， 需要各种各样的输入。参数化输入是一种不错的方法。用参数表示用户的脚本有两个优点：① 可以使脚本的长度变短。② 可以使用不同的数值来测试脚本。例如， 如果企图搜索不同名称的图书， 仅仅需要写提交函数一次。在回放的过程中， 可以使用不同的参数值， 而不只搜索一个特定名称的值。参数化包含以下两项任务：① 在脚本中用参数取代常量值。② 设置参数的属性以及数据源。参数化仅可以用于一个函数中的参量。不能用参数表示非函数参数的字符串。另外， 不是所有的函数都可以参数化的。参数化输入的讲解， 采用一个例子的方式来进行。在本例中参数化用户的登陆名：先看如下脚本，通过脚本录制找到用户登陆部分，如图14、参数名随意取，建议取通俗易懂的名字，下面重点介绍一下参数的类型。●DateTime： 很简单， 在需要输入日期/时间的地方， 可以用DateTime 类型来替代。其属性设置也很简单， 选择一种格式即可。当然也可以定制格式。.●Group Name：暂时不知道何处能用到，但设置比较简单。在实际运行中，LoadRunner 使用该虚拟用户所在的Vuser Group 来代替。但是在VuGen 中运行时，Group Name 将会是None.●Load Generator Name： 在实际运行中，LoadRunner 使用该虚拟用户所在Load Generator 的机器名来代替。.●Iteration Number： 在实际运行中，LoadRunner 使用该测试脚本当前循环的次数来代替。.●Random Number： 随机数。很简单。在属性设置中可以设置产生随机数的范围.●Unique Number：唯一的数。在属性设置中可以设置第一个数以及递增的数的大小。注意： 使用该参数类型必须注意可以接受的最大数。例如： 某个文本框能接受的最大数为99。当使用该参数类型时， 设置第一个数为1， 递增的数为1， 但100 个虚拟用户同时运行时，第100 个虚拟用户输入的将是100，这样脚本运行将会出错。注意： 这里说的递增意思是各个用户取第一个值的递增数， 每个用户相邻的两次循环之间的差值为1。举例说明： 假如起始数为1， 递增为5， 那么第一个用户第一次循环取值1， 第二次循环取值2； 第二个用户第一次循环取值为6， 第二次为7； 依次类推。●Vuser ID： 设置比较简单。在实际运行中，LoadRunner 使用该虚拟用户的ID 来代替，该ID 是由Controller 来控制的。但是在VuGen 中运行时，Vuser ID 将会是–1。File： 需要在属性设置中编辑文件，添加内容，也可以从现成的数据库中取数据（ 下面将会介绍）●User Defined Function： 从用户开发的dll 文件提取数据。就目前我认为， 这种方式没有必要。VuGen 支持C 语言的语法，在VuGen 中重新编写类似的函数应该不难。上面的例子中， 取随机数即可。点“Properties… ..” 按钮， 进行属性设置窗口添入随机数的取值范围为（1-50）， 选择一种数据格式。在“属性” 中有以下几个选项：◆Each Occurrence：在运行时， 每遇到一次该参数， 便会取一个新的值◆Each iteration：运行时， 在每一次循环中都取相同的值◆Once：运行时， 在每次循环中， 该参数只取一次值这里我们用的是随机数， 选择Each Occurrence 非常合适。下面我们再介绍用数据库中的用户名来参数化登陆用户名。框选住登陆名，点鼠标右键，弹出对话框，选择“替换为新参数”弹出对话框，此时参数名输入：name，参数类型选择File，如图15、注意： 参数的文件名不要使用con.dat、pm.dat 或者lpt*.dat 等系统装置名下面我们将会连接数据库， 从数据表中选择用户名。点“数据向导” 按钮，显示如图16、添入连接字符串， 点“创建” 按钮，选择事先配置好的ODBC连接。在SQL语句里输入select查询语句，出现如图窗口17、提醒： 在参数数据显示区， 最多只能看到100 行， 如果数据超过100 行， 只能点“编辑” 按钮， 进入记事本看。“选择下一行 ” 有以下几种选择：●Sequential： 按照顺序一行行的读取。每一个虚拟用户都会按照相同的顺序读取●Random： 在每次循环里随机的读取一个， 但是在循环中一直保持不变●Unique ： 唯一的数。注意： 使用该类型必须注意数据表有足够多的数。比如Controller 中设定20 个虚拟用户进行5 次循环， 那么编号为1 的虚拟用户取前5 个数， 编号为2 的虚拟用户取6-10 的数， 依次类推， 这样数据表中至少要有100 个数据， 否则Controller 运行过程中会返回一个错误。“按编号”指选择列表中的那一列数据，从左到右分别是1、2、3依次通常用在有关联性的数据上面。我们这里取值Sequential 即可。完成设置关闭即可4.3 单机运行测试脚本经过以上的各个步骤后， 脚本就可以运行了。运行脚本可以通过菜单或者工具栏来操作。执行“ 运行” 命令后，VuGen 先编译脚本， 检查是否有语法等错误。如果有错误，VuGen将会提示错误。双击错误提示，VuGen 能够定位到出现错误的那一行。为了验证脚本的正确性， 还可以调试脚本， 比如在脚本中加断点等， 操作和在VC 中完全一样， 相信大家谁都不会感到陌生。如果编译通过， 就会开始运行。然后会出现运行结果。
这个问题问的有点泛。LoadRunner做压力测试也是有比较规范的流程。当然这个还是要看你做压测的目标和场景。目标和场景要从压测需求做起。例如： 需求调研和总结；测试策略和场景制定；测试环境部署；测试用例编写；测试数据准备；脚本录制和调试；场景运行设置场景加压测试测试数据分析和调优优化回归测试 当然以上只是写出测试主干过程，其中细节和要掌握的知识也不是一点点东西能说的明白，希望这点点说明能解你疑惑。
压力测试不是一次并发的数多就说明性能好的，而是要求并发数多并且持续运行一段时间后仍然没有出错，这样测试的结果才有意义的！所以你应该设置持续运行的时间，不然测试的结果不准确的。

在最近的一次测试中定义了测试的目的是：需要了解AUT（被测应用程序）一般能够承受的压力，同时能够承受的用户访问量（容量），最多支持有多少用户同时访问某个功能。在AUT中选择了用户最常用的五个功能作为本次测试的内容，包括登录。大概的需求就是这样。 接下来我AUT的登录说一说怎么用LoadRunner和Jmeter来实现场景的设置达到测试的目的。（注：对服务器的检测不是本次测试的重点，本次测试主要收集并发访问用户数和发生错误用户数）首先是对脚本的要求：1、录制脚本（注意所有的脚本都应录制到Action中），自定义事务，事务从提交用户名和口令的脚本之前开始；2、在定义事务开始的脚本前加入集合点；3、在脚本中加入检查点，以登录成功的页面出现登录用户的ID即可；4、参数化登录用户的身份；其次是对场景设置的要求：1、因为事先我们不知道将有多少用户访问是临界点，所以在测试过程中需要多次改变用户数来确定；2、建议修改运行时设置，优化对服务器的访问；3、计划的设置，每x时间后加载10用户（根据总用户数设置），完全加载后持续运行不超过5分钟（根据需要设置）；4、集合策略，当运行中的用户数100%达到集合点时释放；5、注意事项，需要注意几个时间：1）服务器响应超时时间；2）登录事务迭代一次所使用的时间；3）集合点等待超时时间；4）计划中设置的间隔时间。在我的测试中事务运行一次的时间不超过30秒，通过修改脚本使它的运行时间达到一分钟左右， 服务器响应超时时间、结合点等待超时时间、计划中设置的间隔时间都设置为了2分钟。这样场景开始运行后运行用户数呈阶梯增长，另外在每个上升点新增的用户都会随原来已经运行的用户并发访问服务器。通过多次的运行和对测试结果中正在运行用户数与错误用户的对比，然后根据定义可接受错误率就可得到该功能的最大并发访问的用户数。以上测试中排除了对网络、客户端等的要求。在实际测试中首先要保证这些资源是足够的。使用Jmeter也能够达到上述描述的场景的测试，并且更加的便捷。抄来的 随便看看吧
哼，还不是为了你好，你要嘛，俺又不会，那就抄个来给你看看啦 好心没好报

在“服务器名称或ip”设置127.0.0.1，端口号设置:8080，“方法”设置post，路径设置网站登录的地址，如“/exam/operatorAction”。登录需传入用户、密码。在“同请求一起发送参数”列表中添加参数。参数值根据web应用设置。如login_user=0001;login_password=1;actFlag=login。一般网站登录后，在tomcat中生成了session，之后访问其他页面将无需再次登录，前提是浏览器需支持cookie。在jmap中也同样，如要继续访问其他页面，还需做下面关键的设置。Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试，它最初被设计用于Web应用测试，但后来扩展到其他测试领域。 它可以用于测试静态和动态资源，例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器， 等等。JMeter 可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。
ApacheBench是Apache bin目录下附带的一个小工具，专门用来做HTTP服务器的Benchmark Testing，这玩意儿可以单独运行，可以到这儿直接下载了用 Apache Bench，下载后，将ab文件copy到 /usr/local/bin 目录即可。 工具/原料ApacheBench方法/步骤比较常用的命令，如：ab -n 请求数 -c 并发数 URL跑了一个简单的Demo：usertekiMacBook-Pro:~ zhaoxianlie$ ab -n 200 -c 10http://127.0.0.1:8793/This is ApacheBench, Version 2.3 <$Revision: 1554214 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd,http://www.jinbanz.com/Licensed to The Apache Software Foundation,http://www.apache.org/Benchmarking 127.0.0.1 (be patient) Completed 100 requests Completed 200 requests Finished 200 requests Server Software: Server Hostname:127.0.0.1 Server Port:8793 Document Path:/ Document Length:28012 bytes Concurrency Level:10 Time taken for tests: 6.847 seconds Complete requests:200 Failed requests:0 Total transferred:5665503 bytes HTML transferred: 5601103 bytes Requests per second:29.21 [#/sec] (mean) Time per request: 342.343 [ms] (mean) Time per request: 34.234 [ms] (mean, across all concurrent requests) Transfer rate:808.07 [Kbytes/sec] received Connection Times (ms)minmean[+/-sd] median max Connect:00 0.10 1 Processing: 14833893.2335 633 Waiting:14833793.3335 633 Total:14833893.2336 634 Percentage of the requests served within a certain time (ms)50%33666%37175%39780%41390%46195%50098%56899%610 100%634 (longest request)3这其中Requests per second、Time per request算是大家都比较看重的两个评估参数了吧。不过对于这种压力测试来说，也不能一上来就 -n 1000 -c 10，还是得慢慢来，一开始可以来一个 -n 50 -c 10这样子，逐渐网上增加，取Request per second的最大值作为Http server的性能指标，应该会靠谱一些。假设我的这个测试服务器RPS峰值是30，那一分钟能扛过来的请求差不多 1800 个，这是单核CPU的情况下。假设是我厂服务器的配置，24核，开启Node的cluster模式，RPS应该是倍数增加的，明天去公司找台服务压测一把。如果真是这样，那么每秒钟能扛过来的请求差不多 720 个，换算到一个小时，是259.2w个访问请求。 假设服务器配置是Nginx+Node，Nginx做负载均衡，proxy_pass对应的upstream配置到4台Node服务器，且每台Node服务器均衡负载，那么，一个小时能扛得动的流量基本是 1kw多一些，满负荷跑一天，2.4亿的流量了。

一个压力测试的流程： 1、明确测试目标2、制定测试计划3、实施测试，收集参数4、分析测试结果5、给出优化方案一、明确测试目标：如果是客户的需求，那需要向客户确认，有清楚的性能指标参数，测试时就是保证系统达到该指标并能良好运转，即压力测试。如果是自己的系统需要有一个评估，那就需要完整的得到该系统的几个临界点，拿到完整的性能曲线，从而来分析部署情况，即为性能测试。不管是哪个，知道了需求，才能制定计划。性能测试的目标是发现重大的系统瓶颈。你可以想象一个系统由一系列的瓶颈组成；发现并改善一个瓶颈往往会在其他地方产生一个新的瓶颈。例如，我曾为一运行微软WindowsCE的器件部门工作。我们发现的第一大性能问题体现在某一具体硬件环境下的内存管理中。我们把问题分离出来，改善了内存分配的效率。尔后再次运行我们的测试，又找到了一个新的瓶颈，这次体现在网络吞吐量上（throughput）。解决了这个问题后，我们接着又为下一个瓶颈改善而工作，然后再下一个，直到整个系统都达到了性能目标。要记住的是：关键在于要尽早订立性能目标，否则你可能不知道什么时候该停止性能测试。二、制定测试计划：确定使用什么工具，着重哪些参数，设置线程数，方法执行次数，执行时间，是否多个接口同时进行测试等等。三、实施测试，收集参数：选一个施压工具，来向部署好的服务发起高并发请求，同时关注和收集性能参数。这个是我们花费时间最多的地方。通常该阶段需要反复执行，来得到想要的数据。通常来说，我们可以使用JMeterLRAB自己写多线程等各种方式，之后介绍一下JMeter。四、分析测试结果：即根据上一节的参数介绍来进行参数分析。 五、给出优化方案：如果是代码逻辑耗费cpu，就优化算法；如果是redis等数据库耗时，就增加节点，减少读取，读写分离，使用内存等；如果是外在条件限制，则与外部们沟通问题，共同优化等等。

你好，一个完整的压力测试需要关注三个方面：如何正确产生压力、如何定位瓶颈、如何预估系统的承载能力 (1)首先说一下如何产生压力，产生压力的方法有很多，通常可以写脚本产生压力机器人对服务器进行发包和收包操作，也可以使用现有的工具(像jmeter、LoadRunner这些），所以说产生压力其实并不难，难点在于产生的压力是不是真实地反映了实际用户的操作场景。举个例子来说，对游戏来说单纯的并发登陆场景在整个线上环境中的占比可能并不大(新开服等特殊情况除外)，相反“登陆-开始战斗-结束战斗”、不同用户执行不同动作这种“混合模式”占了更大的比重。所以如何从实际环境中提炼出具体的场景比重，并且把这种比重转化成实际压力是一个重要的关注点。(2)产生压力之后，通常我们可以拿到TPS、响应时延等性能数据，那么如何定位性能问题呢？TPS、响应时延只能告诉你服务器是否存在问题，但不能帮助你定位问题。这些表面背后是整个后台处理逻辑综合作用的结果，这时候可以先关注系统的CPU、内存、IO、网络，对比在tps、时延达到瓶颈时这些系统数据的情况，确定性能问题是系统哪一部分造成的，然后再回到代码的逻辑中逐个优化这些点。(3) 当服务器的整体性能就可以相对稳定下来，这时候就需要对自己服务器的承载能力有一个预估，通过产生真实压力、对比系统数据，大致可以对单套系统的处理能力有个真实的评价，然后结合业务规模配置服务器数量。