性能测试LoadRunner深入浅出_使用loadrunner或jmeter完成20个用户的注册测试

Da01

一、初步概念

1、功能测试：测试软件产品的功能是否达到要求。

  如：ATM取款(在线取款) --- 是否成功

       转账成功，表示功能实现了

     （一个人）

2、性能测试：测试软件产品的性能是否达到要求。

  包括：时间性能；多用户共同使用时的性能。

  如：ATM取款(在线取款) --- 耗时30分钟

      （取款、转账时间太长，就属于性能问题）

      十万个人同时转账，系统崩溃了，也属于性能问题

招聘需求：

 A.功能测试 （手工、自动化）

 B.性能测试 （只能通过工具模拟）

   要求比功能高，涉及面广：网络、服务器、中间件、数据库等不同层面综合问题。

二、性能测试的课程安排

1、性能测试的基本概念   2天左右

1）那些行业需要进行性能测试:(软件)

 通讯、银行、金融、证券、医疗、保险、搜索引擎(谷歌、百度)等多用户系统。

2）对性能要求较低的行业：比如OA 办公自动化、个人系统

2、性能测试的工具部分---LoadRunner11 (HP公司)

  全球至少一半以上的性能测试，使用LR

1）LoadRunner的初级部分--三大组件的简单运行。

1. 脚本生成器：录制、调试脚本(代码)的地方。
2. 控制台：好比总指挥部
3. 结果分析器：分析海量的结果，对影响性能的因素进行判断

2）LoadRunner的高级部分--逐个深入掌握三大组件

3、性能测试的高级部分--性能测试过程中，遇到问题（瓶颈），如何查找、定位，进行性能调优。

分析奥运门票的订票问题：

  先到先得--抢

  压力激增--瞬时压力（性能测试中：并发压力）

  系统瘫痪--宕机 （down机了）

  3小时内，网站的浏览次数达到2000万次

  他们提供的100万次/小时   他们---奥组委

  甲方：奥组委   乙方：开发方   第三方：测试团队

  浏览器第一小时 800万次 -- 8000000 / 3600 = 2222次/秒

  每秒从网上添加的门票申请超过20万张

浏览量：(PV值  Page View)

  页面的访问量或点击量，用户每次刷新即被计算一次。

  每秒平均浏览量：2200次/秒

  购票申请：20万张以上

订票过程：

  客户端   -----    服务器

  北京                 上海   网络延迟 0.2秒    4万张票

  上海                 上海

三、性能测试的概念：

1、性能测试：模拟真实的生产环境，以各种不同的压力（模拟大量用户）去测试被测系统、去“攻击”测试系统。同时记录下被测系统 各台 服务器的各种重要资源情况，包括cpu、内存、磁盘和网络等资源。

说明：用户 -- 虚拟用户

       被测系统 -- 软件 结合 硬件

2、注意：性能测试之前要做好系统备份。

3、性能测试时首先看性能需求，如果没有需求，这时要根据与客户的交流、被测系统的相关资料、以及性能测试工程师的经验，去编写测试计划，进行性能测试。

4、负载测试和压力测试的区别：

说明：国内是混用的，国外有差别，主要应对笔试题

1）共同点: 都是在测试过程中逐步加压

2）负载测试：（Load Testing）  见好就收

    在正常范围内测试；服务器正常的承受范围内、需求范围内，进行逐步加压测试。

3）压力测试：（Stress Testing）使劲折腾

    可以在极端范围内测试；允许通过不断加压，让被测系统出现异常情况，直至宕机。

4）举例：一座大桥，桥身最大载重量，不超过60吨

      但是桥梁内部资料，最大载重量，不超过70吨

授人以鱼 授人以渔

     知识点    学习新知识的方法

5、性能测试的背景课程：

1）数据库 （60%-90%的性能问题都和数据库有关）

2）操作系统（Linux/Unix）

3）其它：网络协议、防火墙、计算机组成原理等知识...

6、被测系统：

 SUT （System Under Test）

 AUT （Application Under Test）

 EUT （Environment Under Test）

 就是WebService和DataBase Service两部分的统称。

（Web服务器/应用服务器）（数据库服务器）

回顾：Web应用，三层架构

                              被测系统 AUT

                  ______________________________

 Client  <-->   WebServer  <--->  DataBase Service

IE浏览器          Tomcat                  Oracle

四、LoadRunner的工作原理（录制--回放的工作方式）

                            和QTP类似。

1、录制时，LoadRunner记录下客户端和服务器二者之间的对话。

2、回放时，LoadRunner模拟真实的客户端向服务器发起的请求，并按照脚本去验证服务器的应答。

补充：有时脚本录不下来，需要自己写脚本，发现测试时通过了，但实际运行时服务器瘫了。

原因：没有模拟真实的客户端效果，就收出现问题，导致失败。

结论：自己写脚本时，也要模拟真正的客户端。

LoadRunner的三大组件：   OALoad工具类似

1）虚拟用户脚本生成器 （Virtual User Generator）

   VUG  或 VuGen

作用：录制、调试运行脚本

2）压力调度控制台  （Controller）

作用：生成场景，调度压力，模拟真实测试环境

    创建场景、运行场景、监控场景，收集测试数据

    场景：就是一个大型的配置文件。

3）压力结果分析器  （Analysis）

作用：把收集到的测试数据以图表的方式展示出来；

       生成测试报告。

熟悉被测系统AUT: LR自带的一个B/S架构的系统 WebTours

 HP LoadRunner -> Samples -> Web -> Start Web Server

 先启动服务器

 HP LoadRunner -> Samples -> Web -> HP Web Tours Application  自带的航班订票系统

五、关注AUT，并进行脚本录制

Web Tours 航班订票系统

默认账户

用户名：jojo

密码：bean

1、使用LR之前，浏览器修改：

 Internet选项 -> 设置 -> 选中"每次访问此页面时检查"

 原因：当脚本更新时，会及时查看到

2、拷贝AUT的网址，准备测试（测试时关闭被测系统网页）

http://127.0.0.1:1080/WebTours/

或

http://localhost:1080/WebTours/

功能说明：

Login         登录

Flights       订票

Itinerary    看到订票线路  订单

Home        主界面

Sign Off    退出

3、解决Flights功能无法使用

（原因：和Oracle安装目录下资源有冲突，需要删除一个目录）

D:\oracle\product\10.1.0\db_1\perl\5.6.1\bin 下

  删除MSWin32-x86 目录

D:\oracle\product\10.1.0\db_1\perl\5.6.1\lib 下

  删除MSWin32-x86 目录

删不掉的原因：Oracle服务未关闭

LR使用注意点：

1、性能测试：LR的三大组件

2、基于教学环境：LR的三大组件运行比较慢

 解决办法：禁用本地连接

3、LR默认浏览器是IE,如果自己机器上默认是FireFox浏览器？

 解决办法：在IE浏览器 

  工具-> Internet选项 -> 程序 ->重置Web设置

4、建议：打开LR的三大组件，都从开始程序中启动

5、当录制时：被测系统无法打开（不自动弹出IE浏览器）

原因：其它程序阻碍了IE浏览器。

解决办法：在任务管理器中把java.exe进程停止

建议：停止其它没用的进程，比如tomcat, apache, oracle, java,

  mysql, 有道, ...

录制脚本：使用VUG  (VuGen)

 HP LoadRunner -> Application -> HP Virtual User Generator

 打开

案例：录制用户登录脚本

  点击New图标 -> New Virtual User  -> 默认协议

  -> Create 开始录制

  填写基本信息：

   选择软件的架构：

       B/S  (Internet Applications)    默认选择 

    或 C/S  (Win32 Application)

   选择浏览器类型： 默认IE

   URL Address: 被测系统的网址

        http://127.0.0.1:1080/WebTours/

   Working Directory: LR工作路径 默认

   Record into Action: 录制脚本文件位置   默认Action

    (vuser_init 初始化、Action 核心脚本、 vuser_end 结束)

 -> OK   自动打开浏览器，开始录制

 -> 输入jojo   bean

 -> 开始事务  名称login (插入事务) ->  OK

 -> Login按钮  完成登录

 -> 结束事务  login

 -> 改为vuser_end模式，点击Sign Off 退出

 -> 关闭浏览器

 -> 点击Stop按钮 结束录制

建议创建目录： D:\work

 创建三个子目录：

 script  脚本、  ctrl  场景文件、 result  结果分析文件

脚本ctrl + s 保存为：D:\work\script\day01\login

基本按钮：

编译：Compile  脚本修改后，检查语法

运行：Run      回放脚本

修改字体：Tools -> General Options -> Environment-> Editor

  Comic Sans MS   14   Bold 加粗

关注左上角对应的独立的源文件：（脚本文件的组成，类C语言语法）

vuser_init   初始化脚本   (仅执行一次)

Action       核心脚本     (默认一次，可循环多次)

vuser_end   结束脚本     (仅执行一次)

globals.h    头文件

六、录制脚本注意要点

1、在使用LoadRnner之前，一定手工执行一遍待测试的 测试点（操作：如登录系统、购买机票）

原因：1）能用  2）属性业务流程

2、录制时：

 一般将登录的动作录制到vuser_init中去；

 关心的测试点（比如订购机票、查询路线）录制在Action中；

 而退出的动作录制到vuser_end中去。

原因：Action比较强大，其它部分不具备某些功能，比如只有Action参与循环（迭代）。

3、创建新脚本时，要从New开始

4、如果只是录制登录脚本，则录制在Action即可。

5、函数的三要素：函数名、参数表、返回值类型

int vuser_init()

{

  初始化脚本中没有代码...

  return 0;

}

6、事务控制  (LR自带的函数)  事务Transaction

lr_start_transaction("login");   开始事务login

事务的代码...

lr_end_transaction("login",LR_AUTO);   结束事务login

事务用途：让LR统计事务时间

7、lr_think_time(19);  

 思考时间（发呆时间）

 此处等待19秒，之后再向服务器提交请求

8、web_submit_form(

       "Snapshot=t2.inf", ...   快照名 t2.inf   快照（截图）

     表单的参数，提交的数据：

     "Name=username", "Value=jojo", ENDITEM,              "Name=password", "Value=bean", ENDITEM,

    );

  表示发送表单提交的请求。

想看到运行结果，配置技巧：

 Tools -> General Options -> Replay 回放

 -> After Replay  选择 Virtual test results 可视化测试结果

再回放，则显示结果报告。

注意：结果的对勾，不一定准确，只验证是否接收、发送成功，不管数据是否准确。后续需要添加检查点等技术，让脚本更完整。

如果想看到回放的图形界面效果：（用处不大）

 Tools -> General Options -> Display 显示

  -> Show run-time viewer during re]     打钩

 之后再取消打钩，以免占用不必要的资源

9、如果实现 多用户的测试，则必须打开 控制台。

VuGen: 只能模拟1个虚拟用户

Controller: 可以模拟多个虚拟用户，模拟千军万马

LR常见术语：

1) 虚拟用户  Virtual User  简称为VU

 在场景中，LoadRunner能用VU代替实际用户，给AUT施加压力。

2) 事务 Transaction

 事务能够度量服务器的性能，我们将主要的业务流程制定成一个事务，LR能够统计事务的响应时间。

3) 场景 Scenario   

 场景是一种大型的配置文件，能将综合运行环境进行记录。

 通过控制台配置场景，比如：用户数、运行时间等

10、录制结束后，保存-> 编译 -> 回放 （编译、运行）

11、编译：检查语法错误   图标Compile

注意：主要检查语法错误，逻辑错误检查不出来

      每次修改完脚本后，及时保存并编译

12、何时需要插入事务？

 关心哪里，就将哪个过程作为一个事务。如果只关心订票，就不要考虑登录。事务的指定，LR后续会统计事务的响应时间，作为性能分析的重要依据。

13、LoadRunner录制时，Action的选择只能从前向后选择：

 即 vuser_init -> Action -> vuser_end

 不可逆，如果选错了，从New开始重新录制

练习：录制购票的脚本   Flights功能 (使用LR的VuGen)

 New -> 选择vuser_init -> OK -> 首页面

 输入jojo bean  -> 插入事务login -> Login -> 结束事务login

 切换为Action  -> 点击Flights (等待页面加载完毕)

 选择城市 从Denver 到 Landon -> Continue -> Continue

 -> 插入事务buy -> 点击Continue -> 结束事务buy

 切换为vuser_end  -> 点击Sign Off

 -> 关闭浏览器  -> 结束录制 Stop

注意：进入新页面，需要等待页面加载完毕，再进行下一步操作，

       确保脚本录制完整。

七、LoadRunner基本测试流程

1、制定性能测试计划        使用Word编辑文档

2、创建测试脚本             就是录制脚本

3、编辑、运行测试脚本      调试脚本（重点）

4、创建场景                  用控制台

5、运行、监控场景，收集数据

6、生成测试报告，分析测试结果   写出测试报告

问题：流程中用到了几大组件，分别是对应什么？

 脚本生成器： 2  3

 控制台：   4  5

 结果分析器： 6

回顾今天主要内容：

1、何时需要性能测试？

对性能要求比较高的行业的软件，多用户系统

2、什么是性能测试？

模拟真实的生产环境，以各种不同的压力（模拟大量用户）去测试被测系统、去“攻击”测试系统。同时记录下被测系统 各台 服务器的各种重要资源情况，包括cpu、内存、磁盘和网络等资源。

3、性能测试的工具-- LoadRunner 11

4、LoadRunner的三大组件：

1）虚拟用户脚本生成器 VuGen

作用：录制、编辑脚本，模拟1个Vuser 虚拟用户

2）压力调度控制台  Controller

作用：模拟场景，使用脚本，结合多用户模拟压力

    总指挥部，结合脚本作为武器，调度VU士兵向AUT发起攻击

3）压力结果分析器  Analysis

作用：分析测试结果 （大量图表）

作业题：

1、简答题：

1）性能测试的主要工具，工具的基本组成和功能。

2）性能测试中吞吐率和点击率的区别。 （预习）

2、思考题：

 录制系统登录、购买机票、查询线路三个脚本（三个测试点），每个脚本在控制台中设置（9个用户，每隔1秒登录一个用户，运行脚本直到结束），得出每个测试点的事务响应时间。（平均）

Day02

复习：

简答题：（20*5=100）

1、负载测试和压力测试的区别？

答：1）共同点：都需要逐步加压

2）负载测试(Load Testing) 是在正常范围内的测试，比如达到性能需求，服务器能够承受的范围。

3）压力测试(Stress Testing) 是在极端范围的测试，发现AUT的最大的潜能。

4）举例：通过逐步增加Vuser模拟压力，在需求范围的人数属于负载测试，超过正常范围属于压力测试。

2、LR的三大组件简介，中英文名称？ （重要）

答：1）Virtual User Generator 虚拟用户脚本生成器 （VUG）

功能：录制、编辑、调试脚本

2）Controller  压力调度控制台

功能：创建、运行、监控场景，收集测试数据

       场景：就是大型的配置文件

3）Analysis  压力结果分析器

功能：将收集到的数据以图表等方式进行展示，以便进行分析，

       并生成测试报告。

3、LoadRunner的工作原理？（重要）

答：录制--回放的工作方式，和QTP类似。

1）录制时，LoadRunner记录下客户端和服务器二者之间的对话。

    分为请求和应答，脚本中主要记录请求。

2）回放时，LoadRunner模拟真实的客户端，向服务器发请求，并按照脚本去验证服务器的应答。（检查点技术）

4、什么是事务，为何要创建事务？

答：事务分为事务的开始、结束和之间的业务操作，事务用于度量服务器的性能。我们可以将比较关心的某个或某些业务操作，设定为一个事务，LR会记录不同事务的响应时间。

5、LoadRunner脚本的基本组成部分。

三部分（vuser_init、Action、vuser_end） + 头文件 globals.h

底层：类C语法

 vuser_init.c    Action.c   vuser_end.c

一、性能测试基本概念

1、并行 和 并发的区别： 和是否共享、抢占CPU资源有关

分时操作系统（时间片）

1）并行：多个进程（任务）拥有各自的CPU资源

2）并发：多个进程（任务）抢占少量的CPU资源（调度）

2、并发 和 在线的区别：

1）并发的压力是一种瞬时压力；

2）在线的压力是一段时间的压力；

3）20用户并发的压力相当于200个用户在线的压力。

   （1:10的比例）

 写测试计划时，可以参考，比如2000用户在线，一般需要测200个用户并发。（并发测试）

 并发的情况：并发登录、并发查询、并发删除等

3、请求响应时间 = 客户端时间 + 网络时间 + 服务器时间

4、可以通过内网测试规避掉网络的问题，客户端一般不会成为性能瓶颈，所有大部分情况下，如果请求响应时间长，性能瓶颈就出现在服务器端。

比如：Web服务器 和 数据库服务器最后分开部署，可以分别监控。

5、事务响应时间：用户完成某个具体事务所需的时间。

一个事务可能包括多个请求，可以包含若干个请求响应时间。

6、点击率：不是指鼠标点击的次数，比如：点击一个按钮，服务器返回的页面中包括3个图片，则当前发起的点击数为1+3=4个Http请求。

原因：网页中包含 <img src="图片的地址" /> 每遇到一个资源，都会重新发地址的请求。

Hits Per Second

7、请求和响应：客户端向服务器发起请求(Request)，服务器向客户端返回应答(响应 Response).

8、吞吐量 Throughput

用户在任意一秒从服务器端获取到的全部数据量，单位：字节

指的是总量。

9、吞吐率 = 吞吐量 / 传输时间

反映服务器的处理效率。

TPS  (Transaction Per Second)  事务数/秒

10、资源利用率：一般指系统中CPU、内存(Memory)、磁盘、网络等主要的资源的使用情况。

（暂时了解，有难度，后续分析）

问题：脚本运行后，点击Replay Log查看，发现红色字体提示：

 Request Connection: Remote Server ....

 (REASON: Unable to connect to remote server.)

  原因:     无法        连接        远程    服务器

  可能服务器未开启，需要提前打开AUT的服务器

综合案例：测试登录模块在8个用户的情况下系统的性能情况。

要求：需要测试点 login (录制login脚本)

                     用户名：jojo   密码：bean

       用户数： 8人

       用户加载方式：每2秒钟加载一个VUser

       运行时间：所有用户运行完脚本

操作步骤：

  打开Controller  -> 默认手工场景模式 ->

     将Use the Percentage Mode to... 去除打钩 用户数不使用百分比模式

  -> Browse按钮 选择脚本login  -> OK按钮

  -> 如果脚本选错了，可以在界面中重新选择

  -> 将用户数改为8：

    Run Mode: 选择Basic Schedule -> 将Quantity改为 8

  -> 每2秒钟加载一个VUser:  左下角窗口 Global Schedule

    Start Vusers:

       Start all Vusers simultaneously 默认8个VU同时加载

    需要修改，双击Start Vusers -> Edit Action

  -> 选择第2个单选钮，

     改为1 Vusers every 00:00:02(HH:MM:SS)

     每隔2秒钟加载一个虚拟用户

  说明：第1个单选钮 Simultaneously  同时地

  -> OK

  -> Schedule Graphics  效果图

   观察预览图，横坐标(Time 测试时间)、纵坐标(Vusers 虚拟用户的个数)

  每隔2秒加载1VU，直到8个就不涨了，虚线表示运行时间不确定

  -> 设置运行时间  Duration中 (持续时间) ->

 Run until completion 运行直到结束 （脚本运行结束） 选择

 Run for __ days and __ (HH:MM:SS)表示运行多久，循环执行

 Run idefinitely 不限定  无休止运行，直到测试者点击停止

  -> 切换到Run视图  （Design 设计 和 Run 运行）

  -> 找到Start Scenario按钮 （Design视图左上角也有）

  -> 运行场景 Start Scenario

