性能测试脚本的要求规范.docVIP

实用标准文案 精彩文档 LoadRunner规范 东软集团股份有限公司 移动互联网事业部测试部 更改履历 序号 版本 更改章节 状态 更改描述 更改时间 更改人 更改申请号 状态：新建、增加、修改、删除。 文档说明 背景及目的 编写这篇文档的目的用于规范我们测试部LoadRunner脚本编码风格，使大家能够养成一个好的编程习惯，使得在日常工作中编写的代码可读性更强，“低级错误”更少，更易于维护以及他人学习，并且希望通过这些点点滴滴的努力从而提高我们的产品质量，降低风险。 该规范的和C语言相关的部分，基本完全借鉴了林锐博士的高质量C++编程这本书里面的内容。因此建议大家学习一下这本书，是开发和测试都需要学习的一本好书。 该规范后面增加了LoadRunner脚本中常用的例子，在实际工作中，基本常用的函数以及写法都已经包含在里面。 注意事项 脚本编写 命名规则 【规则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-1】脚本应采用缩进风格编写，每层缩进使用一个制表位（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】形参的排序风格： 最常使用的参数放在第一位； 输入参数列表应放在输出参数列表的左边； 将通用的参数放在特殊的参数的左边 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文件中指定特定长度的字符。否则才设置接受超时时间。 【规则