天行健,君子当自强不息

天行健的博客已经正式搬家, 新的博客基于WordPress2.1.1构建,空间由www.phpnet.us免费提供.
域名是:www.rickyzhu.com

新博客的目标:
创建国内知名的个人测试博客.结交广大热爱测试,有志于从事测试的朋友.

几大国外免费主机托管

我以为可以彻底抛开和放弃Blogger了,因为之前找到了几家比较好的国外免费主机托管网站, 但是试用这几天给我的第一感受就是一个字: 免费的东西就是不稳定.


前后试用了N多个,包括kingofhosts.com, my-php.net, prehost, awarespace, 9999mb等等,发现所有的免费托管格式几乎千篇一律,引用chinalong兄弟的一句话"不知道他们在搞什么名堂".

连注册的程序几乎都一摸一样,都说中国人喜欢模仿,看来也不完全是这样啊, 另外, 对于网站的管理大都基于统一的模式,而且基本都有快速安装工具,可以快速建立基于WP或者其他主流论坛的能力.这的确可以省去建站所花费的时间,而且支持的空间也超级大,从几十G到几百G多少不一,另外,对于二级域名和顶级域名的支持也是出奇的一致. 真的是让我这样的新手不知如何取舍.

可惜最致命的是对于免费用户的支持都是有限的,而且稳定性没有保证,反反复复折腾吧. 郁闷.看来要想得到稳定可靠的服务和支持还要付出真金白银呐.

真要好好考虑考虑了.

--end

搬家完毕

本博客已经搬家,请访问基于WordPress的站点http://www.rickyzhu.com查看最新的文章和系列.

另外,感谢这个搬家插件,使我的所有文章都能顺利搬家到新的站点.


--以此纪念在blogspot的三个月--


--end--

基于WP架构的个人网站已经建立

今天下午,花费了三个小时左右,基于WordPress架构的个人网站rickyzhu.com已经建立完毕.

现在打算把基于Blogger的这个博客移植到www.rickyzhu.com去,发现WP提供很多其他blog站点的导入功能,其中就包括blogger,不过好像目前只支持旧版本的blogger,也就是用blogger账号,而非google帐号登陆的blogger,看来我的这个站点要搬家还要另外想想办法了....

打算把目前这个站点搬过去之后,年后就开始在新的网站开始经营了,欢迎新老朋友过去捧场.个人站点的空间是kingofhosts免费提供托管,由WordPress提供技术架构的.

我申请域名的时候用的是rickyzhu.com,好像rickyzhu.com已经和rickyzhu.kingofhosts.com绑定,并且由kingofhosts提供空间托管,不过www.rickyzhu.com好像指向的是另外一个网站,不知道为什么,在kingofhosts里面好像提供修改的地方,不过已经修改不过了,哪位高手指点一下? 另外,Kingofhosts是一个国外的网站,可能访问的时候时好时坏,不一定有国内付费的空间那么稳定,没办法,穷啊,暂时只能这样了,而且kingofhosts也是提供了一个很简单的页面底部的广告.

--end

新域名得到启用

Google Blogger的免费域名绑定服务被封之后，我一直在寻找可以免费托管或者免费域名绑定的服务，现在最终有了结果，kingofhosts提供这个功能，而且功能非常全面，最重要的是全免费，提供的服务如下：

Features

KingofHosts has industry leading features that will allow you to build a website above and beyond your competitors, take a look at some of them:

• 1,000mb Disk Space 8,000mb disk space (8gb!)
• 10,000mb Bandwidth 50,000mb bandwidth (50gb!).
• NO ADVERTISEMENTS on your pages!
• FREE subdomain (yourname.KingofHosts.com)
• Easy to use WYSIWYG editor
• Full FTP Support
• PHP 4 Support
• 1 mySQL database 10 mySQL database's
• Instant activation
• Domain name support
• 99.9% Uptime
• and MORE...

您不妨试试，现在我的新域名

rickyzhu.com
或者
rickyzhu.kingofhosts.com

两者都是可以的，目前在暂时将她们重定向到目前这个Google的博客。

















--end

儿子能独自站立了

小猪猪的成长之路

大年初二，小猪猪今天已经满九个月了，可以扶着沙发自己独立行走了，回想起小猪猪的成长经历，从第一声啼哭，第一次主动微笑，第一颗牙齿，第一声爸爸... 一幕一幕仿佛就在眼前，这里把小猪猪每个月有代表性的照片排列在这里，以示留念。



九个月

七个月（脸上还有些湿疹）

六个半月（湿疹比较严重）










六个月














四个月



















百日留影


















三个月










一个月




















第一周


--end

LoadRunner性能数据结果分析连载(引言)