点击Vusers按钮 观察每个VU的运行转态：

  Done.Passed 1 iteration(s) attempted: 1 successed.

    结束 通过  经过1次迭代 尝试1次，成功了

 分析运行走势... (观察控制台Run视图，查看是否出错)

 进一步打开HP LoadRunner Analysis 结果分析报告，可保存

 （控制台Run视图，倒数第三个图标按钮）

可以了解三大组件之间协作关系。

二、性能测试的策略

重要的：基准测试、并发测试、综合场景测试

        （前3个项目必备）

         极限测试、递增测试

次要的：疲劳强度测试（大型系统中）、内存泄露测试、

        数据容量测试    

共同点：向被测系统发起攻击

1、基准测试就是单用户测试。（基本的准绳）

注意：需要打开控制台，配置、运行场景，自动搜集数据，通过Analysis进行结果分析。

2、递增测试：通过逐步加压对系统进行测试

使用场合：比如登录模块，让大量用户陆续登录在线

3、并发测试：多用户并发执行某一操作，强调几乎同一时刻，LR精确到毫秒级别。

注意：并发测试是一种严格的测试，主要考察系统对瞬时较大压力的承受能力。

4、综合场景测试：号称"能够最真实的模拟实际生产环境"

5、综合场景的几个要素: 多用户、多个脚本（至少3个 多种操作）、在线执行一段时间（1个小时、50分钟）

注意：只要是多用户，就存在并发，但是无需像并发测试来设置并发点。

6、综合场景测试过程中，默认所有用户循环执行相应操作。

7、比如：100用户在线综合场景

100用户共同对AUT执行操作，其中30个VU执行浏览首页；50个VU执行查询订单操作；20个VU执行提交订单操作。

（要模拟真实的人数比例）

问题：为什么不模拟大量的登录操作？

关键点：循环   循环登录不真实

8、响应时间：业内有"358原则"，系统响应时间在3秒以内，则用户可以接受；在5秒以内，用户可以忍受；超过8秒，用户不能忍受。

9、疲劳强度测试：在一定强度（压力）下，对系统进行长时间的性能测试，一般7*24小时、或者24小时、12小时等。

比如：银行、电信系统，7*24*365  不停运转

10、考察疲劳强度测试时，要考察其 平均响应时间，其各台服务器的各项资源情况。（CPU、内存、磁盘、网络等）

说明：以上属于比较常见的测试策略，经常出现在测试计划中。

11、内存泄露检查：通过正常的性能测试，如果AUT内存曲线走势不正常，则关注其相关的各项重要内存指标，根据走势确定是否发生内存泄露。

说明：出现内存泄露可能性很小，是程序员的大忌

   Java程序 JVM Java虚拟机 内存（栈、堆、方法区）

    new对象分配在堆区，大量分配，来不及回收，堆内存就满了，称之为内存泄露。程序员凭借经验避免问题发生。

12、数据容量测试：使用大容量数据添加到数据库中，观察AUT是否能够正常运行。

比如：向数据库中添加200G的数据后，再进行测试。大的数据库有几个T.

大数据 Big Data  一般是T级、P级的数据...

      核心：数据挖掘

  1024Byte = 1KB

  1024K = 1M

  1024M = 1G

  1024G = 1T

  1024T = 1P

  E  Z  Y

13、极限测试：使用并发测试、在线测试等方法，测试出系统能够承受的极限压力（如最大用户数），或者系统能够达到的最大处理能力（如最大吞吐量）。测试方法可以采用递增测试，如对系统进行100用户、500用户、1000用户等测试。

（也称为：摸高测试）

三、基准测试：单用户测试

1、测试脚本中要 检查点，原因是LR报告中的验证只是针对网络层面上，服务器收到客户端发送的数据包 将 应答包 发回给客户端，但是LR并未验证应答包中数据是否正确。

案例1：对购票操作进行基准测试。 开始录制脚本，插入检查点。

 先打开AUT网站，熟悉整个业务流程；

 打开VuGen  -> New  输入Url  -> 先录制登录

 -> vuser_init -> 输入jojo和bean  -> 开始事务login

 -> 点击Login  -> 进入欢迎页面：

  选中"Welcome, jojo," 点击Insert text check 插入文本检查点

 -> 结束事务login

 -> Action模式 -> 点击Flights

 -> 选择城市，比如Denver 到 Los Angeles

 -> Continue -> Continue

 -> 开始事务buy  -> Continue -> 订单结果页面：

 -> 选中"Denver for Los Angeles" 插入检查点

 -> 结束事务buy

 -> vuser_end模式 -> Sign Off -> 关闭浏览器 -> Stop

将脚本保存为：sctrip/day02/buy  再回放

观察脚本：

web_reg_find("Text=Welcome, <b>jojo</b>,",  LAST);

web_reg_find("Text=Denver  for Los Angeles", LAST);

2、对应B/S系统，LR脚本中LR函数以lr_或web_开头。

说明：LR函数 和 C函数加以区分

3、web_reg_find函数，带有reg字样的函数称为：注册性函数

这类函数特点：必须写在相应请求之前。（有难度，先了解）

   web_submit_form(...) 就是相应请求

4、加过检查点的脚本如果运行(回放)正确，则说明脚本正确。

（要学会调试脚本，运行出错，运行出错，观察回放日志Replay Log: 红色字体）

vuser_init.c(28): Error -26366: "Text=Welcome, <b>jojo</b>," not found for web_reg_find  [MsgId: MERR-26366]

需求：循环订3张票

 VuGen中 Run-time Settings 按钮 （运行时设置）

  Run Logic 运行逻辑

     Iteration Count  迭代次数 默认1 改为 3

注意：循环只针对Action脚本，init和end只1次

     此时用户登录1次，购票3次

四、注意细节

1、控制台中 和 VuGen中的Run-time Settings的联系和区别：

1）如果从控制台直接打开脚本，则脚本中的Run-time Settings设置会携带过来。（自动显示在控制台中）

2）如果控制台和脚本中同时设置了Run-time Settings，并且值不同，控制台优先级高。

2、Pacing值：每次迭代之间的时间间隔。

 迭代：脚本Action中从第一行执行到最后一行。 1次迭代

 Pacing值越大，对AUT的压力越小

3、Think time: 脚本中步骤（请求）之间的时间间隔。

案例：在控制台中配置场景，进行基准测试

（方法1：单用户循环5次）

操作：

1）调试好脚本（在VuGen中保证运行成功） 已完成

2）打开控制台，加载buy脚本，设置VU: 1个

  Basic Schedule单选  改数量 Quantity: 1

3）迭代次数： 5

 打开Run-time Settings: 默认3次 来自脚本

 Number of Iterations: 改为 5次  优先使用

4）Pacing值： 随机2~3秒

 第1项：

 After the previous iteration ends:  前一次迭代结束

 第3项： （选择）

 At _fixed/random__ intervals,evary ...

   fixed 固定时间      时间间隔

   random 随机时间 （选择）   every 2.000 to 3.000

注意：根据经验，实际企业2~3秒即可，如果软件慢了，可以延长一些。

5）Think time:

  Ignore think time: 忽略脚本中的think time  (先选择)

-> OK

-> Start Vusers 保持默认 因为 1个 VU

     Start all Vusers Simulaneously. 同时加载

-> Duration: Run until completion. 直到运行结束  （默认）

-> 运行场景： Start Scenario

保存场景文件：ctrl/day02/buy1

打开Analysis:进行结果分析

保存结果文件：result/day02/buy1

最关心的是：事务响应时间

  Transaction Name        Average  平均事务响应时间

    buy                       0.284

    login                      0.411

归纳基准测试：

方法1：单用户循环5次

1）调试好脚本（加检查点，在VuGen中脚本运行成功）

2）打开控制台，设置Run-time Settings

3）迭代次数：5

4）Pacing值：随机2~3秒  每次迭代之间的时间间隔

5）Think time: 忽略   请求与请求之间的时间间隔

  忽略的原因：单用户对系统压力较小，忽略与否对结果影响不大 

方法2：单用户持续运行1分钟 （1分钟内不断循环执行Action）

1）调试好脚本（加检查点，在VuGen中脚本运行成功）

2）打开控制台，设置Run-time Settings

3）Pacing值： 随机2~3秒

4）Think time: 忽略

5）Duration: 1分钟

作业：

1、思考题：LR和QTP的区别？

2、尝试完成基准测试方法2.

3、持久题：LR参考文档 （有兴趣多阅读、查找）

   Doc.zip

Day03

复习：

简答题：

1、LoadRunner的工作原理？（重点、难点  BS/MS）

2、基准测试、并发测试的概念？做法？（重要  BS/MS）

1）基准测试就是单用户测试，需要打开控制台，获取Analysis中的测试分析结果。（方法1：单用户循环n次； 方法2：单用户持续执行n时间）

2）并发测试是多用户并发执行某一业务操作，形成瞬时压力（LR同一时刻精确到毫秒级别），是一种严格的测试，主要观察系统对瞬时较大压力的承受能力。

3、并发测试和在线测试的概念、区别？（重要）

1）区别：并发的压力是瞬时压力，在线压力的一段时间的压力。

2）比例：1:10   20用户并发产生的压力相当于200用户在线

3）意义：写测试计划时作为参考

4、吞吐量、点击率的概念、区别？（重要）

1）吞吐量 Throughput: 用户从服务器获得的全部数据量，单位：字节  （反映服务器处理数据量）

2）吞吐率 = 吞吐量 / 传输时间  是服务器每秒处理数据量。

       （反映服务器处理效率，也能反映网络指标）

3）点击率 Hits per Second: 客户端每秒向服务器提交Http请求数。  （点击率越大，对服务器的压力越大）

一、作业题分析

1、思考：QTP和LR的区别。

1）功能(自动化)测试工具 --- QTP

    性能测试工具 --- LR

2）QTP关心的是界面（UI），关心的是对象（对象库的概念）；LR只关心客户端和服务器之间的数据包（请求包、应答包），不关系对象，更不需要比对对象的属性值，只关心抓包（捕捉数据包）。

--如果用户的界面变了，但是业务逻辑不变：

  QTP脚本需要变化；而LR的脚本不变（业务逻辑不变）

3）LR关心客户端和服务器之间的对话，前提是选择正确的网络协议（相当于网络的语言、约定）。

4）LR不能补录。录制失败，从头再来。

注意：录制过程出现失误，该次录制作废，从New开始重新录制；

  录制时要慢，等待资源下载完毕后再进行下一步操作。

方法2：单用户持续运行1分钟

1）调试好脚本 （加检查点，在VuGen运行成功）

2）打开控制台，设置Run-time Settings

3）Pacing值：随机 2~3秒

4）Think time: 忽略

5）Duration: 1分钟

主要流程：

 新建场景 -> 载入buy脚本

 -> 单用户： Basic Schedule -> Quantity: 1

 -> Global Schedule

  Initialize: 初始化  Vuser在Run之前先初始化 （保持默认）

  Start Vuser: 仅1Vuser,默认不改

  Duration: 单选第2项  Run for  0 days and 00:01:00  1分钟

注意：修改完后，观察效果图的状态，有所改变

  Run-time Settings:

    Run Logic: 无需设置迭代次数 （目前不起作用）

    Pacing: 选第3项  随机 random 2~3秒

    Think time: 忽略

-> 运行场景

说明：

1、Duration指的是运行Action的时间。

2、当Run-time Settigns中迭代次数 和 Duration冲突时，以Duration为准，优先级高。

比如：如果Duration单选 第2项，就以此为准。

 如果Duration单选 第1项，Run until completion 还是听Duration，只是此时放权了。

（Duration是一把手，让二把手看着办，所以此时Run-time Settings说的算）

3、运行时间：1分03秒，多出的3秒：用户加载、登录init、退出end 的时间，Duration 1分钟 指的是 Action循环时间

4、测试报告中的结果，建议测试三次（场景运行三次），取中间值（如：0.1秒  0.3秒  0.4秒，结果取0.3秒）。

以上为基准测试。（1VU）

二、并发测试  （nVU）

1、并发测试两个条件

1）脚本中要有 集合点（并发点）

2）控制台中要设置并发策略（选择第一项，所有虚拟用户达到集合点后释放）

 分析集合点：

 5个进程/线程，代表5个VU 并发执行一次购票

 o----------|o------

 o----------|o------

 o----------|o------

 o----------|o------

 o----------|o------

             设置集合点（并发点）

等所有线程到达这一点时，才一起跑，此时的压力最大（瞬时压力）。注意：在事务开始之前，设置并发点

2、并发点 只有在并发测试中使用。

案例：在脚本中添加并发点，执行并发测试

 需求：并发购票

 注意：在购票buy事务脚本之前添加

      lr_start_transaction("buy");

 在事务开始之前 -> 点击Insert -> Rendezvous  集合点

  -> 输入集合点名称 Rendezvous Name: buy  一般与事务同名

 就会生成脚本： lr_rendezvous("buy");

 -> 编译  （同时也会先保存脚本）

      注意：脚本改动后要及时保存、编译

 打开控制台，进行并发测试。如果在原有场景中修改，但需要注意刷新脚本：右击 Script Path 文件目录条目 -> Details 细节

   -> Refresh 刷新  下拉菜单 选中 Script: 刷新脚本

    也可以刷新Runtime Settings: 将脚本中的设置刷新到控制台

3、脚本中发生变动（加了检查点、集合点、参数化等）

1）一定及时保存、编译Compile

2）在控制台中要刷新脚本

在控制台中设置并发策略: （参考：并发点策略_2.png）

  选择Scenario菜单 -> Randezvous... 并发点

  -> 打开窗口，设置策略 -> 点击Policy按钮 （策略）

 第1项：Release when 100% of all Vusers arrive at the

          rendezvous.  （选择此项）

       当100%虚拟用户到了集合点时释放VU

       （所有VU的n%） 10个VU  都算   10 * n%

 第2项：Release when 100% of all running Vusers arrive at           the rendezvous. 

       当100%运行时的VU到达集合点时释放VU

        （所有正在运行VU的n%）

       10个VU只有5个正在运行，5个中的n%  5 * n%

 第3项：Release when 1 Vusers arrive at the rendezvous.

       指定n个虚拟用户到达集合点，再释放

 Timeout between Vusers: 30 sec

    超时时间：两个虚拟用户之间的 （一般达不到，默认不改）

完成5个VU的并发：

  控制台 -> Basic Schedule -> Quantity:  改为5

  Start Vusers: 用户数少，登录时间快，使用同时加载

  Duration: 选择运行直到结束，瞬时压力，无效反复执行

继续设置Run-time Settings:

  Run Logic: 迭代次数  1

  Pacing: 改为As soon as the previous iteration ends.

  Log:  日志  默认

  Think time: 默认 忽略 Ignore think time

    不停地发请求，不给喘息时间，并发测试比较严格

4、并发测试：注意忽略Think time。

原因：Think time时间越长，对AUT的压力越缓，而并发测试是严格的测试，所以要忽略思考时间。

目的：模拟最大压力

配置完毕-> 运行场景  Start Scenario

补充：做完并发测试后的脚本，如果用于其它测试，需要注释掉集合点函数。

三、LR的工具组成

虚拟用户脚本生成器、压力调动控制台、压力结果分析器

（三大组件/四大组件）

1、Load Generator  负载生成器（压力生成器）

 就是一台物理机，负责运行大量的虚拟用户产生负载。

 相当于指挥部指挥下的作战部队。

（比如：一支部队能够支持2000人，如果需要10000人，就需要多支部队协同作战）

  在控制台 Quantity的右边： Load Generators

  默认：localhost 本地主机，负责运行虚拟用户，就是一台物理机

   如何添加同事的主机，协同作战？（联机测试，先了解）

   在Scenzrio Group中，另加一行：

  Group Name    Script Path     Load Generator

                  选择脚本 buy     点击<Add> -> Name

  Name中输入对方主机名 192.168.0.88 -> OK

相当于借助同事的机器的性能帮助自己进行测试。

2、代理程序 （Agent）

 部署在各个客户机，协调得到步调一致的虚拟用户。

 比如:测试时，好比Controller统帅千军万马 （Vuser <-- LG）

                   ---(Agent) Load Generator1

     Controller   ---(Agent) Load Generator2

                   ---(Agent) Load Generator3

 代理程序(Agent) 部署在不同的客户机，好比小的通讯兵

 在控制台启动时，Agent进程会自动启动：

  右下方：一个小雷达图标 LoadRunner Agent Process

 如果不小心关闭，如何打开？

  所有程序 -> HP LoadRunner -> Advanced Settings

     -> LoadRunner Agent Process

结论：如果希望借助其它机器提供负载，其它机器需要启动Agent进程，才能够接收到控制台的命令。（其它机器至少需要安装Load Generator，才可联机测试）

3、监控系统 （Monitor）

监控主要的性能计数器，对被测系统服务器进行监控（后续讲解）

  打开控制台 Run视图 -> 左下角 Available Graphs

   -> System Resourse Graphs   系统资源图

   -> Windows Resource     Windows系统资源图

   -> 图中右击 -> Add Measurements...  增加指标

   -> 打开一个窗口：

   Monitored Server Machines 监控服务器

    Add按钮 -> Machine Information: 主机信息

       Name: localhost     主机名

       平台Platform:  WINXP  ->  OK

    Resources Measurements:

       会自动加载并监控许多资源... (了解，后续需要重新选择)

分析LR工具组成图：（关注四大组件）

 Capture & Record  捕捉 和 录制

 HTTP Protocal   Http协议

 Monitoring  监控  针对被测系统的服务器进行监控

 Run Logs    运行日志

 Load Generator  负载生成器

       模拟 Client Emulation 被测系统真实的客户端

 控制台 Start/Stop 场景，得到分析结果

 产生 Report & Graphs 报告和图表：

（Word、网页格式htm、Excel、Access、

 水晶报表 Crystal Reports、诊断图 Mercury Diagnostics）

4、LoadRunner工具组成图：(描述)

1）对于给定的被测系统，VuGen（虚拟用户脚本生成器）可以按照相应的HTTP协议，对其客户端（IE客户端、Java客户端）进行捕捉和录制，生成脚本；调试脚本：添加事务点、检查点、集合点、参数化等。

2）在VuGen中脚本形成后，可对其进行Run-time Settings设置；

3）在控制台中，选择好脚本（1个或n个），对虚拟用户的加载进行部署，对被测系统的各台服务器进行监控，设置相应的Load Generator（负载生成器）。

4）启动控制台，运行场景，生成Analysis（结果分析报告），进一步获取各种形式的图表。

脚本中如何加注释：

1）单行注释   //

2）多行注释   /*     */

比如，注释掉：  //lr_rendezvous("buy");

   脚本中暂时不用，先注释掉

   注释主要用途，对代码进行解释说明

四、参数化

类似于QTP中的参数池，比如我们可以将用户名作为一个参数池，

可模拟多个用户登录。

以不变的业务（脚本），处理不同的数据（参数池）

1、定义

对脚本中的常量进行参数化，让不同的Vuser在执行相同的脚本时，分别使用参数池中的不同数据替代这些常量，从而达到模拟多用户真实使用系统的情况。

2、步骤：

1）确定需要参数化的数据

2）准备数据 （参数池）

3）参数化

先打开WebTours首页，注册一个用户qq  密码1

   首页 -> Sign up now 开始注册

     Username: qq

     Password:  1

     Confirm:   1

     ...不填

注册后会保存用户信息文件：（后台，不是DB，只是文件系统）

C:\Program Files\HP\LoadRunner\WebTours\MercuryWebTours\users

为了后续便于还原，备份脚本buy

