New LoadRunner Web (GUI level ) Vuser
There’s a saying in software circles that “writing the first 90 percent of a computer program takes 90 percent of the time… The remaining ten percent also takes 90 percent of the time.” A year ago, Mercury started telling people about their new GUI level virtual users for the web. Their promise was an impressive one – no more correlation. Anyone who has scripted for the web knows that correlating a web script can be either incredibly easy or painfully difficult if, for example, the web application constructs HTTP POSTs with an unholy mess of JavaScript. Mercury was promising to make this unnecessary by creating a playback engine that understood what the web page was doing just as well as your web brower, allowing you to create scripts that were all about clicking on buttons and links in a browser rather than sending HTTP requests to the web server.
Presumably, getting the remaining ten percent of this functionality working perfectly before the release of LoadRunner 8.1 was too difficult, so the software was shipped with this Vuser type disabled. The good news is that if you have a copy of LoadRunner (or Performance Center) 8.1, you can enable this vuser type yourself and have a play before it is officially released.
To enable this functionality do the following…
- Open the \dat\protocols\webjs.lrp file under your LoadRunner or Vugen installation directory.
- It is in standard Windows ini format. Find the [Protocol] section and change the line that says “Hidden=1″ to “Hidden=0″ .
- Now open Vugen and create a new script. You will see that there is a new option to create a Web (GUI level) Virtual User
Rumour has it that the GUI level web vusers will be officially released by Mercury in 4-6 weeks with the release of service pack 2 for LoadRunner and Performance Center. This will mean that it will be officially supported by Mercury.
I do not normally recommend that users jump into brand new technology, but this vuser type offers such a huge advantage over regular HTML and URL-mode virtual users (not to mention every other web load testing tool from all other companies), that it is worth spending an afternoon seeing if it works with your application. If it doesn’t, you’ve lost an afternoon; if it does, you’ve saved weeks of your time.
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
March 13th, 2006 at 2:27 pm
Some follow-up points that didn’t make it into the above post.
* This new vuser type is not to be confused with the old GUI Vusers, which were based on WinRunner and a huge pain in the butt to work with.
* Sean Wales notes in the Mercury Support forum that “Mercury has been promising this feature for some time. 2 years ago at the User Group Conference they were referring to it as Athena version.”
* It is unclear whether this will need to be purchased as a separate vuser type, or whether a license for web vusers will allow it to be used (you would presume that this is the case).
* No more having to work with massive .NET ViewStates!!
March 13th, 2006 at 2:47 pm
I have spent some time playing with this vuser type and I am now using it for a real project. I will let you know if I have any problems.
As a test of this new vuser type, I decided to try it with the most difficult web-based application I could find – Zimbra, an amazing rich AJAX-based web mail client. It was unsuccessful in recording everything that it should have. For anything AJAX, I am still recommending URL mode and a lot of hard work.
March 13th, 2006 at 9:20 pm
Quite interesting…I have just enabled it, however ‘No correlation’ is just unbelievable let’s see
March 14th, 2006 at 12:20 am
Very glad to have found your blog! I’m also a performance tester.
Chris
March 14th, 2006 at 3:59 am
Thanks Stuart, please keep us posted on how well it’s working!
Chris
June 21st, 2006 at 8:03 pm
i recorded the web application using above method but i am not able to see the script.
-Rajesh
June 30th, 2006 at 7:05 pm
I have tried this suite. The functions are getting recorded but functions are not recognizing the tags and elements in replay. Is there any more setting to be regulated some where
October 5th, 2006 at 4:56 am
I’ve used the “web click & script” protocol for an application that was a correlation nightmare and it was great; however, the footprint of the click and script vusers are significantly larger than the web protocol vusers, so be advised and have the hardware in place for test execution. I had several load generators that crashed because the CPU utilization was maxed during rampup.
June 8th, 2007 at 11:34 am
I like the idea of Click & Script.
However, I’ve had numerous problems with Click & Script. I was a member of the Beta test group before it was officially released. At that time it was called the “Web GUI” protocol. In the past couple years, we have wasted many months trying to get Click & Script to work. We have found numerous bugs in the protocol.
I have come to the conclusion that when it works, it works great; but if it fails, it should be abandoned immediately. Mercury has informed me that Click & Script is being completely rewritten for version 9.something and advised that the HTTP protocol should be used in most situations.
I am looking forward to the fix.
Ben Simo
http://QualityFrog.com
June 15th, 2007 at 6:48 am
I agree to what Ben Simo says, This protocol is good but it requires the application and mercury themselves areee that this will be slower when compared to HTTP protocols.
I am also facing few problems with this protocol,
1- Mercury says that this protocol will handle client side scripts, but for me it fails in some places.
2- Fails to record on ActiveX controls.
Is there any workaround for this? if so pls let me know my mail id is joseph.varghese78@gmail.com.
Thanks, Joe
September 6th, 2007 at 3:13 pm
I have tried this recently and found that it is unable to record the menu options.if anyone has found a solution,do post it soon.
October 15th, 2007 at 7:55 pm
Hi guys,
I have morethan 4 yrs of exp in testng industry. I have work experience on all famous tools like QTP,WinRunner etc.. Presetnly I have to work on LoadRunner and I am new to loadrunner.
Please send me any study material, notes, scripts, or any stuff related to LoadRunner.
I am looking forward for your reply.
Greatly appreciated your efforts,
Regards,
Ravi.
October 15th, 2007 at 8:00 pm
Hi guys,
I have morethan 4 yrs of exp in testng industry. I have work experience on all famous tools like QTP,WinRunner etc.. Presetnly I have to work on LoadRunner and I am new to loadrunner.
Please send me any study material, notes, scripts, or any stuff related to LoadRunner.
I am looking forward for your reply.
Greatly appreciated your efforts,
Regards,
Ravi.
ivravi@yahoo.com
January 14th, 2008 at 8:44 pm
Hello:
I am working with load runner for quite some time and have worked on few famous protocols.
I want to know if scripts created in click and script protocol are good enough for load testing.
Please advice! Your thoughts are appreciated.
Thanks
M R Shafiquddin Ahmed
January 17th, 2008 at 4:06 pm
Hi,
Please suggest me if we can use Click and Script protocol for load test,
Thanks,
Parveen Banu Shaik
January 25th, 2008 at 7:33 pm
This works like a piece of cake with the application we are testing, a highly wild untamable application that requires lot of correlation running on websphere :) The only downside is the high resource requirements of the loadgenerator machines. I have to say this though. It takes away a lot of flexibility that you would normally have if we stick on to HTTP/HTML protocol.
I am not trying to review the new protocol. Neither I am qualified to do so. Here are my observations.
Pros:
1. Script generated is clean and highly readable
2. Avoids the need of correlation 90% of the times.
3. Low turnaround times during scripting. ~5x more efficient.
Cons:
1. Do not have sufficient control over the content that we would download during the tests. There are no EXTRARES statememts whatsoever with C&S.
2. Poorly written javascript in the pages can some times play havoc with your script.
NOTE: If you are familiar with regex it is a pleasing experience working with C&S.
April 5th, 2008 at 5:30 am
how do we handle the dynamic hard coded values in web click and script?
can someone please reply to me on my email address below.
thanks
amer_ilyas_00@yahoo.com
April 22nd, 2008 at 7:28 am
Other caveats with C&S
1: has trouble with some AJAX
2: almost always needs to run as process, not thread, if you run it as thread and go above 30 or so Vusers, the useage of MMDRV spikes to as close to 100% as it can get.
September 18th, 2008 at 1:00 am
Only problem I face is thet this is slower, and some time does not redord on popup windows… I contacted HP and they gave a stange answer They dont support webclick and script offically now and will do it from version 9 and above.. I dont know what the hec is happening. Mercury released this long back…
December 11th, 2008 at 2:49 am
Hi,
My company had a license of 250 vuser for LoadRunner. How could I run load test for more than 250 license. Is there any way?
January 14th, 2009 at 11:32 am
Hi,
i am working on 8.1 version of LR.
i have 36 scripts recorded (209 vusers) in Http/html and 1 script is recorded in click &Script (6 Vusers).
i am trying to run all the 37 scripts in controller but for C&S only one vuser is running and other 5 get failed in first iteration.
has any one idea about this kind of situation.
1. whether both protocol works together?
2. and why 5 vusers are failing?
waiting for any critical input
thanks in advance
Nesh