HP Mercury LoadRunner 是一款功能相当强大的性能测试工具,由三个部分构成, VUGen, Controller以及Analysis. 其中VUGen负责进行脚本录制, Controller是一个总控中心,负责场景的配置,监控器的选取和监控,并选择合适的负载生成器进行执行, Analysis是一个分析模块,主要负责所有执行数据的分析以及报告的生成.
之所以说LoadRunner是强大的性能测试工具,主要是因为VUGen支持大概好几十种主流的协议. 因此支持的被测对象相当广泛,另外Analysis也有超强的功能,提供非常丰富的图表,供测试结束之后分析和定位问题.
我使用Mercury LoadRunner有一年左右,2006年6月通过了LoadRunner的SP考试,并于12月底参加了CPC考试,以2分之差失败. 在这一年之内对Controller和Analysis的使用有一些心得和体会,大概能看懂一些主要的分析图表,包括事务相关的一些图表,所以希望作一个总结,对希望学习和了解LoadRunner的朋友有一些帮助. 因为时间有限,所以初步打算以系列的形式发表. 下次打算介绍Analysis提供图表的概述.

--to be continued

Andy Mckee

好牛的吉他弹奏.

软件测试自动化之实践

我之前写过几篇原创的关于自动化测试的思考和总结,今天整理资料的时候发现这篇文档,涉及到实施自动化测试的切入,自动化测试的适应范围,自动化测试的环境,自动化测试的开展,甚至自动化测试的风箱评估等等,这篇文档系统的阐述了这些重要内容,给自动化测试的开展提供了一些理论方面的指导,跟我的前面几篇文档有异曲同工之处,可以做为一个补充和参考.

一、概述

软件测试自动化，从计算机这一庞大学科发展至今，最根本的意义是解决手工劳动的复杂性，成为替代某些重复性行为模式的最佳工具。

二、实施软件测试自动化的理由

1. 提高测试效率和降低测试成本

2. 将重复性强的测试由手工转为可以独立开来自动实现的。

3. 实现快速的回归测试，提高新版本发布的速度和质量，尤其是不能适应目前流行的迭代开发，回归测试频度高、工作量大，人工的测试很难对新的迭代版本作出快速评估。

4. 自动测试可以避免，人工测试容易犯的错误：错误测试、漏测试、多测试和重复测试等

5. 典型的应用，例如多用户并发注册、并发交易请求和并发交易应答，这种情况用人工测试几乎是办不到的，而自动测试却很容易。

6. 对于很常用的功能性边界测试测试，人工测试非常耗费时间，而自动测试很快且准确。

可以说，实施测试自动化是软件行业一个不可逆转的趋势，如果在这个领域走在了前列，无论从企业的核心竞争力还是个人的工作技能来说，都有巨大的优越性。

三、软件测试自动化的引入条件

自动化测试能大大降低手工测试工作，但决不能完全取代手工测试。完全的自动化测试只是一个理论上的目标，实际上想要达到 100% 的自动化测试，不仅代价相当昂贵，而且操作上也是几乎不可能实现。一般来说，一个 40-60% 的利用自动化的程度已经是非常好的了，达到这个级别以上将过大的增加测试相关的维护成本。

测试自动化的引入有一定的标准，要经过综合的评估，绝对不能理解成测试工具简单的录制与回放过程。实际上，从实现成熟度来说，自动化测试分五个级别：

级别	说明	优点	缺点	用法
一级	录制和回放	自动化的测试脚本能够被自动的生成，而不需要有任何的编程知识	拥有大量的测试脚本，当需求和应用发生变化时相应的测试脚本也必须被重新录制	当测试的系统不会发生变化时，实现小规模的自动化
二级	录制、编辑和回放	减少脚本的数量和维护的工作	需要一定的编程知识；频繁的变化难于维护	回归测试时，用于被测试的应用有很小的变化
三级	编程和回放	确定了测试脚本的设计，在项目的早期就可以开始自动化的测试	要求测试人员具有很好的软件技能，包括设计、开发	大规模的测试套件被开发、执行和维护的专业自动化测试
四级	数据驱动的测试	能够维护和使用良好的并且有效的模拟真实生活中数据的测试数据	软件开发的技能是基础，并且需要访问相关的测试数据	大规模的测试套件被开发、执行和维护的专业自动化测试
五级	使用动作词的测试自动化	测试用例的设计被从测试工具中分离了出来	需要一个具有工具技能和开发技能的测试团队	专业的测试自动化将技能的使用最优化的结合起来

自动化测试能提高测试效率，快速定位测试软件各版本中的功能与性能缺陷，但不会创造性的发现测试脚本里没有设计的缺陷。测试工具不是人脑，要求测试设计者将测试中各种分支路径的校验点进行定制,没有定制完整，即便事实上出错的地方，测试工具也不会发觉。因此，制订全面、系统的测试设计工作是相当重要的。

