LoadRunner之并发用户数与迭代关系

Loadrunner名词解释

1Loadrunner名词解释响应时间:应用系统发出请求开始到收到服务器所有响应所耗费的时间;并发用户量: 同一时刻与服务器交互的所有用户数量;在线用户数：即同时在使用应用系统的用户，可能在浏览，可能在做交易。

并发用户怎么计算:●一般并发用户数取在线用户的10%-30%。

●八二原则：一般可以认为80%的用户在20%的时间内完成工作，所以峰值压力的时候，一般并发数要乘以80%/20%=4●Loadrunner里计算公式（1）计算平均的并发用户数：C = nL/T（2）并发用户数峰值：C’ ≈ C+3根号C公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session 的平均长度；T指考察的时间段长度。

公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。

该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。

事务响应时间:处理一个事物花费的时间，包含网络传输时间和服务器处理事务的时间TPS: 每秒处理事务数量资源利用率: Cpu、内存、磁盘io、网络的使用情况;思考时间: 用户进行操作时,每个请求之间的时间间隔2性能测试包含了哪些软件负载测试：通过对被测系统不断加压，直到超过预定的指标或者部分资源达到了饱和不能再加压为止，就像举重的过程中不断加杠铃的重量，知道运动员不能举起。

压力测试：给系统增加一定的压力，在一定的压力下测试的cpu、内存、磁盘、网络使用情况，也即业务能否正常使用；并发测试：通过模拟用户并发访问，测试系统是否存在死锁、系统处理速度是否下降的比较厉害等问题；可靠性测试：在一定的业务压力下，让系统运行一段较长的时间，看系统能否无故障运行；3简述使用软件测试工具Loadrunner的步骤制定性能测试计划—>开发测试脚本—>设计测试场景—>执行测试场景—>监控测试场景—>分析测试结果4什么时候可以开始执行性能测试功能测试通过；一般需要进行性能测试的系统，都是用户量比较大、业务使用比较频繁、比较重要的功能模块。

系统吞吐量（TPS）、用户并发量、性能测试概念和公式

系统吞吐量（TPS）、⽤户并发量、性能测试概念和公式⼀．系统吞度量要素：⼀个系统的吞度量（承压能⼒）与request对CPU的消耗、外部接⼝、IO等等紧密关联。

单个reqeust 对CPU消耗越⾼，外部系统接⼝、IO影响速度越慢，系统吞吐能⼒越低，反之越⾼。

系统吞吐量⼏个重要参数：QPS（TPS）、并发数、响应时间QPS（TPS）：每秒钟request/事务数量并发数：系统同时处理的request/事务数响应时间：⼀般取平均响应时间（很多⼈经常会把并发数和TPS理解混淆）理解了上⾯三个要素的意义之后，就能推算出它们之间的关系：QPS（TPS）= 并发数/平均响应时间⼀个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有⼀个相对极限值，在应⽤场景访问压⼒下，只要某⼀项达到系统最⾼值，系统的吞吐量就上不去了，如果压⼒继续增⼤，系统的吞吐量反⽽会下降，原因是系统超负荷⼯作，上下⽂切换、内存等等其它消耗导致系统性能下降。

决定系统响应时间要素我们做项⽬要排计划，可以多⼈同时并发做多项任务，也可以⼀个⼈或者多个⼈串⾏⼯作，始终会有⼀条关键路径，这条路径就是项⽬的⼯期。

系统⼀次调⽤的响应时间跟项⽬计划⼀样，也有⼀条关键路径，这个关键路径是就是系统影响时间；关键路径是有CPU运算、IO、外部系统响应等等组成。

⼆．系统吞吐量评估：我们在做系统设计的时候就需要考虑CPU运算、IO、外部系统响应因素造成的影响以及对系统性能的初步预估。

⽽通常境况下，我们⾯对需求，我们评估出来的出来QPS、并发数之外，还有另外⼀个维度：⽇PV。

通过观察系统的访问⽇志发现，在⽤户量很⼤的情况下，各个时间周期内的同⼀时间段的访问流量⼏乎⼀样。

⽐如⼯作⽇的每天早上。

只要能拿到⽇流量图和QPS我们就可以推算⽇流量。

通常的技术⽅法：1. 找出系统的最⾼TPS和⽇PV，这两个要素有相对⽐较稳定的关系（除了放假、季节性因素影响之外）2. 通过压⼒测试或者经验预估，得出最⾼TPS，然后跟进1的关系，计算出系统最⾼的⽇吞吐量。

LoadRunner常见测试结果分析（转）

LoadRunner常见测试结果分析（转）
在测试过程中，可能会出现以下常见的几种测试情况：
一、当事务响应时间的曲线开始由缓慢上升，然后处于平衡，最后慢慢下降这种情形表明：
* 从事务响应时间曲线图持续上升表明系统的处理能力在下降，事务的响应时间变长；
* 持续平衡表明并发用户数达到一定数量，在多也可能接受不了，再有请求数，就等待；
* 当事务的响应时间在下降，表明并发用户的数量在慢慢减少，事务的请求数也在减少。

