posts - 97,  comments - 5,  trackbacks - 0

性能测试用户模型(三):基础数据分析、场景数据

 性能测试用户模型(一):概述、术语定义、基础数据、压力度量

  性能测试用户模型(二):用户模型图

  基础数据分析

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

系统访问量分布

  由系统的日访问量分布图,可知系统的访问压力集中在哪个时间段内。系统的压力是在一天中平均分布的,还是集中在某几个更小的时间段内。根据此信息,我们对测试场景的时间进行设计,如从分布图中明显看出每天的大部分访问量集中在900110014001600两个时段,那么就可以设计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 条件

如果失败,重试一次,依然失败就中止。

数据

每虚拟用户使用不同的账号

... 

 

 

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

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

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

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



天猫 软件自动化测试开发

posted on 2013-09-25 17:48 zouhui 阅读(154) 评论(0)  编辑  收藏 所属分类: 2.软件测试 性能自动化

只有注册用户登录后才能发表评论。


网站导航:
 
<2013年9月>
25262728293031
1234567
891011121314
15161718192021
22232425262728
293012345

常用链接

留言簿(2)

随笔分类(94)

随笔档案(94)

搜索

  •  

最新评论

阅读排行榜

评论排行榜