自动化测试能提高测试效率，但对于周期短、时间紧迫的项目不宜采用自动化测试。推行自动化测试的前期工作相当庞大，将企业级自动化测试框架应用到一个项目中也要评估其合适性，因此决不能盲目的的应用到任何一个测试项目中，尤其不适合周期短的项目，因为很可能需要大量的测试框架的准备和实施而会被拖跨。

实施测试自动化必须进行多方面的培训，包括测试流程、缺陷管理、人员安排、测试工具使用等。如果测试过程是不合理的，引入自动化测试只会给项目团队带来更大的混乱。

那么应该具备什么样的条件才可以引入自动化测试呢，才可以最大可能的减少引入风险，并能够可持续性的开展下去呢？

第一，从项目规模上来说，没有严格限制。无论项目大小，都需要提高测试效率，希望测试工作标准化，测试流程正规化，测试代码重用化。所以第一要做到的，就是从公司高层开始，直到测试部门的任何一个普通工程师，都要树立实施自动化测试的坚定决心，不能抱着试试看的态度。一般来说，一个这样的软件开发团队可以优先开展自动化测试工作：测试与开发人员比例合适，比如1：3到1：5，开发团队总人数不少于10个。

第二，从公司的产品特征来说，一般开发产品的项目实施自动化测试要比纯项目开发要优越些。但决不是说做纯项目开发不能实施自动化测试，只要软件的开发流程、测试流程、缺陷管理流程规范了，自动化测试自然水到渠成。

第三，从测试人员个人素质和角色分配来说，除了有高层重视外，还应该有个具有良好自动化测试背景和丰富自动化测试经验的测试主管，不仅在技术方面，更重要的是在今后的自动化测试管理位置起着领导的作用。还要有几个出色的开发经验良好的测试人员，当然也可以是开发工程师，负责编写测试脚本、开发测试框架,还有一些测试执行者，他们要对软件产品业务逻辑相当熟练，配合测试设计者完成设计工作，并在执行自动测试时，敏锐的分析和判断软件缺陷。

综合分析上述三个条件，就可以决定是否推行自动化测试；但是为了减少实施风险，还要预测到其他潜在的风险，做好事先解决问题规避风险的思路。

四、对实施自动化测试的风险分析

资金风险，虽然有些项目具备实施自动化测试的条件，但还是要引入自动化测试后组织结构调整等方面的成本估算是很必要的。

自动化测试对软件功能类型的切入点的风险，开发的产品业务和功能是否需要自动化测试？包括白盒自动化测试、功能自动化测试和性能自动化测试。

软件自动化测试切入方式的风险，一定要将自动化测试与手工测试结合起来使用，不合理的规划会造成工作事倍功半。首先，对于自动化测试率的目标开始是 20/80 （20% 的自动化测试和 80% 的手工测试），当这些目标都实现了，再将自动化测试率提高。

时间估算，在评估完前面几项指标后，需要估算实施测试自动化的时间周期，以防止浪费不必要的时间，减少在人员、资金、资源投入上的无端消耗。虽然到测试自动化步入正轨以后，会起到事半功倍的效果，但前期的投入巨大，要全面考虑各种因素，明确实施计划并按计划严格执行，才能最大限度降低风险。

工作流程变更风险，测试团队乃至整个开发组织实施测试自动化，或多或少会因为适应测试工具的工作流程，带来团队的测试流程、开发流程的相应变更，而且，如果变更不善，会引起团队成员的诸多抱怨情绪；所以应该尽量减少这种变更，并克服变更中可能存在的困难。

五、什么条件下使用自动化测试

一般在这样的条件下使用自动化测试

l 具有良好定义的测试策略和测试计划（知道要测试什么，知道什么时候测试）

l 对于自动化测试你拥有一个能够被识别的测试框架和候选者

l 能够确保多个测试运行的构建策略

l 多平台环境需要被测试

l 拥有运行测试的硬件

l 拥有关注在自动化过程上的资源

如下条件下是宜采用手工测试：

l 没有标准的测试过程

l 没有一个测试什么、什么时候测试的清晰的蓝图

l 在一个项目中，测试责任人是一个新人，并且还不是完全的理解方案的功能性和或者设计

l 整个项目在时间的压力下

l 在团队中没有资源或者具有自动化测试技能的人

六、各测试阶段的自动化测试评估