如果系统没有这种下降机制，响应时间越来越长，直到系统瘫痪。

从以上的结果分析可发现是由以下的原因引起：
1. 程序中用户数连接未做限制，导致请求数不断上升，响应时间不断变长；
2. 内存泄露；
二、CPU的使用率不断上升，内存的使用率也是不断上升，其他一切都很正常；
表明系统中可能产生资源争用情况；
引起原因：
开发人员注意资源调配问题。

三、所有的事务响应时间、cpu等都很正常，业务出现失败情况；
引起原因：
数据库可能被锁，就是说，你在操作一张表或一条记录，别人就不能使用，即数据存在互斥性；
当数据量大时，就会出现数据错乱情况。

loadrunner中各性能指标解释

Transactions（用户事务分析）用户事务分析是站在用户角度进行的基础性能分析。

1、Transation Sunmmary（事务综述）对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。

2、Average Transaciton Response Time（事务平均响应时间）“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。

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

3、Transactions per Second（每秒通过事务数/TPS）“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。

通过它可以确定系统在任何给定时刻的时间事务负载。

分析TPS主要是看曲线的性能走向。

将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。

例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。

4、Total Transactions per Second（每秒通过事务总数）“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。

5、Transaction Performance Sunmmary（事务性能摘要）“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。

重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。

6、Transaction Response Time Under Load（事务响应时间与负载）“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。

LoadRunner使用总结报告

在打开的Launcher窗口中，选择Create/Edit Scripts菜单，打开虚拟用户脚本生成器。
打开协议新建协议通过模板新建协议
快捷工具栏
协议顾问
最近使用的协议
最近使用的脚本
打开新建脚本窗口，选择协议，并创建新的脚本。
从本地硬盘打开已保存的脚本。
根据已有脚本模板创建新的脚本。
打开录制窗口，录制用户操作，系统会自动判断使用使用的协议，有可能有多个协议，但系统建议的协议并不一定是最优协议。
LoadRunner包含以下组件： Virtual User Generator：虚拟用户生成器。录制最终用户业务流程并创建自动化性能测试脚本，即Vuser脚本。
Controller：组织、驱动、管理并监控负载测试。
Load Generator：通过运行Vuser产生负载。负载生成器可以在别的计算机上安装，然后在测试机通过Controller连接。 Analysis：用于查看、剖析和比较性能结果。 Launcher：使用户可以从单个访问点访问所有LoadRunner组件。
Comment：注释。为代码或者方法、类添加注释。 Log Message：通过LR的日志系统输出日志。
New Parameter：创建参数化新参数。
Toggle Breakpoint：设置当前行为断点，当在脚本编辑窗口，通过运行命令，程序执行到当前行时挂起，和eclipse的breakpoint 是一样的功能。
如果不设置Pacing时间，即在上次循环结束后，立即进入下次循环，可能会出现因为请求在排队，没有进入执行状态，而导致的事务相应时间很长，甚至超时。这样得到的最终相应时间，包含了队列等待时间，会导致结果不准确。设置Pacing后，会减轻服务器压力，得到的测试结果是服务器非极限状态下的数据。

LoadRunner-迭代和并发设置

LoadRunner-迭代和并发设置
迭代：指运⾏⼀次脚本时某段代码块(action)循环执⾏的次数，串⾏执⾏
并发：指同时运⾏脚本的次数，并⾏执⾏（多个⽤户同时跑）
以下是⽤例和对应的相关设置
Iterations是在Vuser Generator的Run-time Setting中进⾏设置
Quantity是在Controller Scenario中进⾏设置
其余是在Parameter List 中进⾏设置
1.select next row：参数值取值的顺序
Sequential（顺序），Random(随机)，Unique（唯⼀）三个选项；如果要求使⽤不同的账号登录则设置为Unique；
如果构造的账号数不够⼜对⽤户是否相同不做要求，则可以设置Sequential，参数调到最后⼀列后再从第⼀列开始调⽤。

2.update value on ： (什么事件)触发参数取值更换
each iteration：进⼊⼀个迭代更换⼀次参数值；（sequential时）每个迭代不同⽤户使⽤相同参数值（不管并发是多少）；(unique时)每个迭代不同⽤户使⽤不同值
each occurence :脚本中每次变量出现就换⼀个新值，谨慎⽤，⽤于账号肯定不⾏。

（⽐如user1登录user2权限操作）
once:只取⼀个值(不管并发和迭代是多少)。

LoadRunner中Action的迭代次数的设置和运行场景中设置

