一个简单的LoadRunner测试网页游戏压力流程性整理,在此做个备忘。
  需求:测试页游戏WebGame的服务器承载能力、并发量
  工具:Cacti、LoadRunner、Visual VM
  Cacti:监测服务器的网络及负载
  LoadRunner:压力测试脚本的编写及压力场景设计
  VisualVM: JVM运行状态监控
  Step1:为什么选择这样的工具
  基于http+socket的连接请求,客户端as、服务器java
  http+socke协议:选择LoadRunner11中的双协议[Web(HTTP/HTML))+Windows Sockets]
  服务器java:VisualVM可直接监控JVM运行状态及分析JVM消耗的软件
  Cacti:服务器环境搭建于linux的Centos
  Step2:录制脚本
  在LoadRunner11中使用双协议[Web(HTTP/HTML))+Windows Sockets]进行脚本录制,先录制一个角色的登陆
  建议:
  a:游戏的账号名与角色名保持一致,简化参数化的复杂度
  b:第一次录制的时候,尽量简化在游戏中的操作(过多的操作只会生成过多的LR脚本,增加分析脚本的负担)
  c:确定录制到脚本信息的有用性,不要存在有干扰的信息。若本机LR无法正常使用,可选择安装一台VM或者找一台纯净的机器进行
  双协议选择可参考:http://www.cnblogs.com/s1099312273/archive/2013/05/31/3110878.html
  Step3:调整脚本(参数化、精简)
  针对上面录制的脚本,自己先多看几编,分析下客户端真实登陆流程。再与程序沟通,确定正确的登陆与验证流程。
  需要解决的问题:
  a:登陆时如果通过登陆服、游戏服验证
  b:签名验证如何通过验证
  c:分析并找出Action.c及data.ws中有可参数化的数据,如角色名,时间戳
  d:删除不必要的脚本信息
  本阶段需要与程序人员进行沟通,了解服务器验证流程。
  Step4:回放脚本、场景创建
  回放Step3中调整后的脚本,确保在Vuser Generator中可正常回放。
  使用Controller创建并发,并创建对应的场景。如:每秒并发100人登陆持续30秒,2000人持续在线20小时等。
  建议:
  a:同一台机器不要登陆过多的游戏账号,好分布到不同的机器上
  b:每次在跟场景时,记录每次登陆时的时间与在游戏中的真实角色的操作感
  c:及时查看每个场景中并发用户的运行情况
  d:每次测试时,好把服务器重启,保证不会存在内存数据,影响数据的准确性
  Step5:大承载、并发量
  调整场景中数据,测试出服务器的大并发量及大承载量。
  测试时适当的调整不同场景下的并发量,协调服务器的总负载。
  得到当前服务器的大承载、并发量
  Step6:总结
  分析出当前瓶颈,产出测试报告,制定下次测试的计划与目标。
  That's all.