测试阶段	描　　　　　　　述	备　　　　注
单元测试/ 组件测试	这个测试工作通常是开发人员的职责，很多不同的方法能够被使用，比如"测试先行"，它是一个测试框架，开发人员在编写代码前编写不同的单元测试，当测试通过时，代码也被完成了。	通过使用正式的单元测试，不仅能够帮助开发人员产出更加稳定的代码，而且能够是软件的整体质量更加的好。
集成测试	这里的测试工作集中在验证不同的组件之间的集成上。	这种类型的测试通常是被测试系统的更加复杂测试的基础，大量的边缘测试被合并以制造出不同的错误处理测试。
系统测试	这种测试是通过执行用户场景模拟真实用户使用系统，以证明系统具有被期望的功能。	这里不需要进行自动化的测试。安装测试、安全性测试通常是有手工完成的，因为系统的环境是恒定不变的。
其它两种非常重要的测试
回归测试	回归测试实际上是重复已经存在的测试，通常如果是手工完成的化，这种测试只在项目的结尾执行执行一到两次。	这里完全有潜力应用自动化的测试，能够在每次构建完成后执行自动化的回归测试，以验证被测试系统的改变是否影响了系统的其他功能。
性能测试	性能测试包括以下不同测试形式： - 负载测试 - 压力测试 - 并发测试 -.....	使用自动化的测试工具，通过模拟用户的负载实现的高密集度的性能测试。

--end

LoadRunner的工作原理(第二部分)

LoadRunner Internal Architecture This Visio 2002 file is based on LR8.0

application servers under test are placed under stress by driver processes mdrv.exe (the Multi-threaded Driver Process) and r3vuser.exe which emulate application clients such as Internet Explorer web brower. It performs 3 main actions: Kli> cpp (C language pre-processor) cci (C pre-compiling) which creaes a file with ci file, and execute using the driver for the protocol technology being tested. Runs can be invoked to run "silently" by invoking Mdrv.exe from a Windows batch script. Mdrv can automatically stop loading Vusers because they communicate with Vusers and monitor CPU usage on Windows Load Generator machines. A separate JVM is instantiated by each Java-based Vuser on Windows-based machines. Java Vusers are not supported on Unix platforms. virtual Vusers are invoked as groups (logical collection of virtual users running the same script on a specific load generator machine) by agents (3,900K magentproc.exe) running as a service or as a process on load generator client machines. Each machine hosting agents maintains an Execution Log in a .qtp file. When logging is enabled, the agent also creates within the results folder a sequential log file for each Vuser (segregated by Vuser group). During execution, this file is displayed in the view > Show Output window on the LoadRunner Controller machine. Upon a pre-set delay, the Scheduler running on a Controller machine instructs agents (via Windows port 54345 or dynamic Unix port) to initiate test session scenarios. The Controller (wlrun.exe) sends a copy of scenario files along with the request. Agents are launched by the Remote Agent Dispatcher process (formerly called Remote Command Launcher (RCL)) on each load generator machine. Each agent refer to scenario (.lrs) definition files to determine which Vuser groups and scripts to run on host machines. This means the Controller can be started from a DOS batch (.bat) file (preferrably with a short name on a root drive): REM Start Controller: SET M_ROOT=C:\Program Files\Mercury Interactive\LoadRunner\bin cd %M_ROOT% wlrun.exe -TestPath D:\Dev\Dev1.lrs -port 8080 -Run -DontClose pause Press Ctrl-Z to keep this window or Including the -Run parameter is the same as manually pressing the "Start Scenario" automatically upon invocation. This is not a good idea because you may have to decide about collating the file from a previous run or want to change the output folder. This assumes that the system's environment PATH variable was updated to include where LoadRunner is installed.