另存为：day03\buy1   File -> Save As

  找到init脚本中需要参数化的常量：

   双击jojo选中 -> 右击

    -> Replace with Parameter  用一个参数代替

    -> 弹出窗口：

     Parameter name:  name  参数的名称

     Parameter type:  默认File   文件类型，大部分都是  

     Original value: jojo 例子

    -> {name} 代替

  同理,将密码进行替换：bean 替换为 {pwd}

  到此，定义好了两个参数。

  接着考虑参数的数据准备： VuGen中

    倒数第2个图标按钮：Open Parameter List -> 参数池 窗口

    左侧可选择不同的参数名称，进行设置

    比如：点击name

    -> Edit with Notepad 按钮   使用记事本编辑

    name

    jojo

    qq

  注意：用Ctrl+a检查 确保光标在最后一行的下一行开头

   First data: 1 改为 2  从数据的第2行开始取 （原数据还在）

  pwd参数也类似，添加一行 1  First date: 2

 -> Close

参数池数据准备完毕。

编译脚本 -> 运行脚本

 如果运行失败，根据回放日志Replay Log 查看原因！

 原因：脚本其它位置使用了jojo,也需要参数化

 选择jojo -> 右击 -> Use Existing Parameter -> 选择name

 -> {name}

新的需求：让jojo和qq各自订一张票

  首先情况AUT中jojo和qq的订票记录，以便观察

  在Parameter List中： First data: 1  从jojo开始取

       pwd也设置为从 bean开始取

  在Run-time Settings: 迭代次数 2 （Action参与迭代）

编译 -> 运行

 遇到的问题：jojo登录1次，订票2次

     init和end只会执行一次，Action可以迭代多次

 解决办法：将init中的脚本剪切到Action中，参与迭代

 注意：保留原有函数的语法格式 （类C语法）

  vuser_init(){

    return 0;

  }

 重新编译-> 回放

3、要点归纳

1）参数化时，参数池中的数据，让光标停留在新的一行。

  技巧：ctrl + a  观察格式

2）默认只对Action脚本参与迭代，所以需要考虑脚本录制的位置。

3）LR依靠网络协议录制脚本，脚本中记录的是请求和应答的数据包信息，只要用户在线（登录成功），则可以通过发送请求，到达任意界面，完成不同业务，可以实现循环操作。

五、参数池的策略初步 （先了解，后续详细分析）

（HP公司LR产品的亮点，卖点，功能强大，BS/MS拔高点）

（Parameter List 窗口中设置）

1、Select next row （取值方式 How?）

  Sequential  顺序的（默认）

  Random   随机取

  Unique    唯一取

  Same line as xxx   和xxx取法一样 (步调一致)

                 name    name

2、Update value on （更新方式 When?）

  Each iteration  每次迭代时取值 （默认）

作业：

1、对于查询订单，进行基准测试（方法1、方法2）、10用户的并发测试，并记录其平均响应时间。（场景运行3次，取中间值）

Day04

复习：3W1H （What? Why? Where? How?）

What: 是什么？ 核心概念 （言简意赅）

Why: 为什么用？ 好处、优点，弥补旧技术的不足

Where: 在哪儿用？ 应用场合

How: 如何用？ 具体步骤、注意事项 （编程、测试、项目经验）

1、什么是性能测试？

性能测试是一种测试方法，在给定的负载条件下，测试被测系统的各项指标是否符合预期要求（性能需求）。比如：给定CPU、内存、硬盘等指标。

具体性能指标：并发用户数、点击率、吞吐率、响应时间、事务响应时间... 发现这些指标和需求不一致，就找到了性能瓶颈。

2、性能测试的目的？

识别系统中的弱点、评估系统性能、进行系统调优。提供系统的可靠性、稳定性。

3、什么时候需要使用性能测试？

许多行业的系统对性能要求很高：银行、金融、电信、医疗、搜索引擎等多用户系统。

4、性能测试的工具--LoadRunner的组成部分：（突出版本号11）

（重点掌握3大组件，有时 + 1 Load Generator）

1）虚拟用户脚本生成器  Virtual User Generator

2）压力调度控制台  Controller

3）压力结果分析器  Analysis

4）负载生成器 Load Generator

5）代理程序   Agent

6）监控系统   Monitor

5、如何进行测试？

LoadRunner 性能测试工具   测试流程：（三大组件为主线）

1）使用VuGen录制脚本 -> 录制完脚本，进行调试

（1、参数化; 2、添加事务; 3、检查点; 4、并发点(集合点)）

脚本分为：init、Action、end

添加事务的目的：控制台运行场景后，会收集事务响应时间。

对事务进行并发：在事务开始之前，加入集合点

                注意：集合点只能加在Action中

web_reg_find();  检查点函数

  特点：带有reg字样的函数(注册性函数)，放在相应的请求之前

  各种文件的形式：

    脚本保存后：  *.usr    脚本文件

    控制台文件：  *.lrs    场景文件

    结果分析文件：*.lra    分析文件

    控制台的结果文件： *.lrr    Results -> Results Settings..

2）将调试好的脚本 -> 控制台中   设置场景

    可以选择：手工设置 （Manual Scenario）

       或 基于目标的设置（Goal-Oriented Scenario）

   一般选择手工方式，可以选择是否以百分比方式指定VUs (不用)

   选择场景的类型：

     设定场景中虚拟用户数、对虚拟用户的设置：

    （初始化、开始运行、持续时间Duration、何时停止）

   Run-time Settings: (场景的优先级高)

     迭代次数: 针对Action迭代   

     Pacing值: 每次迭代之间的时间间隔

     Think time 思考时间: 每次请求之间的时间间隔

   可以监控系统资源：

     指定某台服务器IP (AUT)  或 本地主机 localhost

3）结果分析器：看结果是否符合性能需求

 概要中：事务平均响应时间、吞吐率、页面请求情况、场景运行人数...

 重要图：平均事务响应时间、吞吐率、点击率、VUs、资源图...

提示：结合LR工具组成、运行原理图 分析和描述

一、继续学习参数化

案例：注册30个用户（准备脚本中的数据），脚本要求：

1）脚本中一定要有检查点

2）主要关心数据，保证30个用户全部成功

3）是单机执行还是控制台？

 使用单机(VuGen)，因为压力较缓，容易成功。

 结论：测试数据，尽量不用控制台

 提示：最多1 VU，并使用循环

4）设置充足的Pacing值（3~6秒）和 think time值。

先准备用户数据：使用Excel 设计出 qq1~qq30   1~30

   桌面新建 text.xls

打开VuGen,新建脚本New，New Virtual User界面说明：

 左侧：

  New Single Protocal Script 新的单协议脚本  （较简单）

  New Multiple Protocal Script 新的多协议脚本 （较复杂）

  New Script Recent Protocal  刚打开过的协议

 上方：Popular Protocals 比较流行的协议

   Ajax..、Flex 就是Flash动画协议、Oracle[2-Tier]两层协议、Oracle NCA是.Net新技术、Web Services等

   Web Service规范：解决异构平台之间的互操作

       Java开发系统 <--  xml技术  -->   C语言开发的系统

           xml语言：跨语言的语言，任何编程语言都能解析xml

                     常用于做配置文件

   最常用的协议：Web[HTTP/HTML] 协议

录制注册脚本：

  Create -> 输入URL -> 选Action 注册参与迭代 -> OK

  等待events 数字不动后

  -> 点击Sign up now

  -> 输入Username: www   Password: 1   Confirm: 1

  -> 开始事务reg  -> Continue  -> 进入欢迎页面

  -> 插入检查点： "Thank you, www,"

  -> 结束事务reg

  -> 切换vuser_end  -> Continue  -> Sign Off

  -> 关闭浏览器 -> Stop

保存脚本：script/day04/reg

提示：再次运行脚本，出错，因为用户名已存在

为了实现其它版本，需要将reg备份：reg1   File->Save As

提示：LR脚本编辑器有问题，撤销ctal+z 步数有限

技巧：多备份

开始参数化，使用方法一：准备两个参数池name、pwd

 双击选中www -> 使用参数代替 -> 命名 name -> {name}

                 Replace with a Parameter

 双击选中 1 -> 使用参数代替 -> 命名 pwd  -> {pwd}

 双击选中 1 -> 使用已存在的参数 -> 选择pwd -> {pwd}

                 Use Existing Parameter

 寻找相关的文本，进行替换：比如检查点函数的参数值

  选中www -> 使用已存在的参数 -> 选择name -> {name}

 (提示：需要通篇查找相关数据，使用Ctrl + F   F3 搜索)

   大量的替换：Edit -> Replace  大量文本替换

 接着，将参数池添加完整：

 Open Parameter List -> 进入参数池配置窗口

 先填name -> Excel中 qq1~qq30 拷贝  ctrl + c

   Edit with Notepad    name之后 粘贴 ctrl + v    name.dat

 再填pwd -> Excel中  1~30  拷贝 ctrl + c

   Edit with Notepad    pwd之后 粘贴 ctrl + v    pwd.dat

 策略默认，关闭窗口

准备运行脚本（无需控制台）

 -> 打开Run-time Settings:

  Run Logic: 迭代次数 10

  Pacing值：第3项 random 2~3秒

   （如果测试机性能较好，使用2~3秒，机器慢，6~9秒）

  Log不变：当前标准日志，想让日志更详细，用扩展日志。

       Standard log  标准日志

       Extended log  扩展日志  （扩展）

          Parameter subsititution  参数替代信息 （选择）

  Think time: 点选Replay think time

   -> Use random percentage of recorded think time:

        Min: 50%    Max: 150%

        根据录制时间给出百分比，模拟实际间隔

     比如：lr_think_time(10);   停10秒 （5秒 ~ 15秒）

     原因：做数据，保证成功

配置完成，编译-> 开始运行  （大约几分钟时间...）

方法一的局限：如果是大型项目，属性较多，多个用户名和密码有联系的。

问题：两个参数值，能否写在一起

   name.dat   pwd.dat  -> xxx.dat  (分列显示)

方法二：将两个(多个)参数表的数据合并在一起。

 再将reg备份为reg2

 name的本质：对应一个name.dat文件  可直接打开编辑

 先对常量进行替换，定义参数名称（同方法一）

    用户名 1处   密码 2处

    检查点 用户名 1处

    准备两个参数池： name   pwd  ->  {name}  {pwd}

 Open Parameter List 配置参数池数据：

   选择name以及对应name.dat (合并在此文件中)

   Add Column -> 起列名 pwd  名字可自定义

   Edit with Notepad 编辑文本

     将Excel中数据 qq1   1  ~  qq30  30   拷贝过来

     大量替换：将所有Tab字符（制表符）替换为逗号,

     name,pwd

     qq1,1

     qq2,2

     qq3,3

     ...

     qq30,30

  关注File format:

    默认指定Column: Comma 逗号   备选：Tab或Space 空格

  检查: name 对应File:  name.dat

       pwd 也对应File:  改为name.dat   共享一个文件

  针对参数名选择指定的列：

    By number: 1  列序号   name 选 1    pwd 选 2

    By name:  列名称

 提示：避免用户名冲突  First data: 11  开始

 配置Run-time Settings: (同方法一)

    迭代次数： 10次

    Pacing: 随机 2~3秒

    Log: 默认  扩展日志 + 参数替代信息

    Think time:  随机 50% ~ 150%

配置完成，编译并运行。

结论：推荐使用第二种，比较常用。

原因：项目中相关属性(列、字段)比较多，一起管理比较方便

（曾经的上机题，同时还考察参数池的策略设置）

二、参数池策略 （笔试题：描述参数池策略、根据规则得出结果）

Parameter List窗口中：

1、Select next row:  选择下一行  （How?  如何取?）

1）顺序  Sequential: 从第一行开始顺序向下取值。

2）唯一  Unique:    从第一行开始，唯一的向下取值。

                      （用过了就不用了，重新取值）

比如：数据 a b c d e f g ...

     有3个Vuser (甲 乙 丙)取值，循环2次。

1. A) 选择顺序方式：甲（a, b），乙（a, b），丙（a, b）
2. B) 选择唯一方式：甲（a, b），乙（c, d），丙（e, f）
3. C) 对于单用户来讲：顺序和唯一取值序列相同。

3）随机  Random:  随机取值，值可以重复

4）Same line as xxx:  取值策略与xxx相同。

 比如：pwd中 设置 Same line as name  (行的步调一致)

2、Update value on:  更新方式  （When? 何时取?）

1）每次循环 Each iteration: 每次循环时取值 （常用）

  指的是：Action中的脚本，每次循环时更新值。

2）每次遇到 Each occurrence: 没次遇到该参数时取值

  指的是：比如每次遇到{name}时，都要取一次值。

3）取值一次 Once: 脚本运行过程中只取一次

  指的是：一次选择，终生不变

3、数据不足时处理情况（只有在选取Unique时才适用）

原因：顺序、随机的情况数据都是充足的

     顺序方式，取完最后一行，循环从第一行重新选取

When out of values: 有三种策略

1）放弃虚拟用户  Abort Vuser   (常用)

2）以循环的方式继续 Continue in a cyclic manner

3）持续取最后一个值 Continue with last value

4、需求：注册脚本，多用户，什么策略？

数据池策略组合：Unique + Each iteration + Abort Vuser

  --- UEA组合 （唯一 + 每次迭代 + 放弃虚拟用户）

三、综合场景测试--号称能够最真实的模拟实际生产环境。

综合场景的几个要素：多用户、多个脚本（至少3个）、在线执行一段时间（1小时、50分钟等），一般无需加并发点。

注意：综合场景测试过程中，所有用户 循环 执行相应的操作。

1、录制三个脚本（测试点）：购买机票、查询线路、浏览航班；

每个脚本都要加检查点（手工）。准备做综合场景。

补充一个设置：（目的：让网页标题变为自动的检查点）

 点击Edit Recording Options (录制选项按钮)

 -> 选择第3项  Recording 脚本录制基本方式 （默认）

 -> 选择Advanced 高级 ->

    选择Preferences复选框： 选择

   Generate web_reg_find functions for page titles

   为页面标题生成检查点函数

 再选择： Support charset  -> UTF-8 对中文网站支持好

 -> OK

练习：录制一个登录脚本，看效果

 新建New -> 输入jojo  bean  -> 开始事务login -> Login按钮

   -> 加检查点 "Welcome, jojo, to" -> 结束事务login

  -> vuser_end -> Sign Off -> 关闭浏览器 -> Stop

效果: 自动增加 web_reg_find("Text=Web Tours",

              LAST);

      验证页面标题是否正确，跳转到错误页面，标题则不同。

开始录制脚本：保存在day05中 buy  search  scan

（1）购买机票   buy

  录制过程和之前一样，注意添加事务、检查点

（2）查询线路  search

 New脚本 -> vuser_init  -> 输入jojo和bean

 -> 开始事务login  -> 点击Login -> 结束事务login

 -> 改为Action  -> 点击Flight按钮

 -> 选择城市从Denver 到 Paris -> 开始事务search

 -> 点击Continue -> 添加检查点"Denver to Paris"

 -> 结束事务search

 -> 改为vuser_end -> Sign Off -> 关闭浏览器 -> Stop

（3）浏览航班 scan

 New脚本 -> 改为vuser_init -> 输入jojo和bean

 -> 开始事务login -> 点击Login -> 结束事务login

 -> 改为Action -> 插入事务scan -> 点击Itinerary按钮

 -> 设置检查点 "A total of " -> 结束事务scan

 -> 改为vuser_end -> Sign Off -> 关闭浏览器 -> Stop

注意：检查点会浪费性能（测试机），所以手工检查点，只需1~2即可。

2、需求：10用户综合场景

综合场景设置的要求:

1）脚本事务中的think time时间要删除或移到事务之外。

原因：综合场景测试如果保留think time ,则事务之内的思考时间会起作用，从而影响事务的响应时间，导致结果不准确。

操作：对三个脚本都要移  buy  search  scan

     （包括init、Action和end都要找遍）

    lr_think_time(25);

    lr_start_transaction("buy");

注意：改后都要重新编译，可运行

     如果有并发点，要注释掉：//lr_rendezvous("buy");

    因为综合场景测试虽有并发，但无需形成瞬时压力

到此，脚本调试完毕。打开控制台：

  New Scenario 新建场景 -> Browse 浏览 找到具体脚本

  -> 依次选择day05下 的三个脚本 buy search scan

  -> 进入场景配置界面  保证3个脚本都打钩

  -> 单选Basic schedule

   Group Name           Quantity

     buy.3                   2

     search                  4

     scan                    4

  一共10个人，保持合适的比例，符合客户需求

Day05

简答题：

1、LR脚本中为何做检查点？请写出检查点函数。

（问法：LR执行报告中显示Pass通过了，是否说明脚本执行正确？）

LR执行报告中显示Pass只能表明服务器已经接收客户端的请求包，并且提供应答包，但是应答的内容是否正确，无法确定。所以需要手工（写函数）来验证页面中内容的准确性。

函数：web_reg_find(); 注册性函数，需要写在相应请求之前。

2、如何让一半的用户实现并发？

思路：并发测试（1,添加集合点; 2,设置策略）

      集合点中策略的选择

1) 选择第一项：设置50%用户到达集合点时执行

2) 选择第三项：设置固定的人数

3、参数池的策略？（File类型）  HP公司

4、Think time和Pacing值的区别？

一个是步骤(请求)间隔、一个是迭代间隔(Action脚本)

共同点：单位 秒、都是时间间隔

5、请描述综合场景测试的基本思路？

复习：

1、参数化  （主要关心数据）

1）含义：同样的业务，出现不同的数据，考虑采用脚本参数化。

2）步骤：

 确定参数化的数据 -- 准备数据(参数池) --提供策略 --参数化

3）准备数据 （目前：File方式）

<1> 每个参数使用独立的文件（参数池）

<2> 多个参数共享同一个文件（常用）

注意数据准备技巧Excel、选取列 Column(序号、列名)、开始的数据行First Data

4）参数池策略 （重点、难点）

<1> Select next row  选取下一行 （How? 如何取？）

1. a) 顺序 Sequential: 从第一行开始顺序往下取
2. b) 唯一 Unique: 从第一行开始，唯一向下取
3. c) 随机 Random: 随机取值（可以重复）
4. d) Same line as xxx: 取值策略与xxx参数相同

<2> Update value on  更新方式 （When? 何时取？）

1. a) 每次迭代 Each iteration: 每次循环时取值
2. b) 每次遇到 Each occurrence: 每次遇到该参数时取值
3. c) 取值一次 Once: 只取一次

<3> When out of values: (Unique)数据不足时处理情况,三种：

1. a) 放弃虚拟用户 Abort Vuser
2. b) 以循环的方式继续 Continue in a cyclic manner
3. c) 持续取最后一个值 Continne with last value

5）经典需求：多用户，注册脚本。

 UEA组合：Unique + Each iteration + Abort Vuser

             唯一   +   每次迭代   + 放弃虚拟用户

 另外，常用的组合: SE （顺序 + 每次迭代）

2、综合场景测试：最真实的模拟实际生产环境

要素：多用户、多脚本(>=3)、在线持续运行一段时间（1h左右）

一、继续完成10用户综合场景

之前完成操作：

1）录制好3个脚本：购买机票buy、查询线路search、浏览航班scan. 添加了事务、检查点。调整了think time时间（合适）

 转移了事务中Think time脚本：lr_think_time(23);

 将脚本载入到控制台中，并设置Vuser人数比例：

 Group Name          Quantity

   buy.3                  2

   search                 4

   scan                   4

2）设置场景

Schedule by:

 Scenario 按场景：场景中每个VU都统一行动  （常用）

 Group 按组：通过分组，按每个组行动

再设置左下角Global Schedule:

 注意：以上三个脚本都选中（出现黑框），一次配置三个

 Initialize 初始化 默认运行场景都初始化 （VU "热身"）

 Start Vusers 双击 -> 设置一个小的递增

  单选第2项：每隔00:00:01启动1个VU  -> OK

          1 Vusers eveary 00:00:01

  观察效果图 锯齿状

Duration 双击： 指定持续时间 （1h左右）

  -> 单选第2项：Run for 0 days and 00:30:00  -> OK

 如果第1项：Run until completion 直到结束，适合于循环

 如果第2项：Run indefinitely  一直跑，直到手动停止

