Re: Unwanted redirection happening in response of web_submit_data and web_url

[Mahesh Kumar Somaraju]

Hi Priyanka,

A few questions..

1. When did you record the script? How long you have been using it after recording??
2. Are there any application deployments done after recording??
3. Can you record the application now and see if these unwanted resources are being requested??

I suspect there has been a change in application since the script is recorded.


Cheers,
Mahesh

On Fri, Feb 22, 2013 at 7:22 AM, Priyanka <priya9...@gmail.com> wrote:

Hi All,

 

I am facing an issue during the replay of a script.During replay in response of web_submit_data and some web_url some invalid redirections are happening to some css ,jsp and jss files URL which is causing HTTP 404  since these redirects URL's are not correct.

 

In tree view of the replay it is clearly visible that only for replay these redirections are happening but for record tree view these redirection are not present.

The URL of these unwanted redirections is not at all related to content of the response.

 

Could you all suggest something to remove these unwanted redirections.

 

Thanks in Advance

 

Priyanka

 

--
You received this message because you are subscribed to the Google Groups "LoadRunner" group.
To unsubscribe from this group and stop receiving emails from it, send an email to LR-LoadRunne...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[James Pulley]

Ask yourself, why would your website be presenting back 302, 303 or 307 responses which would cause a redirect to occur?   VUGEN Scripts do not define redirects, but they will honor them when returned by the server.

 

My hypothesis is that you have dynamic data on request lines which are no longer valid after the session has terminated.   In your environment these dynamic elements are being handled as server redirects.   Cnsider recording twice and examining the differences between the recordings to identify the dynamic elements which need to be addressed before a proper replay can take place.

 

James Pulley

http://www.loadrunnerbythehour.com/PricingMatrix

Honest, Effective, Onshore USA script development beginning at 19.95 per hour USD

[Priyanka Tiwari]

Hi ,

 

The scripts were recorded some one year back and many deployments in applications were done after the script preparation.We use the same scripts since these are a part of a regression suite which we run in every release.

 

I recorded the same flow again now but I am getting the same HTTP 404 during replay but the same is not present during the recording.

 

Could you please suggest.

[James Pulley]

Given the number of generations between when they were built and today you should be thankful that the scripts lasted so long.   Your default position appears to be that these should just run forever.   This needs to be re-aligned.    A better potions would be that with any new release you should expect them to fail (unless this is a static web services interface) because of changes and updates made by developers.  If it does run (and it doesn’t check for expected content on every page return) then be very suspicious.  It it does run and does so successfully you should be elated.

 

It appears that its useful life has run its course and these need to be rebuilt.

 

I am reminded of something similar shared with me recently.   A company had hired a firm to develop VUGEN scripts for BAC monitoring several years ago.   The company was warned that the firm represented people of questionable quality but management at the company dictated that the firm be used because of an attractive per hour rate.   Well, the same management became very suspicious when the BAC availability reports showed great uptime and response time for applications which had been offline for six months or more.   It was only then that the management dismissed the firm for incompetence.

 

Until you have proven that it runs correctly assume otherwise.   Simply running an old script may report a bunch of smiling faces, unicorns and rainbows but the truth may be that the script is totally broken.

 

James Pulley

[Mahesh Kumar Somaraju]

It is obvious that you are scripts are obsolete as they were recorded long time back. It is either an issue with your correlation in script or the application bug causing these 404 errors.

Can you check the application to see if these 404 errors manually while navigating through browser??


Cheers,
Mahesh

[James Pulley]

“100 Scripts”   This is an unsually high number for load and performance.   If you are using this for functional testing, please consider QTP or Selenium which would be more appropriate.

 

Having noted the above, you could well be having 404’s in your web application but they are masked by the front end as an orphaned resource on a page that is not displayed.   This happens quite commonly, but it is very visible in LoadRunner.   Track the resource which is showing the 404 to the source on the page.   Affirm that the resource is actually on the server.   It may not be.

 

From: LR-Loa...@googlegroups.com [mailto:LR-Loa...@googlegroups.com] On Behalf Of Priyanka

Sent: Thursday, February 21, 2013 5:16 PM
To: LR-Loa...@googlegroups.com

Subject: Re: Unwanted redirection happening in response of web_submit_data and web_url

 

Hi All,

 

As I already mentioned in my second reply that same HTTP 404 is observed even while recrding the same flow again and replaying it.

So this issue is not because of the old scripts.Also all scripts are modified after each release for any chages added to the application.

 

Since recording 100 scripts for each release does not fit into the time line ,we do not record the same script same script again and again for each release.

We do follow a process of having mock runs, clean up of logs and data related clean ups after every release.

And I believe that it is very difficult to re-record new script in every month for regression suites which consists of a large number of scripts.

 

The same HTTP 404 are occuring for newly recorded script as well and same error situation is not replicated by manual hit.

 

Since it is only occuring through load runner script run and that too the URL's for which error occurs are not related to application.

 

I kindly request you all to provide some valuable suggestion.

[Ruslan Kholyavkin]

Like James mention before verify page you are hitting probably  some resource(s) of page  ( image or other items) maybe removed but page still  has reference to them  . you still need to do client side performance testing anyway to confirmed that you page has reasonable HTML size  ( if it is web application)  and you do not have missing call to images and other object which is 404  and all not post requests are cacheable  and  also you do not have much of redirects .if you using IE download HTTPWatch  free version go to youtube check how it is work if you using Firefox use FireBug  and do same -- run it and see if you getting 404 during single page load if you do ,you need to logged it  all this problem need to be fixed . If it is not the case  check your 404 error get URL and compare if  your HTTP Watch recoding ( does it  has call you get  from LR 404 URL if it does , does it have 404 on HTTPWatch )

Thanks,
Ruslan

[Mital Majmundar]

Hello Priyanka,

Check if you have some "extrares" in you web_submit_data.
If yes try deletin them and running the script again. That might be the cause of the failure.

[James Pulley]

Deleting your Extra Resources will not solve this issue.  Your page will still be parsed and your page loaded, including all of the resources referenced on the page.   Do not take my word for it.   Hook up a protocol analyzer and watch it for yourself.

[Mukul sharma]

Rightly said by James. If the scripts are recorded in HTML mode and non html components are downloaded similar issue will again come. Also in URL mode there would be individual URLs for the traffic and it will show the the URLs giving 404. Also you can use firebug to see if there are any 404 in the suspected flow. Or you can use Xenu tool tool to identify the 404 links throughout the site.

Regards, 

-Mukul.

--
Regards, 

-mukul

[thilak nadh]

I think..there may be problem in page identification.Use correct string in Web_reg_find for that specific page.