最近有个性能测试项目，测试对象是用domino 开发的B/S架构的网站系统，网站首页的扩展名是nsf。 第一次录制的时候，采用基于HTML方式录制，录制结束后回放脚本，LR报错，如附图所示。

 

无法生成扩展名为.ci和.cci的文件。

 

遂改成用基于URL的方式录制。再次回放，成功。

 

这是一个非常典型的录制方式选择例子。

当模拟较大数量的并发用户时，单台负载生成器往往是难以满足需要的，容易导致负载机因资源占用过大而成为“假瓶颈” ，这种情况下最好使用多台负载生成器来模拟大量并发用户。如何保证controller与负载生成器连接成功呢？

这并非难事，但仍然有朋友出现这或那的连接障碍。具体问题可以具体分析。这里我提的是必备的前提。

首先，保证controller机与负载生成机之间能ping通，即网络连接畅通。两者之间安装的防火墙不会阻隔54345端口的通信。

其次，在负载生成器上必须运行agent process。运行的方法是：点击loadrunner->advanced settings->agent configuration ， 成功运行后会在右下角生成一个agent process图标

完成以上步骤，就可以尝试在controller里连接指定IP的负载生成器了。

 

正版loadrunner高昂的价格，相信是很多企业望而却步的，大多数的测试人员依然是靠破解版loadrunner来练手。

以本人使用的破解版loadrunner9.0为例，就发生过一件有点意思的事情：
破解步骤此处不详细说了，就说做到最后一步时，要输入licence。破解说明书里提供了两个licence，一个是globe-100的，一个是web-10000的，我输入licence的时候，一古脑儿输入了这两个，loadrunner都提示成功，然后我就心花怒放的等着用。结果却发现，LR的controller不支持多协议录制脚本的回放。百思不得其解啊，明明都有licence了，怎么会不支持呢？

直到后来某一天，我在另外一台机再次安装LR并进行破解的时候才发现，先后输入的两个licence，实际上lr只能保存其中的一个！比如先输入globe-100后输入web-10000，那lr就只保存web-10000的licence，若先输入web-10000后输入globe-100，那就只保存globe-100的licence，两个licence是无法并存的。此前出现不支持多协议脚本回放的原因，昭然若揭——正因为后输入的web-10000 licence覆盖了先输入的globe-100 licence，所以lr不能回放包括web协议以外协议的脚本

近期有一个测试项目是用C#3.5开发的一个报表查询网站，实现方式：Report Viewer控件+ RDLC报表（动态生成图表），数据源是报表服务器上的web service

注：客户端的rdlc报表无法实现打印功能

使用LR录制了一段业务操作：用户使用合法帐号登录网站，登录后会默认显示某报表。由于需要考察这个报表显示时间，所以在此定义了一个login事务。录制到的脚本中有这样一个函数：

web_url("Reserved.ReportViewerWebControl.axd", 
        "URL=http://10.194.159.236/PowerDemandAnalysisSite/Reserved.ReportViewerWebControl.axd?ReportSession=cmif3r55wq1irpnjw4glcsjr&ControlID=a6759610018c4899a8a88bd725aa683f&Culture=2052&UICulture=2052&ReportStack=1&OpType=SessionKeepAlive&TimerMethod=KeepAliveMethodctl00_baseBody_ReportViewerReportsTouchSession0&CacheSeed=Thu%20Jul%2002%2011%3A32%3A43%202009", 
         "Resource=0", 
         "RecContentType=text/html", 
         "Referer=http://10.194.159.236/PowerDemandAnalysisSite/reports/NormalReport.aspx?url=/DMISRS/MainReport", 
         "Snapshot=t5.inf", 
         "Mode=HTML", LAST);

注：ReportViewerWebControl.axd 并非一个页面，它是一个 HTTP Handler（HTTP处理程序）

