一、脚本录制技术细节
1、选择合适的协议：
1）B/S架构：常用Web[HTTP/HTML]协议，如果项目中使用了其它技术，比如Ajax、JDBC、FTP等，就需要选择多协议；
2）C/S架构：常用Windows Sockets协议（万能协议）
Socket: 套接字 好比两端进行网络通信的电话机，需要建立连接再通信。
趋势：企业级应用常用B/S； PC端Web测试
移动互联网 App一般C/S； 移动端App测试
2、测试脚本的基本组成：4个部分
1）vuser_init 初始化：仅执行1次 登录等准备工作
2）Action 核心脚本：默认1次，可n次 可进行并发
3）vuser_end 结束脚本：仅执行1次 退出等后续操作
4）globals.h 头文件：包含LR函数的声明
建议：LR脚本中的Action越少越好，易维护、可复用；
QTP中的Action较多，因为功能多。
LR可以录制多Action脚本，但不推荐使用。
3、脚本主窗体部分是代码：主要记录客户端的请求、控制函数（事务、集合点、检查点、流程控制）
LR录制脚本时使用了什么协议？举出该协议下使用的函数。 Web[HTTP/HTML]协议
1）常见请求函数：（对应每个步骤）
web_url: 向服务器发送一个URL请求，访问网页、图片、CSS等、JS等资源；
web_submit_form/web_submit_data: 提交表单数据，携带表单请求的参数数据；
web_link: 超级链接请求
2）其它控制函数：
lr_start_transaction("事务名"); 开始事务
lr_end_transaction("事务名", LR_AUTO); 结束事务
lr_think_time(秒数); 步骤等待时间
web_reg_find("Text=页面源代码文本", LAST);
reg字样，注册性函数，在相应请求之前
lr_rendezvous("集合点名"); Action中，事务开始之前
4、Http协议请求的分类：get和post ...
（Request Method 方法、方式 有多种）
1）get请求
<1> 地址栏写URL回车
<2> 点击超级链接 <a href="URL">文本或图片</a>
<3> 页面中获取图片、css、js脚本等资源
<4> 表单指定get方式提交 <form method="get"> 很少用
<5> Ajax发送异步请求，指定get方式
2）post请求
<1> 表单指定post方式提交 <form method="post"> 常用
<2> Ajax发送异步请求，指定post方式
p1.html?username=Tom&password=123
URL?参数名=参数值&参数名=参数值&... 名值对
查询字符串 Query String
可以通过请求URL携带参数和数据，提交给服务器
get和post请求有何区别？
1）get请求：
<1> 请求参数在URL地址栏后携带，信息不安全
<2> 提交的数据量有限，一般不超过2KB
2）post请求：
<1> 请求参数在请求包的主体中携带，信息相对安全
使用抓包工具Wireshark、Fiddler等能够捕捉到
建议：出于安全性考虑，密码在发送之前要加密
<2> 能够提交较大数据量，适合进行表单提交、文件上传
HTML核心控件：
表单：<form> 地址 action 请求方法 method
文本框 text 密码框 password
提交按钮 submit
表格：<table> 行 tr 列 td
超级链接：<a> 地址href
图片： <img> 地址src
5、常用日志窗口
1）Replay Log: 记录脚本回放（执行）日志 （常用）
调试脚本时，观察脚本运行的轨迹、主要流程，根据错误日志定位、分析错误原因。
技巧1：调试时可以启用扩展日志，查看参数的替代信息
Run-time Settings -> Log Extended Log
技巧2：性价比非常高的调试语句--打印语句
Java: System.out.println("xxx" + 变量名);
如果未打印，说明代码未执行，可能之前出错退出；
如果打印的结果和预期不同，说明有问题。
LR: lr_output_message("Hello");
Action.c (4): illegal statement termination 非法语句结束
Action.c (4): skipping `int' 跳过 int
Action.c (4): undeclared identifier `a' 未定义标识符a
结论：当前LR的类C环境要求
C变量的定义必须在代码的最前面！为了便于统一管理
2）Recording Log: （目前用的不多）
记录LR客户端和服务器二者对话的数据包大小；
（交互的信息量）
用途：和工具统计吞吐量等有关。
3）Correlation Results 自动关联结果（基本不用）
关联 后续一般采用手动关联
4）Generation Log: 生成日志 （常用）
记录LR客户端和服务器二者之间的全部对话（请求包、应答包），录制时产生的完整日志。
用途：脚本是按照这些日志生成的；
在脚本关联技术中需要分析该日志，查看到协议的底层。
以下哪些是前端技术？哪些是后端技术？
Web服务器端技术（后端）：Server端
Java、数据库 SQL、JDBC、JSP、Servlet...
Web前端技术（客户端）：Client端
HTML、CSS 层叠样式表、JavaScript （JS）
二、理解HTTP协议的底层，使用Tree视图方式添加检查点
1、HTTP协议
1）含义：超文本传输协议，互联网最重要的协议
http://www.tedu.cn 域名
2）特点：简单的、无状态的协议
简单的：协议的结构内容较为简单；
无状态：一次请求，一次响应后，服务器默认不会记录用户之前状态的。
3）请求和响应的格式：
<1> 共同点：都分为头header 和 主体body
<2> 请求的头中，会携带客户端浏览器的信息；
比如说明是post方式请求
请求的主体中，会携带客户端请求参数信息，比如：
username=Tom&password=123
<3> 响应的头中，会携带服务器端给客户端的通知，比如：
包括响应状态码 200 或 302 或 404 或 500 ...
是否写Cookie...
响应的主体中，是向客户端返回的页面元素：
包括网页源代码、图片、css、js脚本...
4）如何解析、查看协议的数据包？
<1> 使用第三方工具：WireShark、Fiddler等抓包工具
抓包：捕捉网络通信的数据包（请求包、应答包）
<2> LR中的Tree视图：树视图 查看数据包的结构
打开day05uy 另存为 day06uy
练习：寻找订票成功的请求和响应数据包的对应关系
HTML View 网页视图 -- 直观，便于观察，找对应关系
HTTP View 底层协议视图 -- 底层，便于分析
5）练习：针对登录成功添加文本检查点，建议使用函数web_reg_find 效率高 （web_find函数 效率低）
之前做法：录制时添加 点击Insert text check
局限性：可能录制时不知在何处添加、添加后没有加上、添加的位置出现偏差。
录制后追加（或检查添加是否正确）：
<1> 找到相应请求--其响应结果需要检查的请求
检查点函数带有reg字样，注册性函数放在相应请求之前
技巧：Tree视图，HTML View 确认请求和响应快照的关系
<2> 切换到Tree视图，使用HTML View
-> 选中需要检查的文本 -> 右击
-> Add a text check(web_reg_find)
-> 窗口：
文本：Welcome, <b>jojo</b>, to 页面源代码文本
区分大小写
查找范围：All 或 Body 协议的主体部分
-> OK 生成函数：
web_reg_find("Search=Body","Text=Welcome, <b>jojo</b>, to",LAST);
LR中的检查点函数
文本检查点：
web_reg_find 效率高（推荐） 检查页面源代码文本
reg字样，相应请求之前
web_find 效率低 检查页面文本 相应请求之后
图片检查点：
web_image_check 检查结果中是否有该图片
练习：针对订票成功添加文本检查点，使用Tree视图
步骤：
1）先找到相应请求
2）使用Tree视图添加
web_reg_find("Search=All","Text=leaves Denver for London.<br>",LAST);
三、实验：设置10VU，分别采用进程 或 线程两种方式模拟VU，观察对测试机性能的影响。
基本思路：
1）控制台中，设置Run-time Settings
杂项 -> 选择 进程 或 线程 方式
2）打开任务管理器：查看mmdrv进程 （产生VU）
查看mmdrv进程的数量、占据系统内存的大小
规律：一般线程在50个以内，都使用1个mmdrv进程
1）线程方式：只有1个mmdrv进程，占10M内存
对测试机资源占用少（轻量级）
2）进程方式：有10个mmdrv进程，平均每个占7M内存
对测试机资源占用多（重量级）
结论：使用线程方式模拟VU更有优势，省测试机资源。
对比：JMeter 默认使用线程方式模拟VU.
Java是一种天然的多线程技术，自然采用线程方式模拟多用户，JMeter是使用Java开发的工具。
java Hello
原理：通过java命令启动JVM Java虚拟机 进程，在JVM进程中会启动一个主线程 main，执行main方法中的代码，同时可以启动其它的线程（多线程-多任务）。
四、多机联合测试（联机测试/分布式测试）
1、一台测试机（PC）只能提供有限的负载（平均2000个VU），提供负载的强弱和PC机的配置有关。
大幅度提高负载的方法
1）提高硬件配置；
2）联机测试：使用若干台PC联合产生更大的负载。
2、需求：要求使用联机的方式，订2张票，使用自己PC1和同事的PC2，各自分配1个VU，由PC1作为主控制台，统一向被测系统PC1中订票（WebTours）。
操作：day05uy 打开 另存为 day06uy1
3、查阅本机IP地址，前提：打开本地连接
右击 网上邻居 -> 属性 -> 启用本地连接
打开cmd: ipconfig
PC1: 172.166.100.51 控制台IP、SUT的IP
PC2: 172.166.3.73 负载机IP
4、将脚本中所有的localhost或127.0.0.1都替换成PC1的IP
原理：希望向哪里订票，就写哪台机票的IP，目前就是PC1作为被测系统。
5、检查网络是否可达：
打开cmd: ping 对方IP地址
ping 172.166.3.73
原理：不断向对方发送一些数据包，查看是否正常反馈
如果显示连接具体时间，表示正常；
如果显示连接超时 time out，说明网络不可达。
6、要求负载机PC2至少需要安装Load Generator，并且需要启动Agent进程（小雷达）-- 默认就绪
7、打开控制台，设置两个脚本组，都使用buy1脚本：
前提：buy1脚本编译后 -> 回放成功 再加载 最新版本
两个组：
组名 脚本路径 VU数 Load Generators
buy1.2 day06uy1 1 localhost
buy1.2_1 day06uy1 1 改为负载机PC2的IP
8、使用控制台中Load Generators窗口进行检查：
控制台 -> Scenario菜单 -> Load Generators
逐个测试：点击Connect按钮 连接
结果为Ready 表示成功
为Failed 表示失败
9、准备运行：
建议清空jojo订票记录，便于观察。
默认脚本迭代1次，2个VU各自都向PC1系统中订1张票。
运行场景 -> PC1中订票2张，成功！
如何测试一个杯子？
电梯、钢笔、铅笔、电水壶...
思路：考察对测试策略的理解
默认对需求非常熟悉
请描述数据库中常用的约束？
提示：数据库有规范、标准，所有数据库的约束规范是一致的。目的：为了确保数据的一致性、完整性。
实体完整性：比如确保每一行是唯一的 PK 主键
参照完整性：比如确保值符合具体要求 FK 外键
emp表中的dept_id 必须参照自dept的id
员工的 部门id 部门 id
分类：对数据的制约（规范，符合业务要求，便于管理）
缺点：会影响性能
PK 主键 primary key 行的唯一
FK 外键 foreign key 值的参照
UK 唯一 unique 值的唯一
NN 非空 not null 必须要填
CK 检查 check 值有要求
check age between 1 and 150
check 提成 in(12, 15, 17.5, 20)
Defult 默认值