1
背景
1.1
讲一个故事
以前我们公司招了一个自称非常熟练
loadrunner
的员工,有一次分配给他测试
sso
单点登录系统的性能测试。登录一个网站
A
,需要输入用户名密码,然后在访问另一个
网站
B
,因为在网站
A
已经登录过,所以
B
应该不需要再登录,直接就可以访问
B
页
面。让该员工测试下可以支持多少用户,及稳定性。
该员工使用
loadrunner
测试了
2
天,然后给我们报告说支持
320
左右个用户并发。
然后,我们跟他一起验证下,确实在
320
并发时就出现用户失败。但检查系统
A
与
B
,
发现
A
确实登陆了,但
B
没有数据,后面他定位了半天也没解决问题,最后我帮他定
位下,结果发现是发给
B
系统请求
B
页面的
HTTP
的会话信息里没有包括用户已经登陆
的信息,会话在
Cookie
与
URL
的参数都存在。
还有另外一个问题,当时由于没研究
loadrunner
是如何模拟用户的,后来参与开发
了
kylinPET
性能测试工具,才对性能工具的原理有深入的了解。其实之前
loadrunner
工
具测试的并发用户数最大支持
320
,是错误的,大家可以看我写的“如何测试服务器的
最大并发数”
,网址:
http://www.kylinpet.com/dow_6_1.html
1.2
该故事说明了什么
该故事说明了,一个熟练
loadrunner
的人进行系统性能测试,还是出现
花费了
2
天多的时间是白费的,因为实际
B
系统还需要登录,因此无法访问
B
页面。
为什么呢,因为他对业务了解不透,还有认为
loadrunner
回放通过就表
示脚本没问题,虽然他做了一些关联参数,但脚本其实还是错误的。因此,会