The Controller is invoked using parameter values within files in the Windows OS folder (WINNT for Windows 2000 and WINDOWS for Windows XP). The Windows folder is used because LoadRunner is designed to have only one instance of Controller running at a time on a machine. To quickly switch among several applications, save a copy of LoadRunner's ini files after working on it within the Controller, then use Notepad to craft a batch file to copy application-specific versions of ini files before executing wlrun. An example of file copy actions for application XXX: copy %WinDir%/wlrun7-XXX.ini %WinDir%/wlrun7.ini copy %WinDir%/wlrun7-XXX.dft %WinDir%/wlrun7.dft Some defaults you might want to change: In the wlrun7.ini file file [output] section, MaxNumberOfOutputMessages= from 10000 to 100000 for long runs. This limits the number of output messages stored in the database. MaxOutputUIRowsToShow limits the amount of messages/errors (lines) displayed in the Controller's Output window. In the QTWeb.lrp file within the LoadRunner Program Files dat\protocols folder section [Vugen], add entry MaxThreadPerProcess=5 to limit the number of threads managed by each load generator mdrv.exe process. Values for DefaultScenarioDir, DefaultScriptDir, DefaultResultDir, and [Recent File List] stored in the wlrun5.ini and wlrun7.dft files updated whenever values are changed within the Controller. The blocks of actions taken by each Vuser are defined in Vu scripts created using Loadrunner's VuGen.exe. When this program is invoked, it stores in the Windows folder a comparamui.INI file to save under "[LastTablesUsed]" a history of files and [ParamDialogDates] specified using menu option Insert > New Parameter > Dates. VuGen stores and retrieves a vugen.ini file in the Windows folder. When using Java, enable additional debug options: [DynaDlg] JavaLevel=3 When using 8.0 scripts within VuGen 8.1, add to Vugen.ini: [Editor] OLDEDITOR = 1 VuGen opens in LR folder template/qtweb default.cfg and script files. Vu scripts can be coded to use variable values obtained from parameter files external to the script. I have a lot more on VuGen here During a run, execution results are stored to a results folder. I prefer to set Results Settings to "Automatically create a results directory for each scenario execution." which means that LR will increment the name of the Results Name when I start a scenario runs. For example, a value of "Res11" will be automatically incremented to "Res12" or sometimes "Res11-1". Errors are written to the output.mdb MS Access database. See the ASP page I have written to access this database Within each results folder, a "Log" folder is automatically created to contain a log file for each group. After a run, to view a log file from within the Controller, click then right-click on a group to select "Show Vuser Log". As a scenario is run, monitors maintain counters locally on each host. After a run, the "collate" process takes .eve and .lrr result files and creates in the results folder a temporary .mdb (MS-Access) database. To prevent errors when processing large result files, use MSDE (Microsoft SQL Desktop Engine). Don't install it from the Add-in folder on the LoadRunner 7.8 CD, which is obsolete SQL7. Download MSDE 2000 Release A which includes MSDE 2000 Service Pack 3a and MDAC 2.7 SP1a for use by Analysis on any Windows machine. Extract the file and share that folder. Open a command window to run a command such as: setup SAPWD="StrongPassword" INSTANCENAME="LR" SECURITYMODE=SQL DISABLENETWORKPROTOCOLS=0 /L*v path to log file Using Windows Explorer, share the Data folder. Then in Analysis Options > Database tab, use 8.3 names without spaces (indentified with DOS command DIR /X): Input the SAPWD password specified above. Logical Storage location: \\loadclient02\Data (the folder you shared) Physical Storage Location: C:\PROGRA~1\MICROS~1\MSSQL\Data (not C:\Program Files\Microsoft SQL Server\MSSQL\Data) Click "Test parameters". (This takes a few seconds) The Analysis Module (8,320K analysisu.exe) generates analysis graphs and reports using data from the .mdb database. The LoadRunner Results file results_name.lrr from each scenario run -- also called an Analysis document file -- is read by the Analysis program to display Percentile graphs. By default, the LRReport folder is created in the test analyst's local machine My Documents folder to store Analysis Session files. They can optionally be formated in HTML. Their format are controlled by a .tem template file. Optionally, Mercury's Remote Performance Monitoring (RPM) MS-IIS/ASP web server for LoadRunner 7.8 can be installed on a Windows 2000 server ( but not on a Windows 2003 server) so that load test results to be viewed using a web browser. Not pictured is the LoadRunner Tuning Module (a separate $50,000 product).

LoadRunner的工作原理(第一部分)

Architecture Overview LoadRunner works by creating virtual users who take the place of real users operating client software, such as Internet Explorer sending requests using the HTTP protocol to IIS or Apache web servers. Requests from many virtual user clients are generated by "Load Generators" in order to create a load on various servers under test These load generator agents are started and stopped by Mercury's "Controller" program. The Controller controls load test runs based on "Scenarios" invoking compiled "Scripts" and associated "Run-time Settings". Scripts are crafted using Mercury's "Virtual user script Generator" (named "V U Gen"), It generates C-language script code to be executed by virtual users by capturing network traffic between Internet application clients and servers. With Java clients, VuGen captures calls by hooking within the client JVM. During runs, the status of each machine is monitored by the Controller. At the end of each run, the Controller combines its monitoring logs with logs obtained from load generators, and makes them available to the "Analysis" program, which can then create run result reports and graphs for Microsoft Word, Crystal Reports, or an HTML webpage browser. Each HTML report page generated by Analysis includes a link to results in a text file which Microsoft Excel can open to perform additional analysis. Errors during each run are stored in a database which can be read using Microsoft Access