LoadRunner中Action的迭代次数的设置和运⾏场景中设置LoadRunner中Action的迭代次数的设置和运⾏场景中设置是怎么重复迭代和怎么增加并发运⾏的呢？另外，在参数化时，对于⼀次压⼒中均只能⽤⼀次的资源应该怎么参数化呢？就是说这些资源⽤了⼀次就不能在⽤了的。

－－参数化时,在select next row选择unique,update value on选择 each occurence, 1. 迭代跟虚拟⽤户数没什么必然联系迭代是这样的：迭代1次迭代2次迭代3次⽤户1 X1 X2 X3 ⽤户2 Y1 X2 Y3 其中的X1-3 Y1-3是参数，参数规则就是⼆楼说的这么两个⽤户是根据你的rump up 上来的，⽐如5秒上两个⽤户，那么⽤户1和2就在5秒之内加载进来的，不知道说清楚了没。

第⼆个问题就简单了，只能⽤⼀次的参数，⾸先确保你的参数⾜够，另外规则选择的时候，注意选择唯⼀迭代次数只是对你设置了迭代次数的action进⾏迭代，⽽⽤户数可以理解为对整个录制过程的迭代（只是各个⽤户不同）　⽽且增加并发量可以通过增加⽤户来达到　还可以设置集合点来增加某个操作的并发量假如⼀个脚本，设置最⼤并发量为10，每5秒中增加2个并发⽤户，⽽Action设置的迭代为10次：当开始⾄2秒时，加载了2个⽤户，这2个⽤户分别开始运⾏，并都运⾏10次，不管这个2个⽤户运⾏10次是否结束，当下⼀个2两秒到来时，即开始⾄第4秒时⼜加载了2个⽤户，这2个⼜运⾏10次；就这样⼀直加载到10个并发⽤户，然后当每个⽤户都运⾏完10次时就结束。

这样中间最⼤并发是10个，但不⼀定能达到10个，因为在加载最后⼏个时，前⾯的有可能已经运⾏结束，所以如果要真正达到最⼤并发10就必须设置集合点来完成不过也不⼀定⾮要设置集合点才能实现同时处在running的状态有10个⽤户。

设置duration也是可以的。

探讨LoadRunner的并发用户和集合点

探讨LoadRunner的并发用户和集合点近来跟踪一个项目，发现同事们在执行性能测试时，比较热衷于使用集合点，从概念上认为要得到并发用户就必须设置集合点，认为在执行一个压力测试脚本时，设置了集合点才算是有效的并发用户，没有设置结合点，就认为可能这个就不能准确的代表并发用户数。

当前我并反对这个观点，不过却让我有一种疑虑，促使我想更深入的理解并发用户和集合点，我相信大多数进入性能测试研究领域的朋友都应该有疑惑，主要原因我觉得还是由于不能深入理解LoadRunner的实现原理，而且缺乏对系统整个过程的分析，其中这里面涉及到的知识包括网络、协议、中间件、数据库、应用层以及缓冲区和缓存等等，当然还与硬件资源CPU队列和内存等有着千丝万缕的联系。

所以说要成为一个优秀的性能测试人员，真还不一个容易的过程，是需要长时间积累和学习的，只有通过大量的项目实践和分析，最后再总结于思想，才有可能成为这个领域的专家，当然也希望真正想把性能测试做好的朋友都能为此将不懈努力，乐于分享和讨论。

先来看一个应用系统的结构图，如下所示：这个图源于小布老师的视频中，比较直观、简洁地反映了一个应用系统的运行过程，其中包括客户端、网络、应用服务器和数据库服务器，其中每一个环节都是在执行性能测试分析中必不可少的元素，结构图中也合理得分析出了响应时间的处理过程，当请求从客户端发出之后到最后返回到客户端，这个过程中每一个环节的处理都有可能最后成为系统运行中的性能瓶颈，所以可见对系统整体结构的理解是何等重要。

接下来我们来看看关于并发用户和集合点的定义：并发用户：通俗意义上讲就是同时操作的用户，当然这个“同时”可以理解为同一时间段，还可以理解为同一时间点，当然如果说并发就是同一时间点上同时操作的用户，这样理解没有错误，但对于实际情况来讲，是没有严格意义上的并发执行的，就如同进程和线程关系一样，在某一个点严格上讲就只有一个人得到执行的权利。

集合点：用以同步虚拟用户，以便恰好在同一时刻执行任务。

软件性能测试模拟笔试题目（一）

软件性能测试模拟笔试题⽬（⼀）注：本试卷中题⽬所涉及性能测试⼯具如⽆特殊说明则均为LoadRunner。

⼀、简答题（2*10=20分）1. 1. 客户交付⼀个性能测试项⽬，请阐述你的实施流程。

2. 2. 解释5个常⽤的性能指标的名称与具体含义。

3. 3. 写出5个Loadrunner中常⽤函数，并对其中2个举例说明⽤法。

