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…

  1. Open the \dat\protocols\webjs.lrp file under your LoadRunner or Vugen installation directory.
  2. It is in standard Windows ini format. Find the [Protocol] section and change the line that says “Hidden=1” to “Hidden=0” .
  3. 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

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.

 

Published On: March 13, 2006Tags: ,

27 Comments

  1. Stuart Moncrieff March 13, 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!!

  2. Stuart Moncrieff March 13, 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.

  3. Ashish Dave March 13, 2006 at 9:20 pm

    Quite interesting…I have just enabled it, however ‘No correlation’ is just unbelievable let’s see

  4. Chris Meisenzahl March 14, 2006 at 12:20 am

    Very glad to have found your blog! I’m also a performance tester.

    Chris

  5. Chris Meisenzahl March 14, 2006 at 3:59 am

    Thanks Stuart, please keep us posted on how well it’s working!

    Chris

  6. rajesh June 21, 2006 at 8:03 pm

    i recorded the web application using above method but i am not able to see the script.

    -Rajesh

  7. Srinivas June 30, 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

  8. Jeff Pickett October 5, 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.

  9. Ben Simo June 8, 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

  10. Joe June 15, 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

  11. Ajay September 6, 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.

  12. Ravi kumar October 15, 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.

  13. Ravi kumar October 15, 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

  14. M R Shafiquddin Ahmed January 14, 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

  15. Parveen Banu Shaik January 17, 2008 at 4:06 pm

    Hi,
    Please suggest me if we can use Click and Script protocol for load test,
    Thanks,
    Parveen Banu Shaik

  16. AJ January 25, 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.

  17. Amer April 5, 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

  18. Geoff April 22, 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.

  19. Joe September 18, 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…

  20. susant December 11, 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?

  21. Nesh January 14, 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

  22. Jason Shellman June 9, 2009 at 11:10 am

    I am currently working for a bunch of loser IT Indian monkeys who know absolutely nothing about what they are doing.

    ahhhhhhggggg

    Jason Shellman, Atlanta, GA

  23. Sasidhar November 14, 2009 at 7:56 pm

    Hi,

    Iam also facing the same problem as said above. Even if the web(click n script) vuser fails once because of some web_text_link or web_edit_field not found, then it is directly going to failed state instead of starting a new iteration.

    Plz suggest if any setting need to be enabled to start a new oteration.

    Regards,
    Sasidhar.

  24. Bhupendra Varshney May 12, 2010 at 4:58 pm

    Please check in your thread.

    It should be \dat\protocols\webui.lrp and NOT \dat\protocols\webjs.lrp

    Regards,
    Bhupendra

  25. Sayantani December 15, 2011 at 6:47 pm

    Hi

    My requirement is to test a website that redirects to another page when it is being accessed from Mobile device.
    I want to test only the mobile part.
    Whenever i am trying to record from browser, it is taking me to the PC-based site. So i changed the “user agent” in Firefox, made it as iPhone3, and recorded again.
    Now the script is recorded; but it does not have any explicit declararation of what user agent it is using. To play it back properly, i need the “Custom Browser” string for emulating iPhone.
    What is the string I should use?

    Thanks

  26. Achintya April 21, 2015 at 11:11 pm

    Hi,
    I’ve installed community edition of HP LoadRunner 12.0 Now when I’m trying to record a script with some transaction in a Website through Firefox, it’s not generating at all. Please help!!!

  27. Sandeep August 11, 2016 at 11:01 pm

    Hi,
    Can you send me some material/video tutorial on VuGen scripting to be done for SAP web portal application (NWBC client), it also contains webdynpro application stuff.
    Appreciate if you can help.
    My email id is : sandeep.mhaske@kpit.com

Comments are closed.