LR脚本编写规范
在LoadRunner的脚步编写中,有三个重要的概念：事务、集合点、思考时间
在LoadRunner的脚步编写中，有三个重要的概念：事务、集合点、思考时间事务：事务又称为Transaction，在LoadRunner中的定义如下:An end-to-end(browser-to-browser) measurement of one or more user actions within action file。
中文理解如下：事务(Transaction)是这样一个点，我们为了衡量某个action的性能，需要在action的开始和结束位置插入这样一个范围，这就定义了一个transaction。
事务的作用：LoadRunner运行到该事务的开始点时，LoadRunner就会开始计时，直到运行到该事务的结束点，计时结束。
这个事务的运行时间在LoadRunner的运行结果中会有反映。
通俗的讲LoadRunner中的事务就是一个计时标识，LoadRunner在运行过程中一旦发现事务的开始标识，就开始计时，一旦发现事务的结束表示，则计时结束，这个过程中得到的时间即为一个事务时间。
通常事务时间所反映的是一个操作过程的响应时间。
下面我们说说为什么在LoadRunner中使用事务。
为什么使用事务的原因是多种多样的，总结下来如下五点所示：1、事务是LoadRunner度量系统性能指标的唯一手段;(没有事务则没有办法衡量系统的响应时间，也许有人说LoadRunner可以通过编程来计时得到，不错如果你编程能力够强是能够实现的，但肯定不如LoadRunner中的事务用的简单而且方便)2、事务能够用于度量高风险业务流程的性能指标;3、事务能够度量在一组操作中每一步的性能指标;4、通过事务计时实现了不同压力负载下的性能指标对比;5、通过事务计时可以帮助定位性能瓶颈;从性能测试的角度出发，我们需要知道不同的操作所花费的时间，这样我们就可以衡量不同的操作对被测系统所造成的影响，那么我们如何知道不同的操作所花费的时间，这就用到了事务，我们在操作之前插入一个事务开始标识，在操作完成后插入一个事务结束表示，这样我们就知道了这个操作所花费的时间。
ZEMAX进行MTF的公差分析
ZEMAX进行MTF的公差分析!MTF的公差分析从波前差开始就像优化一样，最好从波前差开始公差分析。
如果你的初始公差太宽松，波前差比直接用MTF公差要快，而且更精确。
最好的，在你开始公差分析之前，打开一个MTF曲线，然后使用公差编辑器中的“覆盖MC 曲线（Overlay MC Plots）”开关。
当生成蒙特卡洛文件是，ZEMAX会自动覆盖MTF曲线，所以你可以看到性能的变化。
这对所有的分析功能都有效，不仅仅是MTF，它是一个神奇的工具，能获得您想要的公差。
例如，如果你需要MTF在50周期/mm时提高40%，如图所示，我们原离所需的性能。
总之，使用波前公差标准和覆盖的MTF曲线是开始MTF公差分析的好方法。
你甚至可以编写一个公差脚本对波前差进行公差分析，但报告最终的MTF性能。
注意，不要限于下拉列表中的公差标准。
你可以编写你自己的标准并编写脚本组合多个标准。
快速，精确的MTF计算在公差分析进行时，你需要直接转化到MTF公差分析，以尽可能使获得的结果与你在车间测试的结果相近。
ZEMAX使用相同的MTF操作数进行公差分析和优化。
在ZEMAX的2007年5月的版本中，我们将ZEMAXMTF操作数的计算时间减少了100%，在某些情况下更多。
这可以使你能对双高斯镜头进行完整的MTF公差分析，有100个公差，5个视场位置，三个波长并包括严格的补偿器优化，例如，在单CPU的膝上型电脑上，4分钟内进行严格的MTF分析，每个公差只需2秒钟，没有一级近似。
2007年5月版本中的另一个重要功能是ZEMAX中的公差也支持多线程，所以当你的电脑中的CPU增多时，公差分析所花的时间减少。
ZEMAX支持多达16个CPU。
记住TOLRTOLR操作数能很容易指定某一性能作为评价函数的一部分。
只要设置你的加工公差，然后设置你要的公差步骤。
TOLR操作数返回归一化的系统性能，期望的性能改变，以及期望的构建镜头性能，所以你可以优化最后的产品而不是设计中的中间步骤。
测试人员的职责
测试人员的岗位职责（通用12篇）测试人员的岗位职责篇1岗位职责：1、根据软件项目的设计方案编写软件代码，完成软件测试；2、编写开发文档及测试报告；3、编写帮助文档，制作软件使用手册；4、对所评测的内容，提出自己的独到见解和建议；5、对测试错误进行报告和跟踪。
测试人员的岗位职责篇2软件测试员岗位职责：1、协助测试经理制定项目的测试计划，保证产品测试工作的计划性与规范性;2、把握有关要求，详细编写测试用例，做好测试前的相应准备工作;3、搭建测试环境，保证测试环境的独立和维护测试环境的更新;4、执行测试，并及时评估软件的特性与缺陷;5、进行BUG验证，督促开发部门解决问题;6、进行测试记录和相应文档编写。
测试人员的岗位职责篇3岗位职责：1、配合项目经理进行业务需求的沟通，整理需求说明书；2、完成软件的功能模块详细设计，业务功能实现与单元测试，bug修改等工作；3、参与产品构思和架构设计，撰写相关的技术文档；4、对测试实施过程中发现的软件问题进行跟踪分析和报告；5、推动测试中发现问题及时合理解决。
测试人员的岗位职责篇4（一）1、制定、编写软件测试方案与计划；2、按时完成软件测试工作任务，执行测试，跟踪缺陷状态，提交测试执行报告；3、编写测试文档，测试报告，提交测试结果；4、测试环境的设计、设置，完善测试规范流程、创建和维护测试用例；5、改进软件测试流程、工具、和质量。
6、参与测试结果评审；（二）1、参与产品测试、根据测试结果编写测试报告；2、负责编写各产品用户文档、技术白皮书、概要设计、功能说明书等各种技术文档；3、提出对(tichudui)产品的改进建议。
测试人员的岗位职责篇5职位要求：1、具有创造性，追求完美；2、准确判断力；3、良好沟通能力，善于说服，善于清晰地表达观点，善于提问；4、拥有编程知识，了解行业知识，能更好的了解软件的目的；工作内容：1、修改测试案例；2、用自动测试工具进行测试，尽早找到软件缺陷，并确保其得以关闭；3、项目可行性、可靠性分析，风险分析；4、制定测试计划；5、测试自动化开发；测试人员的岗位职责篇6工作职责：1、负责大型系统的测试工作，参与测试需求分析、测试用例设计;2、执行测试用例，记录测试结果，分折测试发现的问题，跟踪并验证bug 并确认问题，编写测试报告;3、按时、保质、保量地完成各项分配的任务;4、编写自动化测试及性能测试脚本，开发辅助测试工具;5、负责搭建和维护基于linux和windows下的测试环境，执行自动化测试，提交测试报告;工作要求：1、至少2年以上的it行业(尤其是web)测试经验;熟悉b/s架构、webbrowser软件产品的测试方法;2、沟通能力强，具团队合作精神，与研发等相关部门进行3、有较强的逻辑分析能力和学习能力，可以胜任重复性工作，工作细致认真，有耐心;4、至少掌握一种自动化测试工具或性能测试工具，如：qtp、selenium、lr等;5、熟悉mysql/sqlserver数据库的使用;6、能熟练地应用一门或几门脚本语言perl/python/shell等进行工具开发;7、有ios，androidapp的测试经验优先;8、有大型b/s项目、性能测试经验优先测试人员的岗位职责篇71、参与软件需求分析，编制软件测试计划、测试方案；2、设计测试用例，编写测试脚本；3、对产品进行系统测试，包括：功能测试、界面测试和性能测试；4、对缺陷进行分析、定位和反馈，协助并监督开发人员及时解决BUG；5、记录测试结果，编写测试报告。
第7章 LoadRunner常见问题解答
通过设置vugen.ini的MaxVisibleLines项数值可以调整 LoadRunner参数显示数据的个数。
7.2 如何突破Controller可用脚本50条限制
修改max_num_of_scripts
7.3 如何解决数据库查询结果过大导致录制失败
设置Vugen.ini的CmdSize项完成
解决
7.22 如何解决由于设置引起的运行失败问题
这种情况通常是因为被测试的应用程序应用的链接超 时、相应页面资源的下载时间等超过LoadRunner默认 值而引起来的错误，这时我们通过调整LoadRunner系 统的相关设置，通常这些错误信息都能够得到解决。
7.23 如何实现对服务器系统资源的监控
return 0; }
7.7 如何解决脚本中的乱码问题
问题
平时在对Web应用程序性能测试的时候，可能会出现录制的脚 本中汉字变为乱字符的现象。
解决
7.8 如何在录制时加入自定义标头
问题
有时在录制过程中，要加入自定义标头，那么如何在脚本中 加入自定义标头呢？
解决
7.9 线程和进程运行方式有何不同
解决
System()函数
7.18 如何下载并保存文件到本地
问题
如何下载并保存文件到本地？
解决
获得文件内容后，通过fopen、fwrite、fclose函数，就可以 将需保存的内容保存成本地文件，这样就完成了文件下载操 作。
7.19如何理解常用图表的含义
Transaction Response Time 图 Through吞吐量图 Windows Resource图
7.32 如何用程序控制网站的访问次数
在进行性能测试的时候，性能测试用例设计是模拟用户 实际应用场景是非常重要的一项工作。通常用户操作经 常用到的业务是相对固定的，这样在场景设计的时候， 就需要经常应用的Action执行次数多些，而系统设置方 面的工作通常为一次性操作。
BAT脚本编写教程
BAT脚本编写教程echo、@、call、pause、rem(小技巧：用::代替rem)是批处理文件最常用的几个命令，我们就从他们开始学起。
echo 表示显示此命令后的字符echo off 表示在此语句后所有运行的命令都不显示命令行本身@与echo off相象，但它是加在每个命令行的最前面，表示运行时不显示这一行的命令行（只能影响当前行）。
call 调用另一个批处理文件（如果不用call而直接调用别的批处理文件，那么执行完那个批处理文件后将无法返回当前文件并执行当前文件的后续命令）。
pause 运行此句会暂停批处理的执行并在屏幕上显示Press any key to continue...的提示，等待用户按任意键后继续rem 表示此命令后的字符为解释行（注释），不执行，只是给自己今后参考用的（相当于程序中的注释）。
例1：用edit编辑a.bat文件，输入下列内容后存盘为c:\a.bat，执行该批处理文件后可实现：将根目录中所有文件写入a.txt中，启动UCDOS，进入WPS等功能。
批处理文件的内容为: 命令注释：@echo off不显示后续命令行及当前命令行dir c:\*.* >a.txt将c盘文件列表写入a.txtcall c:\ucdos\ucdos.bat调用ucdosecho 你好显示"你好"pause 暂停,等待按键继续rem 准备运行wps 注释：准备运行wpscd ucdos进入ucdos目录wps 运行wps批处理文件的参数批处理文件还可以像C语言的函数一样使用参数（相当于DOS命令的命令行参数），这需要用到一个参数表示符“%”。
%[1-9]表示参数，参数是指在运行批处理文件时在文件名后加的以空格（或者Tab）分隔的字符串。
变量可以从%0到%9，%0表示批处理命令本身，其它参数字符串用%1到%9顺序表示。
例2：C:根目录下有一批处理文件名为f.bat，内容为：@echo offformat %1如果执行C:\>f a:那么在执行f.bat时，%1就表示a:，这样format %1就相当于format a:，于是上面的命令运行时实际执行的是format a:例3：C:根目录下一批处理文件名为t.bat，内容为:@echo offtype %1type %2那么运行C:\>t a.txt b.txt%1 : 表示a.txt%2 : 表示b.txt于是上面的命令将顺序地显示a.txt和b.txt文件的内容。
Realview MDK中链接脚本的详细解析
例 2 一个加载区域，多个非连续的执行区域。
LR_1 0x010000 { ER_RO +0 { * (+RO) } ER_RW 0x040000 ; 定义可读写数据段 ER_RW 的起始地址为 0x040000. { * (+RW) } ER_ZI +0; 清零数据段 ER_ZI 紧接 ER_RW 段的尾地址存放，即为 0x040000 + ER_RW 的容量。 { * (+ZI) } } ; 所有清零数据都连续地放在这个区域。 ; 所有的可读写的程序都连续地放在这个区域。 ; 所有的只读代码段都连续地放在这个区域。 ；执行区域 ER_RO 的起始地址紧接载于区域 LR_1 的起始地址，即为 0x010000. ; 定义载入区域 LR_1 的起始地址为 0x010000。
例 3 二个加载区域，多个非连续的执行区域。
-1-
LR_1 0x010000 { ER_RO +0 { * (+RO) } } LR_2 0x040000 { ER_RW +0 { * (+RW) } ER_ZI +0 { * (+ZI) } }
; 载入区域 LR_1 的起始地址为 0x010000。 ; ER_RO 段的起始地址为 0x010000.
Realview MDK中链接脚本详细解析
Eembest 徐良平 使用 Realview MDK 时不可避免的要涉及到链接脚本文件， 特别是编译链接那些大的工程文件时更 是如此。在链接脚本中可以指定代码的存储布局，可以将代码段、只读数据段、可读写的数据段分别存 放，甚至可以精确地指定代码放置的位置，这一点是很关键的，譬如说启动代码就必须放在可知型文件 的开始位置。由于链接脚本重要性，开发者必须掌握其编写的方法。 Realview MDK 链接程序使用了两种方式控制程序的链接，即链接控制命令选项和链接脚本文件。 当使用链接控制命令选项时， 链接器定义了 Image$$RW$$Base、 Image$$RW$$Limit、 Image$$RO$$Base、 Image$$RO$$Limit、Image$$ZI$$Base 和 Image$$ZI$$Limit 等 6 个段地址描述符。这 6 个描述符可以直 接在程序中引用。而在使用链接脚本文件后，这 6 个描述符号没有了，取而代之的是链接脚本文件中的 段描述符，格式为：Image$$段名$$Base 和 Image$$段名$$Limit。下面将结合 3 个具体的例子说明链接 脚本文件的使用。 例 1 一个加载区域，多个连续的执行区域。
loadrunner关联函数
loadrunner关联函数LoadRunner是一款性能测试工具，可以模拟多种协议的用户行为，通过对系统进行压力测试、负载测试、并发测试等多种测试方式进行性能评估。
在LoadRunner中，关联函数是非常重要的一种函数类型，它可以将服务器返回的数据提取出来并赋值给变量，以便后续脚本中使用。
一、关联函数概述1.1 关联函数定义关联函数是LoadRunner中的一种特殊函数类型，用于从服务器返回的响应中提取数据，并将其赋值给变量。
关联函数通常用于需要使用服务器返回数据作为后续请求参数的情况。
1.2 关联函数分类在LoadRunner中，关联函数可以分为以下几类：（1）web_reg_save_param：用于从Web应用程序返回的HTML或XML响应中提取数据。
（2）web_reg_save_param_ex：与web_reg_save_param类似，但支持更灵活的参数化选项。
（3）lr_save_string：用于从任何类型的响应中提取数据。
（4）lr_xml_find：用于从XML响应中提取数据。
二、web_reg_save_param关联函数详解2.1 web_reg_save_param语法格式web_reg_save_param("ParamName", "LB=LeftBoundary", "RB=RightBoundary", "Ordinal=All", "Search=Body", LAST);其中各参数含义如下：（1）ParamName：被保存参数的名称。
（2）LB：左边界，用于标识被保存参数的起始位置。
（3）RB：右边界，用于标识被保存参数的结束位置。
（4）Ordinal：指定哪一个匹配项被保存，可以是All、First或Last，默认为All。
（5）Search：指定从响应体中搜索还是从响应头中搜索，可以是Body或Header，默认为Body。
LoadRunner性能测试介绍
2 LoadRunner特点
(1) 广泛支持业界标准协议 (2) 支持多平台开发的脚本 (3) 创建真实的系统负载 (4) 强大的实时监控与数据采集功能 (5) 精确分析结果，定位问题所在
由“性能”想到的。。。
LOGO
（1）性能测试是什么？ 在一定的负载情况下，系统的响应时间、资源利用、效率等特性是否满足特定的性 能需求。 （2）性能测试包含哪些方面？ 压力测试、负载测试、并发测试、容量测试、配置测试、基准测试等。 （3）应用系统性能指标主要有哪些？ 响应时间、吞吐量、服务器资源利用 （4）性能分析方法主要有哪些？ 指标达成法、最优化分析（应用程序诊断、系统调优）。 （5）性能测试的重要性，为什么要进行性能测试？ 评估系统的能力 识别系统中的弱点 系统调优 验证可伸缩性和可靠性 ......
(1)不同用户使用不同的数据（通过“参数化”实现） (2) 多用户并发操作（通过“集合点”实现） (3) 用户请求间的依赖关系（通过“关联”实现） (4) 请求间的延时时间（通过“思考时间”实现）
LOGO
性能指标监控
(1) 请求响应时间监控（通过“事务”实现） (2) 服务器处理能力监控（通过“事务”计算吞吐量获得） (3) 服务器资源利用率监控（计数器接口）
d 检查点
LOGO
在进行压力测试时，为了检查Web 服务器返回的网页是否正确，VuGen 允许我们插入Text/Imag 检查点，这些检查点验证网页上是否存在指定的Text 或者Imag，还可以测试在比较大的压力测试环境中，被测的网站功能是否保持 正确。以下是插入检查点的步骤及检查点在脚本中的函数表示。
关联 概念：所谓关联（correlation）就是把脚本 中某些写死的（hard-coded）资料，转 变成是来自服务器的、动态的、每次都不 一样的资料。 原理：服务器在每个浏览器第一次跟它要资 料时，都会在资料中夹带一个唯一的辨识 码，接下来就会利用这个辨识码来辨识跟 它要资料的是不是同一个浏览器。一般称 这个辨识码为Session ID。对于每个新的 交易，服务器都会产生新的Session ID给 浏览器。这也就是为什么执行脚本会失败 的原因，因为VuGen还是用旧的Session ID向服务器要资料，服务器会发现这个 Session ID是失效的或是它根本不认识这 个Session ID，当然就不会传送正确的网 页资料给VuGen了。 要对付这种服务器，我们必须想办法 找出这个Session ID到底是什么、位于何 处，然后把它记录下来，放到某个参数中 ，并且取代掉脚本中有用到Session ID的 部份，这样就可以成功骗过服务图标的视图。 对于录制期间所执行的每一步骤， VuGen 都在测试树中生成一个图 标和一个标题，并附带相应的录制 快照。
loadrunner简单实用教程ppt课件
1基于浏览器的应用程序推荐使用HTML-based Script
2 不是基于浏览器的应用程序推荐使用 URL-based Script。
3 如果基于浏览器的应用程序中包含了 JavaScript 并且该脚本向 服务器产生
项目背景 性能测试需求 测试环境信息 性能测试场景 测试实施计划 参与人员以及职责
精选课件ppt
11
测试环境、工具、数据准备
测试环境准备 我们的测试环境与客户的实际环境是有较大的不
同，测试环境的网络、计算机硬件软件都无法做到和 客户完全相一致。软件在客户那功能不正常，也许就 是因为客户安装了某个不知名的其他软件造成的。因 此压力测试需要遵循一些基本的原则：
特点： 这种方法的主要目的是验证系统是否具有系统宣称具 有的能力。
精选课件ppt
6
测试方法基本概念
负载测试
通过在被测系统上不断增加压力，直到性能指标。如 通过量，响应时间，资源利用率等。
特点： 这种方法的主要目的是找到系统处理能力的极限， 用这种方法可以比较系统调优前后的性能差异。
精选课件ppt
开发视角的软件性能：
最关注的是使性能表现不佳的因素和由于大量用户访问引起的软 件故障，也就是我们所说的性能瓶颈。
精选课件ppt
4
性能测试的常用方法
1 性能测试 2 负载测试 3 压力测试
精选课件ppt
5
测试方法基本概念
性能测试
通过模拟生产运行的业务压力量和使用场景组合，测 试系统的性能是否满足生产性能要求。
精选课件ppt
16
三、LoadRunner操作介绍
农商银行新一代综合柜面业务系统性能测试报告
北京农商银行新一代综合柜面业务系统性能测试报告修订记录目录1测试简介 (1)1.1 项目背景 (1)1.2 测试目标 (1)1.3 测试范围 (1)1.4 性能测试指标要求 (1)2测试方案 (2)2.1 压力模型 (2)2.2 交易选择 (2)2.3 测试脚本 (3)2.4 资源监控 (3)2.5 测试场景 (4)3 测试环境 (5)3.1 网络拓扑图 (5)3.2 软硬件配置 (5)3.3 测试工具 (6)4测试实施情况 (7)4.1 测试时间和地点 (7)4.2 参加测试人员 (7)4.3 测试实施进度 (7)5测试结果 (8)5.1 基准测试 (8)5.1.1 测试结果 (8)5.1.2 分析图表 (8)5.2 并发测试 (9)5.2.1 测试结果 (9)5.2.2 分析图表 (10)6数据分析 (23)7系统评价 (25)8测试遗留问题 (25)9附录 (25)9.1 性能测试记录表 (26)9.2 0210交易处理脚本 (26)口吕Socket ------- Socl:新柜面系统应用服务器■性能测试范围1.1 项目背景为解决原有字符终端柜面系统不能处理非线性数据（如图像）的缺陷、解决业务中的柜员离柜问题，并对交易前端的功能性梳理和整合，北京农商银行将实施现有字符终端向图形终端的改造，实施新一代综合柜面业务系统项目。
在新一代综合柜面业务系统全面推广上线前，需要对新系统平台进行性能测试，获取系统的并发处理能力、交易响应时间等性能指标。
1.2 测试目标本次性能测试的测试目标为：获取新一代综合柜面业务系统在测试环境中的性能指标数据发现性能瓶颈，协助开发人员进行性能调优，对系统上线提供性能建议和评估1.3 测试范围新一代综合柜面系统的架构示意图如下图所示，图中红线虚框为本次性能测试的范围，包括ABS处理平台的后台应用服务器和数据库服务器。
丨S新一代综合柜面系统ABS新柜面系统数据库服务器1.4性能测试指标要求指标分类序号指标描述是否需求性能指标需求数值备注2.1 压力模型本次性能测试采用如下的简易压力模型:通过LoadRunner模拟图形终端各柜员向ABS平台发起交易压力2.2 交易选择根据和开发组的沟通，选择如下前端处理比较复杂的典型交易:2.3测试脚本根据上述的系统架构示意图，通过LoadRunner的Socket协议录制柜面前端向柜面系统应用服务器发起的柜面交易，发现Socket交互次数（一组send和receive算一次交互）特别多（0210交易51次Socket交互），而且脚本回放时报接收报文长度不匹配错误。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
LR脚本编写规范 第 1 页 共 21 页 LR脚本编写规范 （V1.0.0） LR脚本编写规范
第 2 页 共 21 页 文档修订历史 版本号 日期 描述 维护人 V 1.0.0 2011-04-17 初稿 王颖 LR脚本编写规范
第 3 页 共 21 页 目录 LR脚本编写规范 ............................................................................................................................ 4 1. 命名规则 .............................................................................................................................. 4 脚本命名规则 ........................................................................................................................... 4 Action命名规则 ....................................................................................................................... 4 事务命名规则 ........................................................................................................................... 4 请求命名规则 ........................................................................................................................... 5 参数命名规则 ........................................................................................................................... 5 2. 脚本结构说明 ...................................................................................................................... 5 3. 请求说明 .............................................................................................................................. 6 4. 优化规则 .............................................................................................................................. 7 LR脚本编写规范
第 4 页 共 21 页 LR脚本编写规范
1. 命名规则 脚本命名规则 LR脚本需存放于英文目录结果中，避免脚本在后续执行中出现异常，为方便管理脚本的命名规则需遵循以下原则： ● 简单准确的概括当前脚本的业务功能； ● 可以是英文描述或是功能拼音首字母组合； ● 全部脚本命名规则需统一； 举例： 信用卡还款，脚本名称可以是CreditCardPayment或xykhk。
Action命名规则
Action的命名规则只是针对于默认生成的Action和自己手动添加的action来说的，需遵循以下原则： （1）Vuser_init: action名称不需要修改； （2）默认生成的Action和自己手动添加的action： ● 以“项目简称_业务简称”命名每个业务action；举例：CEB_xykhk； ● 业务名称尽量与脚本名称统一； （3）如需单独存放脚本中使用函数，新建action命名为：Action_lib； （4）Vuser_end: action名称不需要修改； （5）Globals.h: 名称不需要修改；
事务命名规则
考虑到事务是结果中关注点的特殊性，为方便查看结果事务的命名需遵循以下原则： ● 事务名称需以中文命名，明确表述业务功能； 举例：本行转账_第一次请求,或信用卡还款； ● 若一个功能需多次请求，每个请求需封装成一个事务，每个事务以精简的语言描述对应的动作； 举例：比如明细查询的功能需要经过3个步骤，首先选择账户列表，然后列出每个账户中的余额，然后点击每个账户对应的明细链接，进入明细查询结果界面。这个过程涉及到提交3个请求，每个请求可命名为：账户列表查询，余额查询，明细查询； 原因：虽然每个请求都封装成一个事务，但用户真正想得到相应时间等指标的却可LR脚本编写规范 第 5 页 共 21 页 能是其中某个请求的数据，这时我们可以将前面的其他事务放到初始化中，然后将对应的事务注释掉，方便统计任意一个请求的数据。
请求命名规则
每个业务可能都需要提交多次请求才能最终实现一个完整功能，为了清晰了解每个业务的请求数，每个请求的命名需遵循以下原则： ● 以“ceb_业务简称_请求序号”命名每个请求；举例：ceb_xykhk_1，ceb_xykhk_2； ● 若一个功能需多次请求，每个请求名称和对应的事务名称可以准确的描述出第*次请求是完成了什么功能； 举例：比如“我的账户”模块中的明细查询功能需要经过3个请求，第一个请求（ceb_wdzh_1）完成了（账户列表查询）事务的功能，第二个请求（ceb_wdzh_2）完成了（余额查询）事务的功能，第三个请求（ceb_wdzh_3）完成了（明细查询）事务的功能
参数命名规则
参数的命名考虑到两种种情况，一种是在脚本编写过程中需要方便传递过程变量自己定义的参数，一种情况是需要从服务器返回报文中解析出来然后再组合数据串用于向服务器提交请求的参数，所以对应参数的命名可以分两种种情况： ● 对于第一种情况： 比如服务器返回内容可记为Response； ● 对于第二种情况： 比如需要从服务器返回的报文中取到某个参数，直接用对应的参数名称； 举例：CardNo，PayAmount，action对应的url可记为ceb_xykhk_3url； 概括的说，就是每个参数都需要简单准确的表达变量的功能。
2. 脚本结构说明
每个脚本都由基本的3个action和一个globals.h文件组成，如需单独存放脚本中使用函数，可新建action命名为：Action_lib。 ● 对于vuser_init：： 由于初始化在执行场景中只需要执行一次，一般包含以下内容： （1） 宏定义（#define）常量定义，包含地址，证书路径，算法，消息类型等； （2） 脚本中使用到的变量，结构函数及实体对象； （3） 初始化函数： A. 加载外部的dll文件； B. 为之前定义的变量分配合适大小的内存； C. EWP访问地址； D. 添加报文头信息； E. 握手及前期准备获得加解密的密钥串； LR脚本编写规范 第 6 页 共 21 页 F. 凡是在需要关注的事务之前的一切操作都可以放在初始化中，在第一次脚本编写过程中可仅将登录放在初始化中； G. 函数成功返回标志，Return 0； ● 对于业务action： （1） 对于场景执行前的调试脚本，可将全部业务相关脚本放在主action中，具体执行场景时将业务其他脚本放入初始化中； （2） 每次请求之前需明确列出请求地址，提交参数，接口名称； （3） 拼接提交串后需将转LR_ENC_SYSTEM_LOCALE为LR_ENC_UTF8； （4） 提交串需加密，有时需转URL编码； （5） 基本结构为： 注册函数-----发请求（转码）---判断返回结果中的错误串---没有错误串进行解码—查找内容----给出脚本执行正确的提示 每个块结构加上注释说明，方便阅读； ● 对于函数action： 存放脚本中使用的函数； ● 对于vuser_end： 存放需要释放的变量； ● 对于globals.h： 存放需要引入的头文件，头文件需放在LR安装目录的include中；
3. 请求说明
每个请求之前都需对本次请求做说明，内容包括： ● 请求说明: ****业务第*次请求；
● 请求url：【http://{HostAdress}/ceb_s/prelogin?app=ceb&o=i】； ● 提交数据：参数名：***，【固定数据】，{参数数据}； ● 接口方法：【***】 ● 注意：对于个别参数名称不能明显看出的，比如用n表示userid，我们特别需要指出； 举例： /* 信用卡还款业务第3次请求 请求url:【http://{HostAdress}/atompub_s/form/gdb_xyk_bills?app=ceb&o=i】 提交data： body= CardNo: 信用卡号【lr_eval_string("{account_in}")】 AcctNo: 还款帐号【lr_eval_string("{account_out}")】 Org:币种(人民币)【102】 PayAmount：还款金额【1】 OTPPassword：手机动态密码【111111】 OTPPassType：短信、阳光令牌【SMS】