资讯

精准传达 • 有效沟通

从品牌网站建设到网络营销策划,从策略到执行的一站式服务

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小时等。
比如:银行系统,7
24*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://cdkjz.cn/article/iggech.html
多年建站经验

多一份参考,总有益处

联系快上网,免费获得专属《策划方案》及报价

咨询相关问题或预约面谈,可以通过以下方式与我们联系

大客户专线   成都:13518219792   座机:028-86922220