Performance 测试也是自动化测试的一个重点领域，了解和掌握这一部分内容，也是完善自动化测试技能的一个补充。Performance测试包含的内容很多，这可以从其支持的协议看出。但日常测试中往往集中在HTML，WebService等协议，这里我将以实际的测试用例来详细介绍如何利用LR（Load Runner）来实现这类Cases的性能测试。先来看几个Cases。
典型案例
关于Web Service的案例，通常我们遇到最多的Cases类似于下面的步骤，这应该是Web Services的标准测试步骤了，也是PT中测试WebService最常用的步骤。先来了解下，后面再来看怎么脚本实现。
1. Case One –
- Step1： Get WSDL from URL、File、UDDI （http://mdm-itg.houston.hp.com:8180/customer-
manager/services/CompetitorService?wsdl） - Step2：Initialize Parameters with Customer IDs
- Step3：Execute Search operation to get the response
2. Case two –
关于HTML的案例，这部分Cases包含的情况很多，主要是因为基于Html的操作很普遍，比喻页面登录，查找，比较，搜索等等，都是常见的测试，这里我也提炼了一些基本的步骤，不一定全面，但却是可以代表很大一部分基于Html操作的PT方案。
- Step1：Get the URL for portal
- Step2：Login with account
- Step3：Initialize with Pramenters
- Step4：Execute Searching and get the response
上面两中情况的性能测试在软件测试中出现的比率很高。熟练理解和编写这类脚本可以让我们轻松对付performance测试中80%以上的Cases. （呵呵。。。别拍砖，个人就是这么认为的）
这部分内容要怎么介绍呢？采取类似于AT的，一个案例一个案例的说比较乏味，也不太容易理解。因为基本上就是脚本代码重复Copy和Review。不具有参考性。还是围绕这两类Cases步骤，以及与其相关的知识点逐一展开吧。
脚本设计
Performance 测试不同于AT，通常我们主张用Recording的办法来录制脚本，这样做不仅可以节省时间，而且对脚本中的各种Action（如 .CSS , .Do，.Json或者Jave Script， Asp等等控件）能够很好的识别。对于脚本的维护也是显而易见的。请看下面的脚本实现。
For Case one –
1.）录制WebService脚本
web_service_call( "StepName=customSearchLookupService_101",
"SOAPMethod=CustomerLookupEnWebServiceService|CustomerLookupEnWebSe
rvicePort|customSearchLookupService",
"ResponseParam=response",
"Service=CustomerLookupEnWebServiceService",
"ExpectedResponse=SoapResult",
"Snapshot=t1395726342.inf",
BEGIN_ARGUMENTS,
"xml:customSearchLookupService1="
"<customSearchLookupService1>"
"<customerId>{CustomerId}</customerId>"
"</customSearchLookupService1>",
END_ARGUMENTS,
BEGIN_RESULT,
END_RESULT,
LAST);注意Web_Service_Call 用法,从面试的语法可知，Web_Service_Call 通常由
ExpectedResponse
specifications
StepName
参数构成，其他的都是optional. 用户可以根据实际情况选择使用。每个参数的定义可以从Help文档中查询，（F1: 查询函数用法）
2.）设置Checkpoint
getValuefromResponse = lr_xml_find("XML={response}",
"Query=/Envelope[1]/Body[1]/customSearchLookupServiceResponse[1]/customerSearchLookup ResultGroup[1]/externalProfileGroup[1]/externalProfileLocatorBusinessLocatorNumber[1]/text()[1]",
"Value=0709898899",
LAST);3.）判断Checkpoint的条件
if (getValuefromResponse == 1){
lr_end_transaction("RequestAndResponse", LR_PASS);
}
else{
lr_end_transaction("RequestAndResponse", LR_FAIL);
}
return 0;录制和设置Chekcpioint部分可以直接使用LR的界面完成，第三部需要手工编写Checkpoint条件。根据函数的语法（参见上面3.2部分内容）其实也不难完成。
Note：再次体会LR C语法的基本特点，每条语句都以分号结束。小括号内的每一参数赋值均已逗号结束，并且每条语句必须以双引号引用起来。引用变量值使用大括号{ }。另外，如果双引号里的内容又是被上引号引用的，那么就需要用反斜杠 “/”进行转换。（这在LR的help文件里有详细说明）
For Case Two –
这部分脚本完全是手工编写的，目的就是如何利用上面介绍的函数来编写LR脚本。（如果可以录制的话，还是建议录制的办法，这里介绍的手工编写代码，仅供那些不能录制脚本的情况作为参考）
1.）Login URL
使用”Action Function – Web_Submit_Data“函数发送URL请求
web_submit_data("login.pl",
"Action=https://it-services-itg.external.hp.com/auth/login.pl",
"Method=POST",
"RecContentType=text/html",
"Referer=",
"Snapshot=t5.inf",
"Mode=HTML",
"EncodeAtSign=YES",
ITEMDATA,
"Name=action", "Value=logon", ENDITEM,
"Name=deviceos", "Value=2.0.0", ENDITEM,
"Name=devicetype", "Value=TouchPad", ENDITEM,
"Name=deviceNDUID", "Value=123", ENDITEM,
"Name=user", "Value=your email address", ENDITEM,
"Name=password", "Value=your nt account", ENDITEM,
"Name=osType", "Value=WebOS", ENDITEM,
LAST);注意相关参数的设置，同样可以参考Help文档设置Web_Submit_Data函数。接下来就是Search操作了，由下面的函数实现。
2.）Search with the specified initialization
web_reg_find("Search=Body",
"SaveCount=findcount",
"Text=SDGT",
LAST);
status = web_url("rplAnywhere-web",
"URL=https://it-services-itg.external.hp.com/onebox/rplAnywhere-
web_1_0_0/services/rpl?name=BIN%20LADEN&countryCode=US",
"Resource=0",
"RecContentType=text/html",
"Referer=",
"Snapshot=t6.inf",
"Mode=HTML",
LAST);对照Web_URL语法，这里对三个必要参数赋值- Step Name, URL 和 Attribute list. 除了这个函数外，还可以用其他函数如 web_submit_data, web_URL 代替。他们都属于Action Function. 同样可达到发送URL请求的目的。
接下来就是Checkpoint检查了，代码如下
3.) Checkpoint Setting and Validation
lr_output_message("request status :%d", status);
lr_output_message("find count :%d", atoi(lr_eval_string("{findcount}")));
if (atoi(lr_eval_string("{findcount}")) > 0){//check the times of finding 'SDGT' string
lr_output_message("found the value at the return page");
lr_end_transaction("AdhocSearching", LR_PASS);
}
else{
lr_output_message("found fail");
lr_end_transaction("AdhocSearching", LR_FAIL);
}
return 0;此处的函数的理解可参考上面的解析。这里不再重复了。到此为止，两种案例的代码实现介绍完毕，是不是还是感觉云里雾里？很正常，这主要是因为LR的C实现函数参数太多，而且使用起来也不是很有感觉。
比喻说调用Web_Custom_request函数发送URL请求。那么函数Web_Custom_request到底该参数化哪些参数？每个参数的值该如何获取？还是没有一个直观的认识。这也是你尽管看了上面那些函数解析后后任然不知所措的根本所在。这是个难点。但我们有办法破解
方法一： 如何识别哪些方法需要被Action Function提取这是手工开发LR代码的必要步骤，你首先要知道哪些页面方法需要被Action Function提取，找出这些方法，然后调用Action Function函数予以实现。难就难在找出这些方法上。看好下面的介绍，解决上面问题的solution就要出来了 – 进入相关页面，进入代码视图，进入Network视图，反复操作页面，看哪些方法的response是关联下一个步骤的。把这些方法提出来，一 一调用Action Function 函数予以实现。 好了这就是要领 。(这里主要是针对record困难的Chrome环境。 按F12进入)不知道？还是不知道？那你打开一个GUI界面（IE或者Chrome都可以）进入代码视图模式，反复进行页面操作（如login），然后在Network视图里看看哪些方法被识别出来了，再看看这些方法的response，有哪些跟下一步骤的界面相关就提出来。这就是Action Function的函数要去实现的步骤。就这么简单。实在不会的话，就按照上面的介绍反复操练吧，知道熟练找出页面方法为止。
方法二： 如何识别哪些方法需要被Action Function提取请使用第三方工具来帮助提取。这里推荐使用Fiddler工具，这个工具可以很方便的看出页面操作对象以及方法属性。用它可以提高我们的代码开发效率，有兴趣的童鞋不妨试试。个人感觉还是不错的。使用它可以帮我们快速找出页面相关元素，以及相应方法，找到这些方法和元素后，跟方法 一 一样，我们需要将这些方法和元素以函数的形式表述出来。
这就是LR C脚本开发应该遵行的规则。当然如果能record的话，还是建议大家record。毕竟系统自动抓出的方法和属性要比手工去添加的来得快和准。
