When to Re-Script vs not to (431 Views)
Occasional Advisor
Posts: 14
Registered: ‎10-24-2008
Message 1 of 3 (431 Views)

When to Re-Script vs not to

Hi - I'm looking for some understanding of some best practices on when to re-script vs when not to. 


We have a HTTP/HTML script on a web application.  The project team made some code changes within their application that didn't affect the scripts behavior in anyway. 


When doing some monitoring under dyna-trace we still some aspx calls that adding 2 secs to our response time from our old scripts.  Even though the scripts are not showing any failures in them this aspx call are being generated and effecting our times.


Should a re-script be done because of this?

HP Expert
Posts: 573
Registered: ‎05-24-2012
Message 2 of 3 (420 Views)

Re: When to Re-Script vs not to

Hi Hawesch,


My opinion is that if there is a code change in the application it is good idea to record the script again and check if there will be other differences in the new script apart from the dynamic values.

Comparing the scripts you will be able to decide if you should continue working with the new script or not.


Kind regards,

HP Support
If you haven’t tried it yet, come and join us in our entitled forums at Support Customer Forums

If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution and give Kudos to the author for their assistance.
Occasional Visitor
Posts: 1
Registered: ‎07-28-2014
Message 3 of 3 (290 Views)

Re: When to Re-Script vs not to

Hi - to add on...


It is up to you when to make this decision.  Here is my opinion..


Granted it can be difficult to parameterize and alter the recorded script - so the effort to record a new script is weighed carefully against making manual edits.


First - We keep the scripts in a version control system.  This allows you to compare a recent recording to the last saved one.   When development triggers us that something "big" has changed - the team will record the scenario again and compare to the previous version.  This helps us understand the scope of the differences.


If the script can be updated/corrected with a simple cut/paste - then we take that path.    If however the newly recorded script doesn't look anything like the previous - this tips the scale towards recording a new script.


I should also point out that we subdivide our web scripts into smaller functions so that it is easier to compare (and therefore reuse).  For example - there is a section of a web page that is common across all pages.  This HTML code was extracted and placed into a shared code library.  When recording we strip out the recorded HTML and replace it with a call to this library method.  This way if the common frame changes - we record it (fix it) once and recompile all of the scenarios... thus propogating the new HTML everywhere.


Have fun.

The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.