3）虚拟用户加载情况部署：

A）每隔一秒钟加载一个VU

B）Duration --- 30分钟

说明：Duration运行的是Action部分，是指VUs登录后循环运行Action的时间。

  10个虚拟用户，是10个线程，各自运行，模拟实际的负载。

设置Run-Time Settings (细节较多)

 选择三组脚本（出现黑框）-> 点击按钮Run-time Settings

 -> 弹出窗口，选择"多"运行模式（RTS）

  Share RTS 共享 / Individual RTS 独立的

 先选独立的 （对三组脚本，会依次配置，先加强练习）

 Run Logic -> Number of Iteration:  1  不变

 Pacing -> 常用第2项 After the previous iteration ends:

    With a random delay of 4.000 to 6.000 sec

    (迭代之间的间隔)

 Log -> Enable logging  (选择)

   Log options:

     Send message only when an error occurs

     出错时才发日志 （选择）

     Always send messages  总是发日志

   Log message at the detail leval of:

     Standard log 标准日志

     Extended log 扩展日志

 Think time -> 随机的百分比，可以适当调大

   Use random percentage of recorded think time:

     Min: 200%    Max:300%

 Additional attributes  附属选项/特殊参数值，不配置

 Miscellaneous 杂项中 ->

   Error Handling 错误处理

     -> Continue on error （打钩）出错后继续

  原因：长时间测试过程中会执行大量的事务，不要因为某个错误而停止场景的运行。

  说明：

  Error Handling中：

   Continue on error

   Fail open transations on lr_error_message 使用不多

   Generate snapshot on error  出错时，生成快照

      使用不多，会增加工具资源消耗，影响结果

  Multithreading: （Thread 线程）

    Run Vuser as a process  以进程方式 （比较耗资源）

    Run Vuser as a thread  默认 以线程方式 （节约资源）

  Automatic Transactions中：自动事务，一般自定义事务

    Define each action as a transaction

      每一个Action都作为一个事务

    Define each step as a transaction

      每一个步骤都作为一个事务（每一个请求，都是事务）

      主次不分，出现大量事务响应时间，影响分析

  Network -> Speed Simulation -> Network Speed 模拟网速

    Use maximum bandwidth  使用最大的带宽 （选择）

     原因：准备充足的带宽，将最大的压力呈现给服务器  

    Use bandwidth: 使用指定的带宽

    Use custom bandwidth(bps) 使用用户自定义带宽

  Browser -> Browser Emulation

    -> 模拟浏览器 Browser properties

    User-Agent  浏览器信息...

     Simulate browser cache 模拟浏览器的缓存 Cache

     （缓存目的：提高客户端浏览速度）

       注意：去掉打钩！！！

       Cache URLs requiring content[HTMLs]

       Check for newer versions of stroed page eve..

     Download non-HTML resources  下载非HTML资源

       （默认打钩）

     Simulate a new user on each iteration 每次迭代模拟新用户

       （默认打钩）

       Clear cache on each iteration 每次迭代清缓存(默认打钩)

  Internet Protocal  协议 ->

    Proxy   No proxy  不要代理 （默认打钩）

             Use custom proxy 若公司使用代理服务器，选择

    Preferences: 都不要改，进入Option 修改 选项

      -> Options... 打开 将三个120 改为 600

      说明：超时时间，保证充分的时间，确保成功

      包括：HTTP-request connect timeout(sec) -> 600

             HTTP-request receive timeout(sec) -> 600

             Step download timeout(sec)  -> 600

点击OK -> 继续设置其它脚本： search 和 scan (方式一样)

4）Run-time Settings设置

(1) Pacing--随机4-6秒（常用2-3秒，机器慢略微加大）

(2) 日志Log --默认配置（出错时发送）

   日志是把双刃剑，有时大量记录日志，占用大量的磁盘空间

(3) Think time -- 随机百分比，适当调大 200% ~ 300%

(4) Continue on error -- 错误时继续

(5) Vuser 选择 线程方式模拟

(6) 网络 -- 模拟用户的网络，使用最大带宽

(7) 模拟缓存-- 不模拟

 （适用场合：1、对AUT实施严格测试；2、门户网站）

(8) Option选项-- 3个120改为600

 （一般疲劳强度测试，600足够了）

(9) 选择监控AUT服务器资源时注意：

 --网络选loopback（回环，因为当前AUT就是本机;如果不是本机，一定不要选回环）

 --选择磁盘(或cpu)的资源时，遇到total就选total.

继续配置Windows Resources (系统资源监控  Run视图右下角)

  右击窗口 -> Add Measurements... ->

   Monitored Server Machines: 选机器(n台服务器) 

  点击Add... ->

    Machine Information:

      Name: localhost  指定监控服务器的IP地址，目前本地主机

      Platform: WINXP

   -> OK

 Resourse Measurements on: localhost

 先清空所有选项，自己添加（先固定13项）

 -> 点击Add按钮 -> 选择以下内容：

 Memory中有4项：（内存）

   Available MBytes         ->  Add

   %Commited Byte in Use  -> Add

   Page Faults/sec           -> Add

   Pages/sec                  -> Add

 Network Interface中有2项：（网络）

   Bytes Total/sec -> MS TCP Loopback inter...  回环

          -> Add  本地主机才选回环

   Packets/sec  -> MS TCP Loopback inter...  回环

          -> Add

 PhysicalDisk （物理磁盘）包括2个队列，见到Total就选Total

   Avg.Disk Queue Length     -> Total  -> Add

   Current Disk Queue Length -> Total  -> Add

   Disk Read Bytes/sec        -> Total  -> Add

   Disk Write Bytes/sec       -> Total  -> Add

 Processor中有2项：（处理器 进程）

   %Processor Time  -> Total  -> Add      Total总和

   %User Time       -> Total  -> Add

 System中1项：

   Process Queue Length  -> Add

-> OK

（一共13项，先了解，高级部分再讲解）参考 资源图.doc

保存场景文件：10用户综合场景.lrs

开始运行场景 点击Start Scenario

数据结构

  数组、栈、队列。。。

  栈 Stack  先进后出 FILO  First In Last Out

  队列 Queue 先进先出 FIFO  First In First Out

       最大长度

5）当场景中Duration到达指定时间时，会向所有的VUs发出退出系统的指令，所有的VUs要完当前的Action，退出系统。

6）如果场景中报监控服务器资源为负值，不是问题，无需停止场景运行。如果发现Error错误，打开窗口查看错误描述Details

    选中错误 -> 点击Details按钮 -> 显示错误详细信息

    （定位出具体脚本文件(.. Action.c)、错误行）

如果发现设置不合理、或者脚本错误导致场景中出现大量错误，则需要停止场景，重新调试脚本后，再部署。（刷新到控制台）

7）监控的服务器资源举例：

 控制面板 -> 管理工具 -> 性能 -> 计数器

场景运行结束，打开Analysis，分析结果报告：

保存：result/day05/10用户综合场景

综合场景测试案例2： （思考题）

1、使用手工设置方式进行综合场景测试，11用户，其中一个用户执行注册脚本，注册得到的用户名为其它脚本提供数据池（测试数据、参数化）

2、综合场景中脚本：注册、购买机票（登录时，用户名、密码需要参数化）、搜索航班、浏览线路。

提示：注册需要先于其它脚本执行

       分组设置场景: 以组Group方式设置场景

精通  熟练掌握 掌握  熟悉  了解

Day06

复习：

1、综合场景测试注意要点？（整体策略）

提示：有主线，要点、举例说明

1）多用户、多脚本（超过3个）、在线执行一段时间

2）录多个脚本：检查点、事务点、参数化

     移出事务中的think time、设置合适的think time

3）通过控制台设置场景:

    用户数，设置合适的比例；用户加载方式、持续时间Duration一般1小时左右。

    设置Run-time Settings:

      Pacing值 Thinktime  Log  ...

    监控被测系统的系统资源 （13项）

4）运行场景，密切监控运行状态，发现明显的错误，要及时结束运行，进行调试。

5）运行结束，打开Analysis，进行性能的分析。

一、综合场景测试案例2：（11用户综合场景_reg）

1、使用手工设置的方式进行综合场景测试，11用户，其中一个用户执行注册脚本，注册得到的用户名为其它脚本提供数据池（测试数据 name.date 策略：UEA组合）。

2、综合场景中的脚本：注册reg、购买机票buy（登录时，用户名和密码需要参数化，共享参数池name.dat）、查询航班search、浏览线路scan。

说明：控制台中四个常用的按钮

1）运行按场景 

2）Run-time Settings按钮  运行场景时的设置

3）脚本修改后刷新脚本

4）从场景中打开脚本（定位脚本错误位置）

操作步骤：

1、录制脚本，添加事务、检查点、参数化（保存在day06）

（1）reg脚本

 录制过程：

 New -> 选Action -> 点击链接Sign up now

 -> 输入Username: tom  Password: 1  Confirm: 1

 -> 开始事务reg -> Continue -> 进入欢迎页面

 -> 插入检查点"Thank you, tom"  -> 结束事务reg

 -> 切换为vuser_end  -> 点击 Continue

 -> Sign Off退出 -> 关闭浏览器 -> Stop

 参数化name和pwd，在name.dat，使用ww1~ww11，检查光标停留在下一行：

name,pwd

ww1,1

ww2,2

...

ww11,11

 使用参数化的策略：

  针对name: （UEA组合）

    Select next row: Unique  表示从第一行开始唯一向下取

    Update value on: Each iteration  每次迭代时

    When out of values: Abort Vuser 放弃

  针对pwd:

    Select next row: Same line as name  与name步调一致

注意：修改后记得编译！

（2）buy脚本

注意：将登录操作也录制到Action中，目前是迭代时，能够取得参数池的数据。（参数池共享name.dat  策略：SE组合）

录制过程：

 New -> 选Action -> 输入jojo和bean

 -> 开始事务login -> 点击Login -> 欢迎页面：

 -> 插入检查点“Welcome, jojo,” -> 结束事务login

 -> 点击Flights

 -> 选择城市Denver到London -> Continue -> Continue

 -> 开始事务buy -> Continue -> 成功页面：

 -> 插入检查点“Denver for London” -> 结束事务buy

 -> 改为vuser_end -> Sign Off -> 关闭浏览器 -> Stop

参数化：

  将参数池准备好，拷贝reg目录中name.dat到buy目录中

  在脚本中设置参数池，指定File： name.dat文件

  参数池策略：

   针对name: （SE组合  常用80%）

     Select next row: Sequential  顺序的

     Update value on: Each iteration 每次迭代时

   针对pwd:  选name.dat

     By number: 2

     Select next row: Same line as name

测试完数据后，为了综合场景中可用，需要删除底层数据文件

ww1~ww11

（3）search脚本

 New -> vuser_init -> 输入jojo和bean

 开始事务Login -> 点击Login -> 结束事务login

 -> 改为Action -> 点击Flight按钮 -> 选择城市从Denver到Paris

 -> 开始事务search -> 点击Continue

 -> 添加检查点"Denver to Paris"  -> 结束事务search

 -> 改为vuser_end -> Sign Off -> 关闭浏览器 -> Stop

（4）scan脚本

 New -> 改为vuser_init -> 输入jojo和bean

 -> 开始事务login -> 点击Login -> 结束事务login

 -> 改为Action -> 插入事务scan -> 点击Itinerary按钮

 -> 检查点“A total of” -> 结束事务scan

 -> 改为vuser_end -> Sign Off -> 关闭浏览器 -> Stop

注意：检查所有脚本，对事务中lr_think_time(..)函数进行转移

      buy脚本中参数池数据，要和reg保持一致。

到此，脚本调试完成。

2、打开控制台，配置综合场景

 创建一个新的场景，Browse载入day06下的4个脚本：

 reg、buy、search、scan

 选择Schedule by: Group模式 （组模式）

    Scenario模式：多个脚本共享同一场景

    Group模式：各组的脚本使用同一场景

 注意：依次选择每个脚本，选择Run Mode: -> Basic Schedule

   Script Path     Quantity

     reg.1            1

     buy              2

    search            3

    scan              5

注意：由于使用Group组模式，(左下角)每个脚本要逐一设置

（1）reg脚本（选中）

 Start Group: 改为Start immediately after the scanario begins.  场景开始就加载VU

 Initialize: 默认 Initialize each Vuser just before it runs.

 Start Vusers: 默认 Start all Vusers simulaneously.

 Duration: 默认 Run until completion  运行直到结束

打开Run-time Settings:

 Run Logic: 循环11次

 Pacing: 选第2项  random 2~3秒

 Log: 默认

 Think time:  random 50% ~ 150%

 Miscellaneous（杂项）:

     Error Handling: 不选择 Continue on error

      原因：目前主要测数据，一旦出错，不能继续往下执行

 Speed Simulation: 网络速度模拟 （默认）

 Broser Emulation:

     需要选择 Simulate browser cache  模拟浏览器缓存

     原因：做测试数据，利用Cache容易成功

 Proxy: 代理 （默认）

 Preferences:  Option参数 （先不动）

 （其余都默认）

（2）buy脚本（选中）

 Start Group: 选第3项 Start when group reg.1 finishes

 Initialize: 默认 Initialize each Vuser just before it runs.

 Start Vusers: 默认 Start all Vusers simulaneously.

           （人数少，可同时；人数多，小递增）

 Duration: 选第2项 Run for 0 days and 00:30:00(HH:MM:SS)

           （练习30分钟，项目一般1h）

（3）search脚本（选中）

 Start Group: 选第3项 Start when group reg.1 finishes

 Initialize: 默认 Initialize each Vuser just before it runs.

 Start Vusers: 1 Vusers every 00:00:01(HH:MM:SS)

             每隔1秒钟加载1个VU

           （人数少，可同时；人数多，小递增）

 Duration: 选第2项 Run for 0 days and 00:30:00(HH:MM:SS)

（4）scan脚本（选中） 配置 同search

 Start Group: 选第3项 Start when group reg.1 finishes

 Initialize: 默认 Initialize each Vuser just before it runs.

 Start Vusers: 1 Vusers every 00:00:01(HH:MM:SS)

             每隔1秒钟加载1个VU

           （人数少，可同时；人数多，小递增）

 Duration: 选第2项 Run for 0 days and 00:30:00(HH:MM:SS)

看到配置效果图：reg.1 虚线表示时间不确定

                  其它3条平行线  纵坐标：0  1  2  3  5

reg的Run-time Settings已经基本完成，

继续统一设置其它三个：选中buy、search、scan (黑框)

 -> Run-time Settings -> Shared RTS 方式：（共享方式）

  Number of Iteration: 1

  Pacing:  第2项 random 4~6秒

  Log:  Send messages only when an error occurs

         出错是时发送

  Think time: 随机 100% ~ 200%

  Miscellaneous(杂项):

      Error Handling: 只选择 Continue on error

      Multithreading: 选择 Run Vuser as thread 以线程方式

  Speend Simulation: Use maximum bandwidth 模拟最大带宽

  Browser Emulation:

       不选 Simulate browser cache   比较严格的测试

       选择 Download non-HTML resources

       选择 Simulate a new user on each iteration

         选择 Clear cache on each iteration

  Proxy: 代理  不要代理 选择No Proxy

  Preferences: 暂时不选 Enable Image and text check

             Options参数 (后续单独设置)

其余不动 -> OK

之后依次设置Options:

 选择buy脚本 -> Run-time Settings  -> Preferences:

  -> Options  -> 将三个120改为600  超时时间

    原因：保证充足的时间，确保成功

 包括：HTTP-request connect timeout(sec)   -> 600

        HTTP-request receive timeout(sec)   -> 600

        Step download timeout(sec)           -> 600

后续的search和scan脚本也一样...120 -> 600

最后配置Windows resources: 系统监控 13+1项 （Run右下角）

  补充：Memroy 中 Page Reads/sec (页面读取率)

参考之前的笔记（资源图.doc）

  右击窗口 -> Add Measurements... ->

   Monitored Server Machines: 选机器(n台服务器) 

  点击Add... ->

    Machine Information:

      Name: localhost  指定监控服务器的IP地址，目前本地主机

      Platform: WINXP

   -> OK

 Resourse Measurements on: localhost

 先清空所有选项，自己添加（先固定13项）

 -> 点击Add按钮 -> 选择以下内容：

 Memory中有4项：（内存）

   Available MBytes         ->  Add

   %Commited Byte in Use  -> Add

   Page Faults/sec           -> Add

   Pages/sec                  -> Add

 Network Interface中有2项：（网络）

   Bytes Total/sec -> MS TCP Loopback inter...  回环

          -> Add  本地主机才选回环

   Packets/sec  -> MS TCP Loopback inter...  回环

          -> Add

 PhysicalDisk （物理磁盘）包括2个队列，见到Total就选Total

   Avg.Disk Queue Length     -> Total  -> Add

   Current Disk Queue Length -> Total  -> Add

   Disk Read Bytes/sec        -> Total  -> Add

   Disk Write Bytes/sec       -> Total  -> Add

 Processor中有2项：（处理器 进程）

   %Processor Time  -> Total  -> Add      Total总和

   %User Time       -> Total  -> Add

 System中1项：

   Process Queue Length  -> Add

-> OK

（一共13项，先了解，高级部分再讲解）

 再追加一项：

 Memory中：Page Reads/sec  页面读取率

 以上一共14项

->加完资源监控，可以运行场景

保存场景: 11用户综合场景_reg

-> 点击Start Scenario

二、综合场景设置要点

1、Continue on error

 -- Run-time Settings杂项中Error Handling

1）综合场景测试时要选择 （大部分）

2）做测试数据时，由于保证数据成功，不能选择。失败时应该及时停止场景运行。（reg）

2、模拟浏览器Cache --

1）综合场景如果进行严格测试，不选择

2）做数据测试时，利用Cache容易成功，需要选择。

3、监控资源时，添加一项：Page Reads/sec  页面读取率

4、在场景启动之前，服务器监控应该提前启动。确保资源（服务器）连接无误后，再开始场景。

5、在综合场景启动时开始，要密切关注，必须保证所有用户全部上线（登录成功），才称为多用户在线综合场景。

6、当所有用户上线后，也要密切关注，控制台中各个图表，当图表走势不正常时，代表系统不稳定，要及时查找原因，如果是综合场景的设置问题，甚至脚本的问题，要及时停止运行，调整后重新测试。

分析结果图：

Transactions:

Transaction Name   事务名称

Minimum    最小值

Average    平均值

Maximum   最大值

Std.Deviation  标准方差值

90 Percent     90%响应时间

Pass   通过的

Fail    失败的

三、报告讲解  HP LoadRunner Analysis

1、90 percent 响应时间：表示改组中90%的用户都能在该时间内响应（完成该操作）。

  比如：90%的用户在 0.xxx秒内完成

可以修改：

  Additional Settings -> Transaction Percentile

   比如改为80%，再改回90%

2、90%含义：

比如，一个事务，100用户执行，其中一个用户执行1000秒，其它99%用户响应时间0.01秒。

问题：90%时间 和 平均事务响应时间，哪个比较准确？

结论：90 percent

3、Std.Deviation  标准方差值

结论：越小越好，越趋近于0，表示所有用户执行该事务的响应时间越接近，表示系统越稳定。

比如：

   Minimum     Average    Maximum   Std.Deviation

    0.203       0.313      0.403        0.095

需求：将两张图进行合并对比分析

 打开Hits per Second图 -> 右击图片 -> Merge Graphs 合并图

  -> 选择结合Running Vusers图

 图形重叠便于比较，分析：

  当多个用户同时加载时，点击率急剧上升(向AUT发请求较多)

练习：结合Hit per Second 和 Throughput 进行分析

得出以下结论：

4、网络带宽充足的情况下，当吞吐量 随着 点击率的升高而升高，说明AUT的服务器的处理能力充足。

说明：点击率是因，吞吐量是果

将结果保存，后续高级部分再分析：

