1，浏览量
pvpageview， 即页面访问量 ，或是点击量，用户每刷新一次页面被计算一次。
2，性能测试过程中
数据库中的数据不可为空， 或是很少数据量 ，这种情况不符合实际现场环境。 一定要根据现场实际在线情况，插入一定的数据量，再进行测试 。
3，性能测试工作：
1） 被测系统的最大并发用户数。
2） 被测系统8小时的最大业务吞吐量。
3） 稳定性和健壮性。
4） 测试系统在数据到达100万条时的性能。
5） 系统的核心事物响应时间是否满足用户的需求。
4，性能测试的解释
就是使用工具去模拟实际的生产情况中的业务压力，去测试验证系统是否能够承受当前的压力，满足性能的需求指标。
5，备份
性能测试之前，需要将被测系统的数据库进行备份。
6，负载和压力测试的区别：
负载测试和压力测试都属于性能测试。
负载测试强调的是系统在正常工作情况下的性能指标。
压力测试的目的是发现在什么条件下系统的性能变得不可接受，发现应用程序性能下降的拐点。
7，影响系统性能的主要因素：
硬件：cpu内存，硬盘，网卡，其他网络。
操作系统
网络
中间件，web服务器。
数据库服务器
客户端。
编程语言，程序实现方式，算法。
8，并发：
指多用户在同一时刻，共同执行某一操作；并发测试要求比较严格，着重考察系统的瞬间压力。
9，在线测试：
指多用户在线去循环操作某一动作。
10，并发和在线：
对于一般系统而言，多用户并发和多用户在线对aut的压力是10：1的压力， 即50用户并发相当于500用户在线的压力。
11，请求响应时间：
从客户端发出一个请求开始计时，到客户端收到服务器端返回的响应为止，这段时间称为请求响应时间。
客户端 –》网络 –》 应用服务器—》网络-à数据库服务器—》返回响应。
12，网络瓶颈：
实际测试过程中，经常将AUT部署到内网环境中，这样有充足的宽带，即可规避掉网络瓶颈。
13，响应时间的原则（3，5，8）：
对于一般系统而言，如果用户点击按钮后，系统在3秒内得到应答，则用户比较满意。 如果系统在5秒内得到应答，则用户能够忍受。 如果系统在8秒后得到应答，则用户不能忍受。 一般建议都是3秒内。
14，点击率：
每秒用户向web服务器提交的http请求。
点击率越大对服务器的压力越大。
注意：点击不是指鼠标的一次单击，因为一次的单击操作中，客户端可能向服务器端发出多次请求。
例如用户点击登陆按钮，返回的页面中包含3张图片，则点击量是4=3+1，3张图片+1个页面，每秒中的点击量称为点击率。（3张图片需要下载，所以分别又发送了3次http请求）。
15，吞吐量：
用户在任意给定一秒从服务器端获取的数据量，单位是字节，吞吐量/传输时间=吞吐率。
如果在宽带充足的情况下，完美的吞吐量应该是随着点击率的增加而增加的。
--在宽带充足的情况下，完美的吞吐量应该随着点击率的升高而升高。 如果随着点击率的升高，而吞吐量持平或者降低，则说明当前的AUT处理能力不充足，当前AUT有可能会遇到响应时间增长，甚至报错。
16，资源利用率：
指对不同的系统资源的使用程度，包括web服务器，操作系统，数据库服务器，网络，硬件等，是测试和分析瓶颈的主要参数
17，Loadrunner的解决方案：
利用virtualusers代替实际测试人员，
运用大量的virtualuser在不同的机器上。
通过controller管理vuser
利用图表工具分析测试结果。
18，Loadrunner的三大组件：
1， 脚本生成器（virtualusergenerator）--录制，调试脚本。
2， 控制台（controller）--设置场景参数，管理虚拟用户。
3， 结果分析器（analysis）--生成测试报告。
19，Loadrunner的工作原理：
1， 录制时，loadrunner记录下客户端和服务器二者之间的请求和应答。
2， 回放时，loadrunner模拟真正的客户端，向服务器发出请求，并根据脚本来验证服务器的应答。
20，测试注意事项：
1， 设置IE（清除浏览器缓存）：进入工具—internet选项—常规---设置，选择“每次访问此页时检查”。
2， LR中修改参数：进入controller---runtimesetting---internetprotocol---proxy，选择noproxy。
3， 性能测试中，脚本调试不建议过多，----脚本过于复杂，则系统测试结果出现问题时不易查找性能瓶颈，定位较难，降低工作效率。 一般的情况下，一个操作对应一个脚本。
4， 录制脚本不易过急，否则脚本无法录制完全，不能调试成功。
5， 脚本中检查点不需要加过多，一两个即可，因为检查点也是函数，执行时也要耗费资源。---如果脚本中添加函数过多，过于复杂，则需要耗费额外资源，但是所有服务器的资源监控数据都会记录在AUT的结果报告中，造成报告中数据不准确。
6， 性能测试中的并发测试是以循环为主，如init—action-action—action—end。
21，Loadrunner基本测试流程：
1， 制定性能测试计划
2， 创建测试脚本。
7， 编译/运行测试脚本。
8， 创建场景。
9， 运行，监控场景，收集数据。
10， 生成测试报告，分析测试报告。
22，制定性能测试计划：
1， 用户数8人。
2， 用户加载方式：每两秒钟加载1人。
3， 运行时间：所有用户运行完脚本。
23，系统如何产生压力：
1， 用户数量---用户越多，aut压力越大。
2， 用户数量固定，发送请求越频繁，则aut压力越大。
24，录制前设置：
录制设置—高级---选择UTF-8字符集，这样在测试中文AUT能够用。
---录制脚本时关掉杀毒软件，聊天工具等其他无关的软件，否则会将其信息录入到脚本，甚至造成脚本失败。
编译时，可以快速检查脚本的语法问题（格式），但是逻辑问题不能查找出来。
25，场景：
1， 先将运行通过的脚本加入控制台。
2， 控制台中设置参数。
3， 运行场景。
25，web_add_cookie脚本中该段代码
脚本中该句代码往往和本机的浏览器设置有关，如果脚本中出现该类代码，尽量不要删除，因为某些大型软件会将有用信息写入cookie中。
26，Loadrunner和qtp的相同点和区别：
1， 工作方式都是录制---回放。
2， 区别：loadrunner关心的是请求（客户端发请求，服务器应答），关心的是网络协议HTTP。QTP关心的是AUT的界面，以及界面的对象及对象属性。
27，性能测试策略：
1， 基准测试：指测试环境确定以后，对业务模型中涉及的重要业务做单独的测试。目的是获取单用户执行时的各项性能指标，为多用户并发和综合场景等性能测试分析提供参考依据。
2， 递增测试：指每隔一定时间段（如5秒，10秒），加载不同数目的虚拟用户执行测试点操作，对测试点进行递增用户压力加载测试。
递增测试存在的意义：如果虚拟用户同时加载，有可能造成AUT的资源突然增大，进而影响后续测试中关心的测试点数据。所有前面加载用户稍稍放缓。
3， 并发测试：多用户在同一时刻同时执行某个操作，称为并发测试。并发测试目的是考察被测系统的瞬间压力的承受能力。
4， 综合场景测试：通过对系统结构和功能的分析，对用户的分布和使用频率的分析，来构造系统综合场景的测试模型，模拟不同用户执行不同操作。最大限度的模拟系统的真实场景，使用户预知系统投入使用后的性能水平。
----号称能够最真实的模拟实际的生产场景，一般情况下综合场景中要求脚本为3个以上，将虚拟用户分成不同的组，每组执行不同的脚本。注意：一般不要将login脚本加到综合场景中，因为综合场景一般持续很长（1个小时左右），这段时间内，所有的用户在循环执行操作，登陆不适合做循环操作。
----在设置综合场景中用户执行操作比例时，大部分的用户应该做浏览或者查询，少部分做提交操作。
5，疲劳强度测试：一般指长时间的在线综合场景测试，即在一定的压力强度下，进行长时间测试，测试的时间经常为7*24小时，或者24小时等等。
6，数据容量测试：考察AUT中数据库服务器中存储不同容量数据时，AUT的性能反应。
7，极限测试：也称为摸高测试，即使用性能测试，逐渐增加AUT的压力，测试出AUT的极限值，如最大用户数，最大的吞吐量等。
28，内存泄漏：
指当系统运行时，占用的内存没有得到及时释放，随着运行时间的增加，被占用的内存越来越多，导致可用物理内存被用光，系统运行缓慢甚至宕机，这种现场被称为内存泄露。
29，内存泄露检测：
使用相应的测试软件进行内存指定计数器的监控，观察是否符合内存泄露的曲线走势，还可以使用专门的内存泄露检测工具进行测试。
30，解决端口冲突问题：
Netstat-ano查明那个服务占用了端口。
31，虚拟用户（virtualuser）
在场景中，Loadrunner用vuser代替实际用户，vuser模拟实际用户执行操作，一个场景可包含几十，几百，几千个vuser。
32，Loadrunner的工作方式：
1， 脚本生产器将用户的操作录制成脚本。
2， 每个虚拟用户都执行这个脚本。
3， 控制台统一管理所有的虚拟用户。
4，被测系统，部署在服务器。
33，事物transactiong：
为了度量服务器的性能，需要定义事物，事物表示要度量的最终用户业务流程或操作。
34，如何去设置场景中的参数：
把握一个原则---模拟实际的生产环境。
35，Loadrunner工具组成：
1， 虚拟用户脚本生产器—virtualusergenerator。捕获最终用户业务流程和创建自动性能测试脚本，即生成测试脚本。
2， 控制台 –controller。 根据用户对场景的设置，设置不同脚本虚拟用户数量。
3， 压力结果分析器—analysis。 分析测试结果。
4， 负载生成器—loadgenerate。通过运行虚拟用户，产生实际的负载。
5， 代理程序—agent。 部署在各个客户端，协调得到步调一致的虚拟用户。
Agent的作用：当控制台统一对各个压力产生器（loadgenerator）进行控制时，每台压力生成器需要启动agent，agent负载实时侦听来自控制台的指令，以达到协调各压力生成器中虚拟用户的作用。
在做联机测试时，联机的机器需要满足两个条件：安装压力生成器，启动agent。
6， 监控系统—monitor。监控主要的性能计数器。 在性能测试中，要监控所有的服务器重要资源。
36，Loadrunner的工作流程：
1， Lr的脚本生成器对AUT进行捕捉和录制（选择正确的协议，模拟java客户端或者ie客户端），形成脚本。对于脚本可以在runtimesettings中进行设置，进而形成场景。
2， 在控制台中，对vus进行部署，连同场景，形成各种测试场景（包括基准测试，并发测试，综合场景测试等）。场景可以启动或是停止，包括对于压力产生器的控制，还可以在测试过程中对AUT的服务器进行监控。
3， 测试过程中形成的海量数据，在测试结束后，统一提交到结果分线器，形成各式图表。
37，虚拟用户发生器—virtualusergenerator：
1， 主要作用是模拟用户行为：先通过录制或开放完成对单个用户行为的模拟，然后通过参数化等功能来实现多个用户间行为的差异化。
2， 如果是录制用户行为，则通常会在脚本中创建用户事物和集合点，经过调试确定脚本运行正确后，再将其放到controller中创建测试场景。
38，Loadrunner脚本开发步骤：
1， 使用Loadrunner的virtualusergenerator录制基本的测试脚本。
2， 根据需求编辑测试脚本，设定脚本执行参数，增强脚本的功能。
3， 再单机模式下编译运行脚本，看能否通过，如有问题及时调整。
39，浏览器的原理：
1， 当用户访问某个HTML文件时，浏览器首先获得该HTML文件，然后进行语法分析。
2， 如果这个HTML文件包含图片/视频等信息，浏览器会再次访问web服务器，依次获取这些图片或视频，然后把图片和视频组织起来显示在屏幕上。
3， 性能调优时，如果一个页面访问满，跟视频和图片的个数也有关系。 个数越多，加载页面时间会更长些。
40，Loadrunner录制原理：
1， 自动监控制定的URL或应用程序所发出的请求及服务器返回的响应。
2， 他做为一个第三方监视客户端和服务器的所有对话，然后把这些对话记录下来，生成脚本。
3， 再次运行时模拟客户端发出的请求，捕获服务器端的响应。
41，选择协议要重点考虑：
使用的开发技术。
软件的类型。
使用的编程语言。
使用的数据库。
--98%都是用HTTP协议。
42，测试脚本的主要部分
1， vuser_init，应用程序初始化脚本，只运行一次。
2， action，实际的操作，可多次执行。
3， vuser_end， 应用程序注销和关闭的脚本，只执行一次。
4， global.h，头文件。
控制台和脚本生成器中都有run-time-setting，控制台的优先级更高。
43，录制脚本的过程：
1， new一个新脚本。
2， 点击init。
3， 输入登陆信息。
4， 插入login事物起始点。
5， 点击login按钮。
6， 插入login事物结束点。
7， 切换到action，
8， 购票。
9， 插入buy事物起始点。
10， 点击continue按钮
11， 插入检查点 。
12， 插入buy事物结束点。
13， 切换到end。
14， 突出系统---如果直接关闭页面，则用户没有真正退出系统，与服务器的连接还在。
15， 关闭页面。
16， 结束录制。
---上述步骤3，4可以调换位置，因为在输入界面信息时，对服务器没有提交请求，只有当点击login按钮时，才将输入的信息提交给服务器。
Lr脚本中，lr函数都是以web_ 和 lr_ 开头。
Lr脚本中，使用类c语言作为脚本，支持lr函数和c语言函数。
44，思考时间：
两个步骤之间的停顿时间。 一般选择第三种设置：制定一个最大最小的比例，按照两者之间的随机值回放脚本。
---一般在测试过程中，控制台需要设置思考时间，根据实际的测试需求。
而在脚本生成器中，一般忽略思考时间，越快越好 ，
45，为何要插入事物：
有时除了要衡量整个脚本的性能外，还有获取脚本中某一段或是几段的性能，以便更详细的知道具体是用户的那些动作对系统性能影响比较大，lr采用在脚本中定义事物来达到这一要求。
插入事物后，系统会返回事物的响应时间。
46，为何使用集合点：
一般的并发过程仅仅体现在开始执行的一刹那，随着服务器对请求的响应时间的不一致或系统环境条件的限制。用户的执行速度将不一致，在运行过程中能够集合到一点的可能性很小，这样并不是真正意义的并发。
47，什么是集合点：
系统压力最大的情况是：所有用户都集合到系统的某个点上进行操作，从脚本的角度讲，这个点就是执行脚本的某一条或一段语句。为了真实模拟这种情况，lr提供集合点的功能，实现真正意义的并发。
Lr_rendezvous(“buy”); ---所有虚拟用户执行到集合点时停止，等待并发。
48，并发测试：
1， 何时使用集合点---并发测试时使用。
2， 并发测试的两个条件：脚本中加入集合点，控制台中设置集合点策略。
---并发测试是考察系统的瞬间压力承受能力，是比较严格的测试，所以不需要思考时间。
49，集合点中三种策略：
1， 如果在集合点等待的用户数达到所有用户乘以这个比例值，系统就释放用户，继续执行。（一般都是这项）
2， 如果在集合点等待的用户数达到所有正在运行用户乘以这里比例值时，系统就释放用户，继续向下执行。
50，结果分析：
1， lr结果报告中，显示了事物的响应时间的最小值/平均值/最大值，其中平均值比较重要。
2， 平均方差越小，越趋近于0， 表示事物的响应时间越接近，代表系统越稳定。
3， 90percent表示执行该事物的90%的用户都可以在该时间内完成操作。
4， 平均值和90percent都很重要。
51，什么是检查点：
检查点的功能主要是验证某个界面上是否存在制定的text或是image等对象。
在使用loadrunner测试web应用时，可以检查压力较大时web服务器能否返回正常的页面。
可以用下面三个函数实现：web_find ,web_reg_find , web_image_check
1，一个脚本中在关心的操作附近要记得添加事物，所以一个脚本至少一个事物，但是，一般情况下，登陆也会被添加为事物。
2关心的操作就是测试计划中的测试点，如查询稿件/购买机票等，只要测试计划确定，测试点则确定。
3，Lr_output_message函数的结果只显示在日志中，不会显示在结果报告中。
52，Web_reg_find()函数：
Web_reg_find(“Text=ABC”,”saveCount=abc_count”,LAST);
Web_url()
If(strcmp(lr_eval_string(“{abc_count}”),0)==0)
Lr_output_message(“s% time”,lr_eval_string(“{abc_count}”))
1， Web-reg-find函数注册一个请求，在下一个操作函数（如web_url）检索到的缓存中搜索一个文本字符。
2， Web_reg_find()的返回值0和1表示。
3， 该函数是注册类函数，它本身并不执行。Web-reg_find()是否注册成功，不代表查找的内容是否存在。
4， 可用savecount进行判断，查找几次了。
5， strcmp函数的作用是比较两个字符串是否相等，如果两个字符串相等，则函数的返回值为0，即strcmp(a,b)==0
6， ,lr_eval_string函数的作用：
A） 为c语言的函数和loadrunner的变量起到桥梁的作用。
B） 可以取出loadrunner变量abc-count的实际值。
7， 如果取loadrunner变量的值，则必须要用{}。
8， Lr_output_message(“s% time”,lr_eval_string(“{abc_count}”))解释：
A）%s是格式限定符 ，表示输出时该处输出字符串；如果是%d，则该处输出是整型。
B）输出的内容，%s将由逗号后的内容代替。
C）如果引号里有多个限定符，要依次按照逗号后的内容来代替。如lr_output_message(“%s times %s”，a，b) ，输出结果为a times b。
53，Web_find() 和 web_reg_find()的区别：
录制模式区别：
Web_find只能用在基于HTML模式录制的脚本中，web_reg_find没有限制。
位置区别：
---Web_reg_find是先注册register后查找，放在请求语句的前面。
---而web-find是查找前面的请求结果，使用时放在请求语句后面。
设置区别：
--run-time设置中的“enable image and text check” 对web-find有效，但是对web-reg-find无效。
查找方式区别：
--web-reg-find参数中savecount记录查找匹配的次数。
--web-find的机制是一旦查找匹配成功就立即返回，并不继续查找和记录匹配次数。
查找范围区别：
--web-find是在返回的页面中进行内容查找。
--web-reg-find是在缓存中进行查找。
效率区别：
Web-reg-find执行效率高。
54，Reg函数：
1，loadrunner中，带有reg字样的函数，称为注册性函数，该类的函数特点就是要将函数写在响应请求之前。
2性能测试中，所有的数据包（客户端和服务器之间的对话）分为两类：请求包和应答包。
3， 无论是请求包还是应答包，都分为两部分，header和body分部 。
Header中是一些参数设置。
Body中才是真正要传递的参数。
4，loadrunner函数（web_或是lr_开头的函数）中出现的变量，称为loadrunner变量，该类变量不需要在脚本初始位置定义。但是c语言的变量一定要在初始位置定义。
55，基准测试：单用户测试
1， 如果脚本录制过程中，遇到页面报错，则放弃录制，重新录制，要保证录制过程绝对正确。
2， 录制完成的脚本一定要回放，如果正确，再进行下一步增强脚本。如果不正确，要查找原因。
3， 基准测试步骤：
1） 脚本调试，运行通过。
2） 放入控制台。
3） 控制台的参数设置：
A） 用户数为1。
B） 虚拟用户部署不需要设置。
C）Run-time-settings中的设置
--run logic中设置5次（10次也可以）。迭代次数和场景执行时间都设置时，场景的优先级高。 但是当duration中设置“运行直到结束”，则具体运行情况可以参考迭代run logic。
--think time：忽略原因，单用户对系统压力很小，所以是否存在思考时间对结果影响不大。
4）pacing值：循环之间的时间间隔。 一般企业中都是设置2—3秒。
因为在线测试过程中，如果用户循环提交请求，但是每次循环之间没有时间间隔，则过于严格，不符合实际的生成环境。
---注意：只要有迭代，就要设置pacing值，这样是为了真实模拟用户。
4） Think time值：操作步骤之间的时间间隔。
7）如果将pacing值，或者think time值调长，则对AUT的压力减小。
4， 如果测试过程中发现脚本错误，需要修改脚本的步骤：
1） 修改后的脚本要编译。
2） 将新脚本刷新到控制台：
--控制台中选中脚本。
---选择左上角的“details” 按钮 ， refresh script。这样就刷新脚本到控制台了。
---在控制台中重新点击“run”按钮运行场景即可。
5， 测试过程时间会比duration时间长，为什么？
--因为测试时间=初始化+用户开始时间+duration（用户加载后的持续时间）+用户退出时间。
6， 当duration时间结束时，虚拟用户会运行完当前的action，再退出。
7， 每次提交的测试数据，应该测试三次，选取其中的中间值，如测试响应时间有3.5，4.5，6.5，则选择4.5。
56，参数化：
1，在参数池中备用数据设置时，要注意：光标要停留在新的下一行。
58，什么是参数化;
--简单的说，就是将脚本中常量形成变量的过程，所以为了模拟真实的情况，将脚本中录制好的起始城市和目的城市转化成变量，这就是参数化过程 。
Run-time-settings设置的log中扩展参数paramete rsubstitution。
58，为何进行脚本参数化
--脚本在录制的时候，记录的参数都是常量值，这样，虚拟用户在执行同一个脚本向服务器发送请求时，使用的是同一个参数值，与实际情况不符。
--对脚本中的常量进行参数化，让不同的vu在执行相同的脚本时，分别使用参数数据源中的不同数据代替这些常量，从而达到模拟多用户真实使用系统的目的。
59，参数池的策略：
取值方式，更新方式，越界后的处理方式。
1， Select next row（选择下一行方式）
1） 顺序的（sequential）：每个VU都是从第一行开始，顺序的向下取值（第一次取第一行，第二次取第二行。。。。）
特点：每个VU取值序列相同。
--按顺序向每个vuser分配数据，当正在运行的vuser访问数据表时，它将会提取下一个可用的数据行，每一个虚拟用户都会按照相同的顺序读取，如果在数据表中没有足够的值，则循环取值。
2） 唯一值（unique）：每个VU要唯一的向下取值，第一个用户从第一行开始取。举例：如果数据为1，2，3，4…….，VU为甲，乙，丙3个，则取数据的规则：
甲：取值1，2，3….
乙：取值6，7，8…..
--为每个vuser按顺序分配一个唯一值，该情况下，必须确保表中的数据对所有的vuser和他们的迭代有充足的值。
3)随机（random）：所有VU随机取值，可能会有重复取值。
4）same line as xxx
2， Update value on（更新方式）
1） 每次迭代（each iteration）：每次迭代（循环，action的循环）时取值。
--vuser在每次脚本迭代时使用新值，如果一个参数在脚本中出现若干次，则vuser在
整个迭代中，该参数使用同一个值。
2） 每次遇到：当脚本执行过程遇到该参数即更新这个参数。--企业中非常少用。
--vuser在每次参数出现时使用新值，如果一个参数在脚本中出现若干次，则vuser在整个迭代中，该参数使用不同值。
3） Once（一次）：脚本执行过程中，只取值一次
--vuser在脚本运行期间仅使用同一个参数值。
3， 例如：
Select next row： unique
Update value on： each iteration
When out of value：abort vuser（设置唯一时，放弃用户就可以，不需要再循环）
4，when out of value：越界后的处理方法。
1） 继续取最后一个值。
2） 以循环的方式继续 。
3） 放弃虚拟用户。
---只有选择方式为唯一时，才有越界的可能，如果选择顺序方式，则可以循环取值。
---如果对于单用户，顺序和唯一的取值方式一致。
4， Same line as xxx：
---两个参数如果取值保持一致，则设置好其中一个后，另外一个参数的取值方式可以选择same line as xxx。
5， 当进行多用户测试时，分块的方式才起作用。
--自动分块。
--手动分块。
--为何要分块？因为在控制台中，避免多用户打架，让每个vu都有自己的一块，取值（unique方式）时只能在自己的块中取值。
--何时使用分块？取值方式为唯一时。
--当取值方式为唯一，更新方式为每次迭代时，如果选择自动分块方式，则每个vu的块大小是设置的迭代次数。
--当设置为unique + each occurrence （唯一 + 每次遇到）时，lr为何无法实现快的自动分配大小？因为each occurrence 中的更新值方式和action 中的参数的出现次数有关，但是lr无法知道action中参数的出现次数，所有无法实现自动分配块大小，只能手工分配。
6，在控制台中，如果不设置 duration ，可以用run logic 设置迭代次数来代替 。 这样可以控制迭代次数。
57，脚本参数化实例1：
Int i=1;
Action(){
Lr_output_message(“第%d次，用户名：%s，密码是：%s”,
i++,
lr_eval_string(“{name}”),
lr_eval_string(“{password}”));
Return 0;
}
57, 脚本参数化实例2
Run logic0 迭代设置为2次。
Action（）
{
Int I;
For(i=1;i<=3;i++){
Lr_output_message(“第%d次，用户名：%s，密码是：%s”, i,
Lr_eval_string(“{name}”), lr_output_string(“{password}”)
);
Return 0;
}
}
58，参数化总结
下侧select next row(+when out of values)\右侧update value on |
sequential |
random |
unique |
each iteration |
顺序取值，下一次迭代接着上次继续取值，第一次迭代所有该参数取第一个值，下一次迭代所有该参数取第2个值，以此类推（参数列表用完，可以继续循环重复使用参数）。 |
随机取值，下一次迭代继续随机取值，第一次迭代所有该参数取第一个随机值，下一次迭代所有该参数取另一个随机值，以此类推（参数列表用完，可以继续重复使用参数）。 |
|
each occurrence |
顺序取值，下一次函数接着上次继续取值，第一个函数所有该参数取第一个值，下一个函数所有该参数取第2个值，以此类推（参数列表用完，可以继续循环重复使用参数）如：每一个web_url是一个函数。 |
随机取值，下一次函数接着上次继续随机取值，第一个函数所有该参数取第一个随机值，下一个函数所有该参数取另一随机值，以此类推（参数列表用完，可以继续重复使用参数）如：每一个web_url是一个函数。 |
|
once |
n次出现、或者n次迭代都是取参数文件当中的第一个值。 |
n次出现、或者n次迭代都是取参数文件当中的第一个随机值。 |
n次出现、或者n次迭代都是取参数文件当中的第一个值。与sequential+once一样？ |
each iteration+abortvuser |
顺序取值，下一次迭代接着上次继续取值，第一次迭代所有该参数取第一个值，下一次迭代所有该参数取第2个值，以此类推，如果迭代次数多于参数列表个数，会报No more unique values for this parameter in table 'keyword.dat'错 |
||
each iteratione+continue in a cyclic manner |
顺序取值，下一次迭代接着上次继续取值，第一次迭代所有该参数取第一个值，下一次迭代所有该参数取第2个值，以此类推（参数列表用完，可以继续循环重复使用参数）。 |
||
each iteratione+continue with last value |
顺序取值，下一次迭代接着上次继续取值，第一次迭代所有该参数取第一个值，下一次迭代所有该参数取第2个值，以此类推，如果迭代次数多于参数列表个数，会报No more unique values for this parameter in table 'keyword.dat'错 |
||
each occurrence+abortvuser |
|||
each occurrence+continue in a cyclic manner |
顺序取值，下一次函数接着上次继续取值，第一次函数所有该参数取第一个值，下一次函数所有该参数取第2个值，以此类推（参数列表用完，可以继续循环重复使用参数）。 |
||
each occurrence+continue with last value |
顺序取值，下一次函数接着上次继续取值，第一次函数所有该参数取第一个值，下一次函数所有该参数取第2个值，以此类推，如果使用该参数的函数个数多于参数列表个数，会报No more unique values for this parameter in table 'keyword.dat'错 |
select next row |
结果 |
|
sequential |
update value on： |
|
each iteration |
每个用户，每次迭代时，都是从头循环取值。 |
|
each occurrence |
每个用户，每次更新时，都是从头取值。 |
|
once |
只取一次值。 所有迭代和用户都用一个值。 |
|
random |
update value on： |
|
each iteration |
||
each occurrence |
||
once |
||
unique |
update value on： |
|
each iteration |
||
each occurrence |
||
once |
每个虚拟用户都分配唯一的一个值。 每个用户每次循环都是用这一个值。 |
|
when out of values： |
||
continue with last value |
顺序取值，下一次迭代接着上次继续取值，第一次迭代所有该参数取第一个值，下一次迭代所有该参数取第2个值，以此类推，如果迭代次数多于参数列表个数，会报No more unique values for this parameter in table 'keyword.dat' |
|
abort vuser |
当越界时，放弃取值（取完块里的值之后，就报错了）。 |
|
continue in a cyclic manner |
当越界时，继续从头开始循环取值。 |
|
allocate vuser values in the controller： |
控制台中分配块大小。非控制台没有块的说法。 |
|
automatically allocate block size |
在controller设置duration的情况下，自动分块的分块方式有所变化，块大小=我们输入的参数总数/ Vuser的个数 |
|
allocate 2 values for each vuser |
为每个块分配2个虚拟用户。 |
57，什么是并发测试，简介其做法：
--多用户进行并发测试，即在同一时刻同时进行某种操作。
--在线测试--不需要集合点。 。 并发测试---需要集合点。
60，两种录制方式：
HTML-basedscript：
--html模式，该模式可以为每个用户请求生成单独的函数。
--直观，易于维护和理解。
URL-basedscript：
--URL模式。
--可以捕获所有用户操作中的每一个HTTP请求，然后一一记录下来，也可以捕获非HTML应用程序，例如小程序和非浏览器应用程序。
1， 基于HTML方式录制的脚本比较简单， 篇幅较短，但是基于URL方式录制的脚本代码较多，原因及特性如下：
A） lr的厂商建议用户使用基于HTML的方式，由于比较简洁，而且能够实现同样的功能，甚至能够避免关联。
B） 基于HTML方式的原理：当打开脚本进行录制时，lr会将当前页面的信息保存到lr的缓存中，如登陆首页面打开时，缓存中会记录用户名（为空），密码（为空），以及usersession（有唯一值），则当用户继续录制提交登陆信息，点击确定时，lr会按照用户提交的信息和当前页面中缓存的信息进行比较，有区别的记录到脚本中，有区别的有：用户名（原来为空，现在jojo），密码，点击坐标x，y值等，而usersession没有变化，不记录，所以形成的脚本简单，内容少。
C）基于URL方式，则默认没有缓存，缓存为空，则lr会将页面中所有信息全部记录下来，脚本自然比较复杂。 并且将原来基于HTML中一个页面一个请求形式分散成多个请求，即将页面中每个元素（如页面中图片，视频，音频，动画等都称为页面元素）都形成一个web_url函数。
D）基于html方式虽然好，但是不能解决所有问题，如果遇到如银行，证券，保险等安全性比较高的被测系统（协议使用HTTPS---基于安全的http协议），这种系统必须使用基于URL方式，如果使用基于HTML方式，则很多信息不完整，脚本无法调试通过。
E） 总结：遇到一个新的被测系统，先用基于html方式录制，如果不成功，则用URL方式，即可成功， 如果看到HTTPS的系统，则直接使用url方式。
2， 有时使用基于html方式+单协议，如果录制脚本有问题， 则建议使用其他方式录制，如基于url方式+多协议，往往能够成功。
3， 基于url方式 + 多协议， 在lr8.0 的脚本比较明显。
61，run-time settings:
1）run logic ：设置action的迭代次数。
2）pacing：设置迭代间的时间间隔。
After the previous iteration ends: with a random delay of 2 to 3 sec 。
3）log：设置日志 。
Send messages only when an error occurs 。
Extendendlog:parameter substitution。
4）think time ：设置思考时间。
调试脚本时，可lgnore think time 。
场景运行时,replay think time : use random percentage of recorded think time:min50% max150%。
---为何think time 尽量不要注释：因为录制时的停顿一般是模拟用户的操作，如果注释或是删除think time ，甚至脚本中没有think time 则脚本不真实。
--在线综合测试场景为何保留think time ？ 为了真实模拟实际的生产环境。
5)miscellaneous:
error handing: continue on error（在长时间的测试过程中，综合和疲劳测试时，要选择这项。）。
multithreading: run vuser as a thread 。
6）speed simulation:设置带宽 。
network speed:use maximum bandwidth 。
7）browser emulation :浏览器设置。
勾掉 ：simulate browser cache:模拟浏览器cache 。
8）proxy ：代理
no proxy 。
9）preferences :选项设置。
options : 三个120 改成600 。 不能再改大了。
62，场景设置：
1，添加script 。
2，设置用户数。
3, 设置load generators。
4，details ：刷新脚本。
5，run-time settings设置。
6，scenario schedule: 默认是scenario ,real-world schedule .
1)schedule by : scenario (场景)--所有用户统一管理 ， group（组）--每个脚本的用户按组形式分开， 可先执行，可后执行。
2）run mode ：real-world schedule（默认）同Basic schedule，除此之外，还可以设置每次停止多少个用户。 basic schedule可以定义每次运行多少用户，持续时间多久。
7，global schedule：
1）initialize：初始化。
2）start vusers：开始用户数，递增形式。
3）duration：持续时间。如果duration设置为30分钟，则当30分钟到达时，所有的vus运行完当前的action，然后再退出。 Duration中包含的是完整的action 。 ·s
4）stop vusers：停止用户数。
63，编译
脚本修改完毕后，要编译， 确认没有语法错误，准备加入控制台。
64，场景类型：
1） 按场景设置：即场景中所有的虚拟用户统一行动。 所有脚本运行方式都是一样的。
2） 按组设置：场景中每个组（执行不同脚本的vus，一个脚本的用户成为一个组）分头行动。每组的脚本运行方式都是单独的。
64，场景类型
手动测试场景manual scenario：
--由测试人员完全按照需求来配置场景，在实际测试中应用较多，能够更加精确的满足测试的需求。
--属于手工设置的一种，与manual scenario方式比较相似，主要是在分配用户数的方式上有所不同。
---当控制台中虚拟用户数为百分比时，可以通过new新场景中的设置（百分比勾号取消）修改。
面向目标的测试场景goal-oriented scenario 。
--首先制定希望实现的场景目标，然后由controller进行自动测试评估。
65，综合场景的控制台设置
1） 虚拟用户的设置。
2） Vu部署的设置（控制台左下角）
--递增加载vus，每隔1s一个vu
--duration：设置为半小时。一般综合场景都是一个小时。
3）run-time settings 的设置
--pacing值：设置随机6-9秒（企业中一般2-3秒）
--log：不需要设置（如果调试脚本，可以随时查看日志； 如果运行场景，则报错时发送日志即可）
--think time 随机200%-400%（企业中一般为50%-150%）
--continue on error ：选中， 场景出错时继续 。
--带宽 。 选择最大带宽，因为如果带宽不充足，则lr发出的请求可能会只有部分成功到达服务器端，导致性能测试结果不准确。
--不模拟浏览器的缓存：严格执行测试。
---option中三个超时时间由120修改为600 .
综合场景注意：
1） 在所有的vu加载的过程中，如果有错误，马上停止，因为测试要求是所有的VU在线场景，如果没有达到所有VU在线（加载），则无法继续测试。
2） 要保证所有的vu都登陆成功，后面出错可以继续，但是如果大量出错，也要查找原因，必要时停止。
3） 测试结束后，如果失败的事物数是场景中所有事物总和的5%一下，则视为场景通过。
4） 有一种错误是正常的，报发现有资源为负值，没有问题，表示监控的服务器中有出错的计数器，但是不属于监控的13项。
66，综合场景的测试要点
1） 多个脚本：三个脚本以上。
2） 每个脚本think time 调到事物之外。
3） 控制台设置
4） 在线综合场景测试如果有性能要求，则按照需求指标设置运行时间（duration），如果没有具体需求，则按照常规经验设置为1个小时。
66，性能测试中要把握的原则
模拟真实场景。并且不给AUT增加额外的负载。以免结果数据不准确。
---企业中一般的并发测试达到几百用户居多。
67，在线综合测试场景报错，不是测试工程师的问题？
1） 如果报错的位置在脚本的登录过程中，即500用户在线只有490个用户登录成功，则该性能测试工程师执行的综合场景不规范，没有达到500用户在线。
2） 如果所有的虚拟用户全部登录成功，在duration阶段报错数很小，没有达到场景总事物数的5%（依不同单位不同项目而定），则视为场景成功。
3） 如果所有vu登录成功后，大量报错，超过场景总事物数的5%，则场景不通过（不是性能测试工程师的责任）。
68，监控资源初识
1） 如果把cpu比作画家，则画家面前的桌子就是内存，如果内存中找不到想要取的东西，则需要跑到地下室去取。该处的地下室就相当于磁盘。
2） 内存的运行速度可以是磁盘的成千上万倍。所以我们要尽可能的减少磁盘的I/O(磁盘的输入输出，或者叫磁盘的读写)，这也是性能测试调优的一个重要原则。
3） 磁盘的读写可以减少，但是不能变成0。
4） 处理器队列：等待处理的线程（或者进程）。比如：一个理发店3个理发师，来了6名顾客，则3个人要排队，则当前的队列就是3 。
69，联机测试
Loadrunner 允许使用多台机器运行场景来均衡测试机器的负荷。
1） 联机测试时，对方机器需要的准备工作：
--安装了压力生成器。
--开启agent 。
--就可以被controller统一调度来运行场景，controller负责收集统一的测试信息和执行结果。
2）lr的四大组件，压力生成器不仅可以安装在windows上，也可以安装在linux上。但是其余三大组件只能安装在windows上。
2） 联机步骤：
--确认联网（使用ping命令能ping通）
--确认两台机器联机成功（对方要开启agent）
--脚本中url地址中所有的127.0.0.1修改成物理ip地址。 因为脚本中网站地址为127.0.0.1，则不同的压力生成器执行时都是向自己的本机发送请求，所以订票到2台机器。
70，参数类型：
在创建参数的时候，我选择了参数类型为File。参数类型共有9种，现在来简单介绍一下所有的参数类型以及意义。
1.1、DateTime：
在需要输入日期/时间的地方，可以用DateTime 类型来替代。其属性设置也很简单，选择一种格式即可。当然也可以定制格式。
--取当前日期和时间。
1.2、Group Name：
很少用到。在实际运行中，LoadRunner使用该虚拟用户所在的Vuser Group 来代替。但是在VuGen 中运行时，Group Name将会是None。
1.3、Load Generator Name：
在实际运行中，LoadRunner 使用该虚拟用户所在LoadGenerator 的机器名来代替。
1.4、Iteration Number：
在实际运行中，LoadRunner 使用该测试脚本当前循环的次数来代替。
1.5、Random Number：
随机数。很简单。在属性设置中可以设置产生随机数的范围。
--如果脚本中某个参数需要在每次迭代时取值不同或者是随机数，则使用该方法。
1.6、Unique Number：
唯一的数。在属性设置中可以设置第一个数以及递增的数的大小。注意：使用该参数类型必须注意可以接受的最大数。例如：某个文本框能接受的最大数为99。当使用该参数类型时，设置第一个数为1，递增的数为1，但100 个虚拟用户同时运行时，第100 个虚拟用户输入的将是100，这样脚本运行将会出错。这里说的递增意思是各个用户取第一个值的递增数，每个用户相邻的两次循环之间的差值为1。举例说明：假如起始数为1，递增为5，那么第一个用户第一次循环取值1，第二次循环取值2；第二个用户第一次循环取值为6，第二次为7；依次类推。
1.7、Vuser ID：
设置比较简单。在实际运行中，LoadRunner 使用该虚拟用户的ID 来代替，该ID 是由Controller 来控制的。但是在VuGen 中运行时，Vuser ID 将会是 –1。
--可以用来区分不同的虚拟用户，在控制台有效。
1.8、File：
需要在属性设置中编辑文件，添加内容，也可以从现成的数据库中取数据（就是我用到的那种类型）。
--是lr参数中的默认类型，也是最常用的类型，他的特点是参数所取的所有值可以写成一个独立的文件。
1.9、User Defined Function：
从用户开发的dll 文件提取数据。
3， 需求：手机号138/139号段，1000用户并发测试，测试过程中要求手机号不能重复使用，测试时间为1个小时 。已知：单用户在一个小时的运行时间内循环次数为457次，求设计。
分析：
1， 如果不想使用file类型的唯一取值方法，可以使用unique number类型。
2， 如果单用户运行一个小时循环次数为n，则1000用户运行一个小时循环次数要小于n-----因为虚拟用户数多时，压力大，响应时间长，所以循环测试会变少。
3， 为了保险，我们设置每个虚拟用户块大小为500. 那么第一个虚拟用户取值是1—500. 第二个虚拟用户取值是501—1000，以此类推。
4， 这样的测试可以做多少次？？ 10的8次幂除以500000 = 200次。
5， 作业：用户名和密码分别作参数化，用户名aa1，aa2 ，aa3。。aa30 。 共三个虚拟用户， 迭代2次 。
1） 登陆过程在init 中，参数池策略：
A） 顺序+每次迭代 ： aa1 购买6次 。
B） 唯一+ 每次迭代 ：（因为迭代次数是2 ，所以块自动大小是2）
Aa1 购买2次。
Aa3 购买2次。
Aa5 购买2次。
2） 登陆过程在action 中，参数池策略：
A） 顺序 + 每次迭代 ：
Aa1 购买3张。
Aa2 购买3 次
B） 唯一+每次迭代：
Aa1 购买1次。
Aa2 购买1次。
Aa3 购买1次。
Aa4 购买1次。
Aa5 购买1次。
Aa6 购买1次。
71，关联 correlation
1,什么是关联？
把脚本中某些写死的数据，转变成服务器所送的/动态的/每次都不一样的数据。
2，何时做关联？
正常录制，但是回放不成功，考虑是否关联。
4， 一般的关联操作步骤：
A） 从服务器返回的数据中选取需要进行关联的数据。
B） 将该数据写在关联函数中 web_reg_save_param_ex
C）将脚本中需要使用该数据的地方使用b中的函数name来代替。
5， 动态ID ：需要关联的数据。 简单的说，每一次访问时都会变动的值，就有可能需要做关联。
6， 关联类型： 手动关联和自动关联。
7， 手动关联的步骤：
A） 录制脚本，回放有错误，确定由于动态数据造成的。
B） 在录制一份流程相同的脚本。
C）使用wdiff工具（LR中tools - compare with script）进行比较。
D）使用web_reg_save_param()函数，在源文件中找到需要关联的字符串（动态数据），存入一个参数中。
E） 把录制时的数据替换成该动态数据。
8， 关联的步骤：
A） 找到动态ID :
--录制两个操作一样的脚本，比较得到动态ID .
--- 一般情况下，think time ， 检查点，坐标位置，大段代码请求不同时， 都不是服务器端返回的动态ID ， 如果遇到大段代码的请求不同时，建议重新录制脚本。
----动态ID 一般都是一串无规则的字符串。
b）从服务器端通过左右边界提取该动态ID。
---从脚本中拷贝动态id的适当长度，从generation log 中找到该动态id所在的服务器端的应答包。 注意，从第一行开始找 。。
--拷贝当前找到的动态id，包含其左右边界 。
---在generation log 中向上翻页， 确认当前包是应答包即可。 看到response 。记住该应答包的ID号。
--然后先下翻， 找到和应答包ID号同号的request请求。 如果没有找到，则返回后向上翻找， 找到最近一条有效请求， 如请求图片就不是有效请求，此时可以不看ID号，该请求就是相应请求。 找到响应请求后，到脚本中快速定位的方法就是看快照号，快照号是唯一的。
---响应请求一定是在包含动态ID的那条请求之前。可以通过业务逻辑直接找生成动态id的请求。
找关联时，比较两个脚本的方法 :在LR中tools - compare with script 比较两个脚本的不同之处 ， 打开窗口之后， 点击 view - next difference 查看不同之处，
https系统：就是看访问地址的开头都是https://www.sdf
web_reg_save_param_ex(
"ParamName=billidbaocun",
"LB=,\"userid\":\"{userid}\",\"billid\":\"",
"RB=\"}],",
SEARCH_FILTERS,
"Scope=All",
"RequestUrl=*/saveAjax.do*",
LAST);