性能测试
性能测试:通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
负载测试和压力测试都属于性能测试,两者可以结合进行。
负载测试:确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。
压力测试:通过确定一个系统的瓶颈或者不能接受的性能点,来获得系统能提供的最大服务级别的测试。
工具:loadrunner(收费)、jmeter(免费)、locust(新兴,需python语言基础)
LoadRunner最好不要汉化,容易出问题。
安装
(已经有很多人出了详细的安装步骤,不再出了)
(不要汉化不要汉化不要汉化,容易出问题!)
参考链接:
安装包下载链接
安装步骤链接
LoadRunner简介
①LoadRunner,是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并
发负载及实时性能监测的方式来确认和查找问题与瓶颈。
②LoadRunner能够对整个企业架构进行测试。通过使用LoadRunner,企业能最大限度地缩
短测试时间,优化性能和加速应用系统的发布周期。
③LoadRunner是一种适用于各种体系架构的自动负载测试工具,它能预测系统行为并评估系
统性能,能支持广泛的协议和技术。
一般用LR11(系统版本不超过win7),可以通过一定的技术手段提升用户数(许可证)。
虚拟用户数过多可能导致测试机挂掉。
Load Generator:
联机负载
(如果一台机器无法虚拟足够的用户数,可以用另一台安装 Load Generator 负载生成器,
不用安装完整 Load Runner 程序,就可以做联机负载。)
Virtual User Generator :脚本录制器,编辑(像编剧一样)
Controller :控制器(像导演一样)管理监控整个过程,cpu、磁盘内存,吞吐率、响应时间
实时监控,动态的
Analysis :分析器。看数据有没有问题,分析报告。
LoadRunner工作原理:
LoadRunnerAgent Process 是LoadRunner的代理进程,
比如: 当一台机器需要分担一定负载的时候,这个Process需要启动,在安装LoadRunner后,
默认是打开的,可以关闭。
(导航栏中的小雷达图标,是代理进程)
Virtual User Generator:
Virtual User Generator虚拟用户脚本产生器(VuGen)
用于捕获最终用户业务流程和创建自动性能测试脚本(也称为虚拟用户脚本)
Controller:
Controller:压力调度和监控系统
用于组织、驱动、管理和监控负载测试。
Analysis:
Analysis:结果分析工具
查看、分析和比较性能结果
LoadRounner 测试流程:
制定性能测试方案
录制(开发)测试脚本 (这个步骤用 Virtual UserGenerator 实现)
设计测试场景
执行测试场景
监控测试场景
分析测试结果
系统性能调优
制定性能测试方案:
分析被测应用 (系统硬件环境、系统软件环境),包括测试机环境
确定测试目标
设计测试
开发测试脚本:
明确通讯协议:Client与Server端的通讯的基础是通讯协议,有很多支持的协议,成功录制一个
脚本的第一步要选择正确的协议。
有时候录制后,没有脚本,可能就是这个通讯协议没有选择正确。
录制测试脚本
运行测试脚本
调试测试脚本
保存测试脚本
打开lr11的飞机订票系统步骤:
开始按钮——HP LoadRunner——Samples——Start Web Server
(绿色:表明已经起来。红色:没有起来。黄色:繁忙。)
开始按钮——HP LoadRunner——Samples——HP Web Tours Application
登录名:jojo 密码:bean
录制脚本:
File——New...——选择协议(重要。一般网站都是选Web)——点击创建——Start Record
New Script——选择协议(重要。一般网站都是选Web)——点击创建——Start Record
设置生成用户数:
Tools——Create Controller Scenario...
Start Recording 界面含义:
Application type:应用类型
(Internet Applications B/S架构,Win32 Applications C/S架构)
Program to record:要录制的程序(最好选择fire fox24 ,或者是IE9)
URL Address:录制哪个网站(网址)
Working directory:整个代码保存到的位置
Record into Action:先选init 点击录制
录制选项含义:
vuser_init 录制的一般是业务流程开始之前的初始化工作(一般是登录流程)
Action 录制的一般是业务流程操作的事件(操作流程)
vuser_end 录制的一般是退出时候执行的操作(一般是退出登录流程)
设计测试场景
选择场景类型:手动场景(手动设置虚拟用户数量)、目标场景(测试人员想要达到的目标场景)
设置场景参数:组名称、脚本路径、虚拟用户数、负载发生器
常见问题:
1.录制完后没有脚本内容。
解决:(windows)控制面板——Internet选项——高级——勾选 启用第三方浏览器扩展
2.录制过程中出现 应用程序已被Java安全阻止。
解决:打开 Java控制面板——安全——安全级别 调整到 中——把测试网址加入到 编辑站点列表 中——确定
3.不能打开浏览器或是录制不到脚本。
1)用火狐浏览器可能出现 Couldn't load XPCOM.
解释:win7+火狐出现该报错,没办法解决。用win7+ie9或是Firefox24.0一般不会出现这个问题。
2)ie11+win10/win8/win7 录制无脚本
3)尝试:虚拟机安装:win7+ie9
事务与集合点
事务的概述:
在init、action,我们无法从这些一大段操作中找到性能的瓶颈所在,更希望获得脚本(操作)中
的某一段的具体性能数据
如:订票的支付过程
脚本中定义的某段操作,也可以理解成一段脚本语言
事务的作用:
LoadRunner运行到该事务的开始点时,LoadRunner就会开始计时,直到运行到该事务的结束点,计时结束。这个事务的运行时间在LoadRunner的运行结果中会有反映。
通俗的讲LoadRunner中的事务就是一个计时标识,LoadRunner在运行过程中-旦发现事务的开始标识,就开始计时,一旦发现事务的结束表示,则计时结束,这个过程中得到的时间即为一个事务时间。通常事务时间所反映的是一个操作过程的响应时间。
使用事务的原因:
1、事务是LoadRunner度量系统性能指标的唯一手段:(没有事务则没有办法衡量系统的响应时间,也许有人说LoadRunner可以通过编程来计时得到,不错如果你编程能力够强是能够实现的,但肯定不如LoadRunner中的事务用的简单而且方便)
2、通过事务计时实现了不同压力负载下的性能指标对比
3、通过事务计时可以帮助定位性能瓶颈
事务的添加:
从性能测试的角度出发,我们需要知遣不同的操作所花费的时间,这样我们就可以衡量不同的操作对被测系统所造成的影响,那么我们如何知道不同的操作所花费的时间,这就用到了事务。
我们在操作之前插入一个事务开始标识,在操作完成后插入一个事务结束表示,这样我们就知道了这个操作所花费的时间。
添加事务的方法:1、录制时插入;2、维护脚本时操作
注意:事务名称要见名知意
设置事务
开始事务:在需要插入事务的位置 右键 ——Insert——Start Transaction
lr_start_transaction("事务名字1");
(事务名字写中文,到后面Analysis分析里面看,名字可能会不显示)
结束事务:在结束事务的位置 右键 ——Insert——End Transaction
lr_end_transaction("事务名字1",LR_AUTO);
(要对应上开始的事务名,都是成对出现的)
可以边录制边插入事务:
结束事务:
集合点的概述:
执行负载测试时,需要模拟系统上有较重的用户负载。要实现此操作,可以执行负载测试时,同步 Vuser 以便恰好在同一时刻执行任务。通过创建集合点,可以配置多个Vuser 同时执行操作。
当某个 Vuser 到达该集合点时,将进行等待,直到参与该集合的全部 Vuser都到达。指定数量的 Vuser 均到达后,释放所有这些 Vuser。
同时加载用户并不是真正意义的并发Irrendezvous("选票"):
定义:在需要测试并发前,所有虚拟用户等待和集合的位置
添加集合点的方法:
1、录制时插入
2、维护脚本时操作
集合:等到齐了,再发出请求。
设置集合点:在需要插入的位置 选中菜单栏 Insert——Rendezvous...——填写名字后OK
或 在需要插入事务的位置 右键 ——Insert——Rendezvous...——填写名字后OK
lr_rendezvous("集合名字");
(集合名字写中文,到后面Analysis分析里面看,名字可能会不显示)
注意:只能向Action部分(而不是 init 或 end 部分)添加集合
(集合点要设置在事务之前)
插入集合点:为了衡量在加重负载的情况下的性能情况。
在计划中,可能会要求系统能够承受1000人同时提交数据,在LoadRunner中可以通过在提交数据操作前面加入集合点,这样当虚拟用户运行到提交数据的集合点时,LoadRunner就会检查同时有多少用户运行到集合点,如果不到1000人,LoadRunner就会命令已经到集合点的用户在此等待,当在集合点等待的用户达到1000人时,LoadRunner命令1000 人同时去提交数据,从而达到计划中的需求。
controller组件中实操(可以处置、控制、监控):
创建场景:
虚拟10个用户:
选中集合点选项:
即使代码中设置了集合点,也可以在此处关闭集合点:
释放策略设置
设置什么时候释放:
①当100%用户都到达后,释放集合点(不推荐。有些用户登陆时出错、失败,可能永远都无法到达。)
②当100%运行起来的用户都到达后,释放集合点(推荐。不会等已经登录失败的用户。)
③指定具体个数用户到达后,释放集合点(推荐。指定用户一定要比总用户数少。)
设置超时机制(如果后面的用户超过了30s,那就不管了,直接有多少个用户就跑多少个。)
设置好后点击OK,保存设置
运行效果(此图有6个已经到达集合点),当到达设置个数(10个用户)时,Rendez会立马释放变成0,Run会变成10
思考时间(think-time)的概述:
在录制脚时,我们一般会选择记录思考时间 record think time,LoadRunner做为性能测试工具,录制时记录的是客户端和服务端的交互,如果要精确模拟用户的行为,那么客户操作客户端时花费了很多时间要怎么模拟呢?
录入填写提交的内容,从列表中下拉搜索选择特定的值等,这时LoadRunner不会记录用户的客户端操作,而是记录了用户这段时间,成为思考时间(Think-time),因为用户的这些客户端操作不会影响服务端,只是让服务器端在这段时间内没有请求而已
所以加入思考时间就能模拟出熟练的或者生疏的用户操作,接近实际对于服务端的压力。
设置思考时间(假设是5s的思考时间):lr_think_time(5)
为什么设置了思考时间,会感觉没有设置一样?
因为设置了忽略思考时间。
设置思考时间机制:
①忽略思考时间:
忽略思考时间比没有忽略思考时间,对服务器造成的更大。
②设置成随机波动的思考时间
(假设思考时间为5s,那就是在2.5s-7.5s间波动)
事务与集合点联合
综上所诉:虚拟用户集合过程是在login事务开始计算响应时间之前,所有统计出来的时间更能反映login事务的真实平均事务响应时间;action事务时间基本不发生变化。
在性能测试项目中,遇到事务与集合点放置顺序问题时,需要将集合点插在开始事务之前。
版权归原作者 琳达kkk 所有, 如有侵权,请联系我们删除。