loadrunner Please post the resolution for below say there...

[Mallikharjuna Challa]

Please post the resolution for below say there is a URL called customersearch.com Here we need to search for a customer by giving customer number Step 01: Launching customersearch.com URL step 02 : click on customer tab step 03 : search customer step 04 : enter customer number (should display customer details) step 05 : logout But the question is if we click on customer tab, i couldn't see search customer option. Instead of this if i place the mouse pointer at customer tab, search customer option will flash ( without clicking customer tab ). can we record this type of action in VuGen scripting ?which protocol should i use and Is there anything needs to be change in settings ? I have recorded the script by moving the mouse pointer over customer tab and selected search customer optionand i tried to run the script, i am getting error like " search customer " not found. Error - Error -26190: Web element not found (Tag is "DIV", Text is "****") [MsgId: MERR-26190]

 

[Erik Pena]

My guess is you will get data sent over the wire after you enter some customer details. Everything in advance of that is irrelevant for your script and performance test.

 

[Erik Pena]

Also, I would think that HTTP/HTML would suffice to capture this. Try WireShark (or whatever it is called now) to verify. You could use TruClient but then you could also use a screwdriver in your ear looking for a nail.

 

[Santosh Utukuru]

I think you should use Fiddler to see the communication between client and server at this point, and proceed further .

 

[James Pulley]

Well, Let's take some architectural clues from your description "...say there is a URL called customersearch.com..." OK, "there is a URL called customerseach.com " What does this mean? Well, you have used the term URL, which stands for universal resource locator. This is the common addressing method for web sites. Web sites are based upon HTTP technology. So, it stands to reason that with an architecture underpinned by HTTP that you may be able to leverage any of the available client protocol types which are based upon this same technology. Some of the protocol options may be more efficient that others, or easier for your team to pick up and use successfully. But, in general, given your description which appears to have a strong CLIENT ARCHITECTURE basis in HTTP, I would suggest that this is a likely route to protocol success. Your "flashing" attribute of the [search customer] has nothing to do with server communication and depending upon your development method for your script you should not see anything in your code which corresponds to a flashing element. CLIENT ARCHITECTURE suggests that this flashing attribute is caused by JavaScript locally on the client. If you must have a model which executes the client side JavaScript, instead of just actuating the messages going back and forth to the server, and you are unable to integrate the JavaScript components or code that you need into a protocol layer script, then you should consider a development model with a more GUI focus. These may include: TruClient, GUI Virtual User (With QTP), Citrix or RDP. Each of the models has different tradeoffs in terms of resource cost per virtual user, development costs per virtual user and the infrastructure costs to run a given number of virtual users.

 

[Gaurav Shukla]

Dont bother about the client side stuff...thats not ur goal...capture the request for that transaction and you shud be fine