软件测试 - 商城性能测试LoadRunner快速上手教学
软件介绍
Virtual User Generator，记录用户流程并创建一个自动化性能测试脚本Controller，单一控制点，轻松、有效地控制所有Vuser，执行期间监控场景性能Analysis，生成性能测试报告，以图表形式呈现。
由于教程篇幅较大，尽可能地照顾大部分学习情况，更多还是要大家多读官方文档，多去上手测试学习。
如果你还没有安装软件，或者是用的LoadRunner 12这样的老版本，我在阿里云盘分享了LoadRunner 2023的安装包。
教程源码：LoadRunner in quick · 乾坤道長/share-blog-code - 码云 - 开源中国 (gitee.com)
前置要求：
- 需要简单了解LoadRunner软件功能有哪些
- 了解HTTP网络工作方式
- 拥有C语言基础
- 软件测试术语
本次教学应该会花费20-30分钟，生成测试报告也要接近半个小时
选用被测系统
这里选用华测教育在线商城
关于接口文档，在他们培训机构的资料领取里面，同时我也放在了上面链接里面。
VuGen的推荐配置
录制设定
由于是模拟用户真实行为，所以录制应当是基于HTML
脚本只要有包含的URL请求就好了，Web用户的界面动作并不重要。
日志设定
也许你有参数化，但是如果次次手动打印到
output太麻烦了
当然，你还可以将服务器返回的数据打印，但是没必要，snapshot快照就能很清楚查看。
现在不管是关联的，还是预先设定好的参数，都可以很清晰看到值。
录制脚本
初始动作 - 登录
打开VuGen软件
默认创建
新建后，有3个行为(Action)，代表的启动脚本、运行时脚本、结束脚本。
那就开始录制吧
进入到了商城首页，我们需要先进行登录，以模拟场景下用户第一次的动作
| 账号 | 密码 |
|---|---|
| lisi | 123456 |
| huace_tester | huace_tester |
提示登录成功后，就可以将vuser_init切换至Action
事务 - 添加购物车
这里就点进小米4手机，作为要加入购物车的商品。
进入详细商品页面之后。
加入购物车之前，先点击开始事务(Start Transcation)，这里命名为add_car
然后成功加入购物车后，一定不要忘记结束事务了
结束动作 - 退出登录
接下来就是模拟用户的退出系统操作，切换成录制
vuser_end脚本
然后点击系统的左上角退出登录
可以结束录制脚本了
修改脚本
回放脚本 - 程序介绍
修改脚本之前，简单的聊一下录制后的脚本（程序）
可以看到Action都是标准的C语言程序。
不过，并不支持C99语法，要正常写的话，得是C89语法，也就是ANSI C。
C语言基础很好的同学，可以一眼就能理解脚本程序了。
可以说，函数名就是脚本
Action名称，vuser_init和vuser_end对应着启动和结束的钩子函数。执行一个脚本，就相当于调用了这个函数。
进入Actions的vuser_init程序来看一下调用了哪些函数
web_set_sockets_option，用于设置与网络通信和套接字操作相关的选项web_add_auto_header，自动向请求头加入信息，这个自动的意思是“后续的请求，都会有这个请求头信息”。web_url，实际上是发送HTTP请求，可以简单理解“模拟浏览器请求一个新的页面（HTML文件），并同时包含了其他静态文件的请求（css、js、png文件等等）”。web_revert_auto_header，对应结束自动向请求头加入信息web_add_header，下一个请求，会加入此请求头信息lr_think_time，思考时间函数，也就是程序睡眠时间，等同于Windows库中的sleep函数web_submit_data，模拟用户的表单提交操作，也就是HTML的form标签事件。
按F5，或者是点击下面的按钮，先进性回放脚本
回放脚本的意思，等同于执行脚本
在底部的output中，可以看到添加购物车的事务，正常执行并结束
然后看一下快照（Snapshot）
然后此时，鼠标点击函数的地方，就可以看见整个网络请求。
比如我这里演示的是，vuser_init.c脚本中的登录POST请求。
检查点 - 登录成功
这里需要用到函数创建工具，在LoadRunner里叫步骤工具箱（
Steps Toolbox）
然后要使用一个注册类型的函数，web_reg_find可以查找下一个动作函数中，是否符合对应的匹配值（文本）。
再次回放脚本，可以发现已经找到了这个值，如果不成功的话
关联参数化 - 登录账号
这里我们的任务是，随机抽取一个账号密码进行登录
首先必须要有一个外部参数的引入，也就是类似账号密码表格的文件。
文件路径可以自己起个名字保存。
’选择下一次‘ 一定要是 Ramdom（随机），才符合任务要求。（这里其实不只是下一次随机，第一次也会随机）
为什么不用
File类型？因为在LoadRunner中，File类型只能读取行中一列数据，而账户密码是与之相对应的行数据，如果需要随机账户密码登录，就必须让行完整。
这样，拿到的参数值，为 账号,密码 形式，接下来就是分割字符串，要用到string.h库的strtok。
#include <string.h>
vuser_init()
{
char * tableResultString = lr_eval_string("{account}");
// 分割符
const char * delim = ",";
// 账号
char * account = strtok(tableResultString,delim);
// 密码
char * pwd = strtok(NULL,delim);
// 注册关联参数
lr_save_string(account, "acc");
lr_save_string(pwd, "pwd");
// --- 输出变量的值
lr_log_message("account变量 %s",account);
lr_log_message("pwd变量 %s",pwd);
// --- 输出关联参数的值
lr_log_message("关联参数的账号为 %s",lr_eval_string("{acc}"));
lr_log_message("关联参数的密码为 %s",lr_eval_string("{pwd}"));
...
return 0;
}
lr_eval_string的意思是，将LoadRunner可以执行的参数，转换成C语言的字符串。
lr_save_string的意思是，将C语言的字符串值，保存到LoadRunner参数。
lr_log_message则是在LoadRunner的输出中打印信息。
可以看到，实现了随机抽取用户。
接着就是，在网络提交的时候，使用这个值。
找到唯一的POST请求，在请求体字符串中，参数值替换成{参数名}形式。
外部参数化 - 不同商品加入购物车
来看看录制的时候，网络请求和Web页面有哪些关系
这是小米4的，那其他的呢？
可以看到，2、3、4、5对应着苹果、三星、华为、魅族手机。
这个数字，就是商品id，现在我们的任务是：将商品id为1-10的，按每次迭代顺序添加到购物车
打开参数列表，开始创建一个外部参数吧，参数类型为File。
参数值手动录入进去，或者是用工具生成。
然后，将代码中所有的网络请求，引用商品id为1的字段，换成LoadRunner参数goods
有一个便携的办法，那就是通过
action脚本中，搜索全部id/1的地方。因为这里只引用了商品id。
这样我们就完成了本任务，但是会发现output，只引用了goods = 1，因为本脚本只运行一次，后面我们需要加入迭代次数。
集合点 - 加入购物车
本任务：为加入购物车业务设置一个集合点
在设计中，或者是右击脚本，可以找到 插入（Insert） - 集合点（Rendezvous），然后命名为add_car_r。
集合点不应该被包含在事务里面，否则集合点等待时间，会被算在事务时间。
这样就完成了，集合点的目的是，某个业务功能的压力测试，也就是一群用户做相同功能。
回放脚本
迭代次数
这一次任务，将把1-10商品ID都用到，那么需要加入迭代次数
进入 运行时设定（Runtime Settings） - 运行逻辑（Run Logic） - 迭代次数（Number of iterations）
这里设置为15吧，意味着run生命周期的Action（脚本）重复15次。
然后开始点击回放
看见goods已经取向不同的值了，和预期的结果相同
思考时间
任务：由于用户添加购物车时间，每次是不相同的，需要对添加购物车前等待3-9秒。
也许你眼睛比较细，刚刚就发现了 思考时间(Think Time)。
这里就用一个随机区间，意思是思考时间的百分比。然后还要在Action加入思考时间函数。
然后函数调用在事务开始之前、集合点开始之前
然后还需要在初始脚本（
vuser_init），删掉思考时间。因为默认运行时配置是忽略思考时间，当设置了思考时间之后，登录的思考时间其实是没什么用的。
现在脚本编写的过程结束啦。
场景运行
打开Controller
然后直接创建场景，添加刚刚编写好的脚本。用户数为数值就好了，百分比这里不讨论。
任务：在每个虚拟用户运行前将其初始化。启动2个用户（立即全部启动），执行10分钟，执行完成后再启动1个用户（立即开始）执行12分钟，执行完成后停止所有用户（每15秒停止2个）
Schedule by这里不用管，因为只有一个脚本。
真实场景模式和经典模式的区别，经典模式无法增加场景Action
先添加一个Action（场景），这里有两种方式。
最终的Global Schedule效果
然后这个场景怎么运行呢？
需要什么评估报告图，根据自己的需要就行了，这里就默认的就行了。
这里跑场景运行，要等20分钟多。
场景下用户可以增加多一些。但注意，可以减少脚本迭代次数、脚本思考时间、脚本HTML请求。
LoadRunner的web_url函数，模拟的是浏览器整个页面。这样让页面上凡是有依赖，都会去拉取，所有都拉取成功了，才进行下一步。如果测试应用开发为SSR框架，同时框架里含有ISR（客户端渲染）优化，那么性能测试并不能真正反映实际负载。
一个用户的多次业务操作、多个用户的少量业务操作、脚本运行时间、本地机器的资源利用情况、HTML页面请求是否有意义。都需要仔细去思考，来确定具体场景情况。
看到了所有Schedule都停止了，代表性能测试结束了，最后就是性能测试报告。
在Controller可以直接打开Analysis
像每秒点击次数、事务摘要等等，都可以很清晰看到
LoadRunner还有很多非常强大的功能实战，由于教程篇幅，需要各位自行探索啦。
最后，本性能测试结束。