4. 4. 简述LoadRunner的⼯作原理？5. 5. 什么是集合点？设置集合点有什么意义？LoadRunner中设置集合点的函数是哪个？6. 6. HTML-based script与URL-based script的脚本有什么区别？7. 7. 如何设置LaodRunner才能让集合点只对⼀半的⽤户⽣效？8. 8. LoadRunner的Controller组件中Pacing参数的作⽤是什么？9. 9. LoadRunner中如何监控Windows资源？10. 10. 如果让QALoad模拟LoadRunner中只对关注的性能点进⾏迭代测试，你有什么好⽅法？11. 11. 什么是负载测试？12. 12. 什么是性能测试？13. 13. 说明负载测试过程？14. 14. 我们什么时候做负载和性能测试？15. 15. 什么是LoadRunner的组件？16. 16. 你⽤LoadRunner的哪个组件录制脚本？17. 17. 在多⽤户模式下你⽤LoadRunnner的哪个组件来回放脚本？18. 18. 在多⽤户模式下你⽤LoadRunnner的哪个组件来回放脚本？19. 19. 什么是场景20. 20. 解释Web Vuser脚本的录制模式21. 21. 为什么创建参数?22. 22. 什么是关联？解释⾃动关联和⼿动关联的区别23. 23. 什么是关联？解释⾃动关联和⼿动关联的区别24. 24. 你在哪⾥设置⾃动关联的选项25. 25. 什么函数可以捕捉到web Vuser脚本的动态值？26. 26. 什么时候你在虚拟⽤户产⽣器中禁⽤⽇志，什么时候选择标准⽇志和扩展⽇志？27. 27. 你如何调试LoadRunner的脚本？28. 28. 你怎么写LR中⽤户⾃定义的函数？写⼏个你以前项⽬中的函数？29. 29. 在run-time setting⾥你可以设置哪些改变？30. 30. 你在哪⾥设置Vuser测试时迭代？31. 31. 你如何在负载下执⾏功能测试？32. 32. 什么是Ramp up？你如何设置？33. 33. Vuser作为线程运⾏的优势是什么？34. 34. 如果你想停⽌执⾏出错的脚本，怎么做？35. 35. 响应时间和吞吐量间的关系是什么？36. 36. 你如何识别性能瓶颈？37. 37. 如果web服务器、数据库服务器、⽹络都⼀切正常，那么哪⾥可能有问题？38. 38. 你如何找出web服务器相关的问题？39. 39. 你是怎么找到数据库中的相关问题？40. 40. 覆盖图和关联图之间的区别是什么？41. 41. 你是怎么计划负载的？标准是什么？42. 42. vuser_init动作包含什么？43. 43. vuser_end动作包含什么？44. 44. 什么是Think Time？你如何改变这个阈值？45. 45. 简述使⽤Loadrunner的步骤46. 46. 什么是集合点？设置集合点有什么意义？Loadrunner中设置集合点的函数是哪个？47. 47. 请解释⼀下如何录制web脚本？48. 48. 请解释⼀下⾃动关联和⼿动关联的不同。

LoadRunner参数化设置：数据分配与取值方式

LoadRunner参数化设置：数据分配与取值⽅式参数化设置中有九种取值⽅式：（以⽤户名参数user为例，其数据参数列表为：jojo、201401、201402、201403、201405、201406、201407、201408、201409，迭代次数设置为10次） 1、Sequential+Each Iteration 脚本会执⾏10次，每次迭代会按数据列表顺序取值，每⼀次迭代中出现的参数user的值是当前第⼀次参数替换的值。

第1次迭代均为jojo，以此类推。

2、Sequential+Each Occurrence 脚本执⾏10次，每次迭代中出现参数user，顺序取值⼀次，第1次迭代中出现3次user,则user取值为jojo、201401、201402，等到取值到201409，下次会从第⼀个数顺序取值。

3、Sequential+Once 脚本执⾏10次，user只取值⼀次，每次出现的user替换参数值都是jojo。

4、Random+Each Iteration 脚本执⾏10次，数据表中的数据随机取，⽐如第⼀次迭代取值201405，则这次迭代中出现参数user地⽅则⽤201405替代。

5、Random+Each Occurrence 脚本执⾏10次，数据表中的数据随机取，迭代过程中只要出现参数user的地⽅就随机取值⼀次。

第1次迭代出现3次user，则随机数为201407、jojo、201403。

6、Random+Once 脚本执⾏10，数据表中数据随机取值，参数user只取值⼀次，10次迭代过程中出现参数user的地⽅都是⽤随机取值（⽐如201406）替代。

7、Unique+Each Iteration 每个⽤户对应⼀次数据，当迭代次数超过⽤户数据量，根据设置情况处理情况，如下图所⽰：每次迭代出现的参数user⽤当前取值替代。

8、Unique+Each Occurrence 当前有9条数据，没出现⼀次参数user，只能⽤⼀个数值替代，9条数据取完之后根据设置超出值处理。