result\day06\11用户综合场景_reg

四、LR流程：

1、性能测试的基本概念

2、LR的三大组件协调工作（基准测试、并发测试、综合场景测试）

3、三大组件：（加* 表示高级部分）

1）脚本生成器（录制、事务、检查点、并发点、参数化、参数池策略*、关联*）

 后续讲解：参数池策略、脚本关联技术（难点、高级）

2）控制台（基本参数设置、后续细化研究*）

3）结果分析器（简单查看结果[服务器资源分析*]、性能测试综合分析*--瓶颈定位*--性能调优*） **

说明：** 表示扩展部分

五、为了使网站页面响应速度更快，可以将页面中的图片、视频、音频、动画等元素尽量减少，进而减少客户端访问服务器的次数，减少信息的传输量，加快访问速度。

六、脚本录制

1、选择协议，如果正常协议(Web)无法成功录制脚本，可以根据系统（如C/S系统），选择Windows Sockets协议(万能协议)

说明：C/S系统越来越少，逐步被B/S取代，Web项目

2、LR的脚本中Action越少越好，便于性能分析。

3、性能测试中AUT的服务器，要分开部署，便于性能分析。

                    AUT 被测系统

        ___________________________

        应用服务器   ----   数据库服务器

  Application Server         DataBase Server

   /Web Server

4、VuGen窗口：

1）脚本中记录的是客户端的请求。

2）Replay Log --- 记录脚本回放（执行）日志. （较常用）

3）Recording Log --- 记录LR客户端和服务器二者之间对话的数据包大小。（用到较少，内容不及 4））

4）Generation Log --- 记录LR客户端和服务器二者之间全部对话。（关联技术常用）

5、脚本中的LR函数，LAST是函数的结束符

作业：

1、综合场景测试

课上练习--按场景方式(最重要)、按组方式  整理好

比如：10用户综合场景、11用户综合场景_reg

2、知识点复习：基准测试、并发测试、综合场景测试

3、预习检查点添加、参数池策略

Day07

面试技巧：

模板：遇到过什么问题，我是怎么解决的。（项目经验）

  之前是___做的，经过项目实践，发现__不足，___改进的。

今天主要内容：检查点函数及其技巧

案例1：设置检查点，脚本录制好后再加代码

 录制buy脚本

 加web_find函数，文本来自页面内容

 打开AUT -> jojo bean -> 拷贝页面文本 Welcome, jojo

 在相应请求之后添加：(web_submit_form 之后)

 点击Insert -> Net Step... -> Web Checks -> Test Check

 -> OK  出现窗口 Text Check Properties

   Search for: 粘贴文本  -> 确定

 脚本增加：

 web_find("web_find",          //步骤名

     "What=Welcome, jojo",   //检查内容

     LAST);                      //结束符

 编译 -> 回放

 还需要一个设置：Run-time Settings ->

  Internet Protocol -> Preferences 参数 -> Checks 开关

   选择 Enable Image and text check  允许使用

 再允许脚本：日志中出现相关信息

练习：为购票成功添加检查点 web_find

 找到相应的请求：Action的buy事务范围内找

 拷贝网页中检查的文本

 Insert -> 插入web_find函数

继续添加代码：（代码先抓结构：顺序、分支、循环）

vuser_init(){

  int a;  //定义a为整型变量 

  ...

  a = web_find(...);

  if(a==0){

     输出成功   lr_output_message("...");

  }else{

     输出失败

  }

  ...

  return 0;

}

补充：web_find其它参数

 拷贝网页中  Denver for Paris

 在脚本中继续插入检查点：

 点击Insert -> New Step... -> Web Checks -> Text Check

  -> OK 窗口中:

 Search Parameters

    Search for: for

    打钩Right of: Denver   注意：前后不要空格

    打钩Left of: Paris

 确定即可，生成脚本：

  web_find("web_find",

       "RightOf=Denver",

       "LeftOf=Paris",

       "What=for",

       LAST);

 编译 -> 回放脚本

提示面试技巧：使用web_find函数，发现技术细节，Right of反着用...

一、检查点函数

1、web_find函数

1）写在相应请求之后

2）Run-time Settings需要设置：可用 Enable

3）左边界：RightOf

4）右边界：LeftOf

5）web_find执行效率低于web_reg_find.

2、lr_output_message 是LR的输出函数，经常用于脚本的调试。

3、脚本中快速定位

1）从日志定位到脚本行：双击日志、根据行号 Ctrl + g

2）从脚本行定位到日志中：

  右击脚本 -> Go to Setp in Replay log

二、检查点函数区别

1、web_find()    （LR普通函数） 文本检查点

特点：从HTML页面中查找指定的文本字符串

       比较占资源、效率低，较少使用

2、web_image_check()   图片检查点

1）alt参数：当鼠标悬浮在图片上时显示文本，给用户看的

2）src参数：图片的路径名和图片名称，给程序员看的

<img src="图片地址" alt="图片说明"/>

3、web_reg_find()  （LR注册性函数） 文本检查点

特点：在缓存中（HTML源代码级别）查找相应的内容

    效率高，较常用。

案例2：添加图片检查点 （了解）

 先打开AUT网站，找到页面图片，源代码 -> 拷贝图片路径名

 src="images/webtours.png" ->  images/webtours.png

 在vuser_init脚本中，找到相应请求之后：

   web_submit_form(...)  光标之后停留，添加脚本：

 点击Insert -> New Setp -> Web Checks

 -> Image Check   Find Function:自动显示web_image_check

 -> OK 弹出窗口中：

  Alternative image name(ALT)

 打钩Image server file name(SRC) 路径名粘贴 -> 确定

 自动生成脚本：

  web_image_check("web_image_check",

       "Src=images/webtours.png",

       LAST);

 也需要打开Run-time Settings -> Internet Protocol

  -> Preferneces -> Checks

  选择Enable Image and text check  允许使用

 编译 -> 回放脚本

4、web_reg_find是注册性函数，需要写在相应请求之前。

规律：LR所有的注册性函数，含有reg字样，都要写在相应请求之前。

案例3：用两种方式添加web_reg_find检查点

先找到检查的文本：通过网页查看源代码

   Welcome, <b>jojo</b>,

   找到init脚本中，相应请求之前，光标停留

     web_submit_form之前

方式一：点击自动生成

 Insert -> New Step -> Services -> 找到web_reg_find

 -> OK 弹出窗口中：

  单选：Search for specific Text  查找指定文本

   填入：Welcome, <b>jojo</b>,  粘贴

  其它参数，暂时忽略

生成：web_reg_find("Text=Welcome, <b>jojo</b>,",

                    LAST);

方法二：手写脚本（文本内容粘贴才准确）

 web_reg_find("Text=Welcome, <b>jojo</b>,",

                    LAST);

编译 -> 回放

练习：添加订票成功检查点 web_reg_find

关键：什么文本？添加位置？

       源代码       请求之前

5、添加每个检查点的第一步，都要在脚本中找到相应请求：

比如，确定Action -> 确定Transaction -> 找到录制形成的请求

脚本代码阅读：

web_reg_find("Text=ABC", "SaveCount=abc_count", LAST);

web_url("Step", "URL=...", LAST);

if (strcmp(lr_eval_string("{abc_count}"), "0") == 0){               lr_output_message("not found");  //找不到

}else{

   lr_output_message("%s times",

                         lr_eval_string("{abc_count}"));

}

6、LR脚本中有两种变量，一种是C语言的变量，需要在脚本开始处定义（如 int a;）；另一种是LR的变量，出现在LR的函数里，只需提供名称（如 abc_count），实际值由LR函数运行后赋予。

注意：如果需要使用LR变量实际值，则必须加{}  如：{abc_count}

7、lr_eval_string函数 起到一个桥梁作用，将LR的变量介绍给C语言的函数使用。（高级脚本调试时常用）

  LR变量 -> C语言能够理解的字符串

比如：

 lr_eval_string("{abc_count}");

 lr_eval_string("{name}");

该函数的返回结果，就可以给C语言函数当做参数来使用

strcmp(lr_eval_string("{abc_count}"), "0")

8、strcmp(a, b) 表示比较两个字符串的值是否相等，如果返回0，则表示两个字符串相等。（C语言函数）

9、lr_eval_string("{abc_count}")

 lr_eval_string之后参数表 ();  ()中为字符串，所以加" "

 " " 中不是普通字符串，而是LR字符串变量，所以加{ }

Java: System.out.println(abc_count + "次");

C语法：格式化输出   结合LR的类C语言

lr_output_message("%s 次",

                      lr_eval_string("{abc_count}"));

10、C语言中%s表示字符串格式符，经常用于输出语句

      %d 表示整数的格式符

11、以上语句表示将lr_eval_string("{abc_count}") 得到的数据以字符串的格式输出。

提示：C语言严格区分大小写 strcmp

     LR可以不区分，Lr_output_message，但是为了统一，要规范

     统一全部小写：lr_output_message

12、输出count的语句要写在相应请求之后，因为请求之后才有应答，在应答的内容中才可统计次数，所以需要在请求之后。

13、web_reg_find函数中的SaveCount要慎用！如果不是要获取查找次数，而只是检查文本，只需使用"Text"参数即可。

原因：使用SaveCount，文本不对，结果也是Done,引起误导

       日志显示0次

14、网络中，HTTP协议数据包分为两种：请求包、响应包

其中两种数据包中结构相似：分为头(header)和主体(body)两个部分。

比如：请求的body中，带有jojo和bean信息

       响应的body中，带有网页html文本、图片等资源

打开VuGen,目前使用Script视图

  其它：Tasks 任务视图

         Tree  树视图  好处：看到请求、响应的底层信息

案例：使用Tree视图，插入检查点

 需求：添加订票成功检查点

 切换到Script视图，找到相应请求，web_sumbit_form...

 切换到Tree视图，即可定位

 找到HTML View界面：（直观）

 选中Denver for Paris -> 右击

 -> Add a Text Check(web_reg_find)  默认使用推荐的函数

 -> 弹出窗口 -> OK

生成脚本：

  web_reg_find("Search=Body",  //在Body范围内查找 All

      "Text=Denver  for Paris",

      LAST);

练习：以Tree视图（HTTP协议界面）添加登录成功检查点。

三、总结web_reg_find函数的几种添加方法

1、录制时添加 (小望远镜图标)

注意：有时录制过程无法加上，需要后续追加

       录制时无法确定怎么添加，也是后续追加

2、录制结束后从Script视图添加

1）Insert 插入

2）手工书写函数

3、从VuGen -> Tree树视图 -> Html View 页面内容检查点

注意1：选择___页面。（录制/回放） 录制

原因：录制界面保证正确，回放界面无法保证

注意2：选择___页面。（请求/响应） 响应

原因：要检查的内容存在应答包中（验证服务器的响应是否正确）

了解脚本的不同录制方式：HTML 和 URL

打开VuGen:  Edit Recording Options 按钮

   选择 URL-based script 方式录制

录制登录脚本 login_byUrl:

 New -> 选择Action -> 输入jojo和bean -> 开始事务login

 -> 点击Login -> 添加检查点 -> 结束事务login

 -> vuser_end -> Sign Off -> 关闭IE -> Stop

四、脚本的两种录制方式（后续详细分析）

1、目前先统一使用Html方式录制

切换方式：

1）VuGen界面中 -> Edit Recording Options 按钮

  -> General中 Recording 选择其一：

   HTML-base script 或 URL-base script

2）开始录制时，Options按钮 打开选择

2、基于Html方式脚本比较简单，篇幅短。

3、基于URL方式脚本比较复杂，篇幅长。

4、由于一些特殊的系统，比如使用基于Https协议的系统，一般需要使用基于URL方式录制。

原因：URL方式录制脚本比较全面、完整。

说明：Https协议是基于安全的Http协议，常用于银行、证券、石油。

5、所以选择脚本录制方式时，先选择HTML方式，如果不成功，再考虑使用URL方式，绝大部分可采用Html方式录制。

新建脚本：

  New脚本 -> Cancel 取消 ->  直接在Action中编辑脚本

五、几种输出函数的区别 （笔试题）

1）lr_output_message("执行失败！"); 

  脚本,行号,输出引号里内容；    调试时常用

2）lr_error_message("执行失败！");

  脚本,行号,红色字体,输出引号里内容； 常用于报错

3）lr_log_message("执行失败！");

  只输出引号里内容； 常用于输出日常的日志消息

4）lr_message("执行失败！");

  只输出引号里内容；

需求：做一个试验，采用10个虚拟用户，使用进程 和 线程两种范式模拟VU，观察对测试机系统性能的影响。（不是AUT）

基本思路：打开控制台，打开任务管理器 查看mmdrv进程

 打开控制台 -> 选择day05\buy脚本 -> 默认10VU

 -> 默认使用线程方式

 -> 打开Run-time Settings -> Multithreading

    使用默认：Run Vusers as a thread

 -> Think time 默认 Replay think time中 As recorded选项

 -> Start Vuser: 同时加载 Simutaeously

 -> 其它默认

   Duration: Run for 00:05:00

   Stop Vuser: Stop all Vuser: 5 every 00:00:30

 -> 运行场景

打开任务管理器：查看mmdrv进程 就1个，用了11M，对系统资源占少。

  结束场景 -> 改为进程方式：Run Vuser as process

  -> 再运行场景

打开任务管理器：查看10个 mmdiv进程，平均每个7M多内存，对系统资源占用多。

原则：线程一般在50个以内，都使用1个mmdrv进程

结论：推荐使用线程方式模拟VU

六、多机联合测试 （联机测试）

1、一台PC机能够实现有限个VU共同运行，VU的个数取决于PC的配置。

2、假如自己的机器能够承受2000个用户，现系统要求4000用户在线：采用联机测试

（借用其他机器的性能参与测试，共同达到指定的负载 VU）

3、需求：

订票2张，使用自己的机器和同学机器，各分配1个VU，要求2张票都要订在自己机器的网站上。

 --脚本中IP地址，默认localhost，需要改为自己机器的IP

原因：默认localhost或127.0.0.1是向本地主机的AUT订票，结果是两个系统各订1张票。

说明：实际项目中，IP地址一般不是localhost，所以无需修改。

前提：需要保证自己的机器和同学的机器要连通。"ready"状态

   通过ping命令 测试网络是否可达    ping  对方IP

   查看自己IP 打开cmd   ipconfig命令 

   本地IP:172.166.100.53

   对方IP: 172.166.6.99

   ping 172.166.6.99

将day05\buy 打开  另存为 day07\buy1

4、要求负载机（同学机器）需要安装Load Generator，还必须启动Agent进程（小雷达）。---已经完成，自动启动了

5、在脚本中需要修改IP地址，都改为本机IP

注意：多个文件所有127.0.0.1或localhost

       都改为：172.166.100.53   （以自己机器为准）

编译 -> 刷新到控制台中

6、在控制台中，连续打开buy脚本，一个组设置localhost

 另一组设置对方IP （Load Generator设置）

 在控制台中，菜单Scenario -> Load Generators

   -> 弹出小窗口 测试是否连通

    localhost  达到 Ready

    对方IP  -> 点击 Connect按钮  -> Ready 表示成功了

                                         Failed 失败

7、打开Load Generators窗口，连接到对方机器  Ready即可

8、各设置1VU  Basic schedule -> 人数 1VU

运行场景 -> 本机订了2张票  成功了。

回顾今天的内容：

1）检查点函数：web_reg_find 重要

    web_find 和 web_image_check  了解

2）不同的添加方式

3）脚本的两种录制方式：Html 和 URL

4）几种输出函数的区别（记忆）

5）联机测试

复习参数池策略 （重要）

Day08

复习：

脚本参数化（重点：参数化策略）

一、参数池策略（重点，理解记忆，BS/MS常考）

1、Select next row （取值方式 How?）

1）顺序：对于每个VU，都是从第一行开始，顺序(依次)向下取值

         --每个VU取值序列相同。

2）唯一：对于每个VU，从第一行开始，唯一的依次向下取值。

         --每个VU取值序列不相同。

规律：如果是单用户，顺序和唯一的取值序列相同。

3）随机：每个VU，都可随机取值，可重复

4）和xxx步调一致：和xxx参数取值行相同

2、Update value on （何时取？ When?）

1）每次迭代：每次脚本循环(Action)时更新参数值。

2）每次遇到：脚本运行时，只要遇到该参数即更新。

举例：脚本循环2次，脚本中name参数出现3次。

      每次迭代策略 总共更新_2_次.

      每次遇到策略 总共更新_6_次.

--每次遇到=每次迭代次数 * n 

       n表示脚本(Action)中某个参数出现的次数。

3）Once 只取一次：一次取值，从不改变

3、Out of value（越界策略--参数池数据不够时  Unique）

1）放弃VU：直接放弃该虚拟用户，会报错

2）以循环的方式继续：循环从第一行开始

3）以最后一个值继续：一直使用最后一个值

案例1：新建一个空脚本，编写测试脚本，通过不同策略取得参数池数据。

 新建空脚本

 点击Open Parameter List -> 点击New按钮 ->新建name和pwd

 编辑脚本，输出参数内容

 准备参数池中数据  Excel工具生成 a1~a30  b1~b30

   在name.dat添加一列 pwd

   name,pwd

   a1,b1

   a2,b2

   ...

   b30,b30

 让name和pwd 都选择 name.dat

  name 选 第1列，  pwd 选第2列  First Data都从1开始

 设置：循环5次

 运行，查看日志

将param1另存为param2

二、练习（笔试题）

某参数现有备用数据a1 a2 a3 ... a30，脚本迭代3次（不打开控制台），完成以下结果：

分析：单用户，平时可以借助脚本检验

1、顺序 + 每次迭代：a1 a2 a3

2、唯一 + 每次迭代：a1 a2 a3

      规律1：对于单用户，顺序和唯一的取值序列相同

3、随机 + 每次迭代：a12 a3 a30

4、顺序 + 每次遇到：a1 a2 a3

      规律2：对于单用户，如果脚本中某参数只出现一次

               每次迭代 和 每次遇到的取值序列相同

5、唯一 + 每次遇到：a1 a2 a3

6、随机 + 每次遇到：a4 a7 a8

7、顺序 + 一次：a1 a1 a1

8、唯一 + 一次：a1 a1 a1

9、随机 + 一次：a3 a3 a3

        说明：Once 整个过程不改变   随机：任意取值

将param2另存为param3,增加Action内部循环 3次（name遇到3次）

外部循环：Number of Iteration: 2次

三、练习（笔试题）

某参数现有备用数据a1,a2,a3,...,a30; Action中实现3次for循环；脚本迭代2次（不打开控制台），完成以下结果：

1、顺序 + 每次迭代：a1 a1 a1, a2 a2 a2 

           每次迭代时换值，每次迭代使用3次

2、唯一 + 每次迭代：a1 a1 a1, a2 a2 a2

           单用户，顺序和唯一是一样的；迭代时换值    

3、随机 + 每次迭代：a5 a5 a5, a11 a11 a11

           随机的，每次迭代时换值

4、顺序 + 每次遇到：a1 a2 a3, a4 a5 a6

           只要遇到name就换值，从第一个开始     

5、唯一 + 每次遇到：a1 a2 a3, a4 a5 a6

           单用户，顺序和唯一的一样

     考虑超过值时，关注block块大小

     对于单用户，无需关注块大小，多用户(控制台)才考虑

  改为：外循环5次，内循环10

When out of values:

1) Abort Vuser: 放弃VU  报告出错

  Action.c(5): Error: Parameter 'name': No more unique values for this parameter in table 'name.dat'

2) 继续从头再来：不会出错，正常取值

3) 持续取最后一个：结果正常，日志Action.c(5): Error:

6、随机 + 每次遇到：a8 a9 a20, a25 a8 a2

           一共遇到2*3=6次  随机取

7、顺序 + 一次：a1 a1 a1, a1 a1 a1

