小书乖张

版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://sqa.blogbus.com/logs/1395471.html

5月至9月，在云南昆明项目A中运用LoadRunner进行了压力测试，这里写下经验和大家分享；同时本文对工作中其他情况进行描述。

注：Loadrunner下简称LR

经验1：LR不适合做C/S程序的测试
LR中有Oracle Tiger和Socket协议可用于C/S测试，但录下的脚本体积巨大，且不能并发。

项目A中ht子系统为C/S架构，采用C++ Builder 5开发。但录下脚本即出现问题——不管脚本是基于Oracle Tiger协议还是基于Socket协议其体积都非常大，通常会达到3000行左右。然而更奇怪的是脚本不能在Controller中实现并发；后使用IP欺骗进行也未实现并发。

总体来说：C/S的测试可以说是LR的鸡肋。

经验2：良好的命名规则
录制脚本前有个命名规则非常有必要，否则同一动作会有多个事务，会给数据收集、分析带来不必要的麻烦。

假设某J2EE系统实现开户、销户业务，那么自然会有Login、OpenAccount、DestroyAccount和LoginOut动作。那么录制LR脚本时，脚本中的Action列表应该为：

脚本1：初始化-Login-OpenAccount-LoginOut-结束动作
脚本2：初始化-Login-DestoryAccount-LoginOut-结束动作
（即只有一个动作不同）

这样做其目的是创建场景Scene时，在Login、LoginOut的事务只被记录一次。

经验3：组织好参数化
通过LR的参数化可实现诸如用不同客户登录系统并执行操作，这是非常方便的。不过通常带有流水号的业务会给测试带来一点阻力，录下的脚本需要更改流水号才能正确回放！因此，你必须小心处理lr_submit_data中那个带有流水ID的表单，并在参数化时避免流水ID唯一性、格式正确等问题。

（通常有设计经验的人都初学LR时，会尝试用“数组”来解决多用户登录，从时间、效率上来看实际并不划算）

在参数化上还有另一个问题：参数表ListNum，其中有Num1列和Num2列，如何在脚本中同时引用两列的值？我发现在脚本中不能用{ListNum[1]}或{ListNum[Num1]}来引用第一列。

经验4：多场景测试，综合分析结果
一个目的：减少误差

经验5：脚本偶合度高
LR脚本一般都是录制后经过略微修改而成的，其脚本与业务版本要求匹配。虽然可以将诸如ServerUrl、AdminName、AdminPws等定义为一个头文件，但LR对随机变动的树节点、菜单显的十分乏力。