controller 负载测试场景设计_单一业务场景

mr.bee

转眼接触LR三年，水平很长时间止步在工具的使用上，发一篇现在项目性能测试中的非正式场景设计流程，希望各位大虾能够指点一下，也希望能够给那些不知道如何做场景设计的同学一点提示。

--------正文---------
场景设计贴近用户实际是一项非常复杂的工作。在一定规模的系统上线运行后，极少情况存在着一个单业务场景独立的存在与系统中一个较长的时段，所以，即使是负载测试结束以后未能重现某个性能缺陷，也未必是由于该业务场景设计缺陷导致的。我的经验是取出业务峰值中的50%虚拟用户数与150%虚拟用户数分别再执行一次负载测试。

先来看看流程：
一、了解背景，获取关键数据
二、基准测试与数据处理
三、在LR controller中进行场景设计

一、了解背景，获取关键数据
这些关键数据包括了：
业务总用户数、业务常用用户数、业务峰值在线用户数、业务峰值时段、业务会话平均时间。

业务总用户数：即凡拥有该业务操作权限的用户数。当然，这里也可能存在客户端数量的限制，这种情况下的任何时候在线用户数都不可能超过客户端数量，这时候就只需考虑客户端数量即可。

业务常用用户数：即某一时间区间内，进行过此项业务操作的用户数，这一个时间区间可以是一个工作日，也可以是一周，甚至可以是一个月，主要视该业务如何定义“常用”，如无特别说明，本文案例中常用用户数即每个工作日参与至少操作一次测试业务的用户数量。

业务峰值在线用户数：即业务峰值中进行此项业务操作的用户数量，如FWMS4SZ中系统登录业务峰值在线用户数被定义为200，因为根据后台监控数据发现：AM8：30至AM9：00间为系统用户集中登录时段，同理，如何定义“集中”也视业务在整个工作日发生情况而定。

业务峰值时段：通过了解该项数据，可得出“业务考察时长”，至于什么是业务峰值应该很好理解。根据我的经验，可以认为64%业务发生的时段即为“集中”、“峰值时段”。

业务会话平均时间：即所有用户执行该项业务开始至结束所使用时间除以用户数。

以上数据均为设计基础数据。

二、基准测试与数据处理
基准测试的目的是建立一套性能数据基准，取得测试业务中的数据基准，通常基准测试结果代表着系统的最佳性能表现。主要关注点：事务平均响应时间、事务请求数。

业务并发用户数、业务请求数、步进时间的计算：
事务中具体产生多少请求可在Analysis中使用过滤器过滤掉事务以外的所有数据，然后再使用Total hits除以事务通过数得出。因此基准测试中必须保证事务通过率为100%，否则未达到基准测试基本要求，计算结果错误。
并发用户数=会话数*会话平均时间/考察长度
步进时间=考察长度/请求数

完成以上步骤，数据准备工作完成。

三、在LR controller中进行场景设计
1.Quantity：即系统在线用户数
2.Schedule builder：
Ramp up：根据后台监控了解用户进入速度 或 使用“会话数/考察长度”得出
Duration：Run until completion（负载测试中，只需要合理的配置运行逻辑，完成所需模拟业务量即可，这有别于压力测试）
Ramp down：/
3.Rendevours：
并发用户数：根据并发公式计算得出
超时时间：为避免虚拟用户加载速度过慢或由于集合点前请求响应发生了过慢/超时导致超时无法达到并发数，应该尽可能长但又要避免虚拟用户集中在一个时间区间内集中进行N次并发（确实有点难）。

下面看一个案例：
FWMS大集中以后系统登录业务将会是一个重大考验，已知8：30至9：00登录用户数为2500，系统登录业务请求数为102（不含桌面展示窗口），设计一个负载性能测试场景。

1.Quantity：2500
2.Schedule builder：
Ramp up：每60秒90虚拟用户
Duration：Run until completion（半个小时内登录后注销再重新登录的情况不考虑）
Ramp down：/
3.Rendevours：
并发用户数=2500*3/30=250——“系统登录”会话平均时长包括：打开页面时间、完成身份验证时间、桌面待办与统计展现时间、浏览待办与统计时间，考察时长30分钟。
Time out=180s

搞定，Star scenario！

msnshow

顶一个