8、唯一 + 一次：a1 a1 a1, a1 a1 a1

9、随机 + 一次：a10 a10 a10, a10 a10 a10

四、多用户中块（Block）的概念。

1、脚本参数池中 块 的概念只对多用户（控制台）有效。

2、测试过程中如果脚本参数池使用Unique唯一取值方式，要保证数据充足，否则控制台中直接报错。

比如：每个VU执行迭代时需要4个值

  A1 A2 A3 A4   A5 A6 A7 A8 ... An An+1

      VU1              VU2            VUn

  发现VUn+1 后续没有值了，在控制台会报错

规律: 可以自动分块（块大小就是每个VU需要的实际数据量）

            手动分块（由自己指定）

块大小不够用时：参考When out of value

   可指定块内数据的策略(放弃VU、从头继续、最后一个)

五、在控制台中查看日志：（多用户，产生多个日志文件）

1、如果从脚本中直接打开控制台，则控制台的日志默认记录在脚本文件夹下。（不常用，可能出现问题）

 在VuGen -> Tools菜单 -> Create Controller Scenario

 -> 弹出小窗口

 Result Directory: D:\work\script\day08\param3\res

 结果文件夹，存放日志

2、从系统直接打开控制台  （常用）

 加载param2脚本

 Controller中 -> Results菜单 -> Result Settings...  结果设置

 -> 弹出窗口：

  Result Name: res

  Directory:  C:\...  目录名很长，建议自己指定简短目录名

 在D:\下 新建目录 lrlog

 点击Borwser..按钮 选择日志输出目录：D:\lrlog

 另外，还有两个选项：

   Auto...create a results   每次出结果，生成新的文件

   Auto...overwrite existing results  新的会覆盖旧的

   （选择第2项）

3、如果查看日志，则Run-time Settings需要配置：

   Always Send Message  总是发消息

设置Quantity: 10 模拟10个VU

 Start Vuser: 同时开始   Simulaneously

 Duration: 运行直到结束  Run until completion

开始运行场景，观察D:\lrlog 文件的产生

 每个VU都会对应一个日志文件：

  param2_1.log ... param2_10.log 对应10个VU

 提示：出现日志文件的顺序，哪个VU先运行，先记录哪个

调试技巧：在VuGen中调试脚本(改策略)，需要编译后刷新到Controller中。

六、综合题 （BS题）

某参数现有备用数据a1,a2,a3,...a30; 脚本迭代4次；3个VU;完成以下结果：（必须掌握！）

1、顺序 + 每次迭代：<重要>

   VU1: a1 a2 a3 a4   现象:顺序 每个VU取值相同

   VU2: a1 a2 a3 a4     每个VU都从第一个开始顺序往下取

   VU3: a1 a2 a3 a4     共迭代4次，取4次值

2、唯一 + 每次迭代（无特殊说明，块大小自动分配）：<重要>

   VU1: a1 a2 a3 a4

   VU2: a5 a6 a7 a8

   VU3: a9 10 a11 a12

 唯一: 从第一行依次唯一向下取值，每个VU都不同

 每次迭代：每个VU迭代4次，取4次值 （默认块大小 4）

3、随机 + 每次迭代：<重要>

   VU1: a5 a9 a11 a13

   VU2: a22 a6 a8 a11

   VU3: a29 a30 a18 a20

 随机，每个VU迭代4次

4、顺序 + 每次遇到：

   VU1: a1 a2 a3 a4

   VU2: a1 a2 a3 a4

   VU3: a1 a2 a3 a4

 顺序：每个VU都从第一个开始顺序取值  Action中只出现1次

 每次遇到：每个VU遇到4次

 注意：在VuGen参数模拟器，会出问题，无法模拟

        因为 不确定数据量是否足够

5、唯一 + 每次遇到（块大小为6）：<重要>

   VU1: a1 a2 a3 a4

   VU2: a7 a8 a9 a10

   VU3: a13 a14 a15 a16

唯一：块大小6

    第一块（a1 a2 a3 a4 a5 a6）

    第二块（a7 a8 a9 a10 a11 a12）

    第三块（a13 a14 a15 a16 a17 a18）

每次遇到：遇到4次，取每块的前4个

6、随机 + 每次遇到：

   VU1: a3 a6 a12 a5

   VU2: a16 a4 a20 a17

   VU3: a13 a5 a7 a5

 每次遇到：由于参数只出现一次，此处等同于每次迭代

7、顺序 + 一次：<重要>

   VU1: a1 a1 a1 a1

   VU2: a1 a1 a1 a1

   VU3: a1 a1 a1 a1

 顺序：每个VU取值一样； 一次：只取第一个值

8、唯一 + 一次：<重要>

   VU1: a1 a1 a1 a1

   VU2: a2 a2 a2 a2

   VU3: a3 a3 a3 a3

 唯一：从第一个开始，每个VU唯一向下取值

 一次：每个VU取值后不变

9、随机 + 一次：<重要>

   VU1: a9 a9 a9 a9

   VU2: a13 a13 a13 a13

   VU3: a27 a27 a27 a27

 随机：每个VU任意取；  一次：每个VU取值后，不变

10、唯一 + 每次迭代（块大小为6）

   VU1: a1 a2 a3 a4

   VU2: a7 a8 a9 a10

   VU3: a13 a14 a15 a16

 唯一：每个VU，在自己的块内，唯一取值

 每次迭代：每个VU迭代4次

   VU1 第一块（a1 a2 a3 a4 a5 a6）

   VU2 第二块（a7 a8 a9 a10 a11 a12）

   VU3 第三块（a13 a14 a15 a16 a17 a18）

查看执行结果的方法2：在VuGen中

  打开param2  -> 参数池 Open Parameter List

  -> 参数模拟器 Simulate Parameter... 按钮

  -> 弹出窗口

    Vusers: Number of Vusers:  3

    Scenario run mode 运行模式：

       Run until completion:

         Number of iterations to run: 4 -> 点击Simulate模拟

以上参数类型：File类型 使用文件保存参数池数据 （常用）

七、其它参数类型：

1、日期/时间类型 Date/Time，适用于带有日期或时间情况，比如购票脚本中的时间信息。

备份param2为param4

  针对name 选择Parameter Type: Date/Time

   具备不同日期格式，可以编辑、修改，构造格式

   编辑 %Y%mYd  点击Add format  -> 确认添加

  Offset parameter  表示偏移几天 比如 2 days (了解)

     Working days only  仅工作日偏移

     Prior to current  往前偏移

  Update value:  更新策略

       每次遇到、每次迭代（选择）、一次

设置迭代次数：3

编译 运行脚本：时间值---20141016  当天日期值

思考：如果不想要当前日期值？还得用File类型

2、组名类型（较少使用），适用于每组VU中参数值一致的情况。

 Group Name: 用Vuser组的名称替换

打开param2: 右击name -> Parameter properties

   -> 直接打开窗口改属性

 改为：Group Name

    %s

    %01s

    %02s

    ...

    %08s     表示组名 最多占8个字符

   运行脚本 ->  0000None

  将脚本加入到控制台，配置日志细节再运行：00param4

  （Run-time Settings中： Log -> Always send message）

    指定日志输出路径

3、迭代编号（Iteration Number），适合于测试脚本参数取值无特殊要求，只需要每次迭代获取不同值的情况。

  将param4中：类型改为Iteration Number

    %d

    %01d

    %02d

    ...

    %05d   (最多5位，不够使用0补齐)

    ...

运行效果：00001  00002  00003 ...

4、Load Generator Name  负载生成器名称 （了解）

 联机测试时，LR使用该VU所在Load Generator的机器名代替

 改为次方式，%06s   0Local  机器的名称，区别不同负载机

lr_output_message("负载机：%s", lr_eval_string("{name}"));

根据日志文件进行分析

5、随机类型（常用），适用于脚本参数池要求不高，值在一定范围内随机取值。

改为：Ramdon Number  选择Min: 1  Max: 100   %06lu

   表示6位 1到100的随机数

比如：购物系统中，1~5随机数 购买商品数量

说明：Vuser ID  控制台控制的，每个VU都有唯一的ID号，区分不同VU.

 改为：Vuser ID   %06s  运行脚本：000001

   说明：VuGen只能模拟1个VU

 使用控制台：000001 000002 ...

   %06s  不够时使用0填充

   %6s    不够时使用空白填充

6、Unique Number 唯一编号

改为：Unique Number

  Start: 1 表示从几开始

  Block size per Vuser: 100  对于每个虚拟用户的块大小

    1~100 属于 VU1

    101~200 属于 VU2

     ...

  Update value: 更新方法

八、测试需求:准备测试大量的手机号数据，手机号越节省越好，手机号只能用一次。

比如：手机号138、139开头，测试要求1000用户在线，运行时间1个小时，已知：一个用户在线一个小时内循环437次。

将param4备份为param5:

  用户名: {uid}   手机号：{mobile}

测试计划：

 用户名{uid}  选择 Vuser ID 模式  %05s

 手机号{mobile}  选择 Unique Number

   Start: 1

   Block size per: 500  为了好计算

   Sample:

   Number: 138%08d  一共11位,前三位138;后八位,不够0补齐

   Update value: Each iteration    每次迭代取值

   When out of values: Abort Vuser 超过放弃VU

按照测试计划进行配置，编译->运行脚本

打开场景 -> 脚本param5 刷新到控制台

  设置VU: 1000个  （前提：LR必须获得认证） 

  设置日志的输出路径 D:\lrlog

  设置Run-time Settings:  Always send message

每个VU同时运行

运行直到结束

Run-time Settings:  循环 430次 （模拟小于437次）

   Pacing: 没有要求

   Log: Always send message

-> 运行场景

提示：如果运行出错，可能是VU数量限制，需要更换License

2、这样的测试可以重复多少次？

1）一次测试的所有的数据：

   500 * 1000 = 500000

   每块   VU数量

2）可用的总数据量

 13800000000

     00000000

 ~  99999999

一共：100000000 个

3）100000000 / 500000 = 200 次

Data Wizard... 按钮 数据可以来自数据库的表 （了解）

参考table.txt文档

Day09

关联技术：（高级部分--脚本技术）

引入：

 打开Web服务器，打开WebTours网站，进入administration链接:

 -> 选择第三项

  Set LOGIN form's action tag to an error page.

 -> 点击 Update按钮 提交

目的：LR为我们做实验提供的一种效果模拟

开始录制登录脚本：day09/3login

  使用基于HTML方式录制：Option -> ... HTML-base script

录制后，再回放：出错了，增加以下脚本

"Name=userSession", "Value=114500.524503848fiiQzcApQVzzzHDfDDHpHctDHf"

出现此属性：由于LR第3项模拟的，用户id   uid

  User Session ID  用户的会话ID

问题：产生了关联。（项目中：一般10个脚本有2~3个关联）

HTTP协议：简单的、无状态的协议

 简单的：协议文本内容格式简单

 无状态：一次请求，一次响应之后，服务器默认不会记录客户的状态。

 但是有需求：需要记录客户端的状态

 1）服务器端记忆：Session技术  会话  好比：顾客备案册

     占据服务器的内存，通过session id区分不同的顾客

     顾客A来了，根据顾客A的uid找到对应的Session空间和数据

     客户端每次发请求，都会携带该uid

 2）客户端记忆：客户端本地  浏览器目录中

       Cookie技术（名称--值 的文本）

       好比：会员卡  消费记录次卡 

    由服务器端改写Cookie数据，客户端每次携带Cookie数据

    缺点：数据安全，客户端可以更改Cookie数据

产生问题的原因：Client端   WebServer端

真实情况：

  Client 请求1  -------> WebServer

         响应1 <--------  提供一个Uid 123

       请求2 携带Uid 123 ----->

       响应2 <---------

LR模拟的情况：

  Client 请求1 --------> WebServer

        响应1  <-------- 提供Uid 123

        请求2 携带Uid123------> 服务器产生新的Uid 456

        响应2   <------   错误：Uid不匹配

产生问题的根源：客户端的固定数据，无法符合服务器端变化的数据。

一、关联

1、产生原因：某些系统的服务器在第一次和客户端打交道时会附带一个id（该id随着不同用户的变化而变化）；当客户端后续发请求时需要该id才可继续；而LR在录制时形成的id是一个静态id(如123)，这就导致客户端发请求时无法获取到服务器每次发送的动态id，导致脚本失败。（脚本调试方向：将静态的id换成动态id）

关联的概念：Correlation

   把脚本中某些写死的数据，转变为服务器所发送的、动态的、每次都不一样的数据。

何时做关联：录制时正常，但是回放不成功，考虑是否关联

一般的关联操作步骤：

1）从服务器返回的数据中选取需要关联的数据。（找数据）

2）将该数据存入脚本的一个参数中。

  变动的数据在脚本中是参数，由于是变化的，所以叫动态ID

3）将脚本中需要使用该数据的地方用该参数替代。

动态ID: 需要关联的数据

比如：每一次执行脚本都会变动的值，就需要关联

    执行一次就变动一次，或者录制一次也会变动一次

2、如果找到动态ID

1）原理：每执行(或者录制)一次，都会变动的值。

2）录制两个一模一样业务流程的脚本，进行比对，找出动态ID。

操作：再录制和3login一模一样的脚本 3login1

比对脚本的小技巧：选中3login 的 Action脚本

   Tools -> Compare with Script... 和脚本比较 3login1

   针对Action部分  选择要比较的脚本

 白底表示相同，黄底表示不同。黄色的大块，不用太关注，因为和数据包的先后有关。（WDiff工具）

找到："Name=userSession", "Value=xxx.xxxx" 就是动态ID

3）动态ID一般是一串无规律的字符串（少数情况下有规律）

4）动态ID一般不是坐标值、think time时间、检查点函数，也不是整段的请求。

关联类型：

1）手动关联（常用）

2）自动关联（经常导致脚本失败，LR回退，很少使用 了解）

手动关联的步骤：

1）录制脚本，回放有错误。确定由于动态数据造成的。

2）再录制一份相同流程的脚本。

3）使用WDiff工具进行比较。（找到动态ID）

4）使用web_reg_save_param()函数，在源文件中找到需要关联的字符串（动态数据），存入一个参数中。

5）把录制时的数据替换成该参数。-- 以不变应万变

LR中的注册性函数，要写在相应请求之前：寻找到相应请求

3、如何查找到相应请求 （为了在之前写关联函数）

1）拷贝动态ID适当长度（太长有可能会在Generation Log中换行），从Generation Log的第一行开始查找！

Generation Log：记录了客户端和服务器之间所有的对话日志。

需要找到第一次服务器发出的ID值。

如果找到的位置在服务器的应答包中，说明查找正确。

  在脚本中拷贝ID的一小段：114500.524  Ctrl + c

  点击Generation Log -> 从第一行开始查找  Ctrl + f

  -> Ctrl + v 查找该文本

  找到位置在应答包中  Response标题 With Id 16

2）查找到之后，选取适当长度的左右边界，拷贝下来，准备写函数

（左边界  动态ID  右边界）

name=userSession value=114500.524503848fiiQzcApHcQVzzzHDfDDHpHctDHf>

寻找相应请求：

3）先向下慢慢翻找，找到与当前应答id相同的id号对应的请求，该请求即为相应请求。（90%的情况都是在下方不远处）

4）如果找不到，则回到原位置，向上慢慢找到最近的一条请求。

5）Request 或 Event 都是请求。

 web_url(..."Snapshot=t1.inf" ..) 快照名是唯一的，作为线索

 寻找脚本中 t1.inf的请求位置。

 将拷贝好的信息粘贴到相应请求之前。

6）找到相应请求后，在请求之前写关联函数，并将后续脚本中用到动态ID的位置用函数中的参数替代。

//左边界.动态ID.右边界

web_reg_save_param("uid",  //参数名称

                  "LB=左边界文本",

                  "RB=右边界文本",

                  LAST

);

web_reg_save_param("uid",  //参数名称 LR变量名

          "LB=userSession value=", //左边界

          "RB=>",          //右边界

          LAST);

//目的：运行时根据左右边界查找到动态ID值，存入uid变量

//相应请求

web_url(..t1.inf..)

最后将脚本中的动态ID值，使用参数uid替代： {uid}

"Name=userSession", "Value={uid}"

编译 -> 运行 -> 脚本关联成功

4、所谓相应请求，就是产生动态ID应答的相应请求。

5、从业务逻辑去分析脚本，相应请求所存在位置，当前脚本是基于HTML方式录制，结构比较简单，所以当客户端第一次对服务器发请求时，服务器就分配了动态ID，以识别不同的客户。所以第一次发的请求就是相应请求。

（该情况比较特殊）

（基于URL方式录制，脚本比较复杂，要更仔细分析比对）

6、问题：相应请求是否有可能是包含动态ID的请求？

不可能。因为只有先发出相应请求，服务器才会将动态ID生成并发送，之后的请求才会用到该动态ID，所以，相应请求只能在包含动态ID请求之前。

练习：脚本中打印出uid

 lr_output_message("Uid is: %s", lr_eval_string("{uid}"));

运行脚本

二、注意：LR自带网站的第3项，是HP公司开发的模拟实际项目情况的例子，实际项目中没有所谓的第3项，实际项目是否包含关联只与开发方式有关。

三、去掉网站的第3项，录制buy脚本，城市参数化。

（照样可能出现关联）

思路：录制两个脚本，让城市不同，观察脚本的区别

  使用城市参数化，会变换城市，如果发现脚本不一致（动态ID）

  就需要关联

操作： 去掉第3项目  去除打钩 -> Update按钮

 先录制buya脚本  从Denver 到 London

 再录制buyb脚本  从Denver 到 San Francisco

使用WDiff工具，对buya和buyb进行比对：

 "Name=outboundFlight", "Value=020;338;10/18/2014"

 "Name=outboundFlight", "Value=060;202;10/18/2014"

  起始城市Denver -> London

     020 航班号， 338 费用

  发现了动态ID:   020;338;10/18/2014

  特点：该动态ID具备一定的业务逻辑

       这串信息，由服务器端根据实际的业务数据组织的。

操作：针对buya 对城市进行参数化

  针对起始城市Denver

  -> Replace with a Paremeter -> {fromcity}

   继续搜索其它Denver，全部替换  ctrl + f    F3继续搜索

  打开Parameter List: 设置参数池

   编辑 fromcity

         Denver

         Paris   改为从第2行  First Data: 2

  编译脚本并回放，如果出错：

    先找错误日志，双击错误日志，定位到脚本位置

  web_submit_form(...

           "Value=020;338;10/18/2014"   动态Id

  );

  选中拷贝 020;338;  点开Generation Log,从第一行开始找

  找到相应Response的位置： 记录id号 拷贝 文本信息

=outboundFlight value=020;338;10/18/2014 checked >

根据相应id 44 先后找到对应的请求 (Event/Request):

****** Add Event For Transaction With Id 44 ******

 根据请求的快照名：t4.inf 找到脚本中请求的位置：

 将字符串 粘贴到 相应请求之前：

 写关联函数

=outboundFlight value=020;338;10/18/2014 checked >

web_reg_save_param("fid",

          "LB==outboundFlight value=",

          "RB= checked >",

          LAST);

//相应请求

web_submit_data(。。。);

将动态Id值使用参数{fid}替换

编译 -> 回放  成功

以上是基于：单协议、HTML方式  来录制 （A1组合）

要求：分别以单协议、多协议，基于HTML、基于URL方式，

               A        B              1           2

录制buy脚本，城市参数化。

案例：单协议、基于URL方式录制（A2组合） url_buy1

   选择Options 中 URL-base script

回放之后，登录时就失败了！（init、Action脚本都有问题）

四、LR厂商推荐使用基于HTML方式录制，脚本比较简洁。

Html方式和URL录制方式的区别：

1、Html方式

1）录制时，每当打开一个页面，LR默认将页面的内容保存到自己的缓存中，比如用户名（值为空）、密码（值为空）、用户的会话ID（User Session Id）等。