Virtual Users (Vusers) Unlike a WinRunner workstation which emulates a single user's use of a client, LoadRunner can emulate thousands of Virtual Users. Load generators are controlled by VuGen scripts which issue non-GUI API calls using the same protocols as the client under test. But WinRunner GUI Vusers emulate keystrokes, mouse clicks, and other User Interface actions on the client being tested Only one GUI user can run from a machine unless LoadRunner Terminal Services Manager manages remote machines with Terminal Server Agent enabled and logged into a Terminal Services Client session. During run-time, threaded vusers share a common memory pool. So threading supports more Vusers per load generator. The Status of Vusers on all load generators start from "Running", then go to "Ready" after going through the init section of the script. Vusers are "Finished" in passed or failed end status. Vusers are automatically "Stopped" when the Load Generator is overloaded. No additional license is needed to monitor standard web (HTTP) servers (Apache, IIS, and Netscape). To use Web Services Monitors for SOAP and XML, a separate license is needed, and vUsers require the Web Services add-in installed with Feature Pack (FP1)

Product Versions Version 8.1 Feature Pack 4 patch installer LR81FP4P136.exe at 7,786,800 bytes, was signed on January 2, 2007 as file 8.1.4.0 (Build: 1735) is Recorder Version: 1290. Version 8.1 Feature Pack 4 installer LR81FP4.exe, at 194,644,720 bytes, was signed on December 15, 2006 as file version 8.1.4.0 (Build: 2249) is Recorder Version: 1289. This requires an upgrade to MS.NET 2.0 clients. Version 8.1 Feature Pack 3 installer LR81FP3.exe, at 116,601,240 bytes, was signed on June 18, 2006 as file version 8.1.3.0 (Build 2085). It installs (as an item on your Start > Program Files) Microsoft WSE (Web Services Enhancements) 2.0 SP3 to deploy security policies for sytems running .NET Framework 1.1. Version 8.1 became available October 2005. In VuGen it adds a "Workflow View", "Workflow Wizard", and a memory leak which is fixed with a patch downloadable since Dec. 2005. It renames the VuGen "Execution Log" the "Replay Log". Version 8.0 became available August 2004. It adds "Additional Attributes" to Runtime Settings. It also adds (for additional fee) diagnostics and tuning capabilities, allowing Transaction Breakdown to breakdown transaction times across different servers servicing various transaction layers (web server, Oracle 11i & Peoplesoft 8 app server, database) layers. It separates SQL time in execute, parse, and fetch times. Version 7.8 Feature Pack 1 added support for Windows XP. Version 7.8 became available September 2003. Version 6.5 available June 2000 offered new "TurboLoad" technology -- a completely new replay engine that runs thousands of vusers using a single operating system thread. Version 6.0 used a separate thread per user, which required almost 10 times more i/o and CPU cycles than 6.5.

Note: Links to documents that used to be here were removed after Mercury Interactive, Inc. lawyers demanded their removal. Page numbers in online pdf files are different (have more pages) than page numbers in the paper document of the same title.

Application Components' Requirements Loadrunner makes use of four executables with different system requirements Application Product Process Image Name V8.0 Img KB File Size - LRLauncherApp.exe 16,288 n/a Virtual User Generator VuGen.exe 12,436 2,334,769 Controller with On-Line Monitors wlrun.exe 13,076 5,681,215 Load Generator Agent magentproc.exe 3,236 magentservice.exe 65,536 mdrv.exe Analysis Analysisui.exe 13,132 6,058,496 Tuning Console protune.exe 3,403,833

Console programs perl5.8.0.exe Interpreter 20,535 regtlb.exe registers the batch automation type library 30,720 sed.exe 55,296 wdiff.exe Compares text files 197,632 Alex Arbitman's LR 7.8 Footprints.xls reports that to run Web requires __ per process and __ per thread.

Using Windows Remote Desktop Connection Remote Desktop Connection (part of the Terminal Services that comes with Winodows XP) is not as reliable with LoadRunner as Remote Administrator. To keep Windows Remote Desktop Connection sessions from timing out during a test, the Terminal Services on each machine should be configured as follows: Click Start, point to Programs (or Control Panel), Administrative Tools and choose Terminal Services Configuration. Open the Connections folder in tree by clicking it once. Right-click RDP-Tcp and select Properties. Click the Sessions tab. Make sure "Override user settings" is checked. Set Idle session limit to the maximum of 2 days instead of the default 2 hours. Click Apply. Click OK to confirm message "Configuration changes have been made to the system registry; however, the user session now active on the RDP-Tcp connection will not be changed." Make sure that when you do this you're not violating one of your corporation's security policies. Terminal Server only allows two simultaneous connections. To disconnect from a session, do not click "X" on the remote desktop window but click Start and Log Off.

Quality Web Systems: Performance, Security, and Usability (Addison-Wesley Professional; Aug. 2001) by Elfriede Dustin, Jeff Rashka, Douglas McDiarmid The Web Testing Handbook (S T Q E Pub, Jan. 2001) by Steven Splaine, Stefan P. Jaskiel, Alberto Savoia is a good overview introduction, but does not make you an expert.

