百度网站托管,网站做超链接薪资多少一个月,阿里云云栖wordpress,网站qq访客记录原理作者#xff1a;薛定谔的破猫基础数据分析以下图表均取自互联网#xff0c;本文是在“已经获取所需数据”的前提下#xff0c;讲解性能测试的一些设计思路。至于如何才能取得这些数据#xff0c;将在后续的文章中说明。系统访问量分布由系统的日访问量分布图#xff0c;可…作者薛定谔的破猫基础数据分析以下图表均取自互联网本文是在“已经获取所需数据”的前提下讲解性能测试的一些设计思路。至于如何才能取得这些数据将在后续的文章中说明。系统访问量分布由系统的日访问量分布图可知系统的访问压力集中在哪个时间段内。系统的压力是在一天中平均分布的还是集中在某几个更小的时间段内。根据此信息我们对测试场景的时间进行设计如从分布图中明显看出每天的大部分访问量集中在9001100和14001600两个时段那么就可以设计2小时内完成一半访问量的测试场景。用户的平均活跃时间用户活跃时间是指用户一次使用系统的时长可用来指导测试脚本的设计即每个虚拟用户脚本应该在多长时间内执行完。由系统访问量分布和用户活跃时间两个数据可以对系统使用的并发度进行估算。比如已知系统在2个小时内有200访问量且分布接近于平均用户的平均活跃时间为30分钟那么此时间段的并发度应为200*30/12050。这里并发度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最大20sPass/Fail 条件如果失败重试一次依然失败就中止。数据每虚拟用户使用不同的账号...可以说用户模型表达的是系统运行中的压力是如何分布的。 而场景数据表达的是要给系统施加多大的压力。 只有结合用户模型和场景数据两部分才能构造出一个确定的负载场景。如果到这里都已经做好并且经过了技术负责人和业务负责人的确认那么接下来要做的就是按照设计来实现测试脚本了。