2）当用户提交信息时（如点击登录），则LR会比对当前页面中内容和缓存中内存，如果有区别，则记录到脚本中，形成请求。

（区别在于：用户名、密码、鼠标点击位置、Session Id等）

2、URL方式：默认LR中缓存为空。将提交时的页面内容和缓存（为空）中的进行区别，形成脚本。

（结果：什么都记录下来，脚本内容比较复杂）

五、可能需要关联的位置：脚本登录、航班号、入库号（物流仓储系统）、订单号等。

操作：对url_buy1脚本进行调试，关联

 先处理vuser_init

 再进行城市参数化

案例：多协议 + 基于URL方式录制 （B2组合）url_mul_buy

 VuGen -> Edit Recording Options按钮 -> URL-base script

 New脚本 -> 选择多协议 New Mutiple Protocol Script按钮

  -> 选择Web[HTTP/HTML]协议

 -> 开始录制

调试方式：类似于A2组合

结论：基于URL方式和HTML方式区别比较明显

       单协议和多协议，目前几乎无区别

课后作业：

1、今天没完成的脚本，继续完成。

2、熟悉Qtp中自带tours网站，buy脚本，城市参数化

   使用几种组合完成。

http://localhost:8080/mtours

Day10

关联技术：（LR高级、脚本调试技术）

web_reg_save_param("uid", "LB=", "RB=", LAST);

{uid}

录制脚本的方式：

 单协议、多协议；基于HTML、URL方式 （https://）

   A        B           1        2

完成了：A1  A2  B2

一、关联函数的其它参数

1、案例：buy脚本，多协议、基于HTML方式录制，城市参数化。

注意：选择航班号时，不选默认的第一项。（选第3项）

day10\buy_option_select3

回放通过，开始参数化

   {fromcity} 和 {tocity}

"Value=022;320;10/19/2014"

outboundFlight value=022;320;10/19/2014>

fid is:420;108;10/19/2014 checked   当前fid

分析LR解析原理：

  左边界：outboundFlight value=

  右边界：>

到Generation Log搜索：

 outboundFlight value=020;338;10/19/2014 checked >

 符合要求,找到fid:  020;338;10/19/2014 checked

符合要求的有多项：先找到第1项就结束，是不对的

对关联函数添加一个参数：

  LAST之前加入： "ORD=all" 找到所有符合左右边界的内容

  再选择其中一项即可

还需要设置Run-time Settings （扩展日志-看到参数替代信息）

 -> General -> Log -> 单选Extended log

   -> Parameter substitution (日志中出现蓝色的参数替代值)

编译 -> 回放脚本：

Action.c(54): Notify: Parameter Substitution: parameter "fromcity" =  "Paris"

Action.c(54): Notify: Parameter Substitution: parameter "tocity" =  "London"

Action.c(54): Notify: Saving Parameter "fid_1 = 420;108;10/19/2014 checked ".

Action.c(54): Notify: Saving Parameter "fid_2 = 421;97;10/19/2014".

Action.c(54): Notify: Saving Parameter "fid_3 = 422;102;10/19/2014".

Action.c(54): Notify: Saving Parameter "fid_4 = 423;89;10/19/2014".

尝试打印fid  fid is:{fid}  发现：fid无效

Warning: The string 'fid' with parameter delimiters is not a parameter.

2、在关联函数加上"ORD=all"参数，则fid中的内容由字符串变为数组，数组中的元素分别为：fid_1, fid_2, fid_3, fid_4,...

web_reg_save_param("fid",

   "LB=outboundFlight value=",

   "RB=>",

   "ORD=all",  //默认是1，all表示所有内容进数组  fid_3

   LAST);

{fid} 需要改为 {fid_3}

fid is:422;102;10/19/2014

脚本执行成功。

***关注QTP自带的系统***

打开系统的服务器

网址：http://localhost:8080/mtours

http://localhost:8080/mtours/servlet/WelcomeServlet

  先注册用户  qq  密码 1

  点击REGISTER按钮 -> 输入

     User Name: qq

     Password: 1

     Cnfirm Password: 1   ->  SUBMIT按钮

  点击SIGN-ON按钮

     输入  qq  1  ->  SUBMIT

案例：录制单协议、基于HTML的订票脚本 qtp_buy_html

      城市参数化。（A1组合）

开始参数化：Acapulco -> {fromcity}

outFlight value="Blue Skies Airlines$190$706$5:03 pm$">

****** Response Body For Transaction With Id 240 ******

****** Add Event For Transaction With Id 240 ******

"Snapshot=t7.inf",

注意：双引号需要转义，为了避免歧义，影响双引号的配对。

inFlight value="Blue Skies Airlines$910$706$12:23 pm$">

需要转义：

inFlight value=\"Blue Skies Airlines$910$706$12:23 pm$\"

3、注意脚本录制的处理方式：

1）基于HTML方式，LR会将整个页面作为脚本中的一个请求来处理。

2）基于URL方式，LR会将一个页面中的所有元素都作为不同的请求（web_url函数）来处理。

案例：单协议、基于URL方式录制 （A2组合）  qtp_buy_url

回放成功，开始参数化：{fromcity}

问题：URL方式录制，LR的小bug，可能漏掉检查点函数

解决办法：脚本录制后，手动添加

       根据事务buy范围内，找对应的请求，请求前加检查点函数

       Tree视图

问题：本应该运行失败，但是成功了！

如何处理：根据业务经验，进一步分析确认

         城市改变了，业务产生的数据也会改变，还需要关联。

观察回放结果页面：

   Paris to Zurich是对的，航班号、价格都是旧数据

      $190$706

      $910$706

   需要追踪动态ID

获取参考文本，并转义

outFlight value=\"Blue Skies Airlines$190$706$5:03 pm$\">

inFlight value=\"Blue Skies Airlines$910$706$12:23 pm$\">

找相应请求，添加关联函数，替换动态ID   {oid} {iid}

回放成功后，结果页面：$490$140   $940$140 合理的数据

注意：录制脚本时，保证每个脚本都正确，否则项目中多个脚本同时参与产生麻烦。

二、注意：做关联时，左右边界选取合适的长度，如果太长(几行)造成脚本不易维护；如果太短（一个字母、单词）则边界出现相同的频率较高，容易找错。所以，一般选择3~5单词，其中尽量包括特殊的关键字（不常出现），如outbount flight=等。

补充：了解自动关联  结论：一般不用

 Correlation Result (关联结果)   Ctrl + F8

说明：LR版本的差异

 LoadRunner11 单协议和多协议 区别不大

               多协议是为了增强单协议的功能。

 LoadRunner8 是有区别的。

   单协议，VuGen下方是3个窗口，缺少Generation Log，其内容位于Recording Log中。

三、练习题

1、LR自带项目Web Tours，录制随机购票（基于HTML方式），要从参数池中取出起始城市和目的城市，要求城市不能重复。

（提示：脚本实现分支语句 if else）

思路：

1）从参数池中分别取出起始城市和目的城市 fromcity  tocity

2）判断两个城市（字符串）是否相等

3）如果不相等，则购票

4）如果相等，则报错退出（提示）

备用函数：strcmp （字符串比较）、strcpy （字符串拷贝）

版本1：

 先录制buy_rand1脚本

 参数化：{fromcity}   {tocity}

 建议将参数值存储在两个文件中，各自随机

  fromcity

  Denver

  Paris

  tocity

  London

  Paris    (提高重复率)

fromcity 和 tocity策略：

  Select next row: Random  随机

  Update value on: Each iteration 每次迭代

做关联：

outboundFlight value=020;338;10/19/2014 checked >

 并备份为buy_rand2脚本

对脚本进行重构：（改变代码、脚本、项目的结构）

Action(){

   打印出fromcity和tocity 以便观察

   //如果两个城市不相等，则购票 

   if(条件表达式){

     之前的所有脚本...

     //return 0;    //Action返回0 表示成功结束

   }else{

     打印错误消息：两个城市重复，不能购票！

     //return -1;  //-1 表示出错

   }

   return 0;

}

条件表达式：strcmp如果结果为0 表示相等

 strcmp(lr_eval_string("{fromcity}") , ... ) != 0

编译脚本，设置迭代 5次  Run-time Settings中设置

四、函数介绍：C函数

strcpy --- 将一个字符串拷贝到其它字符串中

比如：strcpy(a, b) 将变量b的内容拷贝到变量a中

五、C语言中常用变量的定义方式：

定义整型变量a:     int a;

定义字符串变量a:   char a[32];   (字符数组)

说明：声明字符串变量a，申请32个字节的空间，当程序运行结束后会自动回收该空间。

练习：新建脚本testStrcpy   Action中写代码

Day11

简答题：

1、请描述关联在LR中的应用？

（3W1H  What? Why? Where? How?）

（是什么？为什么使用？在哪儿用？如何使用？(步骤、注意事项)举例说明在项目中的应用）

（1）Why? 关联是LR录制脚本中一种技术  VuGen

能正常录制，但回放不成功，存在动态数据信息，考虑关联。

（2）What?  言简意赅

 把脚本中写死的(硬编码)数据，转变为服务器所发送的、动态的数据。（以不变应万变）

（3）How?  具体步骤

 手动关联 VS. 自动关联（几乎不用） 

1）找需要关联的数据---动态ID

   通过不对脚本的不同 WDiff工具 、 业务经验观察

2）选取动态ID的部分内容，到Generation Log中搜索第一个响应包，根据响应id，找到对应请求包（大多是之后不远处），拷贝日志中的文本（动态ID和左右边界，留取一定单词）

3）根据请求ID找到快照名--> 找到脚本中的请求（相应请求）

  文本粘贴到之前，备用

4）在相应请求之前写关联函数（注册性函数，相应请求之前）

 web_reg_save_param("uid", "LB=", "RB=", LAST);

 补充："ORD=all"  得到多个动态Id的数组  下标获取 uid_1 ...

5）在脚本中将固定数据采用{uid}替代。

（4）Where?

用户Session ID、城市参数化后业务数据改变（由服务器端程序改变）等，出现动态数据的业务。

（5）注意事项？（项目经验）

1）单协议、多协议；基于HTML和URL方式录制

  常用HTML方式录制，如果业务协议比较复杂(https://协议)，可能采用URL方式录制，注意：保存机制不明显，需要及时核对数据的变化，考虑是否关联。

2）...

2、面试中，打开LR界面，问界面中不同功能：

 三大组件、怎么协调工作，如何录制脚本、设置场景、看结果分析报告。如何参数化、并发测试、做关联...

一、性能测试分析

性能测试结束后，要对测试结果进行分析，分为以下情况：

1、测试结果完全符合需求，不需要分析。

2、测试结果存在问题（不符合需求，时间超长），直接通过测试报告（Analysis）查找到原因，直接写出报告。

前提：对应Analysis中结果描述非常清楚。

3、如果通过测试报告没得出结果（性能瓶颈），这种情况比较复杂。

4、比如发现某些事务响应时间超长（最普遍），该如何处理？

1）通过Analysis报告中几个比较重要的图表进行分析，初步定位问题，再通过网页细分图（网页诊断图）去确定响应时间哪里长？

大多数情况下，时间长在服务器端

（响应时间 =客户端时间 + 网络时间 + 服务器时间）

2）要进一步确定是哪台服务器（复杂的系统服务器n台，甚至几十台--集群(负载均衡)）

提示：通过监控服务器的系统资源图，能够很容易地定位出哪台服务器不正常。

3）如果是应用服务器（企业中常称为中间件产品），比如Tomcat、JBoss、BEA Weblogic、IBM WebSphere，发生问题，调整服务器配置参数即可。

共性：都是软件，都安装在服务器主机上提供企业级应用支持。

区别：免费/收费、功能

 Tomcat: Apache开源组织、开源、免费的。

 Weblogic: BEA公司产品，被Oracle收购

 WebSphere: IBM公司应用服务器产品

4）大部分情况都是数据库服务器出现问题，可以通过专门的数据监控工具来监控，甚至提取到发现问题的sql语句。可以针对sql语句进行分析、调优，进而提升被测系统的性能。

5、以上的调优流程不适用于所有AUT，绝大部分系统可以在之前的某些步骤停住，完成性能分析过程。

主要关注：页面细分图、服务器系统资源图

通过Analysis，打开day06\11用户综合场景-reg

二、页面细分图（Web Page Breakdown, 网页诊断图）初步概念

1、页面中的组件，也叫做页面中的元素。包括组成网页的内容：文字、图片、音频、视频、动画...

打开页面组件细分图 Page Component Breakdown  饼图

 对应左下角 Breakdown Tree (细分树)：

   包含场景中涉及的所有页面、及其元素

 Page component Breakdown(Over Time)

   页面组件细分图（随时间变化） 更细

2、页面组件细分图 和 页面组件细分图(随时间变化)的区别：

1）前者可以获取到页面中某个组件的平均响应时间。

 --- 从宏观方面

2）后者可以获取到网页中某个组件在整个测试过程中的响应时间的变化情况。

 --- 从微观方面

分析：以上两张图，相互呼应。比如，如果选择了浏览器Cache,开始时，页面下载较慢，利用了缓存后，下载就变快。

打开：Page Download Time Breakdown   页面下载时间细分图

响应时间：包括请求后，响应的各个阶段

  主要关注4个：

    DNS解析时间

    Connection    连接时间

    First Buffer  第一次缓冲时间

    Receive       接收时间

3、DNS（Domain Name System 域名解析系统）

 将服务器的域名 和 服务器的IP地址 对应起来的系统，可以将域名解析为IP地址。

                             DNS

  http://www.baidu.com   ---  192.168.xxx.xxx

    域名  好记忆                    IP 很具体

提示：局域网，只要IP地址，不存在该时间。

Connection时间：好比总机接到电话，指派一位客服为之服务

                     （总进程）             （多线程）

                   分配客服的时间。

4、First Buffer  第一次缓冲（第一个数据包）

比如：

  Client --->  Web Server  --->  DB Server

        <----                 <----

可以细分为：网络时间  +  服务器时间（数据库时间）

5、1个字节Byte = 8bits 位

内存的分配是以字节为基本单位；网络一般以bit为传输单位

一般一个英文字母占一个字节，一个汉字占用2个字节（和字符集有关：GBK 占2个字节，UTF-8 3个字节）

6、Receive时间可以衡量网络质量情况。如果该时间较长，则一般说明网络不好。如果确定测试环境为内网，网络不是问题，可能是客户端，也可能是服务器的问题。

三、网页细分图（网页诊断图）详解

1、网页下载时间细分图

1）DNS解析时间（好比：根据公司名称找到主机号码的时间）

2）Connection时间（好比：公司找一位客服解析接待的时间）

3）First Buffer时间（好比：获取第一个时间包的时间 重要）

4）Receive时间（好比：获取到所有数据包的接收时间，从第一个字节开始计时）

思考：First Buffer时间 和 Receive时间 有没有交集？

  如果First Buffer 8K  实际发送3K，则有交集

结论：不用太关注，注意点不同

其它时间：

5）SSL握手时间（只发生在基于https协议通信的网页上）

6）Client Time （由于客户端引起的延迟）

比如：客户端接收信息时间长、客户端处理响应包时间较长，或客户端显示处理过的响应包时间较长。

7）Error Time （系统页面报错时才有）

8）FTP Time （FTP验证时间：当系统中存在FTP服务器，下载操作时发生该时间）

FTP: File Transfer Protocol  文件传输协议

功能：文件的上传、下载

打开Page Download Time Breakdown  下载时间细分  宏观图

 Legend图例中：8种颜色，对应8种时间

 大部分：First Buffer Time

 每个柱状图：对应每个页面（主页面）

 可以打开Breakdown Tree 细分树，进一步观察页面细节。

打开Page Download Time Breakdown(Over Time) 随时间变化

  微观图

 Legend图例中：每个元素对应8个时间（8中颜色）

  总条数: 元素个数 * 8

 主要关注：哪个值高，越要注意

2、看结果分析图时，一定注意：不光看图的走势，还要看图中坐标的单位，需要二者结合分析。

规律：First Buffer占的比例较大（与网络 和 服务器有关），可以将其进一步细分为：网络时间 和 服务器时间。

网络时间：

 Client 第一次Http请求开始计时 -> Web Server -> DB Server

       <--直到返回服务器第一个字节为止 （收到确认）

服务器时间：

                        收到确认，并处理请求 --> 数据库访问

       <--直到返回第一次缓冲的时间

3、First Buffer时间：细分为网络时间、服务器时间，如果网络（带宽）情况不好，则网络的性能可能存在瓶颈；如果是内网测试，则基本无网络的问题。

打开：

Time to First Buffer Beakdown 第一次缓冲时间细分图  宏观

  Network Time  网络时间

  Server Time 服务器时间 （占绝大部分 内网）

Time to First Buffer Beakdown(Over Time) 随时间变化 微观

  细分图条数：元素个数 * 2

打开: Downloaded Component Size(KB)  已下载组件大小

4、页面中所有组件（元素）大小的和 = 该页面的大小

5、更加常看的：页面综合诊断图  Web Page Diagnostics

两种打开方式：

1）从Graph中 -> New 打开

 右击Graph -> Add New Item -> Add New Graph

       -> Web Page Diagnostics

2）从响应时间图中选中某条事务分析响应时间，右击直接打开

 找到Average Transaction Response Time -> 找某条折现

 -> 右击 -> show Diagnostics for "事务名称 login"

 分析具体事务对应的：页面诊断图  进一步分析

 （测试分析中常用的操作）

观察综合图的分布规律：

1）左边是细分树  Breakdown Tree

 比如login的URL地址，对应右边中间：

    Select Page to Beak Down 中的地址

2）最上边 Average Download Time  下载时间细分

3）右边中间的组件细分部分（最关心的部分）

具备Diagnostics Options:  四个单选钮

  Download Time

  Component(Over Time)   组件细分、随时间变化

  Download Time(Over Time)  下载时间、随时间变化

  Time to First Buffer(Over Time)  第一次缓冲，随时间变化

关注：Download Time 分为8种颜色对应8种时间

  Conponent显示路径名，右击条目：

1. a) 拷贝全路径到剪切板
2. b) 在浏览器显示 View page in browser  直观看到资源效果

 各种颜色中，蓝色的First Buffer比例最大，想进一步分析First Buffer，将单选钮切换为：Time to First Buffer(Over Time)

 细分为：Network Time 和 Server Time(大部分)

4）Legend中，选择某个地址（页面元素）

归纳：

 右侧：上中下都有关系

   上：显示下载时间图

   中：显示URL地址、具体细分图

   下：显示哪项资源打钩

6、页面诊断图（综合图）的分析方式：

一般从事务平均响应时间图中，定位某个事务时间较长，直接针对该事务打开页面诊断图。（有的放矢、有针对性）

1）一般情况下，先通过默认页面（Download Time） -> FirstBuffer，即发现当前页面中某个组件的第一次缓冲时间较长，再到第一次缓冲细分图 中确认网络时间 还是 服务器时间，多半是服务器时间较长，则瓶颈定位到服务器端。

2）选中页面的某一元素，则其后的Sheet页逐一切换，能够自动针对同一元素查看不同的细分图。（元素加亮显示）

7、分析：如果一个图片0.2MB，加入1000用户并发执行某事务，该页面中包括次图片，0.2M * 1000 = 200M，如果带宽为10MB，则光下载该元素（图片）需要 200 / 10 = 20秒。可能带来性能的影响，带来较大压力。（一般页面 3-5-8原则）

8、关于图片格式的原理

1）bmp (位图图片)：特点是每一个像素都是24bits, 800*600个像素的图片，就有几M. 一张位图图片不论是一张白纸，还是色彩斑斓的图片，大小一样。号称无损压缩。

2）jpg图片是有损压缩图片，存储图片大小，按照像素之间的色彩差值决定的。如果图片比较单一，数据量较小；如果图片色彩变化较大，数据较大。

