LoadRunner脚本测试——登录实践

实习公司最近在做一款会计项目的财政管理系统。跟着测试组在做登录响应测试时，学到了不少实践经验。本文作以简单阐述和分享。

– 通过代理服务器录制脚本

测试系统的门户必须用Chrome打开，然而测试环境lr11似乎只对IE浏览器兼容。事实上，lr与浏览器不兼容、打开浏览器无响应的情况时常出现（详见我的上一篇blog）。通过使用代理可以解决二者不兼容的问题。

启用LR代理服务器后，它会监听设置的端口号是否有请求信息发送给服务器。有请求发生时，代理服务器接收请求，并转发给对应的系统服务器，同时LR获取请求的信息与数据，生成脚本。

注意：使用代理需要使本机IP和服务器IP处在同一网段内。

设置代理需要分别配置lr和浏览器。

• lr代理
  打开Recording Options，在Mapping Filtering中添加New Entry，Target Server填写系统服务器地址，ID选择HTTP。
  在Traffic中同理，注意在设置端口号时避免被占用（尽量大一点，如9998）。
  最后将Application由浏览器更改为lr->bin目录下的wplus_init_wsock.exe。

• 浏览器代理
  在浏览器的连接设置里，选择手动配置服务器，输入本机IP和与lr监听中相同的端口号。

开始录制，Vugen会连接自带的代理，正常情况下用任一浏览器访问服务器的操作都会被录制。

我在手动配置浏览器代理后，出现了外网、局域网、本机服务器都无法连接的情况……Overwhelmed...
  

– 身份标识码token参数化

• About token

token 是在服务端产生的。当前端使用用户名/密码向服务端请求认证，服务端认证成功，那么在服务端会返回 token 给前端。前端在后续的每次请求中可以通过token证明其合法身份。

token一般有两个用处：身份验证和防止表单重复提交。
因此，在测试登录脚本时，处理token的更新必不可少。

当录制好登陆脚本后，在Design Studio中检测到关联。启动关联后，脚本中自动生成了一段关联代码：

（后面所有提交请求代码中的session值都被替换成了{userSession}）

其实关联采用的也是类参数化的方法，新建了“userSession”变量，只不过它的参数取值是即时从服务器获取的。
web_reg_save_param()类函数按照一定的策略从服务器返回的信息中过滤和获取信息。
我们来看看上述代码在生成过程中的日志信息：

可以找到userSession的值。同时也可以看到，当前端发出Body请求时，带上了这个值说明验证成功。
再回头看上面的关联代码中，RegExp的value建立了一个正则表达式来获取session值。
（其它同理，如web_reg_param_ex()是通过设置左右边界的方法，不过只适用于静态边界的情况。）

• 题外话：token有效期的设置
  从确保安全的角度考虑，需要为token设置有效期，过期的token值会在服务器中被吊销。
  那么，有效期应该设置多久呢？从安全的角度考虑当然是越短越好，但不能短的过分。
  例如，在用户正常操作过程中突然被要求验证身份，用户体验会非常糟糕。
  – 方案1：保持token有效状态。当每次用户请求时，都刷新一次token值。但当每秒请求数很大时，频繁刷新会造成很大的传输压力和内存开销。
  – 方案2：Refresh token。当token即将过期时，客户端向服务器请求更新一个新的token。服务器只需要在这个时候检查Refresh token的有效性。

• request 指在一次请求的全过程中有效，即从http请求到服务器处理结束，返回响应的整个过程，存放在HttpServletRequest对象中。在这个过程中可以使用forward方式跳转多个jsp。在这些页面里你都可以使用这个变量。
• Session是用户全局变量，在整个会话期间都有效。只要页面不关闭就一直有效（或者直到用户一直未活动导致会话过期，默认session过期时间为30分钟。

– 通过云服务器资源占用分析性能缺陷（Fusion Cloud 华为云）

在对登录脚本测试时，50个独立用户并发登录的响应时间长达十几秒，其中还出现了Fail的情况。日志显示token没有及时返回导致登录不成功。
在服务器上查看服务资源使用（这还是笔者首次使用私有云服务，有点小惊喜），web-service的内存占用爆红了。
将summit请求代码注释掉，只测试登录动作，结果良好。
得出结论：可能是请求操作过多，占用大量内存，服务器处理不及时导致token值没有成功返回，同样也导致响应时间过长。

前端以单个请求为主，导致很多http请求仅仅包含单个业务请求，大量带宽浪费在http head上，cpu浪费在http协议的解析上。

优化策略：尽可能减少请求数，例如“获取日期、获取省份”可以整合在同一个请求中。