pvpageview， 即页面访问量 ，或者点击量，用户计算每次刷新页面。
数据库中的数据不能空， 或者数据量很少 ，这种情况不符合实际现场环境。 根据现场实际在线情况，插入一定数据量，然后进行测试 。
1） 被测系统的最大并发用户数。
2） 被测系统8小时最大业务吞吐量。
3） 稳定性和健壮性。
4） 当数据达到100万条时，测试系统的性能。
5） 响应系统核心事物的时间是否满足用户的需求。
用工具模拟实际生产条件下的业务压力，测试验证系统能否承受当前压力，满足性能要求。
在性能测试之前，需要备份被测系统的数据库。
负载试验和压力试验都属于性能试验。
负载试验强调系统在正常工作条件下的性能指标。
压力测试的目的是发现系统性能在什么条件下变得不可接受，并发现应用程序性能下降的拐点。
硬件：cpu内存、硬盘、网卡等网络。
操作系统
网络
中间件，web服务器。
数据库服务器
客户端。
编程语言，程序实现模式，算法。
指多用户在同一时间共同执行某一操作；并发测试要求严格，重点关注系统的瞬时压力。
指多用户在线循环操作某一动作。
对于一般系统而言，多用户并发和多用户在线对aut的压力是10：1的压力， 即50用户并发相当于500用户在线的压力。
从客户端发出请求开始计时，直到客户端收到服务器返回响应，这段时间称为请求响应时间。
客户端 –》网络 –》 网络应用服务器--à返回响应的数据库服务器-。
在实际测试过程中，通常会AUT将其部署到内网环境中，以便有足够的宽带瓶颈。
对于一般系统，如果用户点击按钮，系统在3秒内响应，用户会更加满意。 如果系统在5秒内响应，用户可以忍受。 如果系统在8秒后响应，用户无法忍受。 一般建议在3秒内。
每秒用户向web服务器提交http请求。
对服务器的压力越大，点击率越大。
注：点击并非指鼠标单击，因为在单击操作中，客户端可能会向服务器端发出多个请求。
例如，用户点击登录按钮，返回页面包含3张图片，点击量为4=3 1，3张图片 一页，每秒点击量称为点击率。(需要下载3张图片，分别发送3次http请求）。
单位为字节、吞吐量/传输时间，用户在任意给定一秒钟内从服务器端获得的数据量=吞吐率。
如果宽带充足，完美的吞吐量应该随着点击率的增加而增加。
--当宽带充足时，完美的吞吐量应随着点击率的增加而增加。 如果吞吐量随着点击率的增加而持平或减少，则表明目前AUT目前，处理能力不足AUT响应时间可能会增加，甚至报错。
指不同系统资源的使用，包括web测试和分析瓶颈的主要参数是服务器、操作系统、数据库服务器、网络、硬件等
利用virtualusers取代实际测试人员，
运用大量的virtualuser在不同的机器上。
通过controller管理vuser
用图表工具分析测试结果。
1， 脚本生成器（virtualusergenerator）--录音，调试脚本。
2， 控制台（controller）--设置场景参数，管理虚拟用户。
3， 结果分析器（analysis）--生成测试报告。
1， 录制时，loadrunner记录客户端和服务器之间的请求和响应。
2， 回放时，loadrunner模拟真正的客户端，向服务器发出请求，并根据脚本验证服务器响应。
1， 设置IE(清除浏览器缓存):进入工具—internet选项-常规-设置，选择每次访问此页面时检查。
2， LR修改参数：进入controller---runtimesetting---internetprotocol---proxy，选择noproxy。
3， 在性能测试中，不建议脚本调试太多——如果脚本太复杂，系统测试结果出现问题时很难找到性能瓶颈，定位困难，降低工作效率。 一般情况下，一个操作对应一个脚本。
4， 录制脚本不容易过急，否则脚本不能完全录制，调试不成功。
5， 脚本中的检查点不需要添加太多，一两个，因为检查点也是函数，执行也需要消耗资源。如果脚本中添加的函数太多，太复杂，则需要消耗额外的资源，但将记录所有服务器的资源监控数据AUT的结果报告，造成报告中数据不准确。
6， 性能测试中的并发测试是以循环为主，如init—action-action—action—end。
1， 制定性能测试计划
2， 创建测试脚本。
7， 编译/运行测试脚本。
8， 创建场景。
9， 运行，监控场景，收集数据。
10， 生成测试报告，分析测试报告。
1， 用户数8人。
2， 用户加载方式：每两秒钟加载1人。
3， 运行时间：所有用户运行完脚本。
1， 用户数量---用户越多，aut压力越大。
2， 用户数量固定，发送请求越频繁，则aut压力越大。
录制设置—高级---选择UTF-8字符集，这样在测试中文AUT能够用。
---录制脚本时关掉杀毒软件，聊天工具等其他无关的软件，否则会将其信息录入到脚本，甚至造成脚本失败。
，可以快速检查脚本的语法问题（格式），但是逻辑问题不能查找出来。
1， 先将运行通过的脚本加入控制台。
2， 控制台中设置参数。
3， 运行场景。
脚本中该句代码往往和本机的浏览器设置有关，如果脚本中出现该类代码，尽量不要删除，因为某些大型软件会将有用信息写入cookie中。
1， 工作方式都是录制---回放。
2， 区别：loadrunner关心的是请求（客户端发请求，服务器应答），关心的是网络协议HTTP。QTP关心的是AUT的界面，以及界面的对象及对象属性。
1， 基准测试：指测试环境确定以后，对业务模型中涉及的重要业务做单独的测试。目的是获取单用户执行时的各项性能指标，为多用户并发和综合场景等性能测试分析提供参考依据。
2， 递增测试：指每隔一定时间段（如5秒，10秒），加载不同数目的虚拟用户执行测试点操作，对测试点进行递增用户压力加载测试。
递增测试存在的意义：如果虚拟用户同时加载，有可能造成AUT的资源突然增大，进而影响后续测试中关心的测试点数据。所有前面加载用户稍稍放缓。
3， 并发测试：多用户在同一时刻同时执行某个操作，称为并发测试。并发测试目的是考察被测系统的瞬间压力的承受能力。
4， 综合场景测试：通过对系统结构和功能的分析，对用户的分布和使用频率的分析，来构造系统综合场景的测试模型，模拟不同用户执行不同操作。最大限度的模拟系统的真实场景，使用户预知系统投入使用后的性能水平。
----号称能够最真实的模拟实际的生产场景，一般情况下综合场景中要求脚本为3个以上，将虚拟用户分成不同的组，每组执行不同的脚本。注意：一般不要将login脚本加到综合场景中，因为综合场景一般持续很长（1个小时左右），这段时间内，所有的用户在循环执行操作，登陆不适合做循环操作。
----在设置综合场景中用户执行操作比例时，大部分的用户应该做浏览或者查询，少部分做提交操作。
5，疲劳强度测试：一般指长时间的在线综合场景测试，即在一定的压力强度下，进行长时间测试，测试的时间经常为7*24小时，或者24小时等等。
6，数据容量测试：考察AUT中数据库服务器中存储不同容量数据时，AUT的性能反应。
7，极限测试：也称为摸高测试，即使用性能测试，逐渐增加AUT的压力，测试出AUT的极限值，如最大用户数，最大的吞吐量等。
指当系统运行时，占用的内存没有得到及时释放，随着运行时间的增加，被占用的内存越来越多，导致可用物理内存被用光，系统运行缓慢甚至宕机，这种现场被称为内存泄露。
使用相应的测试软件进行内存指定计数器的监控，观察是否符合内存泄露的曲线走势，还可以使用专门的内存泄露检测工具进行测试。
Netstat-ano查明那个服务占用了端口。
在场景中，Loadrunner用vuser代替实际用户，vuser模拟实际用户执行操作，一个场景可包含几十，几百，几千个vuser。
1， 脚本生产器将用户的操作录制成脚本。
2， 每个虚拟用户都执行这个脚本。
3， 控制台统一管理所有的虚拟用户。
4，被测系统，部署在服务器。
为了度量服务器的性能，需要定义事物，事物表示要度量的最终用户业务流程或操作。
把握一个原则---模拟实际的生产环境。
1， 虚拟用户脚本生产器—virtualusergenerator。捕获最终用户业务流程和创建自动性能测试脚本，即生成测试脚本。
2， 控制台 –controller。 根据用户对场景的设置，设置不同脚本虚拟用户数量。
3， 压力结果分析器—analysis。 分析测试结果。
4， 负载生成器—loadgenerate。通过运行虚拟用户，产生实际的负载。
5， 代理程序—agent。 部署在各个客户端，协调得到步调一致的虚拟用户。
Agent的作用：当控制台统一对各个压力产生器（loadgenerator）进行控制时，每台压力生成器需要启动agent，agent负载实时侦听来自控制台的指令，以达到协调各压力生成器中虚拟用户的作用。
在做联机测试时，联机的机器需要满足两个条件：安装压力生成器，启动agent。
6， 监控系统—monitor。监控主要的性能计数器。 在性能测试中，要监控所有的服务器重要资源。
1， Lr的脚本生成器对AUT进行捕捉和录制（选择正确的协议，模拟java客户端或者ie客户端），形成脚本。对于脚本可以在runtimesettings中进行设置，进而形成场景。
2， 在控制台中，对vus进行部署，连同场景，形成各种测试场景（包括基准测试，并发测试，综合场景测试等）。场景可以启动或是停止，包括对于压力产生器的控制，还可以在测试过程中对AUT的服务器进行监控。
3， 测试过程中形成的海量数据，在测试结束后，统一提交到结果分线器，形成各式图表。
1， 主要作用是模拟用户行为：先通过录制或开放完成对单个用户行为的模拟，然后通过参数化等功能来实现多个用户间行为的差异化。
2， 如果是录制用户行为，则通常会在脚本中创建用户事物和集合点，经过调试确定脚本运行正确后，再将其放到controller中创建测试场景。
1， 使用Loadrunner的virtualusergenerator录制基本的测试脚本。
2， 根据需求编辑测试脚本，设定脚本执行参数，增强脚本的功能。
3， 再单机模式下编译运行脚本，看能否通过，如有问题及时调整。
1， 当用户访问某个HTML文件时，浏览器首先获得该HTML文件，然后进行语法分析。
2， 如果这个HTML文件包含图片/视频等信息，浏览器会再次访问web服务器，依次获取这些图片或视频，然后把图片和视频组织起来显示在屏幕上。
3， 性能调优时，如果一个页面访问满，跟视频和图片的个数也有关系。 个数越多，加载页面时间会更长些。
1， 自动监控制定的URL或应用程序所发出的请求及服务器返回的响应。
2， 他做为一个第三方监视客户端和服务器的所有对话，然后把这些对话记录下来，生成脚本。
3， 再次运行时模拟客户端发出的请求，捕获服务器端的响应。
使用的开发技术。
软件的类型。
使用的编程语言。
使用的数据库。
--98%都是用HTTP协议。
1， vuser_init，应用程序初始化脚本，只运行一次。
2， action，实际的操作，可多次执行。
3， vuser_end， 应用程序注销和关闭的脚本，只执行一次。
4， global.h，头文件。
控制台和脚本生成器中都有run-time-setting，控制台的优先级更高。
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语言函数。
两个步骤之间的停顿时间。 一般选择第三种设置：制定一个最大最小的比例，按照两者之间的随机值回放脚本。
---一般在测试过程中，控制台需要设置思考时间，根据实际的测试需求。
而在脚本生成器中，一般忽略思考时间，越快越好 ，
有时除了要衡量整个脚本的性能外，还有获取脚本中某一段或是几段的性能，以便更详细的知道具体是用户的那些动作对系统性能影响比较大，lr采用在脚本中定义事物来达到这一要求。
插入事物后，系统会返回事物的响应时间。
一般的并发过程仅仅体现在开始执行的一刹那，随着服务器对请求的响应时间的不一致或系统环境条件的限制。用户的执行速度将不一致，在运行过程中能够集合到一点的可能性很小，这样并不是真正意义的并发。
系统压力最大的情况是：所有用户都集合到系统的某个点上进行操作，从脚本的角度讲，这个点就是执行脚本的某一条或一段语句。为了真实模拟这种情况，lr提供集合点的功能，实现真正意义的并发。
Lr_rendezvous(“buy”); ---所有虚拟用户执行到集合点时停止，等待并发。
1， 何时使用集合点---并发测试时使用。
2， 并发测试的两个条件：脚本中加入集合点，控制台中设置集合点策略。
---并发测试是考察系统的瞬间压力承受能力，是比较严格的测试，所以不需要思考时间。
1， 如果在集合点等待的用户数达到所有用户乘以这个比例值，系统就释放用户，继续执行。（一般都是这项）
2， 如果在集合点等待的用户数达到所有正在运行用户乘以这里比例值时，系统就释放用户，继续向下执行。
1， lr结果报告中，显示了事物的响应时间的最小值/平均值/最大值，其中平均值比较重要。
2， 平均方差越小，越趋近于0， 表示事物的响应时间越接近，代表系统越稳定。
3， 90percent表示执行该事物的90%的用户都可以在该时间内完成操作。
4， 平均值和90percent都很重要。
检查点的功能主要是验证某个界面上是否存在制定的text或是image等对象。
在使用loadrunner测试web应用时，可以检查压力较大时web服务器能否返回正常的页面。
可以用下面三个函数实现：web_find ,web_reg_find , web_image_check
1，一个脚本中在关心的操作附近要记得添加事物，所以一个脚本至少一个事物，但是，一般情况下，登陆也会被添加为事物。
2关心的操作就是测试计划中的测试点，如查询稿件/购买机票等，只要测试计划确定，测试点则确定。
3，Lr_output_message函数的结果只显示在日志中，不会显示在结果报告中。
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。
录制模式区别：
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执行效率高。
1，loadrunner中，带有reg字样的函数，称为注册性函数，该类的函数特点就是要将函数写在响应请求之前。
2性能测试中，所有的数据包（客户端和服务器之间的对话）分为两类：请求包和应答包。
3， 无论是请求包还是应答包，都分为两部分，header和body分部 。
Header中是一些参数设置。
Body中才是真正要传递的参数。
4，loadrunner函数（web_或是lr_开头的函数）中出现的变量，称为loadrunner变量，该类变量不需要在脚本初始位置定义。但是c语言的变量一定要在初始位置定义。
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。
1，在参数池中备用数据设置时，要注意：光标要停留在新的下一行。
--简单的说，就是将脚本中常量形成变量的过程，所以为了模拟真实的情况，将脚本中录制好的起始城市和目的城市转化成变量，这就是参数化过程 。
Run-time-settings设置的log中扩展参数paramete rsubstitution。
--脚本在录制的时候，记录的参数都是常量值，这样，虚拟用户在执行同一个脚本向服务器发送请求时，使用的是同一个参数值，与实际情况不符。
--对脚本中的常量进行参数化，让不同的vu在执行相同的脚本时，分别使用参数数据源中的不同数据代替这些常量，从而达到模拟多用户真实使用系统的目的。
取值方式，更新方式，越界后的处理方式。
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 设置迭代次数来代替 。 这样可以控制迭代次数。
Int i=1;
Action(){
Lr_output_message(“第%d次，用户名：%s，密码是：%s”,
i++,
lr_eval_string(“{name}”),
lr_eval_string(“{password}”));
Return 0;
}
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;
}
}
sequential |
||
each iteration |
每个用户，每次迭代时，都是从头循环取值。 |
|
each occurrence |
每个用户，每次更新时，都是从头取值。 |
|
once |
只取一次值。 所有迭代和用户都用一个值。 |
|
random |
||
each iteration |
||
each occurrence |
||
once |
||
unique |
||
each iteration |
||
each occurrence |
||
once |