回放脚本的时候，LR在这个函数处报错，错误码http404。跟开发人员沟通后，初步怀疑原因是这个被reportviewer控件调用的url参数值不能通过ie直接访问，只能通过控件来访问（这个url参数值应该就是结果报表的路径，包含有reportsession、ControlID（控件标识符）、Culture、UICulture、ReportStack等参数），所以致使LR报http404错误代码。但真正的原因是否如此？这样的问题又该如何解决？

有高手前辈指点说让我录制两次脚本，观察控件的参数值是否一致。我连续录制两次后发现果然有两个参数的值不一样：ReportSession 和 ControlID，也就是有必要在此处做手动关联。

解决方案：先去掉recording options里的enable correlation during recording选项，录制脚本后选择vuser-scan action for correlation，LR能自动筛选出需做关联的两个位置，即ReportSession 和ControlID，点击correlation

再次运行脚本，问题解决！：）

 

相关背景知识

http://www.cnblogs.com/1-2-3/archive/2007/09/01/877290.html 《HTTP 处理程序介绍》

http://hi.baidu.com/annleecn/blog/item/ea59b21395fd7dc6c3fd7830.html 《RDLC报表》

http://www.bitscn.com/pdb/dotnet/200904/160906.html 《VS.Net中的水晶报表的应用》

http://tieba.baidu.com/f?kz=336538956  《使用ASP.NET 2.0中的ReportViewer控件》

本文讲述的是用controller设计测试场景，运行模式选择“模拟用户真实场景”，这时如何设置最大quality并发操作的时长duration。

   用LoadRunner做负载测试时，controller默认设置duration=5分钟，这个duration值指的是 最大quality并发运行测试脚本的时长。在实际的项目测试中，我碰到这样的情况：一个asp.net+sql server2005开发的OA系统某查询模块，大约可能发生并发操作的人数在100左右。100人并发运行测试脚本5分钟，5分钟之内OA系统没任何异常，超出5分钟后，OA系统响应部分虚拟用户的页面请求的时间变得很长（以至超时），偶尔OA系统还会报“服务不可用”的错误（http 状态码=503）。这样的效果还是开发人员优化代码调优性能后的最好结果。特别在负责调研用户需求的分析人员也不十分清楚这个模块的并发操作时间会持续多久的情况下，作为测试方该如何判断测试通过？测试人员在设计测试场景的时候，如何设定duration？

若系统能顶过最大quality并发运行duration值指定的时长，就算通过性能测试。

  

   Loadrunner里的思考时间，即用户两种操作之间可能存在的间隔时间，它是决定对服务器施压大小的因素之一。举个例子来说，实际用户在浏览网页时，不可能像机器一样不停的点鼠标向服务器发出各种请求，总会在操作和操作之间有一定的间隔。发出某查询请求后，会查看查询结果（这个时候对服务器未产生任何压力），然后看完了第一页，就会发出看下一页的请求。那这个用户看查询结果所用的时间就是前后两次请求之间的思考时间。

   Loadrunner在录制脚本的时候，会把用户实际操作中产生的思考时间录下来。至于在脚本回放时，采用哪种思考时间策略则需在Run-time Settings－Think Time窗口中设置。选项包括：

Ignore think time：忽略think time，即使录制的脚本添加有think time，脚本回放的时候也不会执行。

Replay the think time：下有３个子项

·As recorded：按照录制到的执行。

·Multiply recorded think time by：录制到的think time乘一个系数，此处指定一个系数

·Use random percentage of the recorded think time：设置思考时间的上限与下限。录制到的思考时间 X 指定的百分比，

·Limit think time to：为think time设置一个上限，不管上面的如何设置，执行的时候，取值都不会操过这个上限。 

一般情况而言，测试脚本执行中包含think time能更接近真实的用户场景。考虑到不同的用户可能产生不同的思考时间（反应快的思考时间短，反应慢的思考时间长），所以我常选择指定上限与下限的百分比，思考时间将在这个范围内随机抽取。

