• 【Loadrunner】学习loadrunner——性能测试基础篇(一)


    1.性能测试和功能测试

    1.1.性能测试是什么?

    性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。——《百度百科》

    网上看到的地铁模型:

    假设:
    某地铁站进站只有3个刷卡机。
    人少的情况下,每位乘客很快就可以刷卡进站,假设进站需要1s。
    乘客耐心有限,如果等待超过30min,就暴躁、唠叨,甚至放弃。

    场景一:只有1名乘客进站时,这名乘客可以在1s的时间内完成进站,且只利用了一台刷卡机,剩余2台等待着。

    场景二:只有2名乘客进站时,2名乘客仍都可以在1s的时间内完成进站,且利用了2台刷卡机,剩余1台等待着。

    场景三:只有3名乘客进站时,3名乘客还能在1s的时间内完成进站,且利用了3台刷卡机,资源得到充分利用。

    场景四:A、B、C三名乘客进站,同时D、E、F乘客也要进站,因为A、B、C先到,所以D、E、F乘客需要排队。
    那么,A、B、C乘客进站时间为1s,而D、E、F乘客必须等待1s,所以他们3位在进站的时间是2s。

    场景五:假设这次进站一次来了9名乘客,有3名的“响应时间”为1s,有3名的“响应时间”为2s(等待1s+进站1s)。还有3名的“响应时间”为3s(等待2s+进站1s)。

    场景六:如果地铁正好在火车站,每名乘客都拿着大小不同的包,包太大导致卡在刷卡机堵塞,每名乘客的进站时间就会又不一样。刷卡机有加宽的和正常宽度的两种类型,那么拿大包的乘客可以通过加宽的刷卡机快速进站(增加带宽)。

    场景七:进站的乘客越来越多,3台刷卡机已经无法满足需求,为了减少人流的积压,需要再多开几个刷卡机,增加进站的人流与速度(提升TPS、增大连接数)。

    场景八:终于到了上班高峰时间了,乘客数量上升太快,现有的进站措施已经无法满足,越来越多的人开始抱怨、拥挤,情况越来越糟。单单增加刷卡机已经不行了,此时的乘客就相当于“请求”,乘客不是在地铁进站排队,就是在站台排队等车,已经造成严重的“堵塞”,那么增加发车频率(加快应用服务器、数据库的处理速度)、增加车厢数量(增加内存、增大吞吐量)、增加线路(增加服务的线程)、限流、分流等多种措施便应需而生。

    1.2.功能测试是什么?

    功能测试就是对产品的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能

    1.3.二者区别

    关注点不一样:

    功能测试关注的是是否可以使用;也就是行不行的问题
    性能测试关注的是是否系统的稳定安全及功能使用可靠流畅。 好不好的问题。


    2.如何判断性能好坏

    通过数据来进行展示,借助工具所监控和收集的各项指标来分析系统的性能。

    性能不好的表现:

    • 微博在短时间内访问量暴增,服务器承受不住。崩了

    性能好的表现:

    • 双11瞬间暴涨的交易,但是仍然正常运行。
    • 12306,每年春节抢票的时候,仍旧没有崩溃。“12306服务”承受着这个世界上任何秒杀系统都无法超越的QPS(Queries Per Second,每秒查询率)。

    3.性能指标与常见术语

    3.1.并发和并发用户数

    • 并发:是指一个时间段中有几个程序都处于已启动运行到运行完毕之间,且这几个程序都是在同一个处理机上运行。

    强调的是:大量用户同时性操作,对服务器造成的压力

    平时我们很多人都会刷微博,但是微博依旧能够正常运行,但是在同一时间,大量用户都刷微博,这时候就会对微博的服务器造成压力,甚至可能导致奔溃。就像我们在桥上同时起跳,造成共振,很可能把桥搞塌。

    • 系统用户数:某个系统的注册用户数。例如微博的注册人数xxx人。

    • 在线用户数:登录系统的用户

    • 并发用户数:一起对服务器造成压力或对服务有操作影响的用户的数量。


    3.2.响应时间/平均响应时间

    • 响应时间:从请求发出到看到响应结果的这段时间

    响应时间跟多个方面都有关系:用户的宽带、运营商、服务端、带宽、等

    • 平均响应时间:如果响应时间比较平均,那么平均响应时间就有参考意义,否则,无。

    • 请求响应时间:服务器收到用户请求并发响应内容发出去所耗费的时间

    3.3.事务(Transaction)

    事务:一般是指要做的或所做的事情。

    比如说我们要购买一件衣服,这就是一个事务,但是里面涉及多个操作:进入商品详情页,购买页,支付,购买成功…这一连串的操作都属于买衣服这一个事务。

    • 事务响应时间:处理请求对应的事务的时间。

    • 每秒事务通过数(TPS:Transaction Per Second):每秒系统能够处理的事务数。它是衡量系统处理能力的重要指标 ,每秒事务通过数越高,对应的性能越好。

    3.4.点击数

    点击数并不是说我们鼠标的点击次数,而是代表用户每秒向web服务器提交的http请求数。一次点击可能有多个http请求。

    3.5.吞吐量

    吞吐量:系统处理在某段时间内处理的客户请求的数量。

    • 吞吐率:单位时间内处理的客户请求数量。它直接体现软件系统的性能承载能力

    3.6.思考时间(Think Time)

    思考时间就是用户进行操作时,每个请求或者操作之间的间隔时间,是为了更加真实地模拟用户的操作场景。

    3.7.资源利用率

    资源利用率是指一定量的资源所能创造的价值的数量.

    这里的资源包括:CPU、内存、硬盘、网络等。

    举个例子:烧一壶开水, 用煤烧,本来烧这壶水10千卡的热量就够,而实际用的煤共能放出100千卡的热量。资源只利用了10%。


    4.性能测试分类

    4.1.一般性能测试

    验证软件在正常情况和系统条件下,验证系统是否满足性能指标

    4.2.负载测试(Load Testing)

    负载测试是在被测系统上不断增加压力,直到各项指标达到饱和,例如“响应时间”超过预定指标或者某种资源使用已经达到饱和状态。这种测试方法可以找到系统的处理极限,为系统调优提供数据。

    4.3.压力测试(StressTesting)

    压力测试是测试系统在一定饱和状态下,例如cpu、内存等在饱和使用状态下,系统能够处理的会话能力,以及系统能否会出现错误。

    压力测试与负载测试有些类似,经常把负载测试描述成压力测试的一种场景-例如增加用户数对系统进行压力测试。

    压力测试的目的是为了揭露高负载下的问题,例如资源竞争、同步问题、内存泄漏等。

    【注意】

    • 负载测试和压力测试两者可以结合进行。负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。

    • 压力测试是通过确定一个系统的瓶颈或者不能接受的性能点,来获得系统能提供的最大服务级别的测试。(往往会把系统搞崩)

    4.4.稳定性测试

    验证系统在连续运行的情况下,系统的各项指标是否存在异常

    比如说举重运动员,拿起杠铃之后,需要停留3秒放下才算成功。


    下面用一张图来看看区别:

    在这里插入图片描述

  • 相关阅读:
    冯诺依曼结构体系
    ros小问题之roslaunch tab补不全新增的功能包
    web APIs——第一天(上)
    06:串口通信一
    『现学现忘』Git基础 — 3、Git介绍
    2022年招投标,最加分的资质证书排行榜!
    Labview 实战 99乘法表
    ZynqMP PL固件通过U-BOOT从指定位置加载FPGA BIT
    Postman —— HTTP请求基础组成部分
    TypeScript学习01--安装和基本数据类型
  • 原文地址:https://blog.csdn.net/weixin_46913665/article/details/127853393