LoadRunner用户数计算公式

“并发用户数”、“系统用户数”和“同时在线用户数”的计算公式与并发用户数相关的概念还包括“并发用户数”、“系统用户数”和“同时在线用户数”，下面用一个实际的例子来说明它们之间的差别。

假设有一个OA系统，该系统有2000个使用用户——这就是说，可能使用该OA系统的用户总数是2000名，这个概念就是“系统用户数”，该系统有一个“在线统计”功能（系统用一个全局变量记数所有已登录的用户），从在线统计功能中可以得到，最高峰时有500人在线（这个500就是一般所说的“同时在线人数”），那么，系统的并发用户数是多少呢？根据我们对业务并发用户数的定义，这500就是整个系统使用时最大的业务并发用户数。

当然，500这个数值只是表明在最高峰时刻有500个用户登录了系统，并不表示实际服务器承受的压力。

因为服务器承受的压力还与具体的用户访问模式相关。

例如，在这500个“同时使用系统”的用户中，考察某一个时间点，在这个时间上，假设其中40%的用户在较有兴致地看系统公告（注意：“看”这个动作是不会对服务端产生任何负担的），20%的用户在填写复杂的表格（对用户填写的表格来说，只有在“提交”的时刻才会向服务端发送请求，填写过程是不对服务端构成压力的），20%部分用户在发呆（也就是什么也没有做），剩下的20%用户在不停地从一个页面跳转到另一个页面——在这种场景下，可以说，只有20%的用户真正对服务器构成了压力。

因此，从上面的例子中可以看出，服务器实际承受的压力不只取决于业务并发用户数，还取决于用户的业务场景。

在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也就是从业务角度关注究竟应该设置多少个并发数比较合理，因此，在后面的讨论中，也是主要针对业务并发用户数进行讨论，而且，为了方便，直接将业务并发用户数称为并发用户数。

（1）计算平均的并发用户数：C = nL/T（2）并发用户数峰值：C’ ≈ C+3根号C公式（1）中，C是平均的并发用户数；n是login session 的数量；L是login session的平均长度；T指考察的时间段长度。

loadrunner结果分析：analysis

六.结果分析

监控指标数据分析 1.最大并发用户数：应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。
三.新加监控图

