51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

测试开发精英班,通向高级软件测试工程师论坛测试积点免费获取渠道攻略20+企业级实战项目就在这里!横扫BAT,Python全栈测试开发技能大全
【113期】:Web安全测试你来问我来答!中国软件测试行业现状调查报告新鲜出炉! 【杂志】做测试行业不偏科的尖子生! 【活动】为视频UP主打CALL,互动领福利!
查看: 1091|回复: 1

【转自网络】性能测试用户模型

[复制链接]
  • TA的每日心情
    奋斗
    2020-6-22 16:56
  • 签到天数: 501 天

    连续签到: 1 天

    [LV.9]测试副司令

    发表于 2016-3-15 10:33:39 | 显示全部楼层 |阅读模式

    概述

    在性能测试过程中,很重要的一个部分就是评估待测系统在一定压力下的性能表现。比如系统上线后,真实的性能到底如何?两年后系统的使用用户增加后,性能又如何?这些都是性能测试中,项目相关人最关心的问题。

    所谓的性能表现,说的更直观一些,其实就是用户体验。用户不会在乎系统的处理能力是多少、吞吐量是多少,他们能够感受到的只是系统能否处理他们的请求、处理的速度有多快。

    这里提到的一个关键词是“一定压力”,这个压力指的是系统在预期的线上场景中所承受的压力。只有准确的定义和模拟预期的压力,才有可能获取到实际场景中真实有价值的用户感受,而不是那些只存在理论意义的数据指标。

    压力是由用户产生的,那么如何准确的定义和模拟用户的行为,也就成了问题的关键。

    以往的性能测试中,用户的具体行为是由性能测试人员敲定的。性能测试以外的人员,大概只能了解性能测试会模拟多少个用户,针对哪些模块或者功能做测试,更进一步的还会明确虚拟用户的工作量和所需的时间。这些内容一般也就是性能测试方案中所描述的测试场景。

    但这些信息仍然无法准确的对压力进行描述。比如同是100个虚拟用户,每个人需要在1小时内完成一定量的工作,如果这些用户在时间分布上是一个接一个的使用系统,那么对服务器来说,可能就和单个用户没有区别。再比如同是100个用户在线,每个人间隔30秒操作一次和间隔60秒操作一次,压力可能就会相差一倍。而这些直接影响到测试结果和有效性的细节,测试执行人以外的人员一般无法了解,有时恐怕性能测试人员自己都不明确,完全靠制作脚本过程中发挥,导致测试过程比较随意,测试结果的有效性也大打折扣。

    有可能对测试结果产生影响的因素主要包括:活跃用户数量、用户活跃时间、用户操作频率(思考时间)、用户操作路径、系统访问量随时间分布、各页面访问量(工作量)分布等等。对这些因素考虑的越准确,测试的结果才会越有效。

    本文正是试图对上述内容进行标准化的描述,制定一种规范的分析方法。通过此方法,让测试人员更准确的设计测试场景,让其他人员有机会了解到具体的测试过程,并且能对其进行监督和检查。最终达到“不同测试人员应该测出相同的测试结果”这一目的,也就是获得准确有效的性能测试结果。

    本方法无法取代数据分析,而是应该作为其的一个应用,可以直观有效的对用户行为以及系统的压力做出描述,测试人员、开发人员、管理者和业务人员等所有项目相关人都会从其中受益。

    术语定义

    虚拟用户(Vuser)

    性能测试中模拟的用户,用户的行为由测试脚本定义。

    在线用户(或活跃用户)

    一个时间段内,与服务器保持交互的用户,也称为活跃用户。需与论坛或者QQ上常见的“在线人数”定义区分,该类系统的在线用户不一定是活跃用户,在线只是一种状态。但在业务类系统中,一般只考虑活跃用户,可认为与在线用户通用。

    相对并发用户

    类似活跃用户,表示单位时间段内与服务器保持交互的用户,这些用户在理论上有同一时刻(即绝对并发)进行操作的可能(对这种可能性的度量称为并发度)。相对并发的说法主要是为了区分绝对并发,尽量避免使用“并发”这个容易引起歧义的术语。

    绝对并发用户

    同一时间点(严格的说是足够短的时间段内)与服务器进行交互的用户,一般通过测试工具提供的并发控制(如LR的集合点)实现。

    并发度

    在一个时间点上,可能与服务端进行交互的用户的数量,它表达的是“绝对并发”的一种可能性。

    思考时间

    用户每个操作后的暂停时间,或者叫操作之间的间隔时间,此时间内是不对服务器产生压力的。

    活跃时间

    用户与服务器进行交互的持续时间。

    基础数据

    此分析方法依赖于以下基础数据,基础数据的详尽程度将直接决定此模型的有效性和准确性:

    1、系统的访问量随时间分布关系。可以直观的观察到使用压力是如何分布在一天(一段时间)之间的,通过此数据来构建性能测试场景。
    用户的活跃时间(与系统进行交互的时间)。用户的活跃时间是进行系统并发度估算的基础。比如已知系统的使用压力集中在4个小时内(平均分布),此期间访问量为100,用户的平均活跃时间是30分钟,那么并发度估算为100/(4h/30min)≈12.5。

    2、用户操作路径。完成一个典型业务可以通过哪些途径?更有效提高测试覆盖率。

    3、系统的访问分布。哪些页面是用户经常访问的,用以选取性能测试将覆盖的功能点。也可以通过此数据来对用户的工作量进行估算,这是确定系统压力很重要的一项信息。

    4、页面停留时间(请求间隔时间)。属于测试的细节,可以使脚本更加真实的模拟用户操作。

    注:此类数据可能需要专门采集才能获取。性能数据的采集参见另一文档《性能数据采集分析系统.docx》。

    压力的度量

    1、TPS:每秒钟(关键)事务数。

    2、并发度:单位时间段(一般为用户活跃时间)内,理论上有可能发生绝对并发的用户数。

    3、活跃用户数:一段时间内与系统进行交互的用户数量。

    4、单位时间工作量:比如一小时或一分钟内完成的工作量。

    用户模型

    用户的行为主要分为两部分来考虑,一是针对一类特定角色的用户,二是针对整个用户群体。通过一组图形来描述用户的行为、操作路径以及系统各部分的使用率,此种方法称之为用户模型(或者系统使用模型)。

    用户模型表示的是系统的使用场景,更准确的说是一个特定时间段的系统使用情况。操作路径是用户模型的核心,通过用户模型,每个人都可以轻易的理解系统是如何被使用的。

    基本图形:


    数量或百分比

    用户类型

    动作类型

    同步点(集合点)

    选择或数据

    条件

    循环

    循环

    分支


    合并

    扩展图形:

    随机顺序访问

    应用示例:

    下面以一个在线书店为例,假设我们已经得知以下信息:

    1、有4种类型的用户:新用户、已注册用户、供应商、管理员。

    2、所有的用户都从主页开始。

    3、新用户和已注册用户可以做如下操作:

    1)通过标题、作者、关键字搜索图书

    2)添加到购物车

    4、新用户可以注册成为会员。

    5、会员可以登录、修改帐户信息、下订单、查看订单状态

    6、管理员和供应商必须从主页登录,然后进入管理页面。

    7、管理员可以添加新书、查看订单状态、更改订单状态、取消订单

    8、供应商可以查看库存和销售的统计报表。

    首先为每个类型的用户分别绘制模型图。根据已知数据来制定用户的操作路径、操作比例。

    新用户

    解释:假设有100个新用户,其中33个会进行多次搜索,有5个用户会因为没有找到相关书目而退出系统。其他的95个用户都可以找到所需书目并将其放入购物车中,这时会有20个用户没有创建账号直接退出,其他的75个用户都选择了创建账号。之后有45个用户成功提交了订单,另外30个只是保存了订单。最后有60个用户是通过直接关闭浏览器退出系统的,选择注销的只有15个。

    会员

    解释:100个会员,有一半是进行买书流程的,还有一半是进入账号进行信息维护和查看订单状态。

    管理员

    解释:管理员操作都需要从登录管理页面开始,操作最多的是查看订单状态(50%),其中有一半的订单需要修改,增加书目和取消订单都占25%。

    供应商

    解释:供应商也需要从管理员页面登录。供应商用户只能进行查看报表操作,可以选择多种不同类型的报表进行统计,平均每个用户需要查看3种报表。

    确定了各个用户角色的模型后,再根据各用户所占的比例,合并成整体用户群的使用模型。

    解释:从整体考虑,新用户占20%,会员70%,管理员4%,供应商6%。不同类型的用户通过不同颜色来标识,所有的用户都需要从主页开始访问系统。此模型反应了系统的整体使用情况,也即测试场景需要模拟的压力。而测试场景中具体要执行的测试脚本,则主要根据各类型用户各自的用户模型来开发。

    在绘制出模型图后仍然需要不断的同技术人员、业务人员沟通讨论,找出模型中不合理或者遗漏之处,并逐步完善,直到共同确认。甚至是测试结束后,也需要根据系统实际运行环境来不断调整,为后续的测试提供更准确的模型。

    但只依靠模型图仍然不能有效的对压力进行描述,可以发现前文提到的种种基础数据信息目前还未得到使用,如用户操作的间隔时间、页面上需要输入的数据等等。没有模型,这些数据是缺少实用意义的;没有数据,模型图也无法得到应用。

    基础数据分析

    以下图表均取自互联网,本文是在“已经获取所需数据”的前提下,讲解性能测试的一些设计思路。至于如何才能取得这些数据,将在后续的文章中说明。

    系统访问量分布

    由系统的日访问量分布图,可知系统的访问压力集中在哪个时间段内。系统的压力是在一天中平均分布的,还是集中在某几个更小的时间段内。根据此信息,我们对测试场景的时间进行设计,如从分布图中明显看出每天的大部分访问量集中在9:00~11:00和14:00~16:00两个时段,那么就可以设计2小时内完成一半访问量的测试场景。

    用户的平均活跃时间

    用户活跃时间,是指用户一次使用系统的时长,可用来指导测试脚本的设计,即每个虚拟用户脚本应该在多长时间内执行完。

    由系统访问量分布和用户活跃时间两个数据,可以对系统使用的并发度进行估算。比如已知系统在2个小时内有200访问量,且分布接近于平均,用户的平均活跃时间为30分钟,那么此时间段的并发度应为:200*30/120=50。这里并发度50传递的信息是,在一个用户活跃周期内,总共会有50个用户与服务端进行交互(即相对并发)。也就是说任意时间点,最大的绝对并发可能性是50,当然实际可能远低于此,可以根据业务特点再乘以相应比例进行估算。

    在性能测试时,可以依据此数据设计系统高峰期压力的测试场景。比如我们已知,系统压力最大时,单位时间段内活跃用户有100人(并发度100),那么这种压力场景,就可以以用户平均活跃时间为测试时间段,启动100个虚拟用户并在该时间段内完成各自的工作量。

    页面停留时间

    即请求之间的间隔(思考)时间,如在编辑页面上停留多久才会点提交按钮。如果无此数据,性能测试脚本只有运行时长是有数据(活跃时间)支撑的,脚本中的各请求之间的思考时间,只能通过常规判断和猜测,由性能测试人员自己掌控。收集到此数据后,性能测试脚本会更加符合真实用户的操作习惯,更加接近真实用户。

    热点模块(页面)

    分析系统各模块或页面的访问频率,可以用来检查性能测试是否设计了足够的覆盖、是否遗漏的用户频繁使用的功能,并据此对用户模型进行完善。

    此外,此数据可用来分析各模块或功能所涉及到的工作量,如每天平均完成多少次提交操作、多少次统计操作。这对于确定系统的使用压力有很大的作用。

    场景数据

    最后,综合所有数据,为特定测试场景制订出成如下表格:

    总体

    场景名称
    100用户负载场景

    场景描述
    模拟系统使用高峰期时,在2小时左右有100用户的访问

    场景时长
    2h

    场景加载策略
    每4.5分钟加载5个虚拟用户。因为要在2小时内完成100用户的访问,而每个用户的运行时间在30分钟左右,那么在1小时30分钟时就最后一批用户就要开始访问系统,即90分钟内加载100个用户。

    虚拟用户数
    100

    用户模型
    见XX用户模型

    虚拟用户运行时间
    30min

    平均思考时间
    30~60s

    场景并发度
    25。 虚拟用户数*(虚拟用户运行时间/场景时长)
    操作说明
    登录
    Think Time
    平均8s,最小5s,最大20s
    Pass/Fail 条件
    如果失败,重试一次,依然失败就中止。
    数据
    每虚拟用户使用不同的账号
    ...


    可以说,用户模型表达的是,系统运行中的压力是如何分布的。

    而场景数据表达的是,要给系统施加多大的压力。

    只有结合用户模型和场景数据两部分,才能构造出一个确定的负载场景。

    如果到这里都已经做好,并且经过了技术负责人和业务负责人的确认,那么接下来要做的就是按照设计来实现测试脚本了。


    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /3 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2020-7-12 21:10 , Processed in 0.074565 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2020 Comsenz Inc.

    快速回复 返回顶部 返回列表