HTTP协议性能测试方法.docx
《HTTP协议性能测试方法.docx》由会员分享，可在线阅读，更多相关《HTTP协议性能测试方法.docx（18页珍藏版）》请在冰点文库上搜索。
HTTP协议性能测试方法
HTTP协议性能测试方法
撰写人：
王涛
审核人：
邓雪峰
文档版本：
V1.0
撰写日期：
2012-07-10
测试部
2012年07月10日
目录
一、HTTP协议介绍2
1.1、协议工作原理2
1.2、协议内容3
二、HTTP协议性能测试方法3
2.1、录制前的准备4
2.2、录制及调试脚本4
2.3、设计测试场景8
2.4、测试结果分析13
三、注意事项17
一、HTTP协议介绍
1.1、协议工作原理
超文本传送协议（HTTP）是一种通信协议，它允许将超文本标记语言（HTML）文档从Web服务器传送到Web浏览器。
HTML是一种用于创建文档的标记语言，这些文档包含到相关信息的链接。
您可以单击一个链接来访问其它文档、图像或多媒体对象，并获得关于链接项的附加信息。
HTTP工作在TCP/IP协议体系中的TCP协议上。
客户机和服务器必须都支持HTTP，才能在万维网上发送和接收HTML文档并进行交互。
一次HTTP操作称为一个事务，HTTP协议工作原理可分为四步：
首先客户机与服务器需要建立连接。
只要单击某个超级链接，HTTP的工作就开始了。
建立连接后，客户机发送一个请求给服务器，请求方式的格式为：
统一资源标识符（URL）、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。
服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。
客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客http工作流程图户机与服务器断开连接。
如果在以上过程中的某一步出现错误，那么产生错误的信息将返回到客户端，有显示屏输出。
对于用户来说，这些过程是由HTTP自己完成的，用户只要用鼠标点击，等待信息显示就可以了。
许多HTTP通讯是由一个用户代理初始化的并且包括一个申请在源服务器上资源的请求。
最简单的情况可能是在用户代理和服务器之间通过一个单独的连接来完成。
在Internet上，HTTP通讯通常发生在TCP/IP连接之上。
缺省端口是TCP80，但其它的端口也是可用的。
但这并不预示着HTTP协议在Internet或其它网络的其它协议之上才能完成。
HTTP只预示着一个可靠的传输。
这个过程就好像我们打电话订货一样，我们可以打电话给商家，告诉他我们需要什么规格的商品，然后商家再告诉我们什么商品有货，什么商品缺货。
这些，我们是通过电话线用电话联系（HTTP是通过TCP/IP），当然我们也可以通过传真，只要商家那边也有传真。
1.2、协议内容
HTTP/1.1协议中共定义了八种方法（有时也叫“动作”）来表明Request-URI指定的资源的不同操作方式：
OPTIONS返回服务器针对特定资源所支持的HTTP请求方法。
也可以利用向Web服务器发送'*'的请求来测试服务器的功能性。
HEAD向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。
这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息。
GET向特定的资源发出请求。
注意：
GET方法不应当被用于产生“副作用”的操作中，例如在webapp.中。
其中一个原因是GET可能会被网络蜘蛛等随意访问。
POST向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。
数据被包含在请求体中。
POST请求可能会导致新的资源的建立和/或已有资源的修改。
PUT向指定资源位置上传其最新内容。
DELETE请求服务器删除Request-URI所标识的资源。
TRACE回显服务器收到的请求，主要用于测试或诊断。
CONNECTHTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
方法名称是区分大小写的。
当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405（MethodNotAllowed）；当服务器不认识或者不支持对应的请求方法的时候，应当返回状态码501（NotImplemented）。
HTTP服务器至少应该实现GET和HEAD方法，其他方法都是可选的。
当然，所有的方法支持的实现都应当符合下述的方法各自的语义定义。
此外，除了上述方法，特定的HTTP服务器还能够扩展自定义的方法。
二、HTTP协议性能测试方法
针对HTTP协议的特性，我们在录制其方法和报文的过程中，选取了LoadRunner这个工具，下面介绍我们利用LR如何录制和编辑HTTP协议的测试脚本。
2.1、录制前的准备
在录制脚本前需检查压测环境的整体功能是否正确，待测部分的功能是否正确，只有确保功能正确后才可进行压测。
如本次测试，可先验证环境是否正常，应用服务器是否正常，等等，一切确定OK后，开始验证功能，这些都保证没有问题后，检查一下测试工具LoadRunner是否正常使用，可简单的点点用用，确保工具OK。
2.2、录制及调试脚本
（1）、在VuGen的主界面中，选择菜单“File|New”，参见下图
（2）、在界面中选择“Web（HTTP/HTML）”协议。
然后单击“creat”按钮，则出现如下图所示的界面。
在这个界面中可录制HTTP/HTML的测试脚本。
（3）、单击“StartRecord”，出现如下图所示的Web服务管理界面。
图中的URLAddress输入待测的网址，在RecordintoAction中选择Action，把登录部分放在vuser_init中，退出部分放在vuser_end,vuser_init与vuser_end在测试过程中仅执行一次，这里解释一下，Action的作用是讲测试功能主体放在里面执行。
具体业务操作放在Action中，这样，我们将压力集中在业务操作上，而不是登陆退出上。
（4）、录制脚本
设置好后，点【OK】，进行录制，在录制前，如果已经打开待测页面的话，建议关闭该页面，并且确保ie浏览器→internet选项→高级→启用第三方浏览器前面的对勾取消，点【OK】后，这时会出现待测页面http:
//10.10.71.238:
8080/hispub?
method=sendMessage，同时会出现
这就表示录制开始了，在每一个动作的开始前点击
并输入事务名称，在需要定义事务的操作后面插入事务的“结束点”
，当LoadRunner运行到该事务的开始点时，LR就会开始计时，直到运行到该事务的结束点，这个事务的运行时间在结果中会有反映。
为了衡量服务器的性能，必须要定义事务。
插入集合点是为了衡量在加重负载的情况下服务器的性能情况。
在测试计划中，可能会要求系统能够承受1000人同时提交数据，在LR中可以通过在提交数据操作前面加入集合点，当虚拟用户运行到提交数据的集合点时，LR就会检查同时有多少用户运行到集合点，从而达到测试计划中的需求。
具体的操作方法如下：
在需要插入集合点的前面，点击菜单InsertRendezvous，也可在录制时按插入集合点按钮
注意：
集合点经常和事务结合起来使用。
集合点只能插入到Action部分，vuser_init和vuser_end中不能插入集合点。
所有操作完成后，点击中停止按钮
，停止录制，页面将自动关闭，返回到loadrunner录制界面，将在界面中显示录制脚本代码，保存录制的脚本。
（5）、参数化设置
录制后的代码需要进行调试才可用于压测，调试的办法就是进行回放操作，如果回放过程无错误，运行结果也正确的话，则可用于压测。
具体调试步骤如下：
点击界面中的，进行单次运行调试，运行后，会弹出运行预览的一个窗口，可以看到每一个Action的执行过程，
运行结束后，会出现一个结果报告，如果有错误，会在报告中以红色叉标志显示出来，同时在Executionlog中也会打出错误信息，可以根据这些错误信息进行调试。
如果无错误，则可进行插入事务、参数化设置等其他操作。
现假设调试无错误，进行参数化设置。
在测试过程中，有可能需要不同的id、sequence、session等等，如果有同样的号码将导致测试失败，因为相同的号码不能做同样的业务操作多次，所以需要大量不同的测试号码，这个就需要用到参数化设置。
我们在编写测试方案的时候，已经得出要准备多少测试号码，在测试工作准备的时候，已经准备好测试号码，那么可以利用这些准备的号码进行参数化设置。
参数化设置的意思就是将需要用其他数据代替的地方设置为一个参数，在运行时读到这个参数，就使用其他的值代替。
有三种方法进行参数化：
a．在界面中点击
，或者快捷键ctrl+L，弹出如下界面
在这个界面中，点击左边的New，创建一个新的参数，在界面的右边，Parametertype选择File，Filepath选择存放号码的dat文件路径，选定文件后，会在下面的表格中列出测试号码，我们在Selectnextrow中选择Unique，这个表示整个测试过程仅使用唯一的号码，保证号码不重复，这样就要号码资源足够多，同时测试时间也需要控制好，否则会报错。
创建好参数后，返回到刚才录制的脚本中，找到对应的Action，选择该empi_id，右键选择“Replacewithaparameter”，在Parametername的下拉列表中选择需要替换的参数empi_idV，选定后点击OK；设置OK后，可进行调试，如无问题，则可以进行场景的设置。
这里有个注意点要说明一下，参数化也可以直接在脚本中选中需替换的地方，点右键，选择“Replacewithaparameter”，改更Properties进行设置，但这样做经常出问题，不容易调试，不建议这样做。
b.在globals.h定义一个初始定量intempi_id=1,返回到刚才录制的脚本中加入下列代码：
empid=++empid;
lr_save_int（empid,"empidV"）;//全局变量统一+1，并转换成可以利用的参数。
并将全文中需要参数化的empi_id全部转换成{empidV}。
c.在脚本回放过程中，客户端发出请求，通过关联函数所定义的左右边界值（也就是关联规则），在服务器所响应的内容中查找，得到相应的值。
可在action中手动写入下列函数:
web_reg_save_param（"empi_idV","LB=","RB=","Notfound=error","Search=Body",LAST）;譬如在response的页面中需要获得id号443214，"LB=","RB="，这样443214就被获取出来，并存入参数empi_idV中了。
这里需要注意的问题是对关联参数相关的操作,需要放到包含该关联数据的请求函数之后,都需要放到web_request（）之后,否则也不会取到关联的数据，可通过打印函数进行验证lr_output_message（"返回的empid值为：
%s",lr_eval_string（"{empidV}"））；还有就是web_set_max_html_param_len（）函数可以自定义关联返回值存放的参数的最大长度，记得一定要写在关联函数前面；例web_set_max_html_param_len（"1024"）;
（6）、插入Text/Image检查点
在进行压力测试时，为了检查Web服务器返回的网页是否正确，这些检查点验证网页上是否存在指定的Text或者Image，还可以测试在比较大的压力测试环境中，被测的网站功能是否保持正确。
操作步骤:
可以将视图切换到TreeView视图；
在树形菜单中选择需要插入检查点的一项，然后点鼠标右键，选择将检查点插到该操作执行前（InsertBefore）还是执行后（InsertAfter）；
在弹出对话框中选择webChecks下面的ImageCheck或是TextCheck；
对需要检查点设置相关的属性。
2.3、设计测试场景
在脚本录制完成，调试通过后，可以进行测试场景的设计。
具体步骤如下：
（1）、打开“tools－>creatcontrollerscenario”参见下图，填写并发数后，点击ok。
●ManualScenario：
该项要完全手动的设置场景；
●PercentageMode：
该项只有在“ManualScenario”选中的情况下才能选择。
选择该项后，在场景中我们需要定义要使用的虚拟用户的总数，LoadGeneratormachine机器集，然后我们为每一个脚本分配要运行的虚拟用户的百分比；
●Goal—OrientedScenario：
在测试计划中，一般都包括性能测试要达到的目标。
选择该。
项后，LoadRunner基于这个目标，自动为你创建一个场景。
在场景中，我们只要定义好我们的目标即可。
这里默认选择ManualScenario，无需勾选PercentageMode；
选择需要运行的场景，点击add后，ok进入下一步。
（2）、下图中的ScenarioGroups，显示的是脚本的路径与并发数个数，根据测试方案中的并发数可更改此处的并发数，loadgenerators添加一平台为windows的localhost本地用户。
双击StartVusers后：
双击duration后：
双击stopvusers后：
举个例子，假如我们设计的场景是每15秒增加2个，所有并发数增加完后持续运行5分钟，5分钟运行结束后，每30秒减少5个并发，则上面三张图的设置就行了。
（3）、在脚本scriptpath的位置点击右键出现“Run-timeSettings”，出现下图
选择图中的ThinkTime，在右边选择Replaythinktime，再勾选中Limitthinktimeto：
1seconds，表示即使脚本thinktime时间可能超过1秒，也用1秒替换，可以自行调整这个时间。
这样做的目的是在测试过程中使得每个业务操作里加上thinktime，表示用户在操作的时候，有个时间延迟，真实的模拟用户的操作，比如用户在做产品转换的时候，可能在选择产品的时候，有个停顿思考的时间，这样loadrunner会记录下来。
如果选择Ignorethinktime，这样对服务器造成的压力是最大的，在运行时，会没有停顿的，持续对服务器加压，不太符合实际使用情况。
（4）、一切设置OK后，在run界面，点击startscenario，运行测试场景，如下图
在图中的左边可以查看并发用户数的运行情况，右边可以查看通过的事务数、失败的事务等，如果运行过程中有错误出现，则可以点击Errors右边的放大镜，查看详细错误信息。
窗口下面是各种监控窗口，RunningVusers展示的是目前并发用户数的运行情况，TransResponseTime表示的是事务的响应时间，即每个事务处理的时间是多少秒。
2.4、测试结果分析
场景执行结束后，可以使用loadrunner自带的分析工具进行结果分析，这里我们主要考察三个地方，第一是平均事务响应时间AverageTransactionResponseTime（响应时间<5s，则满足基层文件传输的标准线）第二是并发数运行情况RunningVusers，这两个显示了场景运行过程中并发数的执行情况与每笔事务的处理时间。
第三是TransactionPerSecond（简称TPS），tps是否满足要通过计算来验证，还有其他几个考察点，这里不做解释。
在图中的菜单栏中点击Results，选择analyzeresults，直接收集场景运行结果进行分析。
打开执行结果后是如下界面
界面左边是各个指标的列表，右边是图形的显示，下面是指标对应的采集数据。
接下来将重点选择几个指标做解释。
（1）、并发数执行情况（RunningVusers）
并发数执行情况反映了在场景执行过程中各个并发数的运行情况，成功了多少，失败了多少，是否按照既定的场景执行计划运行，是否达到预期的执行效果，如果在某个时间，执行失败了，或者存在异常，那么并发数的图表将是波动，可以从图中直观的看出来，同样根据场景中Error的信息，定位在何时出现了错误，此时执行的并发数是多少。
并发数的图表如下：
（2）、吞吐量（Throughput）
吞吐量的意思是指单位时间内系统处理的客户请求数量，直接体现软件系统的性能承载能力，如果随着场景执行时间的推延，承载能力应该是平缓的，如果突然上升，则可能是服务不稳定，或者网络因素导致的，如果持续下降，则表示服务的处理能力在下降，此时可以查看服务器段是否有进程堵塞，或者服务器的连接数不够，也可能是网络带宽不够。
事务通过数的图表如下
（3）、平均事务响应时间（AverageTransactionResponseTime）
平均事务响应时间在整个测试过程中是一个很重要的参考指标，他能清晰的反映出场景执行过程中，每个事务的执行时长，整个业务中哪个操作最耗时等等。
场景执行结束后，可以根据这个图表分析出在一定响应时间要求下，系统可支持的并发数，假如我们要求在查询的时候要求这个返回结果的时候不超过5秒，那么可以在场景中找到对应的事务在处理时间为5秒左右的时间点，再从RunningVuser图中找到对应的时间点，查看对应的并发用户数。
同样，在整个执行过程中，当并发数达到一定数值后，平均事务响应时间曲线应该是平缓的，如果出现突然升高或者降低的情况，则表示系统存在异常，这样我们可以找到这个时间点去查看服务器端的运行日志，查找原因。
平均事务响应时间的图表如下：
（4）、每秒通过事务数（Transactionpersecond）
TPS指应用系统每秒钟处理完成的交易数量是估算应用系统性能的重要依据。
一般而言，评价系统性能均以每秒完成的技术交易的数量来衡量。
系统整体处理能力取决于处理能力最低模块的TPS值。
举个例子，一个普通的查询包含10个事务，去年一年里某天的最高的查询最高为10万次，10万*10个事务/（每天工作8h*3600秒），计算的结果为34.7，所以在TPS必须大于等于34.7，否则我们的系统将不会满足需求。
（5）、服务器资源分析
服务器资源监控利用的是nmon工具，在得出分析结果后，可以查看对应的图表进行分析。
三、注意事项
整个测试过程是有序的，需要事先计划好，在录制脚本，调试脚本的时候需要注意的是要单个脚本的调试，不可一次把参数都跑完，这样不经济。
这里仅仅介绍了简单的测试流程，更深刻更精妙的功能未能列出，请自行学习。
升级会员 