LR11-性能测试基本概念-策略
性能测试 LoadRunner11
创新互联公司是一家网站设计公司,集创意、互联网应用、软件技术为一体的创意网站建设服务商,主营产品:成都响应式网站建设、品牌网站制作、网络营销推广。我们专注企业品牌在网站中的整体树立,网络互动的体验,以及在手机等移动端的优质呈现。成都网站制作、做网站、移动互联产品、网络运营、VI设计、云产品.运维为核心业务。为用户提供一站式解决方案,我们深知市场的竞争激烈,认真对待每位客户,为客户提供赏析悦目的作品,网站的价值服务。
一、性能测试基本概念(术语)
1、并发 Concurrency
在线 Online
并行:多个任务占据各自资源,一起运行
并发:多个任务占据同一资源,一起运行,需要争抢资源
1)、并发和在线的区别:
并发的压力是一个瞬时压力,一般针对同一类型的业务。
在线的压力是一段时间内的压力情况。
2)、20用户并发的压力相当于200用户在线的压力。(1:10的比例)
写测试计划时,可以参考,比如2000用户在线,一般是200个用户并发。
(并发登录、并发查询、并发删除等)
2、请求响应时间(TTLB,Time to last byte)=客户端时间+网络时间+服务器时间
单位,一般是秒/毫秒
可以通过内网测试规避掉网络的问题,客户端一般不会成为性能的瓶颈,
所以大部分情况下,如果请求响应时间长,性能瓶颈出现在服务器端。
建议:Web服务器和数据库服务器最好分开部署,可以分别监控
3、事务响应时间:前提是在录制脚本时,插入事务点
4、吞吐量(TP):Throuthput 是总量,是累计时间的全部数据量,
用户在任意给定1秒从服务器获得的全部数据量,单位,字节
吞吐率(TPS):在单位时间内的吞吐量
吞吐量/传输时间 每秒
TPS: Transaction Per Second 每秒事务数(事务数/秒)
点击率:每秒钟用户向Web服务器提交的Http请求数。
不是指鼠标点击的次数,比如:点击一个按钮,服务器返回一个页面,页面中包括了3个图片,
则当前发起的点击数:1+3 = 4个Http请求。
*.html 带有 每个图片都是一个资源.都会重新发请求
吞吐率和点击率区别:
吞吐率:服务器每秒处理的数据量
点击率:客户端每秒向服务器提交的HTTP请求数
5、请求和响应:
客户端向服务器发起请求(Request),
服务器向客户端返回应答(响应 Response)。
6、资源利用率:一般指系统中CPU、内存、磁盘、网络等主要资源的使用情况。(了解,有难度)
案例:测试登录模块在8个用户的情况下系统的性能情况
要求:用户数:8人 VU
用户加载方式:每2秒加载1个VU
运行时间:所有用户运行完脚本
登录用户名:jojo
密码:bean
操作:
1)录制好脚本 login day02/login
->点击New图标 -> New Virtual User -> 默认协议
-> Create 准备录制
-> 填写基本信息:
选择软件架构:Internet Applications (B/S) 默认
Win32 Applications (C/S)
选择浏览器类型:默认IE
URL Address: 被测系统的网址
http://127.0.0.1:1080/WebTours/
或http://localhost:1080/WebTours/
Working directory: LR工作路径 默认 常用工具命令
Record into Action: 录制脚本的位置 默认Action
(vuser_init 初始化 Action vuser_end 结束)
-> OK 自动打开浏览器 AUT,开始录制
关注小操作条 (录制控制 关注数字变化,数字稳定才继续)
-> 输入jojo bean
-> 开始事务 名称login (插入事务) -> OK
-> Login按钮
-> 结束事务 login -> OK
-> 改为vuser_end模式,点击Sign Off 退出
-> 关闭浏览器 -> 点击蓝色按钮 Stop 结束录制
-> 保存到新创建的day02/login文件夹中,脚本名:login
2)打开控制台Controller,使用login脚本,配置场景
打开Controller -> 默认手工场景模式 ->
将Use the Percentage Mode to... 去掉打钩
目的:用户数不使用百分比模式
-> Browse按钮 选择脚本 login -> OK
提示:如果脚本选错了,可以在后续主界面中修改
-> 设置8个VU: Run Mode: 选择Basic schedule
将Quantity 改为 8
-> 每2秒钟加载一个VU: 左下角窗口 Global Schedule
-> Start vusers: Start all Vusers simultaneously
默认是 同时加载8个虚拟用户,需要更改
-> 双击Start vusers -> Edit Action
-> 选择第2个单选钮,改为 1 Vusers every 00:00:02
(HH:MM:SS)
-> OK
-> Schedule Graphics 计划预览图
横坐标:Time 测试时间 纵坐标:Vusers 虚拟用户个数
每隔2秒钟加载一个虚拟用户
虚线表示 不确定
-> 设置运行时间: -> Duration中
Run until completion 运行直到结束 (脚本结束) 选择
Run for __ days and ___ (HH:MM:SS) 固定时间多久
Run indefinitely 不限定 无限制运行,测试者点击结束才结束
-》正常测试,还需要设置Windows Resources 监控的系统资源
(暂时不配置)
-> 切换到Run界面(运行场景)
(之前是Design 设定场景)
-> 设置好场景,可以运行场景
-> Start Scenario 按钮
点击Vusers按钮,进一步查看VU运行状态:
Done. Passed 1 iteration(s) attemped: 1successed.
结束 经过 1次迭代尝试1次成功了
观察场景运行结果图:
Running Vusers 正在运行的虚拟用户
Hit per Second 点击率
Throughput 吞吐量
点击正上方,右边倒数第3个图标按钮:
查看 Hp LoadRunner Analysis 结果分析报告
Reports 报告
Graphs 图片
Running Vusers 虚拟用户运行情况
Hit per Second 点击率
Throughput 吞吐量
Transaction Summary 事务概要
Average Transaction Response Time 平均事务响应时间
二、性能测试策略
重要的:
基准测试(单用户)、并发测试、综合场景测试 (前3个项目必备)
极限测试、递增测试
次要的:
疲劳强度测试(大型系统中)、内存泄露测试、
数据容量测试。
共同点:向被测系统发起***
1、基准测试:就是单用户测试 (重点)
注意:还是需要使用控制台,运行场景,自动搜集数据,通过Analysis进行结果分析。
2、并发测试:多用户并发执行某一操作(同一时刻,LR精确到毫秒级别)。
注意:并发测试是一种严格的测试,主要考察系统对瞬时较大压力的承受能力。
3、综合场景测试:号称“能够最真实的模拟 实际生产环境”。
综合场景的几个要素:
多用户、
多个脚本(至少3个,就是做多个不同的任务)、
在线执行一段时间(1个小时、50分钟等)
注意:一般不需要设置并发点。
多用户一起运行,一定会有并发。
综合场景测试过程中,所有用户 循环 执行相应的操作。
比如:100用户在线综合场景
100用户 共同对被测系统执行操作,
其中30用户执行浏览首页操作,
50用户执行查询订单操作,
20用户执行提交订单操作。
(要真实模拟人数比例)
问题:为什么不模拟大量的登录操作?
因为用户不可能一直在登录,模拟真实情况。
以上操作,用户在循环执行。
响应时间:业内一般有“358原则”,
系统响应时间在3秒以内,则用户能够接受;
响应时间在5秒以内,用户能够忍受;
响应时间超过8秒,用户不能忍受。
比如:一般需求指标,不超过3秒
4、递增测试:每隔一定的时间(1s,5s,10s)逐步加载虚拟用户,逐步加压。
用途:登录测试时,可以递增测试
极限测试:使用并发测试、在线测试等方法,测试出系统能够承受的极限压力(如最大用户数),
或系统能够达到的最大处理能力(如最大吞吐量)。
测试方法可以采用递增测试,比如对系统进行100用户、500用户、1000用户等测试。
(也称为:摸高测试)
5、疲劳强度测试:在一定的强度(压力)下,对系统进行长时间的性能测试,
一般为724小时、或24小时、12小时等。
比如:银行系统,724*365 全天候不间断运行
考察疲劳强度测试时,要考察其平均响应时间,以及各台服务器的各项资源情况。
比如:集群 负载均衡、降低成本
以上是比较常见的测试类型,经常出现在测试计划中。
6、内存泄露测试:
通过正常的性能测试,如果被测系统的内存曲线走势不正常,则关注其相应的各项重要的内存指标,
通过对应走势来确定是否发生内存泄露。
7、数据容量测试:使用大容量的数据添加到数据库中,观察被测系统是否能够正常运行。
比如:向数据库中添加200G的数据量,再进行测试。甚至几个T
大数据 Big Data 一般是T级、P级的数据量
1024Byte = 1KB
1024K = 1M
1024M = 1G
1024G = 1T
1024T = 1P
E Z Y
三、基准测试:单用户测试
1、测试脚本要加检查点。
原因:LR报告中的验证只是针对网络层面上,服务器收到客户端发送的数据包,之后将应答包发回给客户端,
但是LR不会验证应答包中数据是否正确。
案例1:对下订单操作进行基准测试。先录制脚本,插入检查点。
先打开AUT,熟悉整个业务流程;
打开VuGen -> 新建 输入URL -> 先录制登录
-> vuser_init -> 输入jojo和bean -> 开始事务 login
-> 点击Login -> 欢迎页面:
添加检查点:
选中“Welcome, jojo” 点击Insert text check 插入文本检查点
-> 结束事务login
-> Action模式 -> 点击Flights
-> 选择城市:从Denver 到 London
-> Continue -> Continue
-> 开始事务buy -> Continue -> 订单结果页面
添加检查点:
选中“Denver for London” 插入文本检查点
-> 结束事务buy
-> vuser_end模式 -> Sign Off -> 关闭浏览器 -> Stop
脚本保存:day02\buy 再回放
web_reg_find("Text=Welcome, jojo,",LAST);
web_reg_find("Text=Denver for London",LAST);
检查点函数:web_reg_find() web_或lr_开头
reg字样的函数:注册性函数
web_submit_form() 提交表单的请求
对于B/S系统,LR脚本中的LR函数都是以lr_或web_开头。
(另外,还有C语言函数 strcmp)
web_reg_find函数,带有reg字样的函数称为:注册性函数
该类函数的特殊:必须写在相应请求之前。
加过检查点的脚本如果运行(回放)正确,则说明该脚本正确。
(学会调试脚本)
需求:循环订3张票
VuGen中的Run-time Settings按钮 (运行时设置)
Run Logic 运行逻辑 -> Iteration Count 迭代次数 默认1 改为3
注意:循环的只是Action. 次数登录仅一次
init和end脚本仅执行一次。
注意:
1、控制台中和VuGen中设置Run-time Settings当前区别和联系:
1)如果从控制台直接打开脚本,则脚本中Run-time Settings设置会自动显示在控制台的Run-time Settings中。(带过来)
2)如果控制台和脚本中同时设置了Run-time Settings,并且值不同,控制台的优先级高。
2、Pacing值:每次迭代之间的时间间隔。
迭代:脚本Action从第一行到最后一行。迭代一次
Pacing值越大,对AUT的压力越小。
3、Think time: 脚本中步骤之间的时间间隔。
(请求之间的间隔)
案例:针对buy脚本,进行基准测试 (方法1:单用户循环5次)
打开VUG录制脚本
1)调试好脚本(在VuGen中运行成功)
保存脚本文件:scrip/day02/buy1
打开Controller,设置场景
2)打开控制台,加载buy脚本
首先设置人数: Run Mode 单选Basic schedule模式
Quantity改为1 单用户模式
3)打开控制台Run-time Settings设置
Run Logic 迭代次数 5 (优先使用)
Pacing值 -- Start new Iteration 建议设置随机2~3秒
As soon as the previous interation ends 只要前一次迭代结束
关注第3项:
At fixed intervals, every 60.000 sec
random every 2.000 to 3.000 sec
fixed: 固定的
intervals 间隔
random: 随机的
Think time:
Ignore think time 忽略思考时间 选择 为了简单化
Replay think time 具体设置思考时间策略
-> 点击OK
6) Global Schedule设置
Initialize:初始化 Vuser在Run之前先初始化(保持默认)
Start Vusers: Start all Vusers simulaneously
就一个VU 默认
Duration: Run until completion 运行直到结束 默认
-> 切换到Run
开始运行场景: Start Scenario
6)结果分析
分析结果图:Running Vusers
横轴:Elapsed Time 测试时间
纵轴:# of Vusers 虚拟用户数量
点击启动后,场景初始化需要时间,无需关注
分析结果图:Hits per Second 点击率(每秒点击量)
横轴:Elapsed Time 测试时间
纵轴:# Hits per Second 点击率
数据偏低,因为是单用户
分析结果图:Throughput 吞吐量(服务器处理过的数据)
横轴:Elapsed Time 测试时间
纵轴:# Bytes/sec
由于时间不长,规律无法体现
保存场景文件:ctl/day02/buy1
打开Anlysis:倒数第3个图形按钮
最关心的是:事务响应时间
Transcation Name Average 平均事务响应时间
buy 0.23 合理的
login 0.406 合理的
细节可以关注左上角列表:各种常用指标图表
(先了解,后续会专门讲解)
保存结果文件:result/day02/buy1
2.归纳 基准测试:
方法1:单用户循环5次
1)调试好脚本(加检查点,在VuGen中运行成功)
2)打开控制台,设置Run-time Settings
3)迭代次数:5
4)Pacing值:随机2~3 (每次迭代之间的时间间隔)
5)Think time: 忽略 (请求之间的时间间隔)
忽略的原因:单用户对系统压力较小,忽略与否对结果影响不大。
方法2:单用户持续运行1分钟
1)调试好脚本(加检查点,在VuGen中运行成功)
2)打开控制台,设置Run-time Settings
3)Pacing值:随机2~3
4)Think time: 忽略
5)Duration: 1分钟
提示:配置好后,观察图表状态,有所变动,才修改成功。
3、注意点:
当Run-time Settings中迭代和VU部署设置(Duration)有冲突时,Duration的优先级较高。
比如:Duration选择第二项,就以此为准
Run for __ days and __ (HH:MM:SS)
如果选择第一项:Run until completion 还是听Duration
只是它放权了。Duration是一把手,让二把手看着办,此时Run-time Settings说的算。
Duration:指Run的Action时间
测试报告中的结果,应该测试三次,取中间值。
(如:0.1秒 0.3秒 0.4秒 结果取0.3秒)
以上就是基准测试。
简答题:
2、基准测试、并发测试的概念和做法?
1)基准测试就是单用户测试,需要打开控制台,获取Analysis中的结果。
(方法1:单用户循环n次;方法2:单用户执行n时间)
2)并发测试是多用户执行某一操作,形成瞬时压力(精确到毫秒),是一种严格的测试,
主要考察系统对瞬时较大压力的承受能力。
3、并发测试和在线测试的区别?
1)并发和在线的区别:
并发的压力是一种瞬时压力,
在线的压力是一段时间的压力。
2)20用户并发的压力相当于200用户在线的压力。(1:10比例)
在写测试计划时作为参考依据。2000用户在线,设计为200用户并发。
(并发操作:查询、登录、删除、添加)
4、吞吐量和点击率的概念、区别?
1)吞吐量(Throughput):用户从服务器端获得全部数据量,单位是字节(Byte)。
2)吞吐量/传输时间,就是吞吐率,是服务器每秒处理的数据量。
3)点击率(Hits per Second):客户端每秒向服务器提交Http请求数。
(鼠标的一次点击,请求数可能为n个)
说明:吞吐量是总量,是累计时间内全部数据量。
吞吐率反映服务器的处理速度和性能,也是衡量网络性能的重要指标。
点击率越大,对服务器的压力也越大。
Files/Doc.zip
脚本中如何加注释
1)单行注释 //
2)多行注释 / /
一、昨天作业题:
1、思考:QTP和LoadRunner的区别。
1)QTP: 功能测试工具 (自动化)
LR: 性能测试工具 可以测多用户
2)QTP关心的是界面(UI),关心的是对象(对象库的概念);
LR只关心客户端和服务器之间的数据包(请求包、应答包),
不关心对象,更不需要比对对象的属性值,只关心抓包(捕捉数据包)。
如果用户界面变了,但是业务逻辑不变:QTP脚本需要变化,LR脚本不需改变。
3)LR关心的是客户端和服务器之间的对话,前提是选择正确的网络协议(相当于网络的语言)
4)LR不能补录。录制失败,从头再来。
注意:录制过程中出现失误,该次录制作废,从New开始重新录制;
录制时要慢,等待页面资源下载完毕后再进行下一步操作。
文章题目:LR11-性能测试基本概念-策略
路径分享:http://myzitong.com/article/iggech.html