LoadRunner规范
东软集团股份有限公司  移动互联网事业部测试部
更改履历
序号
版本
更改章节
状态
更改描述
更改时间
更改人
更改申请号
状态：新建、增加、修改、删除。
1 文档说明
1.1 背景及目的
    编写这篇文档的目的用于规范我们测试部LoadRunner脚本编码风格，使大家能够养成一个好的编程习惯，使得在日常工作中编写的代码可读性更强，“低级错误”更少，更易于维护以及他人学习，并且希望通过这些点点滴滴的努力从而提高我们的产品质量，降低风险。
    该规范的和C语言相关的部分，基本完全借鉴了林锐博士的高质量C++编程这本书里面的内容。因此建议大家学习一下这本书，是开发和测试都需要学习的一本好书。
    该规范后面增加了LoadRunner脚本中常用的例子，在实际工作中，基本常用的函数以及写法都已经包含在里面。
1.2 注意事项
2 脚本编写
2.1 命名规则
● 【规则2-1-2】命名规则尽量要遵循“言简意赅、望文生义”的八字方针。
● 【规则2-1-1】变量名应当直观且可以拼读，可望文知意，不必进行“解码”。
变量名最好采用英文单词或其组合，便于记忆和阅读，切忌使用汉语拼音来命名。程序中的英文单词一般不会太复杂，用词应当准确。
● 【规则2-1-2】程序中不要出现仅靠大小写区分的相似的变量名。
例如：
int  x,  X;        // 变量x 与 X 容易混淆
● 【规则2-1-3】程序中不要出现完全相同的局部变量和全局变量，尽管两者的作用域不同而不会发生语法错误，但会使人误解。
● 【规则2-1-4】变量的名字应当使用“名词”或者“形容词＋名词”。另外，对于大家常用的、习惯成俗的形容词，可以采用缩写。
例如：
uint32     value;        //名词
uint32     n_val;        //形容词+名词，n是new的缩写
● 【规则2-1-5】尽量避免名字中出现数字编号，如val1,val2等，除非逻辑上的确需要编号。这是为了防止程序员偷懒，不肯为命名动脑筋而导致产生无意义的名字（因为用数字编号最省事）。
● 【规则2-1-6】全局变量加前缀g_（表示global）修饰，单词之间采用下划线分割。
例如：
Char     *g_msg_pool;
● 【规则2-1-7】函数名尽量采用“模块名+动词+名词”（动宾词组）或者“模块名+名词+动词”的方式命名，尽量做到根据函数名能大概明确函数所完成的功能。
例如：
bool  comm_hash_create(…)        //模块+名词+动词
● 【规则2-1-8】宏常量名必须全部采用大写的字母，单词之间使用下划线分隔。
例如：
#define DEF_BUF_LEN 150        //宏常量
2.2 格式化代码
● 【规则2-2-1eval是做什么的】脚本应采用缩进风格编写，每层缩进使用一个制表位（TAB），类定义、方法都应顶格书写；
● 【规则2-2-1】左花括号要另起一行，不能跟在上一行的行末； 
● 【规则2-2-2】一个变量定义占一行，一个语句占一行；
● 【规则2-2-3】对独立的程序块之间、变量说明之后必须加空行；
● 【规则2-2-4】对于较长的语句（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读；
● 【规则2-2-5】循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分；
● 【规则2-2-6】在结构成员赋值等情况，等号对齐，最少留一个空格；
● 【规则2-2-7】若函数或过程中的参数较长，则要进行适当的划分。
● 【规则2-2-8】形参的排序风格：
    最常使用的参数放在第一位；
    输入参数列表应放在输出参数列表的左边；
    将通用的参数放在特殊的参数的左边
2.3 Vuser
● 【规则2-3-1】脚本越小越好。就像写code一样，不要太长，这样易于维护也易懂。尽量做到一个功能写一个脚本。如果那些功能是连续有序的，必须先做上一个，下一个动作才能进行，就只能放在一起了。
● 【规则2-3-2】对于在脚本中常用的函数，需要进行抽取，放到专门的.h中进行定义实现。
● 【规则2-3-3】能用到高级协议的，不要使用底层协议。
● 【规则2-3-4】通常将登陆业务放到init里面；业务放到action里面；退出放到end里面
● 【规则2-3-5】在脚本中，必须自己定义事务，不允许使用默认事务。
● 【规则2-3-6】在脚本中，如果有登陆和退出操做，也必须声明事务。
● 【规则2-3-7】脚本名称，事务名称、参数名称要做到见名知义。
● 【规则2-3-8】对于socket需要明确是长连接还是段连接
● 【规则2-3-9】socket编程必须关闭系统的buffer
● 【规则2-3-10】对于socket，如果能每次返回的长度确定，那么一定使用data.ws文件中指定特定长度的字符。否则才设置接受超时时间。
● 【规则2-3-11】对于操做二进制，不使用字符串操做函数，需要使用内存函数。如memcpy代替strcpy
3 场景执行
● 【规则3-1】在执行前，建议将所有的脚本放到本地的英文目录下，建议d:\script
● 【规则3-2】运行时需要关闭系统的日志。
● 【规则3-3】运行时根据实际情况设置场景的思考时间
● 【规则3-4】运行时去掉每个action作为一个transaction的统计
● 【规则3-5】对于HTTP协议测试，正确合理设置缓存策略
● 【规则3-6】在执行时每次将执行的结果放到本地的英文目录下，建议d:\result
● 【规则3-7】执行单交易测试最少需要20分钟；执行混合场景测试最少需要30分钟
● 【规则3-8】对于测试使用负载均衡策略的系统，需要考虑负载均衡的方案，以便决定是否采用IP欺骗。
● 【规则3-9】在整个测试执行过程中，使用excel记录整个执行过程，尤其是在执行过程
中新设计的场景。
序号
内容/场景
负责人
开始时间
结束时间
测试结果记录
发现问题
解决办法
备注
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
　
4 一些经验
1、 能用简单方法实现的，别用复杂的实现。尤其是获取loadrunner测试数据模块。
2、 关联函数使用

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。