通过graph—add new graph或者在会话浏览器窗口右击选择add new item—add new graph来打开新加监控图页面新加监控图页面默认显示监控到数据的部分资源，可以将右上角的display only graphs containting data不选查看所有资源。常用的5种资源是：vuser、transactions、web resources、web page breakdown、system resources 点击工具栏上的合并图按钮，可选择两个不同的监控图进行合并查看
内存资源成为系统性能的瓶颈的征兆: 很高的换页率(high pageout rate); 进程进入不活动状态; 交换区所有磁盘的活动次数可高; 可高的全局系统CPU利用率; 内存不够出错(out of m分析 4.处理器： UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server, 可接受的最大上限是80-85% 合理使用的范围在60%至70%。 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。 CPU资源成为系统性能的瓶颈的征兆: 很慢的响应时间(slow response time) CPU空闲时间为零(zero percent idle CPU) 过高的用户占用CPU时间(high percent user CPU) 过高的系统占用CPU时间(high percent system CPU) 长时间的有很长的运行进程队列(large run queue size sustained over time)

loadrunner性能测试结果分析实战

▪测试结果分析LoadRunner性能测试结果分析是个复杂的过程，通常可以从结果摘要、并发数、平均事务响应时间、每秒点击数、业务成功率、系统资源、网页细分图、Web服务器资源、数据库服务器资源等几个方面分析，如图1- 1所示。

性能测试结果分析的一个重要的原则是以性能测试的需求指标为导向。

我们回顾一下本次性能测试的目的，正如所列的指标，本次测试的要求是验证在30分钟内完成2000次用户登录系统，然后进行考勤业务，最后退出，在业务操作过程中页面的响应时间不超过3秒，并且服务器的CPU使用率、内存使用率分别不超过75%、70%，那么按照所示的流程，我们开始分析，看看本次测试是否达到了预期的性能指标，其中又有哪些性能隐患，该如何解决。

图1- 1性能测试结果分析流程图▪结果摘要LoadRunner进行场景测试结果收集后，首先显示的该结果的一个摘要信息，如图1- 2所示。

概要中列出了场景执行情况、“Statistics Summary（统计信息摘要）”、“Transaction Summary（事务摘要）”以及“HTTP Res ponses Summary（HTTP响应摘要）”等。

以简要的信息列出本次测试结果。

图1- 2性能测试结果摘要图场景执行情况该部分给出了本次测试场景的名称、结果存放路径及场景的持续时间，如图5- 3所示。

从该图我们知道，本次测试从15:58:40开始，到16:29:42结束，共历时31分2秒。

与我们场景执行计划中设计的时间基本吻合。

图1- 3场景执行情况描述图Statistics Summary（统计信息摘要）该部分给出了场景执行结束后并发数、总吞吐量、平均每秒吞吐量、总请求数、平均每秒请求数的统计值，如图5- 4所示。

从该图我们得知，本次测试运行的最大并发数为7，总吞吐量为842,037,409字节，平均每秒的吞吐量为451,979字节，总的请求数为211,974，平均每秒的请求为113.781，对于吞吐量，单位时间内吞吐量越大，说明服务器的处理能越好，而请求数仅表示客户端向服务器发出的请求数，与吞吐量一般是成正比关系。

Loadrunner_参数化_迭代参数说明

Loadrunner参数化策略测试小组齐国杰使用工具：Loadrunner 8.1试用版引子近日没有具体的项目做，就总去泡论坛，发现有的网友会问一些参数化的问题，回答他们的问题时，突然发现自己也是一知半解，因此写了三个实验脚本，目的是彻底搞清楚参数化的做法以及参数化策略的疑问。

流程参数化要做一些准备，主要是参数化数据的准备，例如TXT文本、EXCEL表格以及数据库中的表都可以作为参数的数据集载体，而且LR都是支持的。

具体的参数化流程如下：1、录制脚本2、准备参数的数据集（也可以不准备，让LR自己生成固定格式参数）3、把对应的变量参数化4、选择对应的参数化策略具体的操作请查询LR帮助手册例子下面我来介绍几个例子，例子统一使用try_params.txt做参数数据集，txt内容如下：aaa bbba1 b1a2 b2……a30 b30脚本一：Action(){char *a = "{aaa}"; //获得参数赋值给achar *b = "{bbb}";//获得参数赋值给blr_log_message("%s,%s,%s,",lr_eval_string (a),lr_eval_string (b),ctime(&t));//打印结果return 0;}运行时设置：设置action的迭代次数为30（runtime-setting的Run Logic里）备注：“…,…”省略符号，如果前后都相同则省略相同部分，如果前后不同则省略不同部分。

脚本二：Action(){int i; //循环种子for (i=0;i<30;i++) //循环30次{char *a = "{aaa}"; //获得参数赋值给achar *b = "{bbb}";//获得参数赋值给blr_log_message("%s,%s\n",lr_eval_string (a),lr_eval_string (b));}//打印结果return 0;}运行时设置：设置action的迭代次数为1（runtime-setting的Run Logic里）回放结果：脚本三：Action(){char *filename = "C:\\work\\log\\try_params.log";typedef long time_t;time_t t;char *a = "{aaa}";char *b = "{bbb}";long fileopen;if ((fileopen = fopen(filename,"a+")) == NULL) {lr_error_message ("file isn't open,path=%s",filename);return 0;}time(&t);fprintf(fileopen,"%s,%s,%s",lr_eval_string (a),lr_eval_string (b),ctime(&t));fclose(fileopen);return 0;}运行时设置：设置action的迭代次数为1（runtime-setting的Run Logic里）场景设置：不更改任何场景策略，运行vuser数为30备注：“…,…,…”省略符号，如果前后都相同则省略相同部分，如果前后不同则省略不同部分。

指标关系：你知道并发用户数应该怎么算吗

指标关系：你知道并发⽤户数应该怎么算吗性能综述的那三篇⽂章中，描述了各种指标，⽐如TPS、RPS、QPS、HPS、CPM等。

我也强调了，我们在实际⼯作的时候，应该对这些概念有统⼀的认识。

这样的话，在使⽤过程中，⼀个团队或企业从上到下都具有同样的概念意识，就可以避免出现沟通上的偏差。

我说⼀个故事。

我以前接触过⼀个咨询项⽬。

在我接触之前，性能测试团队⼀直给⽼板汇报着⼀个数据，那就是10000TPS。

并且在每个版本之后，都会出⼀个性能测试报告，⽼板⼀看，这个数据并没有少于10000TPS，很好。

后来，我进去⼀看，他们⼀直提的这个10000TPS指的是单业务的订单，并且是最基础的订单逻辑。

那么问题来了，如果混合起来会怎么样呢？于是我就让他们做个混合容量场景，显然，提容量不提混合，只说单接⼝的容量是不能满⾜⽣产环境要求的。

结果怎么样呢？只能测试到6000TPS。

于是我就要去跟⽼板解释说系统达到的指标是6000TPS。

⽼板就恼⽕了呀，同样的系统，以前报的⼀直是10000TPS，现在怎么只有6000TPS了？不⾏，你们开发的这个版本肯定是有问题的。

于是⽼板找到了研发VP，研发VP找到了研发经理，研发经理找了研发组长，研发组长⼜找到了开发⼯程师，开发⼯程师找到了我。

我说之前不是混合场景的结果，现在混合容量场景最多达到6000TPS，你们可以⾃⼰来测。

然后证明，TPS确实只能达到6000。

然后就是⼀轮⼜⼀轮的向上解释。

说这个故事是为了告诉你，你⽤TPS也好，RPS也好，QPS也好，甚⾄⽤西夏⽂来定义也不是不可以，只要在⼀个团队中，⼤家都懂就可以了。

但是，在性能市场上，我们总要⽤具有普适性的指标说明，⽽不是⽤混乱的体系。

在这⾥，我建议⽤TPS做为关键的性能指标。

那么在今天的内容⾥，我们就要说明⽩TPS到底是什么。

在第3篇⽂章中，我提到过在不同的测试⽬标中设置不同的事务，也就是TPS中的T要根据实际的业务产⽣变化。

那么问题⼜来了，TPS和并发数是什么关系呢？在并发中谁来承载”并发“这个概念呢？说到这个，我们先说⼀下所谓的“绝对并发”和“相对并发”这两个概念。

LoadRunner之并发用户数与迭代关系

Q1:
例如在LR里，要测100个用户同时并发登陆所用时间，是不是在录制好脚本后，需要参数化“用户名”，“密码”以及在那个记事本里构造100个真实的用户名和密码？然后运行Controller，设置用户数为100？
A:说的是对的。

但是测并发数的时候，本身就是模拟的虚拟用户，所以认为不一定非要参数化100个用户，用一个用户跑100遍也是可以的。

当然这样进行设置的话更符合实际情况。

Q2:那么这里的迭代次数该怎么设啊，设成1和设成10有什么区别啊？搞不清测试并发用户，“迭代”和“并发用户数”（就是controller里设的虚拟用户数）的区别。

A:
迭代次数如果设置为1，那么你的脚本就只跑100遍（续Q1）,如果你设置为100，那么当你设置并发数为100，那么脚本就要跑100*100=10000 遍。

当然这种情况是在没有设置Conrtoller中的durantion，如果设置了这个场景的持续时间，那么你运行的场景时间就以这个时间结束为准，和迭代次数就没有关系了。

Q3:假如用LR测100个用户同时注册一个网站的帐号，参数化了100个用户名和密码，那么跑一遍脚本，并跑通了，并在controller里也run了一遍，那么这100个新增帐号是不是就真在数据库里添加了啊？
A:是的，如果脚本没问题的话，那么数据库里肯定会有100条记录的。

可以自己查看数据库，或者访问你录制的脚本网站，都能看到相应的记录。

Q4:对于并发数更多的情况下呢，例如并发数是1000，那是不是应该在多个机器上运行才可以阿？
A:不一定啊，如果你有条件的话，当然多台机器运行得出的结果更为准确，但是用LR如果是录制web应用程序的话，最大并发数可以到10000的。

并发用户数、吞吐量、思考时间的计算公式

并发用户数、吞吐量、思考时间的计算公式二、软件性能的几个主要术语1、响应时间：对请求作出响应所需要的时间。

在所有加载的用户稳定运行后，目标系统平均完成客户端用户请求的一个交易的总时长网络传输时间：N1+N2+N3+N4应用服务器处理时间：A1+A3数据库服务器处理时间：A2响应时间=N1+A1+N2+A2+N3+A3+N42、并发用户数的计算公式系统用户数：系统额定的用户数量，如一个OA系统，可能使用该系统的用户总数是2000个，那么这个数量，就是系统用户数同时在线用户数：在一定的时间范围内，最大的同时在线用户数量平均并发用户数的计算：C=nL / T其中C是平均的并发用户数，n是平均每天访问用户数，L是一天内用户从登录到退出的平均时间（操作平均时间），T是考察时间长度（一天内多长时间有用户使用系统）并发用户数峰值计算：C^ 约等于 C + 3*根号C其中C^是并发用户峰值，C是平均并发用户数，该公式遵循泊松分布理论3、吞吐量的计算公式吞吐量(TPS)即在所有加载的用户稳定运行后，目标系统在单位时间内完成被请求的交易的数量。

在使用测试工具模拟业务请求压力时，吞吐量TPS是指所有被加载的虚拟用户在运行一段时间后稳定获得的每秒交易数。

指单位时间内系统处理用户的请求数从业务角度看，吞吐量可以用：请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量从网络角度看，吞吐量可以用：字节/秒来衡量对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，他能够说明系统的负载能力以不同方式表达的吞吐量可以说明不同层次的问题，例如，以字节数/秒方式可以表示数要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈；已请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。

当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系，可以采用以下公式计算：F=VU * R / T其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间4、性能计数器是描述服务器或操作系统性能的一些数据指标，如使用内存数、进程时间，在性能测试中发挥着“监控和分析”的作用，尤其是在分析统统可扩展性、进行新能瓶颈定位时有着非常关键的作用。

LoadRunner中的迭代

通过用lr做负载压力测试过程发现，如果设定不同的action迭代次数，每次得出的结果是不同的，曲线的表现形式也是不同的。

这点就使我们会感觉困惑,为什么要设置action 的迭代次数？以及对于不同的应用系统应该怎样设置迭代次数呢？首先你要理解性能测试是在干什么？性能测试是模拟系统一段时间内真实的压力情况，以考察系统的性能。

再看怎么模拟系统真实的压力情况？比如在半个小时内，用户都在进行登录操作，且平均分布在这半个小时内。

我们要做的是什么？模拟这半个小时用户的行为。

怎么模拟？估算出同时操作的人数，并用LoadRunner不断的发送登录请求，这就是我们为什么要迭代。

至于迭代次数，只要能够模拟出真实情况，多少次都无所谓，不过10次8次估计是模拟不出来。

迭代次数至少要保证压力达到一个稳定值后再运行一段时间，这样我们得到的数据才是有效的。

所以我们除非是特别要求，一般不用迭代次数，而是用运行时间。

1，迭代和并发，是完全不同的概念。

没有什么关系。

比如，一个用户迭代十次，还是一个用户的压力。

10个用户执行一次，就是10个用户的压力。

10个用户迭代10次，还是10个用户的压力。

但他们都和参数化的数据有关系（也要看参数化是如何设置的，以及系统如何判断提交值的）。

2,你要是想知道，LR是如何实现迭代和并发：说一个比较容易理解的层面：迭代就是不停的反复调用同一脚本，反复执行，注意，对1个用户执行10次来说，只会分配一块内存。

10个用户执行一次，是调用同一脚本10次，会分配10块内存。

LR调用脚本，编译后，运行，按脚本发送数据。

比如：web_url这样的函数，执行就会发HTTP request。

如果你还想知道更细节的进程和函数的实现，只能侧面验证（具体方法看各人的能力和擅长），因为我们都不是LR的开发者。

3,太显然的问题了，参数化时选择每次出现唯一，只要参数够用就OK，不够用，就设置相应的规则。

action在场景运行中iteration只对其起作用，对vuser_init和vuser_end都不起作用，action是一个可以被重复使用的最小单位其实你可以将所有脚本录制到一个action里，只是不方便管理罢了。

LoadRunner多用户并发操作解读

LoadRunner多用户并发操作解读假设存在：数据：A、B、C虚拟用户：Vuser1、Vuser2、Vuser3脚本中参数出现三次，脚本迭代三次怎样取下一行数据？Sequential：顺序，所有虚拟用户按照顺序读取数据表Random：随机，所有虚拟用户随机形式读取数据表Unique：唯一，所有虚拟用户每次各取一值（不重复）什么时候访问数据表完成数据更新？Each iteration：每次迭代以后Each occurrence：每次出现参数Once：每出现一个虚拟用户实例：顺序Sequential + Each iteration第一次迭代无论参数任何时候出现Vuser1、Vuser2、Vuser3 取A第二次迭代无论参数任何时候出现Vuser1、Vuser2、Vuser3 取B第三次迭代无论参数任何时候出现Vuser1、Vuser2、Vuser3 取CSequential + Each occurrence第N次迭代参数第一次出现Vuser1、Vuser2、Vuser3 取A第N次迭代参数第二次出现Vuser1、Vuser2、Vuser3 取B第N次迭代参数第三次出现Vuser1、Vuser2、Vuser3 取CSequential + Once第N次迭代无论参数任何时候出现Vuser1取A Vuser2取B Vuser3取C随机Random + Each iteration第N次迭代无论遇到该参数多少次Vuser1都只取A，或者B，又或者C，本次迭代不再更新第N次迭代无论遇到该参数多少次Vuser2都只取A，或者B，又或者C，本次迭代不再更新第N次迭代无论遇到该参数多少次Vuser3都只取A，或者B，又或者C，本次迭代不再更新在N+1次迭代，每个Vuser重新随机抽取数据Random + Each occurrence第N次迭代第一次遇到该参数Vuser1、Vuser2、Vuser3在A、B、C中随机抽取一个第N次迭代第二次遇到该参数Vuser1、Vuser2、Vuser3重新在A、B、C中随机抽取一个第N次迭代第三次遇到该参数Vuser1、Vuser2、Vuser3重新在A、B、C中随机抽取一个在N+1次迭代，每个Vuser继续保持每遇到一次参数就重新抽取一次数据Random + Once第N次迭代无论遇到该参数多少次Vuser1都只取A，或者B，又或者C第N次迭代无论遇到该参数多少次Vuser2都只取A，或者B，又或者C第N次迭代无论遇到该参数多少次Vuser3都只取A，或者B，又或者C在N+1次迭代，每个Vuser不会重新抽取数据唯一注意：使用该Unique类型必须注意数据表有足够多的数。