Among Common problems installing LoadRunner: Windows 2003 & XP SP2 have a DEP (Data Execution Prevention) feature which prevents VuGen recording. Go to Control Panel, System -> Advanced tab, Performance section "Settings" button Data Execution Prevention tab and add the client program or choose "Turn on DEP for essential windows programs and services only." A reboot is required. LR Installation and Configuration Download [after required registration] the 10 day trial from here or here. I recommend that you put downloaded LoadRunner installation files and patches to a separate media such as a CD or USB drive. Then mark those files as read-only. Disable your anti-virus software (Symantec, McAfee, etc.) before invoking on installers. Virus Detection engines (such as Hauri versions since May 18) may find that program regtlb.exe (which registers/unregisters type libraries) to contain a "virus" they call "Backdoor.Win32.PoeBot.15872". Automatic repair by the virus remover will break those files. The LR box comes with two CD's and this installation manual. Separate installation manuals are available for the Controller and Analysis modules. The Windows CD autostarts to this initial screen for v7.8 and this initial screen for v8.0 You can install just a single component (such as VuGen) by (ironically) selecting "Full install" and then the "Custom" option to check the specific components to install. However, due to a strange bug with v8.0, before you do that, first install the Load Generator, then return to install "custom" components. The UNIX CD installs only the Load Generator (not the Controller or VuGen) on UNIX machines because the Controller and VuGen only run on Windows machines. Zero fill machine names to t001, ... t010, etc. The LR Controller sorts machines named t1, t2, ... t10 as t1, t10, t2. Location of Program Files The LoadRunner installation program adds files in Program Files, Windows folder, and the Windows Registry that are NOT removed during un-installation. If you get a "License violation" message, you need to get from Mercury support a one-day license key to install with. By default, different versions of LoadRunner are installed to different parts of your hard disk: LoadRunner 8.1 executable files are installed to file path "C:\Program Files\Mercury\LoadRunner\bin" LoadRunner 8.0 "stutters" when it installs to its default file path "C:\Program Files\Mercury Interactive\Mercury LoadRunner\bin" Note: Even though 8.0 uses a different folder, folders created by previous versions still need to be removed before its installation. LoadRunner 7.8 executable files are installed to file path "C:\Program Files\Mercury Interactive\LoadRunner\bin" When working with Java, instead of overridding these default installation folder to a path without spaces (such as C:\LR78) as recommended by KB article 11878, just use the equivalent DOS 8.3 file names: For LoadRunner 8.1: C:\PROGRA~\MERCUR~1\LoadRunner\lib For LoadRunner 8.0: C:\PROGRA~\MERCUR~1\MERCUR~1\lib To quickly get at this LoadRunner installation folder, create an environment variable named "LR81" so you can use a quick command such as cd %lr81% To get at this folder quickly, I created a batch file named "L.bat" in the cmd's default C:\ root folder containing this: cd \Program Files\Mercury\LoadRunner\bin pause I created a shortcut to this file on my desktop and dragged it over Windows so that I can click into that folder from anywhere. The pause command ensures that the command window does not disappear automatically. Alternately, from within a command window I can just type "L" and press Enter. Files in Windows Folders This path specified is stored under [ProductEnv] as M_ROOT in file wlrun.ini in the C:\WINNT (or C:\Windows) folder. The C:\WINNT (or C:\Windows) folder also holds the Maintenance Number (MPN) specified during installation, stored as a parameter named "LoadRunner_SerialNumber" (such as 1234-1234567890) in the mercury.ini file. Start Menu The LR installer adds links to the most used programs in > Programs > Mercury Interactive > LoadRunner However, some programs are installed which are not conveniently listed there, such as WDiff.exe v1.49 to compare differences between two ASCII text files. It has an accompanying help file Beginning with v7, LoadRunner prevents software piracy (much like Microsoft began doing with Windows XP) by requiring that a license key be provided within 10 days of installation. Mercury generates its license key based on a host ID generated on each computer. CPT12784.doc With v7.x, to generate Generate a HostID key (such as "XCCWJU-APBE-BYDS") click down Programs > Mercury LoadRunner > LoadRunner > License tab The key can be obtained before installation from program licidgenerator.exe and (after registration) its lm70.dll from the installation CD folder \lrunner\lm70.nt\bin or \lrunner\setup\lm70.nt\bin. Sample Apps / Protocols Running the samples install program populates folder C:\Program Files\Mercury Interactive\Mercury LoadRunner\ Copy the link location below into the "Program to record:" field: Protocol Server Client Program Parameter Notes Web WebTours\StartServer.bat http://localhost:1080/mercuryWebTours COM/DCOM (Operating System) samples\bin\frsui.exe Winsock sockfrs.exe samples\bin\flights.exe Winsock WinSockWeb ODBC (MS Access) samples\bin\flights.exe ODBC_Access CORBA samples\CorbaSamples\server.cmd & samples\CorbaSamples\server.bat samples\CorbaSamples\client.cmd & samples\Corbasamples\clientrecord.cmd Stuart Moncrieff's article on CORBA RMI samples\RMISamples\server.cmd & samples\RMISamples\server.bat samples\RMISamples\client.cmd & samples\RMISamples\clientrecord.cmd According to CPT11877.doc, JDK 1.5 users need to contact Mercury Support for a patch to each specific LoadRunner version (7.6, 7.8 FP1 or 8.0). Otherwise, you'll get these messages: Error: Failed to find javac.exe Java Compiler in Path and JDK installation folder in registry. [MsgId: MERR-22981] Error: Failed to compile the Actions.java file. Please add the \bin to the path and try again. [MsgId: MERR-22996] Warning: Extension java_int.dll reports error -1 on call to function ExtPerProcessInitialize [MsgId: MWAR-10485] Error: Thread Context: Call to service of the driver failed, reason - thread context wasn't initialized on this thread. [MsgId: MERR-10176] The Java sample apps use the "flight32lr" User Data Source with Microsoft Access driver(*.mdb) in the USER DNS table in Data Sources(ODBC) of the VuGen's local machine. Additionally, the sample Java servers must be operational prior to starting the client. This is done with the "samples\RMISamples\server.cmd": set lrpath=C:\PROGRA~1\Java\jre1.5.0_02\bin;C:\PROGRA~1\MERCUR~1\MERCUR~1\classes set lrclasspath=C:\PROGRA~1\MERCUR~1\MERCUR~1\classes;C:\PROGRA~1\MERCUR~1\MERCUR~1\classes\srv;C:\PROGRA~1\Java\jre1.5.0_02\lib\rt.jar set flightRmi=%~dp0;%~dp0RmiSamples.zip set classpath=%lrclasspath%;%flightRmi%;C:\PROGRA~1\Java\lib\rt.jar;.;%classpath% set path=%lrpath%;.;%path% cd %~dp0 start java -Djava.security.policy="%~dp0RmiFlights.policy" RmiFlights.Server Note the location of loadrunner class files I added to the default sample. They are pre-pended to the existing classpath. Note that there are no spaces in the file path. The Zip file is equivalent to a JAR file in Unix systems. Do not delete the black command window because the Java server runs within it. CORBA and RMI Java clients are invoked with a command for Windows to start the java.exe program. This "samples\RMISamples\client.cmd" file contains: set lrpath=C:\PROGRA~1\Java\jdk1.5.0_02\bin;C:\PROGRA~1\MERCUR~1\MERCUR~1\classes set lrclasspath=C:\PROGRA~1\MERCUR~1\MERCUR~1\classes;C:\PROGRA~1\MERCUR~1\MERCUR~1\classes\srv;C:\PROGRA~1\Java\jdk1.5.0_02\lib\rt.jar set flightRmi=%~dp0;%~dp0RmiSamples.zip set classpath=%lrclasspath%;%flightRmi%;C:\PROGRA~1\Java\jdk1.5.0_02\lib\rt.jar;.;%classpath% set path=%lrpath%;.;%path% cd %~dp0 start java RmiFlights.main Note that the RmiFlights.main class file name is passed into java for it to load. When recording Java with VuGen, a different command — such as the sample clientRecord.cmd — needs to be invoked because VuGen needs to be invoked within the JVM sandbox: set flightRmi=%~dp0;%~dp0RmiSamples.zip set classpath=%flightRmi%;%classpath% cd %~dp0 start InvokeVugen.exe The location of the JDK needs to be specified in the Windows PATH environment variable PATH to avoid this message: Error: Failed to find javac.exe Java Compiler in Path and JDK installation folder in registry. [MsgId: MERR-22981] VuGen "Java Vusers" can only operate as Single Vuser mode (not multi-vuser). Instead of web "Start recording", Java VuGen scripts invoke Java functions within the Actions section. "vuser_init" and "vuser_end" actions are not relevant within Java VuScripts. Internally, the cjhook.ini file specifies which Java classes can hook in its [EXC_SYSTEM_CL] section. Java classes specified in the [SYSTEM_CL] section are not hooked. The user.hooks file in LR \bin folder is a general format and cannot be used as-in. It needs to be copied. Uninstall To uninstall LoadRunner, you must be logged in with the same Windows userID as was used during original installation! If you use a different userid, the uninstall will delete only the dat folder which contains the "miuninst" file. Unlike Microsoft Office applications, Mercury has not programmed invididual components to be selectively uninstalled on its own.