软件测试 - 商城性能测试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
还有很多非常强大的功能实战,由于教程篇幅,需要各位自行探索啦。
最后,本性能测试结束。