也许将思考时间设置大点，会在一定程度上减小对被测机器施加的压力，但我想，还是从现实的角度去考虑多点，因为只有测试场景尽可能地接近真实用户操作场景，测试结果才更有意义。另外有个使用经验就是，如果录制脚本时定义了多个事务，但最好在事务里插入think time，这样能让不同事务的响应时间曲线能明显的区分开，测试人员可以很方便的看到各曲线的变化趋势。否则响应时间相近事务响应时间曲线会发生重合。但最后统计事务响应时间时，务必记得减去这个think time

  

    测试报告是提供给开发组或其他关注性能测试结果的读者的文档，其核心内容是性能测试用例执行结果的分析。性能测试人员通过对监控数据详细而深入的分析，从而对系统的性能表现做出客观的评价。我所定制的模板内容如下

 

 

 

系统性能测试报告模板

 

 

版本历史

日期	版本	说明	修订人
2008-11-17	1.0	新建	XX

 

1．      编写目的

            描述本篇性能测试报告的涉众利益，即为了什么目的而编写

 

2．      参考文档

列出编写性能测试报告所需的所有参考资料，包括文档的标题、文件编号、版本，以及这些文件资料的来源。

序号	名称/版本	修订日期	来源

 

3．      测试资源

3.1    环境资源

序号	用 途	硬件环境	软件环境

 

3.2    人力资源

工作任务	测试人员	工作日
编写测试计划
设计测试用例
执行测试
编写测试报告

 

 

 

  

 

 

 

4．      术语定义

简要说明本次性能测试中所涉及的专业术语的定义

5．      性能测试用例执行分析

5.1                     预期指标性能测试

5.2                     负载测试(单业务)

5.3                     负载测试(组合业务)

5.4                     评估系统性能测试用例

6．      测试结果综合分析及建议

6.1                     硬件方面

6.2                     软件方面

根据本人所在公司可能有的性能测试目的，我定制了性能测试用例模板，包括三个页签：

1、《预期性能指标测试用例》——用户对系统响应时间提出明确的性能需求，性能测试以验证响应时间是否符合需求为目的，一般测试对象为一些查询、统计模块等（测试时有可能是一个用户，也有可能是多用户并发）。

2、《负载测试用例》——以系统调优为目的做性能测试,通过对系统不断施压,找出系统瓶颈作为调优的依据，包括负载测试（单业务）和负载测试（多业务），测试时必然是多用户并发操作。

3、 《评估系统性能测试用例》——用户未提出明确的性能需求,测试的目的仅仅是对系统做性能评估。测试时将利用LoadRunner的性能指标评估功能。

详细模板内容参见附件，同时也附上测试案例分析图

严格来说，这并非LoadRunner的使用技巧，但我觉得，一个应用程序性能问题的解决方案也应该被收集，下次对其他系统做性能测试若碰到类似的性能问题，可以为开发人员提供一个可行的解决方案。

被测软件用asp.net开发，在对使用率较高的查询模块模拟并发测试时发现，系统不能承受区区20人并发操作查询（数据库记录数达中等规模业务量），报outofmemory内存溢出的异常，系统崩溃，用户无法继续使用。

为了解决这个性能瓶颈，开发人员先后调整查询sql语句，IIS配置，但一直不能解决。最初怀疑是sql查询语句耗费资源太大（监控到的全表扫描率很高）导致内存溢出，但在调整sql语句使全表扫描率大为降低后仍不能解决问题，随后调整IIS配置也于事无补。因为一直查不到原因，所以软件的性能调整一直拖延。不过最终问题还是被解决。导致系统报内存溢出的异常是查询结果分页，开发人员修改代码后系统的性能表现很平稳及优越。修改前后，前台展现方式的区别是：

 

修改前：从数据库里把所有查询结果读出来再分页

修改后：在数据库里对查询结果先做分页然后再显示到客户端