网页推荐图片格式：jpg  png  gif等

补充：*.emf 矢量图  记录像素间比例，有公式算法

       工程图纸，放大缩小，不会失真。

四、模拟浏览器缓存设置

1、一般在进行测试时，都要清除缓存，一方面是为了达到严格的测试，另一方面是模拟实际情况（比如：网络应用）。

2、在做测试数据时，越省力越好，所以一般无需清除缓存。

打开VuGen -> Run-time Settings -> Browser

 -> Browser Emulation  浏览器模拟

 -> Simulate browser cache  模拟浏览器缓存 （一般不选）

后续一般都选择打钩：（严格测试）

  Download non-HTML resources (加大服务器压力)

  Simulate a new user on each iteration

    (模拟每次迭代时，当前新用户，达到严格测试)

    Clear cache on each iteration

      (每次迭代清缓存，真实模拟浏览器)

五、系统资源监控

1、CPU、内存、磁盘之间有千丝万缕的联系，论速度：CPU快于内存，内存快于磁盘。内存相当于一个系统（好比工厂）的加工车间，磁盘相当于工厂的仓库，工人处理相当于CPU执行指令。如果车间全部被废料填满，则系统运行缓慢。

关注13项：

  处理器 Processor:  %Processor Time  处理器时间

  内存Memory:  %Commited Byte in Use   利用率

                   Available MBytes    可用的空间

  系统 System: Processor Queue Length 系统队列长度

    队列Queue：先进先出  FIFO  First In First Out

2、Processor队列长度：处理器中暂时无法处理的进程（线程）就形成了队列，排队等待进程（线程）的个数称为队列长度。

六、CPU的各项指标

1、%Processor time: CPU忙的时间的百分比(CPU利用率)

 当前值的平均值超过80%或85%时（yu 阈值：正常范围），一般怀疑CPU有瓶颈。

---如果CPU的确有瓶颈（处理能力不足），可以添加CPU或置换性能较高的CPU。（硬件问题容易解决，软件问题较难解决）

2、Processor Queue Length

1）阈值：单CPU不应大于2，如果是n块CPU，该值不能大于n+1.

2）双核CPU，则n=2

说明：双核性能还是不如2块CPU，但也当做2块CPU处理。

3、注意：在服务器资源中，如果没有特殊说明，则都是值 平均值。（最大值和最小值一般做参考）

4、举例分析：如果一个性能测试点（比如login），依次完成单用户登录、50用户并发登录、100用户并发登录；则这个测试中%Processor Time的平均值应该呈现递增的趋势。

回顾：

1、页面综合诊断图 （构成、分析思路）

2、模拟浏览器设置 （对测试的影响）

3、系统资源监控  （关注不同指标，不同阈值）

 系统资源：CPU、内存、磁盘、网络等

 观察AUT的服务器相关性能

复习作业：

1、项目之前的准备：前10天内容为主

1）脚本技术 （检查点、事务、参数化、集合点、关联）

2）场景的设置

   基准测试、并发测试、综合场景测试

   都要进行系统资源监控（13项）

3）基本的结果分析

2、做笔试题、面试题

 

 

Day12

复习：

性能测试分析（LR高级部分，只需了解）

涉及面广：

 操作系统OS (Unix/Linux)、计算机组成原理、计算机系统结构

针对系统资源的监控，了解其中重要的指标。

针对Web项目，描述如何进行性能分析：

 事务响应时间 -> 网页细分图 （页面综合诊断图）

 针对系统资源监控的结果，结合阈值进行判断

一、内存重要指标

1、Memary: Available MBytes: 当前系统的可用内存（单位 M）

对于Windows系统而言，可用物理内存不要少于1% ---比如，2G的内存，如果可用物理内存20M或者或者更少，则要引起注意，怀疑内存处理能力不足。

2、观察可用物理内存曲线时，在测试过程中物理内存会在测试结束后慢慢释放回来，则内存表现正常。

3、系统的内存存在大量的软错误（在内存的其它位置找到该资源）的情况下正常工作，但是如果硬错误（需要在磁盘中找到该资源）较多，则会给系统的性能带来影响。

比如：1G内存，可能有1~2千个软错误，算正常。

4、Page Reads/sec （页面读取率）：主要监控硬错误，如果该值持续大于内存的1%，则怀疑内存不足。（内存空间不够大，很多新的资源放不下）

结论：Memory部分，Available MBytes、Page Reads/sec比较重要，Page Fault/Sec（软+硬错误）、Pages/sec（Pare Reads/sec子集）也可监控。

二、磁盘重要指标

1、Disk Reads(Writes)/s 磁盘的读/写的率，阈值一般不超过几十M。如果发现磁盘的读/写 超过了几十M或上百M,则会严重影响系统性能，怀疑磁盘瓶颈。

2、性能调优的重要原则：尽量减少磁盘I/O (Disk I/O 磁盘的读/写  Input/Output)

3、磁盘I/O决定不能避免（因为磁盘与内存的交互必不可少），但是可以尽量减少交互。

三、网络重要指标 (Bytes Total/sec 和 Packets/sec)

1、Bytes Total/sec: 将该值乘以8，与网络带宽的一半比较，如果小于带宽的一般，则一般没有问题。

2、1Byte = 8bits

说明：网络商一般都用bit，显得数字大。比如，100Mbps

四、性能分析---监控服务器资源

说明:客户端在测试时，不做重点监控；因为主要对被测系统服务器的监控。

1、为何只监控服务器：测试AUT的性能，只需重点监控AUT的服务器，客户端只需关注即可。

如何关注：使用安装LR的测试机（模拟客户端、负载）测试时，偶尔打开本机的任务管理器，点击"性能窗口"查看，保证正常运行即可。

2、如何监控服务器的内存泄露？

--首先正常测试（监控正常指标），当发现AUT的内存曲线不正常时，再去测试三项指标。

正常情况：物理内存在测试过程中不断被吃进，在测试结束后释放回来。

三项指标：规律-- 两升一降

  Process\private bytes 和 Process\working set 计算器 升高；

  Availble bytes 值降低。

3、如何判断应用程序的问题：CPU平均值高，吞吐率整体水平不高甚至有所下降，但是上下文切换很高，说明系统应用程序在设计或编码方面存在问题。

提示：正常系统中偶尔的(适当的)的上下文切换是有必要的。

性能分析角度和基本流程：

（具体问题具体分析、由易到难，逐步排除）

1）服务器硬件瓶颈

2）网络瓶颈（对局域网，可不考虑）

3）服务器操作系统瓶颈 （参数配置合理）

4）中间件瓶颈（应用服务器/Web服务器  参数配置 数据库管理）

5）应用瓶颈（SQL语句(Sql优化)、数据库设计、业务逻辑、算法）

五、性能分析：

1、系统响应时间、多用户使用人数都满足需求，但是系统中处理器队列（Processor队列）的平均值达到56（其它各项指标都在阈值范围内）。---如何处理？

从硬件开始分析：

 首先查看服务器的配置，发现：采用PC机做服务器 -> 硬件条件不达标 -> 需要更换服务器

2、如果搭建测试环境时，需求说明书中要求1台4G内存服务器，但是我们只有2台，一台2G内存，一台8G内存，问使用哪台搭建？

---使用低配的服务器来搭建环境，能够保证严格测试。

3、Bug一般指功能测试中，性能测试中称问题为瓶颈，或者性能瓶颈。

六、测试过程中报错分析

1、提前断开连接

1）应用服务器死掉down机（宕机），被测网站无法访问。

 --用户数少时，一般是程序的问题。

2）应用服务器没down机，被测网站可以正常访问。

 --一般怀疑服务器连接池的问题。（大用户量访问，连接池提供出现障碍）

   可以对AUT的服务器进行修改参数（配置文件），注意：修改服务器参数后控制台的结果，如果报错说明超出承受能力；修改建议是每次只修改一个参数（避免多个参数引起干扰），没次调整幅度25%-50%。

3）修改完服务器参数后，无需重新录制脚本，因为业务逻辑不变。

4）注意修改参数时，AUT压力的流向。（压力链）

客户端发起压力 -> Web服务器 -> 应用服务器-> 数据库服务器

                   （Http请求/应答） 业务计算      数据存储

                                   （发现性能瓶颈）

七、并发用户数失败规律问题：

1、并发25用户 --- 全部成功

2、并发50用户 --- 失败了9个用户

3、并发100用户 --- 失败了59个

4、并发150用户 --- 失败了109个...

写报告时：该系统值支持_25_个用户。（没有必要过多次测试）

因为：报告中记录系统支持用户数时，如果某次并发不成功，则使用上一次测试成功的结果。担心41可能不准确。

八、HTTP状态码

1）200 --- OK 服务器成功接收请求并提供应答

2）4xx --- 表示客户端错误   比如404：资源找不到

3）5xx --- 代表服务器端错误  比如500：服务器端有异常

w3school.chm 文档

Connections（连接数）

 TCP/IP连接数，能判断出何时需要添加其它连接

Connections Per Second （每秒连接数）

练习：

 Graphs -> Add New Item -> Add New Graph

 -> Web Resources  -> Connections图

 继续打开Connections Per Second图

    Connection Shutdowns: 关闭的连接

    New Connections: 新的连接

在Connections中合并 Average Transaction Response Time

对比分析：核心连接数图 和 平均事务响应时间，步调比较一致

性能测试进阶---性能测试系统分析及调优（补充2）.ppt

搭建被测系统不同组成和性能指标关系：

被测系统AUT：

1、硬件：

 主机（CPU、内存、磁盘、网络支持）<监控不同主机系统资源>

 （主机1：部署应用服务器  主机2：部署数据库服务器 ...）

2、软件：

 操作系统（Unix/Linux/Windows）

 应用服务器（Tomcat、Weblogic、WebSphere）<配置调优>

 数据库管理系统 （Oracle、DB2、Mysql、SqlServer）

     <数据库调优>

 安装Web应用程序 （部署到应用服务器）

     <应用程序调优：架构、算法、sql等>

     事务响应时间 -- 页面综合诊断图

集群：提供规则、算法将多台服务器协同在一起，负载均衡。

http://www.baidu.com -> DNS -> 百度服务器IP ->Server

明天开始完成LR项目：性能测试项目 

网站稿件管理系统

B/S架构  应用服务器：Tomcat  数据库：MySql

(被测系统搭建明天进行)

今天主要任务：看清软件需求、了解基本功能

三个文档：

 1）需求规格说明书

 2）用户手册

 3）结果判断依据

涉及技术知识：重点day01~day10  性能分析 day11~day12

重点：

1）脚本录制和调试

 检查点、事务、参数化（准备数据、策略）、并发点、关联

2）测试主要策略

 基准测试、并发测试、综合场景测试

3）场景的设置

4）结果分析

在项目过程中，多搜集项目经验（心得笔记、截图）

项目分组：5人/组  组长

项目天数：3天  每天项目审核

1）Day01: 分析需求、编写测试计划（设计）

2）Day02: 录制脚本、调试脚本

3）Day03: 设置场景、运行场景、写分析报告

网站稿件管理发布系统-stud.rar

Day13（Project  1）

性能测试项目：稿件管理发布系统

 （Manuscript Management System）

初步计划：3天

Day01: 分析需求、搭建测试环境、编写测试计划（设计）

Day02: 录制脚本、调试脚本 （脚本技术）

Day03: 设置场景、运行场景、写分析报告，项目综合评审

一、性能测试流程

第一阶段：测试设计阶段 （模板）

1）拿到客户需求之后，对被测系统进行详细分析，确定测试模块和范围。即功能模块、功能点。

比如：稿件管理、文件上传下载   登录、查询、增加

      （对信息的CURD操作 增删查改）

2）了解被测系统的技术组成，如系统为C/S、B/S架构

  开发技术、语言: Java、Java Web

  操作系统：Linux/Unix   数据库：Mysql5  Web服务器:Tomcat

3）确定测试方案，设计测试场景

4）评审测试方案（方案通过后，后续严格按照测试计划执行）

第二阶段：测试环境准备阶段

1）选择测试工具：LoadRunner11

2）搭建测试环境：要保证测试环境能够正常运行

3）对被测系统录入初始数据（业务数据）

第三阶段：测试执行阶段（LoadRunner工作流程）

1）录制脚本：对选定的需求针对性能测试的测试点进行脚本录制。

2）调试脚本：对脚本进行参数化、添加检查点、集合点、事务、关联...

3）设计场景，并运行场景（按照测试计划）

4）分析结果，并导出测试报告

第四阶段：测试分析阶段

1）分析测试数据，为了调优做准备

2）提交测试报告

补充：关注测试点的小技巧

1）比较重要的功能点

2）用户使用比较频繁的功能点

3）用户比较关心的功能点

4）与DB密切相关的（如：查询、增加...）

5）模拟未来用户产生的数据量

测试点：一共6个

0）登录操作

1）稿件管理：稿件查询、稿件增加、稿件显示

2）文件上传下载：文档上传、文档查询

名称术语参考：

  登录 login    稿件 MenuScript   文档 Document

  查询 search  增加 add    显示 view/show  上传 upload

  文件名多个单词采用_分隔  search_menuscript.dat

熟悉AUT需求规格说明书、系统说明书，安装并使用，熟悉AUT业务。

搭建测试环境：安装liferay.exe  放到D:\ 再安装

（提示：项目路径名，一般不要有空格、中文等）

注意：该服务器使用的是80端口，需要关闭占据80端口的进程

       使用Tomcat服务器、自带Mysql数据库

打开任务管理器：将Mysql、tomcat、Apache、oracle、IIS、xitame、java 服务关闭。

可打开CMD:  netstat  -ano   查看找到占用80端口的服务

启动服务器：运行startall.bat   批处理文件

一旦启动成功，AUT可以使用了

访问AUT: http://localhost/web/guest/home

有效的用户名：test01 ~ test50

 密码都是： 1111

上传文档的文件格式：*.txt   *.jpg   *.doc (不用*.docx)

主要的测试策略：

1、基准测试：单用户、单测试点 确保脚本正常运行

2、并发测试：50人在线，10人、20人并发  递增测试

3、综合场景测试：找到相关的测试点，设计综合场景

4、疲劳强度测试：基于综合场景、增加测试压力（VU 任务 时长）

Day01主要任务：

1、项目需求分析、环境部署 （OK）

2、主要任务：完成测试计划文档

   性能测试计划模板(完整)1.doc    分析和修改（今天提交评审）

3、附加任务：构建测试数据  *.dat  参数池数据（作业，明天提交评审）

注意：根据实际情况准备数据 （真实、合理）

  多个属性共享同一个*.dat文件，一般使用逗号分隔，所以每一列的值应该去掉英文逗号。（先用空格代替）

title,content

天气预报,今天天气挺好的 适合出去玩~~

系统自带数据存在不一致：

user.dat文件

username,password

test01,1111

test02,1111

...

 test05,1111   注意test05前需要加一个空格

...

test50,1111

要求明天各组提交Data目录，不同脚本对应参数池数据 *.dat

明天主要任务：录制并调试脚本

Day14(project 2)

性能测试项目Day02:

之前完成的任务：《网站稿件管理发布系统-性能测试计划》

今天主要任务：

1、准备好参数池数据  *.dat  主要以File方式、唯一、随机、日期

 每一列采用逗号分隔，每列的值使用空格替代逗号

 目标：测试过程中，保证事务成功

注意细节：

 用户名 test01~test50  密码1111  test05之前需要加1个空格

 模拟出50个用户在线 文档上传  十几个

 项目中经常采用分页技术，便于用户使用、降低服务器负担

  越靠后的记录，查询速度越慢

  查询记录不一定在第一页，由于新插入其它记录。

 查询编号需要取自真实的数据

 增加新数据时一般可任意选择，但文档的别名不能重复（策略？）

2、录制、调试脚本（6个测试点--6个脚本）

考虑：检查点、事务、并发点、参数化（结合参数池、策略）、关联

<1>登录      user_login

<2>查询稿件 search_menuscript

<3>显示稿件 show_menuscript   考虑参数池？是否关联

     难点1：录制时如何考虑数据

     由于模拟客户端漫无目的查询，浏览个别信息

     使用数据，比如稿件编号，是否需要结合服务器动态产生的数据，是否关联。（记录不断增加，影响原有页面的数据分布）

<4>增加稿件 add_menuscript

<5>查询文档 search_document 

     参数池：文件名不需要后缀

              文件名必须存在，提前上传已有文档供查询

<6>上传文档 upload_document

     难点2：参数值获取、检查点选取

         提前准备好文件存放在File目录下

           *.txt  *.doc  *.jpg  (不要太大)

    提示：重命名 采用Unique策略  Test%05d

       采用固定十几个文件，循环上传，重命名每次都不同

     难点3：选取恰当的测试用例 

             调整常规的业务流程，达到测试目的

源文件目录：

D:\LR_Project\File\测试计划.doc   (Windows系统盘符 \)

脚本中修改为：

D:\\LR_Project\\File\\测试计划.doc

(Linux/Unix中，分隔符/)

 通用的分隔符：//（适用于Windows和Linux/Unix系统）

D://LR_Project//File//测试计划.doc

项目过程中，多记录总结问题：

 项目中遇到___问题，是___解决的。 （项目经验）

比如：录制过程发现中文网站编码出问题？

        录制选择 选择UTF-8编码

       查看详细日志信息: Log 打开扩展日志相关选项

       关心某个变量取值：采用lr_output_message函数及时输出

说明：Data目录中的*.dat 数据供参考，以自己的数据为准。

type="checkbox" value="46701_version_1.0" onClick

HTML许多块级元素：能够将页面分块，独立指定样式，其它操作

<div id=""></div>

<p></p>

<table></table>

....

Day15（project 3）

性能测试项目Day03:

之前完成任务：

Day01: 根据需求规格说明书进行系统分析

         根据系统说明书，搭建AUT

    关键：完成性能测试计划

           准备参数池数据

Day02: 根据测试计划，录制、调试脚本（脚本工作量80%）

完成的6个脚本：登录、稿件查询、显示、增加，文档查询、上传

Day03: 根据测试计划，结合脚本设置场景（基准测试、并发测试、综合场景测试），运行场景，搜集分析数据，生成结果报告。

参与项目综合评审(项目经验交流、分享)。

注意：在场景运行过程中，可能出现脚本错误

 查看错误信息 Details、定位到脚本以及发生错误的行（错误列表提示出错脚本和行，可在控制台打开相关脚本）

80/20原则：80%的精力花在20%的重点上。

项目周期5个月：

       Mon1   Mon2   Mon3  Mon4   Mon5

       需求    设计     开发    开发   测试

工作量 20%    20%    20%   20%     20%

精力   80%     80%   80%    80%    80%

字符编码问题：（乱码问题）

原因：编解码方式不统一

 GBK编码          UTF-8解码

  A   65            65   A        AscII编码兼容

  a    97            97   a     字母不会乱码

  中  2233       2233  ? 囧

资源文件本身也要考虑字符编码问题：编辑时指定___编码

*.txt  *.sql  *.dat  ...

纯文本文件自身的编码

服务器：硬件配置较高

安装服务器操作系统：Linux/Unix

准备安装文件：

1、Linux安装文件 （iso 镜像文件  虚拟光盘）

 shrike-i386-disc1.iso   638M

 shrike-i386-disc2.iso   646M

 shrike-i386-disc3.iso   485M

2、小工具

 SSHSecureShellClient-3.2.9.zip

 secureCRT.rar

后续加强：脚本调试技术（测试计划 用例）

            场景设计技巧（测试计划）

            分析方法    

补充：JMeter  开源的基于Java开发，负载测试工具。

     Apache组织研发，主要用于内部对其它产品的测试，比如Tomcat服务器软件。共性：基于Java开发的。

多线程并发下，被共享的数据的安全？ --- 锁机制

多做笔试题、面试题（提高表达）

 争取自己独立描述（专业、术语）