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

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

　 1.什么是LoadRunner

　　LoadRunner是HP公司的一款付费工具，该工具是一种预测系统行为和性能的 负载测试工具。通过模拟上千万用户实施并发负载来确认和查找问题。

　 　2.什么是负载测试

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

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

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

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

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

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

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

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

　　 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() { <span style="white-space:pre">  </span>//输入字符串 char input[500]="command="; //日志记录地址 char *address="D:\\LoadRunnerWorkSpace\\RunLog\\log.log"; <span style="white-space:pre">  </span>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能做系统程序的性能测试，在一些大型系统中，可能对系统测试要分为多个目标多个维度，要对硬件架构进行性能测试，对系统进行性能测试，对网络进行性能测试等等多个维度。

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