被测系统的导航目录采用树形控件（即TreeView控件），通过展开和折叠各节点，用户可以方便地访问到各级菜单。录制后回放第一次没问题，但再次回放LR报错：Error -27995: Requested link ("Text=娌规枡璐规湀搴︾粺璁?) not found（Text后的乱码是菜单名）。一旦LR出现了这样的错误，就意味着虚拟用户不能访问某个菜单链接，自然也无法做后续的业务操作从而给系统加压。这个报错之所以棘手是因为它不是每次都出现。录制的脚本首次回放一般不出现该错误，再次回放则必然出现。原因不明，也不知道如何杜绝。这种报错很麻烦，脚本必须重新录制了才能回放，导致脚本不可重用。

搜索百度网也查不到解决方案，问题未能彻底解决。

录制包含附件上传功能的web页面操作时会遇到什么样的问题？且看

第6天 关于录制附件上传的问题

被测系统有一个业务模块带有附件上传功能。为了验证部分用户在上传附件的同时，另一部分用户能正常工作，所以在进行组合业务并发用户测试时，选取上传附件这一操作。附件大小限制是200M，录制时上传超过100M的附件，结束录制后LR不能生成相应的Vuser脚本，aciton事务中未生成任何脚本。

无论是重新录制，还是更改设置，始终无法录制出上传>100M附件的脚本。随后将附件大小改为100M以下，此时能够正常录制。导致该现象的原因不明，LR也无任何明显提示。

遗留问题：性能测试有一种是大数据量测试，目的是验证网络传输模块在传输超大文件时的性能以及在大规模数据库里查询时的性能。倘若上传超过100M的附件LR无法正常录制，那也就无法用LR做大数据量测试

事务响应时间(Transaction Response Time)是LR提供的最常见性能指标。通常录制者会将一系列操作定义为一个事务，这是从宏观的角度来说。而从微观来看，事务是若干个客户端请求的集合。那事务响应时间由哪些时间组成？今天我突然问自己，却发现这个看起来最熟悉的字眼，却还未真正了解它……

欲知详情，请看附件

   大多数基于.net平台的系统会有DropDownList控件（下拉选项列表），该组件有一个属性称为AutoPostBack，这是一种数据自动回发机制。当用户更改了下拉选项，系统会自动将新数据提交给服务器端处理，随后刷新客户端页面，显示服务器端回传的处理结果（从原理来说 ，更改下拉选项，会激发SelectedIndexchange事件，事件代码被执行）。

如何成功录制包含DropDownList控件的web程序……

欲知详情，请看图文并茂的附件

LR9.0的手动测试场景界面较前面的版本有所变化。其中测试场景运行模式有了更细的划分：Real-life Schedule  和  Run until complete .

如何根据实际需要选用测试场景的运行模式……

欲知详情，请看附件

在对B/S架构的系统进行性能测试时，为了让测试场景更接近真实的用户使用场景，往往在LR中设置“IP欺骗”。所谓IP欺骗，即每个虚拟用户使用自己的IP地址访问WEB服务器，但实际上这些虚拟用户只运行在一台主机上，共用一个IP地址。

本篇讨论的是在LR启用“IP欺骗”后可能引发的问题。欲知详情，请看附件。

前言

 

写手记的目的就是想把实施性能测试的过程中遇到的一切奇怪、棘手的问题都收录下来，已解决的就附带解决方案，以便保留这样一个学习历程与学习心得。

 

第一天  无法启用IE录制脚本 

 

    今天初次录制脚本，发生了很奇怪的事情，LR捕获不到任何浏览器的行为。并且在LR里已设置在IE中打开指定URL，可LR还是启动TT（腾讯浏览器），结果用户在浏览器上进行的一切操作均无法录制到。最后尝试如此解决：设置IE为操作系统默认的浏览器，然后LR在录制脚本时才会启动IE，继而捕获到浏览器行为。但这并没有从根本上解决问题，无论操作系统指定的默认浏览器是什么，LR应该始终启动指定的浏览器进行录制。但为何设置IE不生效呢？

   

欲知详情，请看图文并茂的附件