LoadRunner使用入门 进行Webservice负载測试

1.什么是LoadRunner

LoadRunner是HP公司的一款付费工具，该工具是一种预測系统行为和性能的负载測试工具。

通过模拟上千万用户实施并发负载来确认和查找问题。

2.什么是负载測试

通过測试系统在资源超负荷的情况下的表现。以发现设计上面的错误或验证系统的负载能力。

负载測试的目标是确定并保证系统在超出最大预期工作量的情况下仍能正常执行，还能评估系统的性能特征。

以下介绍一下关于负载測试的几个基本概念：

2.1吞吐率：server并发处理能力的量化描写叙述（单位reqs/s）,单位时间内处理的请求数。

2.2并发连接数：某一个时间点同意最大的请求数量。这个经常使用来衡量系统的并发处理请求的能力，应该区分与以下的并发用户数。

2.3并发用户数：一个用户可能会产生多个并发连接，比如IE8眼下支持6个并发连接。

2.4用户请求平均时间：大量用户请求从发起到接收到处理结果的一个平均时间，在web页面默认不超过3秒是最佳的用户体念。

2.5server平均处理请求时间：处理完毕一个请求所用的平均时间，这个指标可用来衡量业务逻辑复杂度和机器的性能指标。

3.使用LoadRunner进行负载測试具体解释

3.1负载測试目标

在做不论什么事情的时候。都应该三思而后行，明白要达到的目标。然后计划一步一步的达到所定的目标。相同在測试初期我们应该明白定义须要达到的測试目标，比如：我们如今要測试一个调用人力资源数据的WebService接口。我们的重点測试规定时间长度的接口并发处理能力，且接口的单次调用时间不超过3秒。在最大并发用户80最小并发用户20平均并发用户40的情况下进行30分钟的接口调，估计总调用次数10000次，用户平均请求时间不超过5秒。

如何定义以上測试目标的呢？第一、写一个脚本顺序多次调用接口获得一个平均单次调用时间，且这个时间作为基础时间。

第二、最大并发用户、最小并发用户和平均并发用户来自对原有系统的分析。发现人力资源接口在公司中被大量其它系统所訪问经过分析和调查得出最大并发用户80最小并发用户20平均并发用户40的结果。第三、调用次数10000次如何得来。依据设置的3个请求源，分别设置这3个请求開始时间和结束事件计算得来的。如A请求源从0~20分钟并发用户訪问数为20，B请求源并发数为30从10分钟~25分钟，C请求源从15分钟至30分钟，并发用户数为30.

3.2创建负载測试脚本

脚本是用来执行须要測试对象的主要力量。

脚本主要分了3个部分vuser_init和Action和vuser_end这三个部分。vuser_init 是虚拟用户创建的函数，vuser_end是执行结束后销毁虚拟用户的函数，Action是基本的代码执行測试的部分。

Action能够建立多个，每个Action都负责各自的事情。

Action()
{
	//输入字符串
	char input[500]="command=";
	//日志记录地址
	char *address="D:\\LoadRunnerWorkSpace\\RunLog\\log.log";
    	long filename;//定义存储文件指针的变量
	//输入參数，进行了參数化，可以进行配置
	char *cmd = lr_eval_string("{InputParam}");
	//输出參数
	char *out = "";

	lr_start_transaction("init"); //定义初始化事务
	strcat(input,cmd);
	lr_end_transaction("init", LR_AUTO);//结束初始化事务

	lr_rendezvous("beginaction");//事务集结点

	lr_start_transaction("call");//初始化訪问接口的事务

	web_service_call( "StepName=ExecuteCommand_102",
		"SOAPMethod=Test|TestSoap|ExecuteCommand",
		"ResponseParam=response",
		"Service=Test",
		"ExpectedResponse=SoapResult",
		"Snapshot=t1397177849.inf",
		BEGIN_ARGUMENTS,
		input,
		END_ARGUMENTS,
		BEGIN_RESULT,
		"ExecuteCommandResult=outPutParams",
		END_RESULT,
		LAST);

	lr_end_transaction("call", LR_AUTO);//结束訪问接口事务

	lr_start_transaction("log");//初始化记录日志事务
	//获取输入值
	out = lr_eval_string("{outPutParams}");
	//输出信息
	lr_output_message("调用日志|Cmd=%s|Re=%s\r\n",cmd,out);
	//写自己定义日志文件
	if ((filename=fopen(address,"a+"))==NULL)//打开文件
	{
		lr_error_message("can not open this file,address=%s",address);
		return -1;
	}
	fprintf(filename,"调用日志|Cmd=%s|Re=%s\r\n",cmd,out);

	lr_end_transaction("log", LR_AUTO);//结束訪问接口事务

	lr_start_transaction("interval");

	lr_think_time(0.1);  //定义思考时间，思考时间和模拟程序对业务处理事件有些相似

	lr_end_transaction("interval", LR_AUTO);

	return 0;
}

创建完毕脚本之后单次执行该接口查看action程序是否正确，可以正常执行。

假设可以正常执行。进行下一步操作。

3.3运行负载測试（Run Load Tests）

在运行之前（Design）中对我的測试目标的3个请求源进行配置，创建对应的请求场景，这个配置能够在（Interactive Schedule Graph）查看对应请求场景。

配置好之后在（Run）点击Start scenario。

经过漫长的等待測试执行完成。系统自己生成响应的測试结果，泡杯茶小酌一杯呵呵。

3.4运行測试结果的分析（Analyze Load Tests）

导入生成的res1文件，系统会自己主动生成出对应的測试报表。

在Analysis Summary中就能够看出总体的測试结果。

还能够通过查看Running Vusers的情况了解整理的并发訪问情况。

查看Hits per Second，查看每秒的请求数量的走势。

查看Throughput，能够查看整个压力測试过程中处理数据的吞吐量情况，是否达到设计的要求。

查看Transaction Summary。查看整个压力測试的所处理的事务的汇总统计。

查看Average Transaction Response Time ，能够查看整个Action中全部事务处理的时间走势。

4.通过上面的測试结果我们能够判定我们的測试是否满足要求

不要迷信性能測试，全部的性能“系统的性能不是測试測试出来的，而是系统设计出来的。”

LoadRunner能做系统程序的性能測试，在一些大型系统中。可能对系统測试要分为多个目标多个维度，要对硬件架构进行性能測试，对系统进行性能測试，对网络进行性能測试等等多个维度。

性能測试的目的有双方面，第一方面是測试系统是否满足设计要求。第二方面发现系统的瓶颈，为系统优化提出改动建议。